Don’t use code names for your products.

It is my sad duty to announce that the time has come for Devshop to bid farewell.
Devshop has operated for nearly 5 years. The company has had the wonderful support of many smart & talented people over the journey, including advisors, supporters, investors and fans who all believed there was a better way.
Timing is everything as they say, and without the ability to properly fund the company through its next stage of growth, the time has run out.
The Devshop service will continue operating until the end of April 2010, at which point it will be time to turn out the lights, sigh a little and close the door. If you have any data that you need to retrieve from the application before hand, please make sure to login and extract it.
In parting, I’ll leave you with 2 videos I recorded some time ago, in the early days. One was a commercial, which intended to capture the spirit of what I was trying to accomplish. The other is a lecture I gave which intended to share the thinking behind it all. Both, I believe, still ring true today.

“Developers in Pain”

The ideas behind Devshop:

I would be interested in putting the source up on GitHub as an open source project. If there’s someone out there who’s run an open source project before that would be interested in taking the reins and has a bit of a vision for what they’d like to do with the product, please feel free to email me: craig@devshop.com

I don’t usually forward along anything that smells-like-petition, but everyone in the Web development community should be aware of this. Microsoft has publicly confirmed that they are using a rendering engine (from MS-Word), dating back to before the year 2000, in their upcoming Outlook 2010 product. Have a look at the difference between how Outlook 2000 and 2010 will render a simple HTML newsletter in this article by Campaign Monitor:

The scariest part of the article is the position of the Outlook Product Manager:

Having multiple HTML engines could reduce performance, as well as create an inconsistency in terms of what type of content the user is able to create vs. consume.

Microsoft is using the Word rendering engine so emails composed in Outlook will look consistent when viewed by other Outlook users.

In other words, more walled garden thinking. The old Microsoft is back at it again. I mean, um, the whole world uses Outlook right? Cough.

MS claims they’re listening. Outlook 2010 is still in Beta for another year so there’s time to raise a little hell. See if we can smack some sense into them. This is a ridiculous step backwards.

There’s a Twitter campaign here:

www.fixoutlook.org

I’ve heard and read a lot more references to A/B testing lately. For those of you that don’t know, A/B testing is a process where you pit 2 designs against each other to see which works better. For example, you have 2 home page designs and you want to know which one converts more users, so you implement both, then have some random switcher that presents half the people with Version A and the other half with Version B – then you evaluate.

Like most things in life, whether it’s “good” or “bad” depends on context. So…

Here’s some context.

I’ve heard of people deciding to split A/B test little tweaks to their designs, that someone has a hunch will make a positive difference, but where there’s been some internal debate about it, or the champion hasn’t been able to articulate their hunch and therefore hasn’t swayed their colleagues. In these cases, someone often exclaims, “Let’s A/B test it!” Well, ok. The good thing about A/B testing is that it’s democratic. May the most popular design win (as judged by end-users successfully completing their tasks with the design). Hard to argue with that, right?

In other situations, I’ve heard teams decide to A/B test whole modules or whole features of applications. This tends to come from more agile oriented shops who are often more reactive about design than pro-active. I say this not as a jab, but as an observation. Less decisions up front, more “figure it out as we go.” This is a complimentary style to A/B testing, in a Darwinian sort of way. Trouble with using A/B testing on larger chunks of designs, is there’s a point where it starts costing way too much. This is a similar optimization problem to How much unit testing is too much unit testing? To A/B test something implies you have both to test, PLUS you have some mechanism to randomly shuffle the 2 across users. So, you eat the cost of developing both and some switching mechanism so you can do your empirical observation.

The fundamental danger of relying too much on unit testing as opposed to the alternative (which is a dictator-like designer calling the shots based on their own skills and experience of the space), is that a good designer should have accumulated enough flight time to have internalized the knowledge that A/B testing often delivers, at least at a higher level. So, if used at a macro level (larger chunks of the design), it can be very costly. Also, the larger a chunk you’re testing, the more moving parts there are, the more likely that other influencing factors will creep in to the test and blur the findings.

That said, here’s my take. A/B testing is best used to optimize a design that was put together by a good designer. It’s about taking an existing design and either uncovering design errors, or optimizing it to squeeze every last drop of effect out of it (i.e. what happens if we move the purchase button closer to the screen shot tour?). It’s for things like testing wording, layouts, aesthetics, proximity, etc. It’s by no means a substitute for a strong designer making an executive decision.

The other major use for it I see is to de-risk a cut-over from an existing design to a re-think. If you’re worried about the switching drama (“Gah! Where’d my favorite button go?!!!”), it’s an alternative to having a separate Beta program where a sub-set of your users get to react to it first before you force it down everyone’s throats.

For the alternative version of this post, click here. Just kidding

Wow. This article on the measurable benefits of aesthetics in user interface design is brilliant.

We’ve all participated in debates about form follows function and vice versa. I have never heard such a well reasoned and scientific (i.e. observed, measurable & repeatable) perspective on the subject before.

This is a must-read for anyone embarking on a new UI design or a re-design of an existing product. Heck, those thinking about branding should read it too (after all, UI design and branding are as joined at the hip as form and function).

Here’s a snippet to wet your appetite:

By making intentional, conscious decisions about the personality of your product, you can shape positive or negative responses. Take a look at Sony and how they applied this knowledge in the Sony AIBO. Let’s consider why they made this robot resemble a puppy.

Here, you have a robotic device that isn’t perfect. It won’t understand most of what you say. It may or may not follow the commands it does understand. And it doesn’t really do all that much.

If this robot was an adult butler that responded to only half our requests and frequently did something other than what we asked, we’d consider it broken and useless. But as a puppy, we find its behaviors “cute.” Puppies aren’t known for following directions. And when the robot puppy does succeed, we are delighted. “Look, it rolled over!” What a great way to enter the robotics market.

Here’s the link again:

In Defense of Eye Candy