A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Joel, you make really good points regarding the OS wars. As long as software works "exactly as [they] think it should," people will be happy with what they're used to.
I think a point should also be made - and Microsoft should be made to hear about it - that changing the way software works from one version to the next should be undertaken very, very carefully. I prefer Windows to the Mac, but I also spend my days screaming towards Redmond each time I find they've disabled a shortcut key or buried a function a couple levels further down than it was in the previous version.
I've read PoET, so I feel where you're coming from on the the whole 'usability is attained when the system should behave as the user expects it should' thing, but I feel that this is so reductive as to be of little practical value.
For non-trivial types of software, say...bug tracking applications, how would the user have any predispositions as to how a 'department' should be different from a 'company'? What is the user's mental model there? Also, this is fairly generous example: bug tracking software is generally used by sophisticated users, and there is a long history of bug tracking software out there that has built up models in users' minds.
What about products in (relatively) new categories? How should the picture-sending interface on my cameraphone work? I have no mental model of this system's behavior.
It seems that many interface designers faced with this quandry have looked to various real-world metaphors to help the user import a mental model from another context, with greatly mixed results: the original MacPaint was a stunningly succesful example, that Microsoft prototype where the windows UI = a room with a desk and cabinets is a considerably less successful one.
It would seem to me, upon admittedly cursory observation, that there is a degree of correlation between the success of the metaphor and the...'naturalness' of the metaphor. What I mean is that in the real world, there are painting tools, and what is done with those painting tools is not entirely dissimilar from what is done with MacPaint, at a first cut. However, managing applications and files on my computer is really nothing at all like managing the physical objects in my office.
It seems that many interesting new technologies don't have natural real world analogues upon which to draw. Sometimes, this presents problems: Prior to the late 90s, we had no shared model of how a global, peer-to-peer, windows-based music sharing system should work (Napster's interface seems to reflect this). There are examples in the positive as well: Flickr doesn't seem to draw on any 'real world' system models, and yet its users seem to be able to figure out how it works fairly quickly, nearly everyone compliments the quality of its UI.
Which brings me back to my original question: I have no mental model for how Flickr should work, or if I do, it is very, very thin. Flickr seems to exploit more base-level human traits in interfaces like our Highlights Magazine (or PhotoHunt for you pervs in the audience) Skills (identifying that which is different: e.g. the unfamiliar superimposed box on an image makes me move my mouse there almost instinctively-- with no further action I see a 'tooltip' that makes clear what the purpose of this 'annotation' is). So, armed only with your guiding principle, it seems to me that we have very little to go on in building these new types of apps.
Tuesday, March 07, 2006
The whole metaphor issue is a red herring. Actually, it's worse than a red herring because it's a TRAP. It leads you into dead ends, as is the case when there are no natural analogues, with nothing to get you out of them.
But to appreciate how evil this trap is, consider GIMP vs MacPaint. GIMP doesn't do anything that MacPaint couldn't have done. It's just that MacPaint's designers were so focused on the paint metaphor that they couldn't come up with something that went beyond it.
So we see that metaphors leave you up a fetid brown creek without a paddle even if they're used "correctly". Metaphors are a dead end, always.
What Joel says about expectations is also a dead end, and a trap. It's good for a zero-order explanation; it explains nothing useful.
There are two kinds of expectations in any complex system;
* the ones that are created by the system itself
* the ones the user brings in from other systems
It is the system's job to create such powerful expectations in the minds of users about the system's behaviour, that these new expectations will annihilate any previous expectations the user brings to bear.
Some people think that tools should meet whatever expectations the user brings to them. Such people are fools. If your tool is exactly like another tool that users are familiar with, then users will never adopt your tool. And if they do, then it will only be because your tool is an incremental improvement over what they had previously. You can get good design that way, but you've destroyed any possibility of Great Design by lowering your expectations so.
Further, the developers that think users can't generate new expectations for their tool are fools for a second reason. Nearly all users are perfectly capable of generating new expectations for a new tool. Only the mentally deficient could fail to do so. Such developers are treating their users as mentally deficient, and that makes them fools.
In the general case, it certainly is not a tool's role to meet the user's expectations. That's what a crutch is, and tools aren't crutches. It's a tool's job to *exceed* the user's expectations.
By these measures, the Mac UI is miserable. It is a poorly designed UI. It is poorly designed because it's not powerful enough to destroy the expectations that Windows users bring to bear on it.
So Joel's "the system should do what the users expect" is just WRONG.
Are you saying that you think GIMP has a well designed interface?
Tuesday, March 07, 2006
thats a very good post richard, thanks.
Tuesday, March 07, 2006
As always a good read, but IMHO I do think the definition of usability is inadequate:
"Something is usable if it behaves exactly as expected!"
As I read the rest of the article it's clear what makes it inadequate - diversity. Two random individuals are not likely going to have the same expectations about something, unless there is only one way for these expectations to be had and "the way" itself to these expectations needs to be obvious, thus:
"Something is usable if it behaves exactly as it only can be (obviously) expected!" :)
(NOTE: The grammar/wording might be fishy as my english is not as good as my native language)
To me the "the way to only obvious expectations" is the hardest part of good design and usuability.
As Oliver said -- what does a user expect? A Mac user and a Windows user will have different expectations which are easy to anticipate, but what expects someone who has never used a computer before? Or one who only used command-line interface before?
Also, for a Western user it's natural to expect a progression to be displayed left-to-right (e.g. a progress bar) -- is it also true for an Arab user? Also, red means "stop" and green means "go" -- what if a user is color-blind?
Wednesday, March 08, 2006
Like the so-called “Principle of Least Astonishment” ( http://en.wikipedia.org/wiki/Rule_of_least_surprise ), Joel’s One Easy Step appears to be easily misunderstood to only include external consistency –that the application should work like prior applications or artifacts (the latter including metaphor consistency). While Joel’s example of a Windows user using a Mac tends to reinforce that perception, his other writing indicates that he is well aware that is only a small part conforming to user expectations. There is also internal consistency –the degree the same thing in the application works the same way in different places (e.g., Foo is under the Bar menu in all windows of the app). There’s also the clarity of the UI: the degree it sets user expectations due to broad cultural and human perceptual elements. You can carefully label a feature so the user knows what to expect. Many times just the graphics or layout of the feature can effectively set expectations ( http://www.zuschlogin.com/?p=4 ). This is how you handle novel features or apps and go beyond whatever metaphor you find yourself using.
That said, there’re a couple weaknesses with Joel’s One Easy Step. Firstly, by itself, it’s crummy for directing the *design* of a UI. What are the user’s expectations? How do you approach the design to best satisfy them all? Joel obviously knows there’s a lot to this or he wouldn’t have written an entire book about it. The One Easy Step is just a shorthand reminder of everything in that book.
Secondly, conformance with expectations really isn’t all there is to usability. That leads you to make a consistent, clear, and well organized UI, but there’s more you have to do. You have to accept you despite your best efforts, you will violate some expectations some of the time. You have to accept that despite the users’ best efforts, sometimes they’re going to do things they didn’t really intend to do. So usable means a tolerant UI, where the user can easily recognize, correct, and learn from errors. You have to accept that, whatever their expectations, users like to get the job done fast and easily, so usable means an efficient UI with the fewest clicks, least time, and smallest cognitive demands to complete a task. Finally, you have to accept that, no matter how good your task analysis and other up-front research of your users, you are not going to be able to anticipate every way the user is going to want to use your app, so usable means a flexible UI, allowing user to do what they want, how they want, whenever they want to.
Wednesday, March 08, 2006
"What are the user’s expectations? How do you approach the design to best satisfy them all?"
Well, you don't expect to satisfy *all* expectations. That's just not a reasonable goal. You attempt to satisfy most--or the most important--expectations for the specific user you're designing for. Of course those expectations are a combination of external influences (like competing software or real-world analogs) and internal influences (consistency from screen-to-screen in your app).
Which answers the first question: what are the user's expectations? I suspect that Joel's next article will address this. Of course there's no magic bullet here, no set of nice rules that lay out The User's Expectations.
The answer is that you have to roll up your sleeves and *find out* what the user's expectations are. Talk to them, watch them use software, show them new software and watch them use it. And once you learn something about users' expectations, you try to identify the ones you absolutely must honor, and the ones that are more flexible. This process is iterative: you (almost) never hit "what the user expected" on the first try, and usually not even on the second.
The points above about mental models are really good. We've heard a lot about "mental models", but how do you use them for new products? "Learnability" is an aspect of "expectations": if something is easily learned, I develop accurate expectations very quickly; if it's hard to learn, I might never be able to expect what the hell some button will do.
Flickr is a good example. There's no good existing mental model for online photo sharing. So how *quickly and easily* can I form new expectations? Are functions discoverable and obvious? Are buttons labelled so they do what I expect they might, or do they use cute words or jargon? Is the UI consistent, so that once I learn one new thing, I can apply that knowledge to other aspects of the product? I think in Flickr's case, the answers to most of those questions is "yes."
Wednesday, March 08, 2006
"no matter how good your task analysis and other up-front research of your users, you are not going to be able to anticipate every way the user is going to want to use your app, so usable means a flexible UI, allowing user to do what they want, how they want, whenever they want to."
That's often the attitude of programmers or designers who themselves prefer flexibility in UIs. "Whatever, whenever, however" can easily lead to mystifying complexity. Too often, "flexibility" is a cop out for a designer who simply throws up his hands and says "I have no idea how people will use this, or what they want to do with it. I don't even have a good opinion about what the right answer might be. So I'll make it 'flexible': here's all 57 functions in a big list, just use the one you want."
Wednesday, March 08, 2006
Andrew makes some good points. I didn’t mean to imply that a usable UI has every conceivable feature or the 32-Tab Preference Dialog from Hell. To me, flexibility means *making available* the features you have chosen to include, putting the user in control. Flexibility is about eliminating unnecessary modes. For example, an e-commerce site should support changes to an order on the last page of Checkout, not forcing the user to discard everything and start over. Flexibility is about allowing multiple expressions of the same semantic input. For example, a data field should accept mm/dd/yy and Mmm d, yyyy. In an email app, there must be a dialog box for attaching files to an email, but drag and drop should be supported too. Note that these add little or nothing to the UI complexity from the user’s point of view. On the contrary, using the app is simpler for them. That said, one shouldn’t pursue flexibility at all cost. Good design finds the right balance among clarity, consistency, tolerance, efficiency, and flexibility. My point is that if you think “conform to expectations” is all there is to usability, then your design can easily be imbalanced.
Wednesday, March 08, 2006
First you have to ask yourself, do you want to do good design or do you want to do great design? If you want to do good design then go right ahead and follow Andrew's advice. Just go to the users and figure out what they expect and implement that.
If you want to do great design then you cannot ask users what they expect or even figure out what they expect because it *won't* work. The users *don't know* what they expect at a base psychological level, and what they expect in terms of higher order functionality is going to be stunted like a tree in the arctic.
If you bother to read Eric von Hippel's Sources of Innovation then you'll know why focus groups don't work. The overwhelming majority of users are incapable of conceiving something beyond what they've already experienced. Oh wait, I just gave it away.
Yeah, cause now you have two avenues open to you. You can read Sources of Innovation or watch the 3M tutorial videos and try to implement the Lead User method. Probably you will fail because you need to be an extremely creative person to apply the lead user method.
Or, and this only works if you are a creative genius, you can study basic psychology (this will give you what users expect), requirements, and come up with a genius design. This will be a Great Design.
Well, it's kinda pointless explaining how to go about great design to people who can't do it, but it's severely annoying to be reading about 'external expectations' being put on par with 'internal expectations'. Why? Because great designers not only never bother to meet or accept external expectations, but they go out of their way to avoid *learning* them. As von Hippel points out on page 102 of SoI, there are plenty of studies demonstrating that knowledge of existing solutions (eg, competitors' software) inhibits the creation of innovative software.
It's not just the case that Andrew's advice is useless to the design of great software, it is actually *destructive* to the design of great software.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz