In these flippant web-2 days full of flashy sites with
Its author, Tantek Çelik, tries to elaborate the fact that doing the same thing in a simpler user interface is better than doing it in a more complicated user interface. Which has been a well accepted fact for a while. What’s unfortunate that these ‘hypotheses’ which are aspiring to become ‘laws’ are almost impossible to read because they are so crammed with complicated words. E.g.
Hypothesis 1: Human interface cognitive load is proportional to the number of clicks/keystrokes/gestures.
cognitive load may be – is it the task actually being complicated and demanding my full attention or is it more something that isn’t particularly difficult but tedious and time consuming? – for me this doesn’t look more elaborate than claiming that doing something in many complicated steps takes more effort than doing it in a few simple steps. – Who would have thought?
The second hypothesis is probably the best one and deals with an issue that is frequently ignored:
Hypothesis 2: Human interface cognitive load is proportional to interface latency. I’d freely translate that as ‘Slow interfaces suck’ or, in a more friendly way, as ‘Don’t let the user wait’. It addresses a real problem in today’s computing environments where you are using machines that love to slowly load stuff from virtual memory and where using ‘web applications’ that actually run on a computer half way around the world is becoming more and more common.
Çelik’s final point,
Hypothesis 3: The usability of an interface is inversely geometrically proportional to its cognitive load introduces more complicated words and states a strangely precise mathematical relationship between two things that you most probably can’t even express in a single number. (If you can – do it!)
While I can appreciate the basic ideas behind these claims, I found them rather unfortunate in this pseudo-scientific form. They also lack any reasonable data to back them up. In fact, only the first hypothesis is backed up by an example: A comparison between sending instant messages and sending e-mails. It claims that sending an instant message is a lot simpler than sending an e-mail message. And of course this is true if you start counting clicks in the particular situation that Çelik implies.
In that situation, the person you want to send a message to is (a) in the ‘buddy list’ of your instant messaging client, (b) happens to be online at the time you want to send that message and (c) is immediately visible to you in that list because you only have a dozen or so people showing up in it. It might be more fair to compare this with a situation where you have your most frequently used e-mail addresses just a click away.
And even in that situation the bigger picture is missed. Instant messages are more disrupting to people than e-mails. You never know whether the person will actually read your message right away. And thus you don’t know whether you will receive a reply. Immediately? Or in an hour’s time? Perhaps you don’t even want to enter a two way communication but just say ‘Don’t worry about the book, I got it already’ or ‘I’ll be home around 7’. In those cases I find the instant messaging user interface to be more stressful or putting the burden of a greater ‘Human interface cognitive load’ on me because sending that message doesn’t finish the whole process as it does in an e-mail but merely starts it. And don’t even get me started on the incapability of instant messaging when you want to send more than a few words but, like, complete paragraphs and possibly even an image or a file (yes I’m looking at you, Adium users!).
While Çelik’s second point about the latency points to an important issue, I think it is wrong as well. Of course, latency is a problem. But a small bit of latency can be quite unproblematic in case the system doesn’t lose track of things while you have to wait. Just remember Mac OS 9: From time to time things stalled there. But the system was exceptionally good at keeping track of the keypresses you did in the meantime and it executed those as soon as it was ready. While this is worse than an instantaneous reaction, it was much better than a system with the same stalls which frequently manages to ‘lose’ or misdirect events in those periods as Mac OS X does: Latency problems of the same magnitude with vastly different outcomes for my ‘cognitive load’.
And on the other end of the scale we have more counterexamples. When a network server becomes hard to reach and the Finder decides to stall for a while because of that. Then it is insignificant whether that stall lasts 15 or 30 seconds. You will be annoyed and distracted to the same extent in either case. Thus, it seems there are fairly obvious counterexamples to a claim that stall length is proportional to annoyance.
Finally to the third point: Its justification starts with a remark that – contradicting any dictionary and even technical reference I could find – equates usability with ‘how much use it gets’. That probably makes typing SMS messages on a numeric keypad a feature of particularly good usability rather than an indication of people just loving to send those messages, no matter what. And then we dive into the world of starting to relate numerical values which aren’t well defined and confusing squares and exponentials. Ahem.
Oddly, after all those weak arguments, the Çelik arrives at rather good and, I assume, widely accepted conclusions: A simpler interface is better than a complicated one and a faster interface is better than a slow one. I have the impression that perhaps he started with those points and tried to build some ‘theory’ to justify them (to some managerial types or so). And then ‘theory’ sounded more like having to use big words rather than making an argument.
Great post. I had similar thoughts when I read Çelik’s article. I think the pseudo-scientific jargon he used served to confuse some folks into thinking that what he was saying was more profound than it actually was.
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.