I came across a very interesting paper by Bret Victor a couple of week ago- “Magic Ink: Information Software and the Graphical Interface“. Here’s an extract from the abstract :

The ubiquity of frustrating, unhelpful software interfaces has motivated decades of research into “Human-Computer Interaction.” In this paper, I suggest that the long-standing focus on “interaction” may be misguided. For a majority subset of software, called “information software,” I argue that interactivity is actually a curse for users and a crutch for designers, and users’ goals can be better satisfied through other means.

The paper echoes some of the views Alan Cooper discussed in The inmates are running the asylum – another text that I think anyone interested in HCI / User Interface Design / Interaction Design should definitely read!

The author goes to great lengths to try demonstrate why information software design should be seen as the design of context sensitive information graphics. He goes to great length to explain and demonstrate what he feels is the importance of information graphic design:

A well-designed information graphic can almost compel the viewer to ask and answer questions, make comparisons, and draw conclusions. It does so by exploiting the capabilities of the human eye: instantaneous and effortless movement, high bandwidth and capacity for parallel processing, intrinsic pattern recognition and correlation, a macro/micro duality that can skim a whole page or focus on the tiniest detail. Meanwhile, a graphic sidesteps human shortcomings: the one-dimensional, uncontrollable auditory system, the relatively sluggish motor system, the mind’s limited capacity to comprehend hidden mechanisms. A graphic presents no mechanisms to comprehend or manipulate—it plugs directly into the mind’s spatial reasoning centers.

On the face of it this sounds reasonable – a picture speaks a thousand words. How we present information to our users has to be the most important question software designers should be asking themselves. So why don’t they? Well I wrote a piece offering my views on that question a while ago: programmers are generally bad at user interface design. So as you might imagine I find myself agreeing with what Bret writes here:

Compared to excellent ink-and-paper designs, most current software communicates deplorably. This is a problem of surface, but not a superficial problem. The main cause, I believe, is that many software designers feel they are designing a machine. Their foremost concern is behavior—what the software does. They start by asking: What functions must the software perform? What commands must it accept? What parameters can be adjusted? (In the case of websites: What pages must there be? How are they linked together? What are the dynamic features?) These designers start by specifying functionality, but the essence of information software is the presentation.

I believe there is a great deal of merit in the argument that Bret makes, and the examples he uses such as his BART project are indeed compelling. However its important to note that they are relatively small software projects. BART is a small desktop widget that provides train schedules so you can plan journeys around the San Francisco bay area. It’s a great example of providing users with information that is important to them and providing interactions that are intuitive but not distracting. It feels even more compelling when he compares his widget to the official bay area trip planning tool – which presents information to user in html tables full of text.

Unfortunatly highly graphical user interfaces aren’t normally very accessible to people with disabilities, for example visual impairments. When I look at the BART widget, as a user I love it, its simple presents a wealth of information that I can take in, in a glance – but that’s because I don’t have any disabilities. If I take a screenshot of it, then using photoshop turn it into a grey scale image – its suddenly much harder to use. It’s one of the reasons many DDA standards require that you cannot use colour alone to signify meaning. I could go all the way and ask how a blind user might use the widget. The answer is, they wouldn’t be able to. There’s a wider question of course of whether they’d want to or need to use it 😉 .

The accessibility issue aside, I think software designers should reflect on what Bret has written, and others before him, like Alan Cooper. I know I struggle with some of the ideas he’s presenting here, but I can’t help but feel that too many software projects descend far too quickly into the delivery of “functionality”, without any significant effort or thought placed into whether the software is presenting the user with the information he/she wants as effectively, and efficiently as possible from the point of view of the user. Far too often the very interactions and flows through an application can be a product of the framework the developers have chosen to use, for example JSF – forces certain patterns of behaviour that the user in turn is forced to adopt by proxy.

I’m not sure if there’s a right or wrong answer, but Bret’s paper has given me plenty of food for thought, you should definitly read it!