Wednesday, May 10, 2006


You're writing a program.  It could be a library for your own personal use, or it could be a webapp for your friends, or it could be your paycheque for the month to do this kinda thing.  Stop for a second and think about how much effort it takes to go from a zipfile on the disk (or however you're delivering it) to using it normally, and how much effort it takes to use it for its intended purpose.

Is it effortless?'s not, is it?

That's a bad sign.

The reason it's a bad sign is that as soon as your program requires *any* effort to use, you reduce its reach.  Every step that can be messed up will be messed up by some group of people -- and most of them will throw up their hands and quit when they do mess it up.  The people who don't quit when the going gets tough are either forced by circumstance to use your program, or take some kind of perverse joy in the self-flagellation that's usually involved in installing and using non-effortless software.  Don't give up hope, though.  There are a few ways to Effortless from where you are.

Check your interfaces
Think HARD about your user interface.  (This means you too, library writers.)  What clutter can you remove so that there's less setup, less configuration, less data entry, fewer clicks?  How could you change names, or shift workflow, so that things that are Bad are harder to do?  How many knobs and frobs and bells and whistles are there that you could really remove, or at least give a default for and hide the customization and the choice from people who don't care?

Check your installation
You'll have to spend a disproportionate amount of time on the initial setup stuff, on making installation a breeze.  Your average user will spend a lot more time using your program than they will getting it working in the first place, but when they're installing it that's all they've seen of your baby and if you don't get that part right, they'll never see the rest.  You don't get a second chance to make a first impression.

Check your documentation
Nobody's going to read it, yeah, we all know.  That's not why you're checking it, though.  You're checking it because everything you felt the need to document, you thought was tricky enough that it needed explaining.  Is there something you could change about the interfaces to reduce the need for the documentation?  ...Since nobody's going to be reading it, after all.  Maybe you could put (pretty and unobtrusive, please!) tooltips on things so that people don't have to go looking for documentation. 

Check your ego
Some people say the best interface is no interface at all.  When something Just Happens and the user doesn't really know why, but they're happy it did -- that's a happy user, that's a user you're not getting in the way of, that's a masterfully Effortless program.  But all that means that the bulk of your work is going to go unnoticed by most of your users, most of the time.  And that's OK.  In fact, that's great.  You can do it -- but that means that you have to stay out of the user's way, even if what you're doing is Really Cool (tm) under the hood.

[Editor's Note:  This started out as a response to Mr Governor's article on smalltalk.  My point there was that while effortlessness is indeed bourne out of practice, the amount of practice necessary can be influenced by the program's design.  To extend the butcher analogy, even a master butcher needs more practice with a tricky, soft, easy-to-dull knife than a comfortable, hardened-steel one.]


Post a Comment

<< Home