Uncommon Sense (for Software)

Podcast #1: Coloring Outside the Lines with WordPress, Thesis, Firebug, HTML & CSS.

Just tried my first podcast.

Scary... MS to use a pre-yr2000 Rendering Engine for Outlook 2010, and break the Web... again...

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

When A/B Testing is a) Good and b) Bad.

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 ;)

A Scientific Perspective on Form vs. Function

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

April Fools

I wonder how many startups will announce large VC rounds tomorrow, April 1st? I predict reading about that at least 4 times tomorrow, just in the blogs I follow ;).

Paying Down Technical Debt

Excellent post on paying down technical debt. This is an excellent analogy for something many of us have known in our guts for some time, but have trouble articulating so clearly. I can think of several occasions where I've had to explain this concept to a big boss. I'll keep this article handy now for explanation.

One more analogy I'd add: when you find yourself in serious need of a re-write, that's the equivalent of technical bankruptcy.

Here Comes the Golden Age of Web Development

Wow. I was just reading up on what's packed in to the new Safari Beta (v4).

Not only does it have the usual "it's now the fastest browser" stuff, because they all leap frog each other with speed anyway, but some impressive "net new" capabilities:

1. Dramatic UI improvements like cover flow and something kind of Expose-like for browsing your top sites and history


2. CSS effects and animation - I wonder what this will do to some of the Javascript libraries out there? Allow them to trim this stuff out? Only once the other browsers catch up of course...


3. Live fonts - so you can specify the fonts for a page and if the machine doesn't have them installed, it'll go get them automatically. No more being limited to the handful of "web-safe" fonts.


4. And for the developer: a SQL browser for the local offline database, that actually lets you run queries against it through the UI... and some pretty advanced performance optimization tools & debuggers!

What really excites me, because I'm not personally surprised at what Apple has come up with (I have a lot of faith in their ability to raise the bar) is that it's not just Safari on Macs that will reap the benefits of this next wave of enhancements. It's the iPhone, Safari on Windows (which will likely receive a boost in adoption as they are going with native Windows chrome now to make the Windows users feel more at home) and Google's Chrome, which is coming on strong and is based on the same rendering engine as Safari.

I feel like it really is the golden age of Web development. The browser really has become a professional run-time environment. Finally!

Investment

In the last 4 months, I've had conversations with 5 different US-based VC's who've approached Devshop about growth capital. It's wonderful to know that Devshop is popping up on people's radars, particularly among large VC firms. Some of this is due to the Red Herring press this past Fall.

With each of these conversations, it was clear that it's too early in the company life cycle to be entertaining these kinds of deals. They typically put in amounts in the $10 million range, which at this point would swallow up the company a couple times over.

That said, I am starting a new investment round. We've worked with local Angel investors in the past and it has worked well. The company has been built so far with a mixture of bootstrapping and Angel investment.

Devshop has been operating since Fall 2005, though it was in R&D mode until Spring 2007. For the last year and a bit, we've been essentially test marketing the Devshop product and the indicators are good. We've received a lot of feedback from users about where to go next. It's time to ramp up a little and pick up the pace.

Ideally we'd like to raise $500k to $1 million. This could be done with one institution, or a syndicate of individuals and/or institutions. Interested parties can contact me directly: craig (at) devshop.com.