What users want (3)

The ideal user application structure was known and understood by the developers of both Pick and the relational database in the late sixties

Aero, Aqua, Looking Glass, Glassfish; compelling stuff, right? Not for the typical business users - Want to know the truth? they don't care - as long as it works, doesn't feel slow, doesn't get in their faces, and doesn't force them to unlearn what they already know only to make them learn another way of doing what they see as the same thing, they just don't care.

Want to frustrate your typical clerical or shop floor worker? move the application start-up from the shutdown menu to an icon or from an icon to a menu. Want to make things even worse? make him wait while you load a bit of the screen from one server, transfer control to another, load some more - and then crank in some AJAX style magic to bung together a custom display for his PC - one that's exactly like all the other ones accessing the application.

What users want from software is easy: it's all defined by negatives: don't frustrate them, don't confuse them, don't over complicate things, don't create inconsistencies, don't get the computer between them and their work -they want the reliability, ease of use, and continuity that comes with POTS - plain old telephone service, unchanged since the introduction of touch tone dialling in sixties.

The ideal user application structure was known and understood by the developers of both Pick and the relational database in the late sixties, and later codified in "Query-by-Example: A Data Base Language", a 1977 article by by Moshé M. Zloof for the IBM Systems Journal,

It's simple: the application is the interface, data is clearly presented in multiple rows, the data entered by users determines what data is retrieved by the system, stored by the system, or used in "next step" options presented by the system.

In contrast the epitome of bad design is reached by applications which show records one at a time, rejoice in pop up interfaces to complex applications for simple jobs - like starting Microsoft Word to enter notes within a dietary management application - and force users to repeatedly click "ok" and wait when there are, in reality, no other practical choices.

Google's incredibly simple search interface was the key to its early success - and represents query by example at its most flexible. If you want to find information using google, the computer just gets in the way - the steps you go through before getting to type in your search terms are extraneous to the process: your results will be the same whether you had to boot Windows and start IE or just type "ns8 [CR]" in a CDE window - and that's exactly how non IT people feel about the applications they use every day, all day: the computer gets in the way, and all this fancy interface stuff you and I care about is just so much crap they shovel out of the way before getting down to work.

So what do users really want? Magic: all the data they need for their work, all the analytic power available from modern hardware, and none of it more impinging on their awareness than the 1941 touch-tone dialling demonstration that led to today's plain old telephone service.