Making User Tools a Delight, Not a Pain.

The fateful day that the snow arrived. It's white outside, and the forecast sounds pretty relentless at providing us with a constant replacement for anything that melts during the near zeroC temperatures. I'll have to find some time to go do some shovelling. And it's the heavy stuff too, at this temperature, and with drizzle mixed into the rain. The sound of the obsessive guy's snowblower is rumbling outside. This is the guy that mows his lawn and his neighbours lawn every day during the summer. In winter, the slightest dusting of snow means he's blowing as well. He's a one-man green-house gas king. Still, it's not helping with shortening the winter for us at all.

Yesterday on my project I started into a next phase. Planning the evolution of my tools to make them more functional, now that I've got a basic proof of concept in place. I'm employing a technique that works very well for application design in the past, so I'll share it.

Assuming you are an experienced user of applications of the type you are designing, you have expectations about how such a tool will work. Thus, to help the user discover that the tool responds as he would expect, a good approach is to think of the task you want to acheive - the end goal you are shooting for- and then imagine opening and using a finished tool to accomplish that. Write out each step, ignoring whether its possible or easy to program it or not, until you've described a full funciton.

That's the tough part - and many programmers are too close to their craft to pull it off successfully. You have to forget what you know ('everyone knows that file modes are set with control-alt-F9') and concentrate on making something that is as easy as possible for a non-programmer, intelligent, but novice user. Later, one can consider expert modes and such things, but concentrate first on the learning curve, and getting the task done effectively.

The next stage is to move those walk through steps into a table, and create another column for resources - these are UI resources. What things will be needed for what you
described. Mode menu entries, text entry areas, file open or file save capabilities, timer displays etc.

Make another pass through after that, to indicate how often each of those elements will be used. Is it a setting tweaked at the first use, and retained forever, rarely adjusted by the user again? Is it a button that will get clicked every few minutes. This will guide placement as to whether something can be in a pull-down menu or should be front and centre.

A good tip here is to think also about anything that is dangerous. Is there a delete-everything button mentioned? You'll want to remember to not place that beside the quick-save button. That's a rule violated by many UI's - yes I'm talking to you microsoft with your delete email button beside the send email button. "Yikes, what was I thinking I can't send that email to bob" *click* "Oh crap!"

Following that step, then create another column in which you can look over the previous column's elements and group things together into sensible places. IF you have 3 or 4 file configuration widgets needed, those might fit well into a "file config" menu, or a config menu under file, or into a configuration panel.

Lots of erasing and rejigging is useful there, and finally you have a rough idea. Then take a pencil and paper and sketch out a rough view, and imagine yourself following the steps laid out earlier. Some adjustments are likely.

Switch back to the programmer mode, and think about how you'd code it now. Are there some impossibilities? Sometimes a minor element might take 80% of the effort, so you have to rationalize the usefulness - but don't compromise on quality if you can help it. An elegant, intuitive user interface is a beautiful think. Nothing encourages a user more than guessing where a feature might live, and finding it there exactly as expected.

Some adjustments might be possible that both preserve intent and make programming easier, but be prepared to work a bit harder to preserve the user experience.

Anyway, that's what I'm into just now - and there's a whole lot of work ahead of me.

Researchinator returns to crafting a UI plan...