All actions in your application should require 1 mouse click, AT MOST!

The less mouse clicks the better right? If you're even vaguely aware of usability you are probably aware of this notion, for some it seems to be the holy grail of usability, the be all and end all. You show them a UI change, they're more than happy to help you evaluate it, using their super human knowledge of this single usability metric and excellent counting ability they can give you a quick and useless evaluation of your UI.

The problem with this? Following this rule to it's end, as you apply it to more and more of your UI the mouse clicks required for every action would tend towards one. There's a nice example of an application apparently built with this constraint here http://stackoverflow.com/questions/1486420/how-can-i-enhance-the-aesthetics-of-an-ugly-windows-form-packed-with-too-many-ne

In truth, when people bring this metric up they don't really mean they want everything to only be one click away, just whatever it was they were recently doing which now requires one more mouse click than it did before. Inevitably as you evolve a product and add functionality you eventually end up with too much functionality to fit in the space available. At some point you need to simplify your interface, simple to say, hard to do. Sometimes they can be right about the number of clicks, the important thing is to look at the key tasks anyone using your software is trying to achieve. Those key tasks need to be as frictionless as possible, making anything else so simple to do can lead to clutter in your interface. Hide it away and you may well be doing people a favour. As your product evolves possibly somethings which you allowed to be simple early on will need to take a back seat to other functionality.

This slide share presentation is the best example I've seen of someone going beyond a glib 'Keep It Simple Stupid' attitude or unhelpfully telling you that your application should do next to nothing and that any customers who want more can piss off.
http://www.slideshare.net/cxpartners/secrets-of-simplicity

(I'd also say it's also a good example of how to do a really good presentation )


Sometimes you'll need to hide things away from view to keep the core of your application simple to use, sometimes you'll need to add an extra mouse click between a user and some piece of functionality. I'm not going to try and summarise the presentation linked above, I couldn't do it justice and it's actually really really interesting to watch so stop paying attention to me and head over there.

David Heineimeier Hansson podcast on Entrepreneurial Thought Leaders

Really good podcast in the Entrepreneurial Thought Leaders series from Stanford here:
http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2334

It's David Heineimeier Hansson of 37 signals and Ruby on Rails fame, always good for an opinion and I think part of a company a lot of people would like to imitate one day, as in the best kind of flattery type of imitation.

Top bits for me:

Don't try to compete with Microsoft etc. on programming effort, marketting spend etc, they'll crush you. Especially on the marketting front this carrys some weight with me, I think some small companies try to imitat the big boys in this arena too much and don't make enough of what they have the big boys don't.

Don't take VC finding unless you actually need to build a factory in India or something. Having sat in a meeting to discuss how we'd spend a million dollars if we got it I know some companies are attracted to the VC capital without neccesarily thinking through what it is they actually need it for. Also, the risk of wasting your time on something which isn't going to be profitable is increased, fail fast and fail often as they say.

All his stuff about building a scalable company, not as in one which can scale to tonnes of employees, but one which scales the cash coming in without scaling up the employee numbers. Very nice idea to try and focus on, keeping this in mind is I guess how you keep a lean startup lean as it ages and evolves.

Exceptional? No.

Spotted this the other day whilst making a small change to the code at work. It was strange, something felt very wrong but I couldn't quite put it into words. I see this sort of stuff occasionally that just feels wrong but I can't always say exactly what it is. As luck would have it a coworker wandered in at that moment so we looked at it together, he declared if he;d written code like that he should be shot. Here it is. It's an accessor method on a class representing a row in a db table.

public boolean getColumnBlah() {

    try {
        return columnBlah.getValue();
    } catch (NullPointerException ex) {
        return false;
    }
}

It was the use of a NPE to catch an empty value, if the default was meant to be false, make it false by default surely and assume it won't be null in this method. Also, where did the NPE come from, obviously some lazy dev assumed it was due to a null value on that column, and not as was possible from some place else in the getValue() call which was entirely possible. If it was you'd be silently failing at something else and detecting the failure would be far less likely.

Exceptions should indicate something exceptional happened not something predicatable and expected. Special bonus points awarded this time as Mr Cowrker joining me in looking at this turned out after some cvs detective work to be responsible. Some time ago admitedly so we decided he'd not leave the company with his head hung low. He did also point out that paying the company back for the 2 years emplyment after creating the sinful code and rolling back all his commits for the last 2 years would be pretty hard work as well.