Slashdot Mirror
User-centric GUI Design Explained to All
TuringTest writes "The webzine User Instinct carries an article on Usable GUI Design showing that good user interfaces are not beyond the means of free and open software development: 'This article presents five key points of user interface design [...] that any software developer should be able to use.' In related news, The Economist writes against software complexity in an interview to MIT's John Maeda, PhD in interface design. See also OpenUsability, a project for testing user interfaces in a bazaar-like model. The specifics of UI design in Open Source projects has been previously debated on Slashdot."
... about User Interface research. My DVD, VCR, TV, CD, CD-writer, portable mindisc player are all laid out completely differently, and -- despite similarities -- behaved subtley differently from one another (If I hit Pause-record, what do I press to recommence recording? Is it Pause or REC?)
My car has a completely different set of layout for dash controls from my girlfriends. The gears are in different places on the stick, and the feel of the clutch is completely different.
And yet, after a short period of familarisation, I find I can cope pretty well with all of these things, as can everyone else I know.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
I've said time to time again that a lot of free/open source software suffers from not having an ease to use interface. One can argue that functionality is more important than the presentation/interface layer, but seriously, users are more attracted to pretty pictures.
But it's not just the subject of pretty pictures. Professional software companies may actually spend several subsequent dollar signs into providing a consistent, easy-to-navigate user interface. The trick isn't to show all functionality. The trick is to present the functionality the user needs, in a logical grouping as the users expect it.
This is probably why the iPod has been so successful. It doesn't have all the features you could hope for (FM tuner, voice recorder built in, Ogg Vorbis support, etc), but it does what it does so well that even technophobes can "get it."
Part of the Audion Story from Panic software details how iTunes didn't have all the features of Audion, but how they (Panic) had a breakthrough realization that they didn't NEED to have all these great features (that only few people would use) to make a great app.
Alex.
The trick is to balance a few things: Ease of learning for infrequent users, ease of use for heavy users, easy to customize to meet particular user's needs.
Predictability is the key.
Some people love GUIs for the same reason (ease & hand-holding) that others hate them. Some people love CLIs for the same reason (succinct power) that others hate them . Although people like to think there are universal design principles, and there are some, most real world designs require compromises based on the needs and proclivities of a diverse user population.
The challenge for OSS is that its developers tend create the kind of software that they themselves want. It does not have many developers creating software for a non-developing/non-geek user populations. Thus, OSS will invariably create software in its own image. This is not a "bad thing" unless the only true goal is universal adoption of OSS at the expense of OSS geek-usability.
The point: you can't please all of the people all of the time. And given the model underlying OSS, it is unlikely to focus on pleasing non-programmers.
Two wrongs don't make a right, but three lefts do.
showing that good user interfaces are not beyond the means of free and open software development
Firefox
If, for example, the window frame doesn't look familiar, and doesn't have Help in the upper right, and File Save is renamed Keep This...
Then most people will spend some time wondering whether they are about to get unexpected results. The purpose of using the device (hw/sw) is to accomplish some mundane task (99% of the time anyway). Some UI designers can't resist the urge to show the world how clever they are by doing interfaces in an innovative and new way. WAY bad!
An article with noble intentions, but it falls far short.
To begin with, anyone involved in UI development needs to read Joel Spolsky's User Interface Design for Programmers .
From Roe's article:
This is like saying all developers care only about performance, and all manager care only about impossible schedules. There are a number of books out there that aim to give developers the skills to design usable interfaces -- in fact some are on Roe's reference list!
Fitt's law is not the "most basic ... of UI design". Fitt's law has become unreasonably important because UI designers stopped giving users visual cues about keyboard shortcuts. Even my Dad uses the backspace key rather than the back button! Its so much easier. Mouse gestures will also dramatically change the effect of Fitt's law.
In my experience, the weaknesses of open source UI design are also its strengths: (1) the ability to experiment with new interface metaphores; and (2) the flexibility of the software.
The more you conform to established metaphores, the more easily you can make your product usable. Creating new metaphores is difficult, and getting them accepted is even more difficult.
Flexible software typically has a lot of functions and options. The capacity of short term memory is important here: a person at random can remember or concentrate on 7 +/- 2 items at once. At no point should a person be presented with more than 9 items in a selection when one has to be chosen. So there should be at most 9 menus, 9 items per menu, etc. Any more than that and people are operating at less than peak efficiency in order to find the functionality they want.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
I wasn't able to get to the GUI Design article, but I read The Economist's one. One telling point I thought was referring to people as Analogues, Digital Immigrants, and Natives. These being people who are unfamiliar with new technology and ignorant of how to use it (note, not 'ignorant' in general, just the classification of the lowest-skill computer user if at all), then those that came to technology and adapted to it, and finally people who grew up in the digital world.
I think most of this problem is simply the rapid pace of change. We're in the first era that has seen a revolutionary invention go from non-existant to an everyday fact of life in such a short span of time that most people were not only alive when it was something rare and required special talent, but they are still working! The change has simply outpaced a lot of people's ability to adapt to it, so much so that it is shocking to those of us in the 'next' generation that the previous one could be so clueless.
Its not that they are clueless users, its that they have been thrown head-first into a pond that they vaguely knew existed, let alone how to swim. But the upside is that the problems we agonize over, the clueless user, tech support pains, is for the most part a self-fixing problem. In 30 years the older generation will have retired and moved on, while those of us who will take over for the most part are native users, we grew up immersed in technology and rapid change. Thus in another couple of decades, the problems of technological ignorance and inability to use modern systems will dwindle away. Not that it will ever disappear, there will always be people unable to grasp these things, but the fact that everyone has grown up with this knowledge will all but eliminate a lot of the problems we're dealing with today.
There will always be bad interfaces, unusable technology, its a given. But if this rate of rapid change continues, in a generation's time everyone will have been born and raised in an environment of rapid change and cutting edge technology. It will be commonplace, and I think that the issue of entire segments of the population being unable to adapt will no longer exist.
This is not a sig.
UI-centric design makes sense for the UI layer. For the logic and data layers, the equivalent design consideration is API design, which is not as compelling as functional design, including maintenance features. Dictating the whole application's design by the UI is like flying not just on one wing, but on no wings, or engine, just the cockpit dashboard. This balance is one reason to have one UI-centric person develop the UI, a data person develop the data layer, and someone with knowledge of the actual business executed by the application designing the logic layer that ties them together. We don't make one engineer design all the devices in a 747 or F16 - they'd crash, even if they looked great going down.
--
make install -not war
What I mean is that you have, let's say, you want to make a word processor. You know how most of them have about 200+ different buttons and functions to choose from on 2 - 4 toolbars at the top? Try condensing those into 1 toolbar with 6 buttons. If I recall correctly, there's TextEdit(?) in the Mac OSX that looks pretty sexy, and has almost nothing on the word-processor exept the sheer minimum (Which is what is recommended by this article, no?).
;P
But now they need to spend a lot more time fiuring out how they're going to put all the features of a Word-Processor in to a much smaller/cleaner design. It's a lot easier to just make a bunch of buttons on the main screen toolbars, each pointing to it's indipendant function, than it is to organize everything into more specific sub-categories and simplified menus.
The code needs to be tweaked out a bit to accomodate a more complex design (ie: To save a file: File -> Save As.. -> 'Pop-Up Menu', instead of: 'Save Icon' -> 'Type Name'. I know this isn't that complex to begin with, there's bound to be more highly contrasting examples).
Not just that, but a lot more time has to be invested into the development of the app, because of the more detailed work that has to be done.
I'm not saying it's a bad thing to make apps with these guidelines. Hell, I've been making my programs with over-simplified UIs for as long as I can remember, because people tend to enjoy the less clutter. All I'm saying is that, a lot more effort has to be put into an app. And OSS dev's might not want to spend more time tweaking a UI, and instead focus on the product's ability (PearPC doesn't even have a UI, aside from third party ones).
Heh, I think my first post was too over-simplified.
I'm a signature virus. Please copy me to your signature so I can replicate.
The UI design failure that annoys me the most is media players that the developers obviously have spent a long time getting the user interface to look like a panel for an expensive car stereo or DVD player.
Why tiny little buttons jammed close together that are hard to see and click correctly? Sure, in a car dashboard space is expensive, but when you are looking at a film on your computer screen you are going to use fullscreen and have the controls hidden most of the time, so when the users wants to see them, why not make them big with clear lables?
Especially gratuitous is when a player has new controls that are specific to a DVD player, such as a subtitle/audio selector or a click/draggable progress bar. The developers often don't integrate this with the main controller (cause there is no analogy in a car radio, which appearently makes them confused) but instead the player opens other windows with a totally different look and feel. Or if they DO include it, it is often also tiny, squeezed in between the play button and the usually useless "eject" button for instance. This is especially bad with the progress bar or volume bar where you might want to have fine selection resolution. Why not put these controls along the lower edge of the film screen where they can be stretched out? (I think Quicktime and *yech* Windows Media Player gets this right. Haven't used them in a while though, I might be wrong.)
Xine, mplayer to mention two have this problem of suffering from the Car Stereo look for controllers. Lots of mp3 players the same. Ok, they can be skinned differently... but why such as bad default, and why do all have to have their own format for skins?
(On a related topic, while I'm stil whining, I have yet to find a media player under Linux that allows you to select smoothly with a scrollbar where in the film you want to jump down to seconds. Xine for instance jumps 1 minute back or forth when you use the arrow keys to skip. When you drag the scrollbar it doesn't show where in the film you are, and it has a minimum resolution of something like 30 seconds, so it snaps to the closest 30 second segment start when you let go. I think mplayer is similar.)
Now, all this said, I do appreciate the great work people put in in making open source players that I can enjoy. If you are one of these developers, feel free to flame me for complaining instead of contributing.
Being bitter is drinking poison and hoping someone else will die
Toolbar buttons require a lot of work from the user- You have to memorize them, or take time reading the tooltip to learn what they are for. Usually it is much better to put commands into menus with regular text since you can tell what they do by their text.
However, sometimes a command is used so frequently that it is worth forcing the user to learn to use a toolbar button, because toolbar buttons have some important advantages:
1. They take up less space and because of that can be left on the screen all the time
2. The human eye is great at recognizing toolbar icon once they're meaning has been learned
But usually, making a toolbar button for a command is a bad idea, unless you know otherwise. Look at Firefox: It only has 5 buttons on its basic toolbar and places everything else into the menus- Great design!
### Some people love GUIs for the same reason (ease & hand-holding) that others hate them. Some people love CLIs for the same reason (succinct power) that others hate them
Usability is really NOT about religion, CLI vs GUI or whatever, its about doing things the right way, placing stuff where it makes sense and not wasting the users time. Sure there is not one true right way, so a lot of good interfaces don't necesarily make a consistend one, but for sure there are a lot of things that simple are done really bad in OSS and other software, no matter if you are pro CLI or pro GUI or whatever. If you get useless dialog boxes popping up for no reasons thats simply bad usability, same for colors that make text unreadable and the other points the article mentioned. You are not telling me that OSS people like to not being able to read their text and that they like to click dialogs away, are you?
The reason that most OSS guis are the way they are is simply because people didn't spend much time at all designing them, they just implemented a feature, quick&dirty punched a UI ontop of it, end of story. The result is not a 'designed for OSS' userinterface, but a 'not designed at all' userinterface, which will be both a pain for OSS users as for the rest of the people and even the programmer itself. The article gives some good points which are pretty general appliable to all kinds of software.
Often, when people talk about good GUI design, Fitt's law gets dragged up. Fitt's law is, at best, a footnote to good GUI design. I think UI designers hold on to it so tightly because it's one of the few scientific-seeming "laws" they have and because the improvement is easy to measure.
Fitt's law tells you what you need to do so that people can hit your buttons faster with a mouse (well, it's more general than that, but you get the idea). But most of the time, the time users "save" is so slight that it makes no difference to the overall efficiency with which users can use the application. The few areas where it does matter have already been encapsulated (context menus and pie menus are a good thing because of Fitt's law, but your framework already provides them for you).
People who design GUIs based on Fitt's law may often do the right thing by accident. For example, putting a button with a 1 pixel wide inactive border at the edge of the screen is not a good thing to do. Fitt's law says, in effect, that if the button is not at the edge, you have to slow down and hit it directly, whereas with the button at the edge, you can just slam into the edge with the mouse and hit it. But that's not the main reason it's bad to put buttons one pixel away from the edge; the main reason is that doing so confuses the hell out of users who simply don't see the border and wonder why nothing is happening when they think they "are pushing the button".
At other times, Fitt's law misleads you. Making the "Back" button bigger on Firefox, as the article suggests, probably doesn't save you any significant amount of time (anybody who really cares is using gestures or pie menues anyway), but it does make the UI look ugly to users and they'll like it less.
Erase Fitt's law from your mind. To the degree that it matters, it will be obvious to you anyway. And in subtle cases, it's a treacherous guide.
What you should focus on is making your UIs intuitive, unobtrusive, internally consistent, unsurprising, and pleasant to look at. Fitt's law doesn't help you with any of that.
It's not about programmers vs non-programmers. It's about the person who created the application vs everyone else. And when it's put like that, there's no choice to make. If software hasn't been designed for other people to use, there's no point releasing it.
The idea that only non-programmers fall victim to usability problems is wildly wrong. The vast majority of usability problems are not about beginners not having enough general knowledge in the field, they're mostly about non-optimal design. Take the example in the original article (you did read it, didn't you?) about search tools throwing up error dialogs when they fail. A programmer is going to get just as annoyed about that as a non-programmer.
I'm a coder who administers multiple Windows and Linux machines and codes in a variety of different languages. Usability problems piss me off more than most users, because I realise they're the fault of a programmer who just said, "It's good enough for me!"
The distinction you make - that usability comes down to a choice between two groups of people who fundamentally differ in technical ability - is not only very wrong, it's actively harmful, and the reason why so many OSS interfaces (whether GUI or CLI-based) have such poor usability. The programmer thought he could get away with poor interface design because he was aiming at geeks. What he ends up with is no users.
Unlike most /.ers, this guy did more than just whine, complain and bitch. He took some well known examples and showed us where they fall short. Wether we agree with every single point is irrelevant.
I found this article to be well written, well laid out, and quite informative. Definitely things to keep in mind.
And I totally agree with point 0 - the user is not using our application, so it should be as unobtrusive, and helpful as we can make it.
I like the one point the author brought up: most used buttons should be bigger and easier to find. Good point! "It should be the back button" BAD point!
I think everyone is different in how they use their applications. E.g., I prefer alt-right to go back or use the drop down list (it's position matters not to me) if I use the button at all. So what might be most common for one user isn't for the other. And having your most used button ("Stop" in my case) smaller than the buttons you don't use is really, really annoying!
SOLUTION:
Most used buttons become automagically bigger. So as an application learns how a user works, it will optimize the user interface for them. Most use buttons get shifted to the left (or right) and made larger. Toolbox panels that percolate up most used features to the top so the top half is the most used features in a larger hit box, and the bottom half is the "usual" layout.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Computers are complex.
That makes them difficult to use.
We don't like that.
Fix it now.
The underlying theme is very much a mark of our times. There is no doubt that it has genuine resonance for many people as they deal with an overwhelmingly complex world. On the other hand, it is a position fundamentally based on ignorance, and thus there is not much hope of reasoning with it.
It's not as if the issue of complexity has never been investigated. We knew from the earliest days that simply by being constructed of digital elements, computers would be characteristically different from other human artifacts. David Parnas and Fred Brooks both made early contributions on this subject, and their work is still eminently relevant today.
Probably the simplest artifact in common use is the knife. Yet given our resources and technology, it's appalling what passes for a knife in most people's kitchens. If the simplest artifacts still have such problems after thousands of years of refinement, what can we reasonably expect from the newest and most complex artifacts ever created? Demands to make them "simpler" can only be met cosmetically, and of course the illusion of simplicity in a complex system is necessarily fragile.
The fact is that the design problem is very hard in digital systems. The popular mood may be to deny this problem rather than to engage with it, but that doesn't change its nature or its inevitability. If our species survives long enough, I think we'll eventually the maturity and humility to see this.
Parity: What to do when the weekend comes.
The funny thing about all this UI talk is that, while Apple is better than most, Apple also breaks a whole lot of UI design guidelines, especially its own.
For one, the titlebar pills are really quite small, esp. in comparison to the titlebar itself. I remember when I first got OS X I noticed that these buttons were among the smallest ones I've ever seen on a GUI.
I'm sure a lot of people will hate to hear it, but Expose tends to be another feature that can be annoying, especially to people who aren't familiar with it. In particular, the option to activate it by moving the mouse cursor to one of the screen corners. It's always a bit annoying to overshoot the down arrow on a scrollbar a little bit only to suddenly have your whole world change without any sort of clicking or anything on your part.
I've escaped this by turning off the ability to activate Expose by moving the mouse to the corner of the screen (keyboard only for me), but I still find it maddening when I'm working on someone else's Mac. And to someone who doesn't know what Expose is, it's even worse because they don't know how to make all their windows go back. In programing, unexpected side-effects in functions is generally considered to be impolite. I think this applies to UI, too.
I don't think anything I've seen recently really shines on most of the points TFA is talking about. I think that's why HCI people like stuff like Fitt's Law - it means they will always have something to complain about. But it's also a perfect example of worrying about minutia when there are much bigger problems to deal with.
The big issues that most folks seem to need to get a handle on w/r/t UI is 1)no surprises 2)everything is discoverable 3)don't keep every single thing you own on the floor of your house and 4)it's polite to answer questions when asked.
The real problem with most FOSS is that it is too complex and inconsistent architecturally. No matter how pretty or usable a GUI you slap on top of it, if the underlying system is too complex and inconsistent, it won't be accessible to normal people.
Example: someone writes a niffty GUI wizard for Linux for setting up a printer. The wizard itself follows all the usability guidelines and is quite nice. But the problem is that the wizard is just a front-end for CUPS or some other nastily-complicated printer driver system. When the back-end chokes in some unexpected way the front-end isn't expecting, the user has to comletely sidestep the wizard, go the command line, and whip out Linux-fu magic to fix the problem. The problem here isn't the front-end GUI wizard; the problem is that the architecture of the underlying printer driver system is overly complicated and completely blows, and there's no tight integration between the back-end and the front-end so that the user can use the wizard to easily fix any possible problem that may arise.
You see this over and over again in the Linux/BSD worlds. Slapping a pretty GUI on top of a shit architecture does not make thing easier to use.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
The most basic point in all computer UI design is that the user does not want to use your application. They want to get their work done as quickly and easily as possible, and the application is simply a tool aiding that.
There is also a class of user, more common that one might expect, that does not want to get his work done quickly, although he may say he does. UIs designed for the lowest common denominator are often dedicated to trying to get this user to do something he's not inclined ever to do. As a result they fail to satisfy this user as well as the other type who really does wants to get his job done quickly and easily.
Among the quickly-and-easily crowd, there are two types of the users: those who use the product a little and those who use it a lot. You can argue about what is most intuitive for the use-it-a-little segment, but keyboard shortcuts are usually what experienced users prefer. If you really want to get your work done quickly and easily, keyboard shortcuts are what you want.
As a result, for people who use the product the most, an intuitive interface may not be all that important except as a learning tool.