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.
Hi, I'm the guy who wrote the article.
Yes, it's hosted on my 256k upstream ADSL line, which is why I said "Use the Coral cache" in all the story postings!
Slashdot would also choose the day when I switch to my back up server (K6-2 233), in order to fix my main server, to post this on the front page. I was wondering why it was making that funny noise when I loaded the Slashdot front page...
Please use the Coral Cache!
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.
The Mirrordot version and Google cache are also available.
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.
Poor user interface design is the second biggest failure of this kind of software. (The first is failure to plan for failure, but that's a different problem.) The problem isn't that guys like me don't understand how to design a user interface; it's that we don't even think about it because we tend to be thinking in terms of the process or machine rather than the human user.
There are no universal guidelines for how to lay out a user interface. The only sure method is to code it, then try using it and see if it feels natural. Often an interface that "follows the rules" will feel clunky in use, and when that happens you should rewrite it and try again until it is intuitive. When you've gotten it to feel right yourself, you should put it in front of the people who will use it all day long and see how they like it. And you should be willing to rearrange it until they find it natural and intuitive.
One reason those field-programmable controllers have become so popular is that people like me, working in the field, can do this. If a manufacturer builds, say, a batch process controller, it must implement every possible function that any process might ever need. This usually results in a bewildering user interface since most actual processes will only use a fraction of the controller's functions. By writing a custom controller in a programmable device, I can give the user just the controls he needs to do his job.
It used to be a once a month occurrence for us to get a service call along the lines of "our scale is only weighing about half what we put on it," because a user accidentally switched from pounds to kilograms. Newer devices let us turn off modes the end user will never use, and the result is less friction all around.
It goes without saying of course that you put the most-used controls where they are easiest to find and most obvious, you only put controls that are used constantly where they are always visible. You always provide keyboard shortcuts for EVERYTHING. Especially in the workplace, day-in day-out users will learn all those shortcuts, but the temp timer needs the GUI. Both are absolutely necessary. Not putting in keyboard shortcuts is the single biggest screw-up in industrial GUI's I have used.
The art comes in determining what controls are really used most often, and when things like confirmation dialogs shift from being a useful safeguard to an annoyance. I can't begin to count the times when I've installed a relatively simple system only to find that some control I'd buried in a deep menu is used much more often than I'd realized. Usage patterns are often radically different in simulation than they are with a real machine connected to real processes. The job isn't done when you close the build file and put field installation on your calendar; you will almost always have to refactor at least once based on end user feedback. If you don't plan for this and budget for it, it's a big, big mistake.
Brackets contain world's first nanosig, highly magnified:[.]
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.
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
The automatic transmission shifter sequence is Park, Reverse, Neutral, Drive, Low, [Lower, [Lowest]]
But the parent was talking about a manual gearbox. Maybe the positioning of those is mandated by US law too, but I've certainly driven manual cars where the reverse gear has been in the top-left (left of 1st) and the bottom-right (below 5th, right of 4th) and, I think, bottom-left (left of 2nd). Additionally, sometimes you have to pull/raise some sort of flangey thing and others you push the entire stick downwards in order to change to reverse.
Plus, there's always the differences between indicators and wipers (sometimes they're switched).
Without doubt, though, the biggest problem that comes through lack of standardisation is the position of the damned fuel tank filler. If I had a dollar for every time I'd had to get out of a rental car to figure out where the hell it is, I'd have... like... $10.
Registering accounts later than some other chrisb since 1997
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.