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.
google's cache right here
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.
Consistancy is the KEY and has been since the early days of cobol when report and screen generators were designed with consistancy in mind. IMO Apple does a pretty good job with this. It's a big part of what makes an intuitive system intuitive and needs to be approached from the lowest levels (naming and structure within the source) through presentation and the UI.
Now I'm the grandest Tiger in the Jungle!
MS Bob for the win.
Usable GUI Design: A Quick Guide for F/OSS Developers
Update: I have read many comments on this article and have written an FAQ responding to some of them
Introduction
The Open Source software world is full of excellent software. High-quality F/OSS software is available for virtually any task a computer user could want to do, from word-processing to web-serving. There is one small problem with much of this huge array of software: it is often far more difficult to use than it could be. Professional UI designers tell us that user interfaces should be the first thing designed when we come to develop an application, and that programmers are incapable of doing this kind of design. They say it can only be done by the professional UI experts; OSS projects don't have access to these kind of people, and therefore can never be truly usable.
This doesn't mean we should just give up on UI design. From the quality of many commercial applications' UIs, having usability experts on staff doesn't guarantee a good interface either. Effort, knowledge and thought by any developer can improve the usability of an application greatly. We may only find a local optimum rather than the global, but even that is a step in the right direction.
After years of struggling with these problems, I thought I would write down a short list of five things that we OSS developers should consider when designing our application's GUI. These are drawn from my experience in using and writing OSS software and my reading of a few very interesting books and web sites on the subject. These works are listed in the references -- they are all excellent reading for any developer interested in usability issues.
I have intentionally only mentioned points here which do not require major amounts of work to implement, and about which there is little controversy. Larger "whole-application" issues are beyond the scope of this article. None of these ideas is new or particularly complex, but their effect can be very great. I should also note here that in several of the examples I use, it is possible to fix the problem by changing the application's settings. I have decided to only consider the default settings: presumably, the defaults represent the developer's idea of the most usable design for their application.
Before I start, I should probably make one more point in order to at least mitigate the flames I will receive: although I may sound quite harsh on some applications below, this is in no way meant as anything but constructive criticism. I use most of these applications every day and they are fantastic pieces of work, the product of years of hard work by dedicated developers. I am merely making suggestions of potential improvements; no offence is intended to anybody.
The Points
0) The user is not using your application
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. The more you can keep your application out of the way of the user, the better. Effort spent on using your application is effort not spent on the work the user is trying to do. Two key quotes from Alan Cooper's second book, About Face 2.0, summarise this very well:
1. "Imagine users as very intelligent but very busy"
2. "No matter how cool your interface is, less of it would be better"
Points 1 to 4 in this article are really just special cases of this rule.
1) Fitt's Law
This is the most basic and well known of UI design laws. It states that the larger and nearer to the mouse pointer an on-screen object is, the easier it is to click on. That's common sense, yet it is often completely ignored in UI design.
Firefox toolbar
Figure 1: Firefox toolbar
Consider, for example, the default Firefox button bar (Figure 1). When web browsing, by far the most common button anyone hits is the Back button. The Back button should therefore
Sean Lane Fuller - The truth is out there!
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!
How Sbout slashdot cut down on the amount of links per news story? That would be a nice GUI design. I like to RTFA, but half the time I don't know which link it is. In this case I do though, but it's dead.
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.
Part of every software project should be to analyze how the users interact with the software. Using that information, the interface can be tweaked to provide more efficiency and reduce errors. Of course, the customer would have to pay for this but it would probably pay for itself. For example, if a clerk takes two seconds less to input a transaction and there are 100 clerks doing 200 transactions per day, then the company saves 20,000 seconds per day. That's about five hours per day or say $50. That times 200 days per year is about $10,000. So, if the company spends 10k, they get their investment back in a year. That's pretty good roi.
There should also be a mechanism whereby the end user (clerks in this case) can provide feedback to the developer. I'm sick of hearing: "We can't do that because the computer won't let us." This way, annoyances like that could be flagged as they happen.
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 only problem is that the simpler interfaces get for complex apps, the more intricate the code has to get.
I'm a signature virus. Please copy me to your signature so I can replicate.
... to the rescue!
e s/gui.html
http://66.102.9.104/search?q=cache:benroe.com/fil
Gnome is proof positive that lipstick on a pig is exactly what it sounds like. That a few hearty souls can learn to love it is a cause for lamentation.
I would say, the object of the UI is to present the minimum number of tools for the maximum functionality, in a layout that requires a minimum amount of explaination based on information it's already collected from the user.
This is not the linux way, and there are probably a phallanx of penguins carrying torches over to my house right now.
showing that good user interfaces are not beyond the means of free and open software development
Firefox
The Mirrordot version and Google cache are also available.
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
"Usable GUI Design showing that good user interfaces are not beyond the means of free and open software development:"
The problem is that open source is dominated by the uber-geeks, and not enough people who specialize in user experience. So obviously, if more GUI specialists got involved in open source, the better the user experience of open source software. (Need I add a "duh" to this?)
Well, first thing I thought when I saw this was this previous article that was listed on ./. the link is here. It's really a rather good read, especially if your a big fan of Apple like myself. I found a lot of his suggestions to be good guides toward a better GUI, but a few were also a bit flaming. I do like the idea of simplicity, but I also like to be able to delve as deep as possible, when I can, and understand as much as I can shove into this tiny planet-sized brain of mine. I think that after using a lot of different products, and quite a few OS's, well, I can't settle on the perfect list, but this comes close.
sig!wind down the juuice, let the tubes roar with the glow of alternative powers, not they that be." me, today...
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.
IN THE RED CORNER
.....
we have a trembling k6-233, never done any harm to anyone, never let you down since the day you purchased it, but worked away slowly processing any task thrown at it.
IN THE BLUE CORNER
We have the Might of a front page Slashdot Effect
Secounds out, Round 1. Ding Ding......
Will there be a burial at dawn?
The article gives an example of enlarging the back button as this is most used by users. I think a better improvment would be move the buttons to the right hand side of the screen (you can do this in Firefox!) so they are near the sroll bar which is the widget that I probablyu used second-most-of-all ! In fact, just drag the back button over and it's easy to hit as nothing else is there!
----------------------------------- My Other Sig Is Hilarious -----------------------------------
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
Go read Eats, shoots and leaves for even more.
creation science book
and the links on the bottom lead to all the right places, so how come there are still so many bad GUIs around? My last project involved building a GUI except for other things, and I can tell you, a shift in paradigm in the right direction can really do wonders. You can have a bunch of text boxes with pixel offsets, if you want to allow user to do layout of some graphical box with some text on top of the screen (text overlay on a video output,) or you can give the user a scaled representation of the screen and let him(her) move the graphical box around that screen, while watching how the real box moves across the real video screen, and then allow the user to do precise positionning by 1 pixel with the arrow keys. That's a paradigm shift and it is both visually pleasing and more functional than typing in precise coordinates (especially if the precise coordinates do not really matter, but you have to realise that they don't matter and often we don't think like that, we think - the user wants to do precisely this, but the user does not know and/or care about precision, (s)he only cares about approximation that gets the job done.) So it is hard to realize such things and it is kind of counter intuitive to people who think in precise terms. How do you teach that? You go over many variations of interfaces on the same idea and you show different possibilities. I discovered this through trying to think like my user, and it's not obvious. Maybe my university HCI courses paid off after all? :)
You can't handle the truth.
Personally, when I hit the edge of the screen it changes to the next active desktop. It's a very useable setup and I personally think that once we finally get people to realize the power of virtual desktops then that's the future of minipulating them.
So his statement that it's easy to hit a 1-pixel button on the edge of the screen is very inaccurate. In fact, please keep the scrollbars 1 pixel away so we don't constantly have people ramming their pointer into the sides of the screen, it will be damaging for future usablity if we all do decide that active boarders is the way to go.
I touch computers in naughty places
I think most of the issues the author raises are pretty minor. Saving a mouse click here or there is convenient, yes, but its trivial compared to real usability issues like how do I use this application without reading a manual? Large, well placed, and convenient buttons are useless if the user doesn't know what to do with them. Having a good help system that explains the purpose of the different elements of an app is essential. There's nothing worse that being stuck in a completely opaque application with no clue as to how to proceed, and the help system has no answers. For me this kind of program is CAD or (at first) the GIMP. For some users this opaque program is mozilla or outlook. From what I've seen these programs don't really cater to the beginning user that well, there's nothing to really explain the basics like what is email, the difference bewteen a browser and the internet, what is a scroll bar, etc.
Which brings me to the topic of widgets. Why can't you help-click on anything in your gui and have it explain itself? One obvious problem with such an elaborate help system like that is that the infrastructure for it is a lot of work to build. Why should I have to explain what a scroll bar is to some noob, I'm trying to write an email client here! That's why the widgets should have help built in to them.
The other thing is that a lot of the author's issues are with widgets, like scroll bars that don't go to the edge of the screen. Like most developers have control over that! 99% of developers will never bother to develop their own scroll bars to get that extra pixel. And if they did, every application would have different widgets, and that would suck too.
All that said, I do like the point about only showing the user what is really needed. Lately as the app I've been working on has grown, the menus and toolbars have begun to look more and more intimidating. Its much better to keep what the user can see down to a small set of frequently used items, and tuck the esoterica away. Otherwise they end up having to ask themselves whether they are supposed to know what every obscure menu item does, and its a lot of work to know what is important and what may be safely ignored. And that's what I want to minimize: the amount of knowledge the user needs to know to get the job done.
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
The automatic transmission shifter sequence is Park, Reverse, Neutral, Drive, Low, [Lower, [Lowest]]
Th automatic transmission gear slector must be labled as Park, Reverse, Neutral, Drive, Low ... or with the letters P, N, D, L ...
The car turns toward the right when the stearing wheel is rotated clockwise.
These standardizations are mandated by law, and have been in the USA since the 1960's. Prior to that time, shifters had various orders, and there was lots of discussion about which was best. Accidents happened when folks picked the wrong gear inadvertently. The popular public demands for safety that resulted in mandated seatbelts also resulted in automobile UI standardization of gearshifts...
I just noticed that the URL has the name "Ben Roe" in it....strangely enough, this reminds me that we should all be thankful, this Thanksgiving season, that the URL was not http://www.mikeroe.com/, for if it were, Microsoft could've sued! The horror!
The Fine Article, in its point 0, says that the user isn't trying to use the program, they're trying to get their work done. That's correct. Think of your program as a screwdriver. What's the user interface on a screwdriver? A handle. When's the last time you had to think about the handle on a screwdriver? That's a good interface.
(I don't want to get sidetracked with tool analogies, so I won't talk about why a Leatherman is good while a Swiss Army Knife is bad. Ok, I will: it's easy to access all of the functions of a Leatherman, because of the way the blades and such are arranged, but it always takes me fumbling and cursing of fingernails to get at the right part of a Swiss Army Knife.)
But TFA is mistaken to say that Ficks Law dictates placement of controls in a GUI. There are othe factors at work.
English-speaking readers (and anyone else who reads left-to-right) have been trained to read left to right, top to bottom (LTRTTB). Therefore the most important spot on the screen is the upper-left corner. Since 'Back' is the most oft-used function, its control should be in the upper-left corner.
In general, location should be sorted by relevance, since you really don't know where the mouse pointer will be. Vision is random-access, but search patterns for a person's focus are dictated by the LTRTTB training. Developers targeting, e.g., East Asian or Semitic readers (who may read in a different direction) may want to take that into account.
The other principle is cleanness. Common functions should be easy to invoke, while dangerous hacks should take more work. In no case should a user have to look outside the program to find information needed to navigate it. I cry foul on cheat sheets.
Just my take.
sigs, as if you care.
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:[.]
I agree besides, I don't even run any off my apps maximized anymore. Damn windows defaulting apps to be maximize annoys me to no end.
The problem with the computer's user-friendliness starts from the CPU. Fix the CPU, and many problems will just go away.
It may first seem to be no connection between the problem of usability and the CPU. But, if you think about it:
-computers would be way more friendly if applications were easier to make.
-in order to make easier applications, a new application model is needed. Something that separates the data from the view from the controllers. It is very difficult to concetrate on all the sides of an application. It would be much easier if one person could design the GUI while another one designs the model while another one programs the logic. And it has to be truly object-oriented.
-in order to make this easier application model, support is needed from the operating system. There is a need to go from processes to objects.
-In order to go from processes to objects, hardware support is needed. Todays CPUs offer isolation between processes, but not between objects. A missed opportunity was with the segmentation architecture of 80x86 that is not used by modern operating systems.
So there it is. Hardware support (or the shortsiteness of CPU engineers) can be partially blamed for the monolithic application model of operating systems; the monolithic application model makes application development difficult, and thus GUIs are not a top priority when making applications that are especially complex.
One would say that the Apple's Macintosh has the best GUI while operating on traditional operating system design. Well, that's true, but usability extends *beyond* pretty widgets laid out nicely.
Let me give you an example of a usability problem: the e-mail applications. Every e-mail received from one e-mail application is not shown in the others (unless of course the e-mail stays in the server), simply because the data model is not separated from the application.
There are even more problems regarding the usability of computers:
-computer files not 'strongly typed'; files are not objects in some permanent storage but rather blobs of bytes. This leads to several problems:
a) viruses disguised as useful programs.
b) files destroyed from implicit actions of applications not intended to handle them. For example if I open a Word document with Wordpad, I might destroy some part of the document.
c) open source apps can't handle proprietary-format files, thus spending too much time on reverse-engineering formats (instead of focusing to the GUI and its usability issues).
The usability problems continue:
a) when a font changes, some applications may not be immediately scalable, because applications can not be notified if fonts are changed (at least on X Windows).
b) drivers are not hot-swappable (or at least truly isolated from the rest of the system/kernel). This leads to all problems like crashing PCs etc that the other article says.
c) Distribution of updates is difficult. An application's GUI can't easily be replaced with something else. The whole application needs to be re-downloaded, even if I only want to make a simple change like changing the browser's back button.
Dispite the fact the article isn't at all graphics heavy. Google cache took bloody ages to load up here in the UK but interestingly enough Google's Text Only cache works great
For example, I never use the Anjuta IDE in anything but a maximised window. Anjuta defaults to an window almost as large as my screen when opened, with the top left corner about three pixels from the corner of the screen.
This is the one thing that really annoys me about Anjuta. Synaptic does this as well. I thought it may have been my system, but apparantly it's like that for everyone.
It's a really small problem, but extremely annoying. It would be great to see this fixed.
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!
Something about multimedia seems to drive programmers insane. Skins are great, but there is a default user interface for a given OS and programs should fricking use that interface by default. There is a way that buttons, menus, and the screen controls are supposed to look, and nothing is more annoying than opening an application that has tried so hard to look cute that you can't figure out how to close it because all the controls are hidden as hot spots in some clever bitmap image.
Brackets contain world's first nanosig, highly magnified:[.]
At Advogato: http://www.advogato.org/article/780.html - about FOSS harnessing the multitudes to perform UI design.
Now, specifically about the comments regarding Firefox: It would be monstrous to make a huge "back" button in Firefox, just because you click it more. By that reasoning, all buttons should be different size, proportionately to how likely they are to be clicked. That would be nuts! There are five buttons in Firefox. Making one of them large would mean either: the entire button bar must get fatter, or the button has to stick out over the page (might be kinda cool), or it would have to stck up into the menu bar (stupid), or it would stay the same size and the other buttons would shrink (stupid). Well, this is something he doesn't think of because this guy is obviously not much of a designer. Yeah, he can rattle off some "principles" of interface design, and they might be useful, but blindly following any principles, as this guy seems to do, will not generally lead to a good outcome. You also need to have taste.
But you can't have a theme that looks like a three year old tried to imitate Mac OS X.
(Don't get me wrong, I hate Apple as much as the next hetero, but to imitate it is real gayness.)
### 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.
As programmers we know that to optimize something
we have to have a way to measure it.
I think that a good user interface should be easy to learn and very productive.
But in most cases is easy to use (GUI's) not very productive
and very productive (like vi) is not easy to use.
So, for a ui the is tree thing to measure.
1) usability.
2) productivity.
3) the users transit time from newbie to expert.
A way to measure this would be to make a test
where you asked a user to make many similar excises.
Then the usability would relate to how fast they solved the first excises.
The productivity would relate to how fast they solved the last excises.
The transit time would be the time from the start to when the minimum excises time where reached.
Then give the same test to a group of different users to generate a representative data set.
To test a new email client you could ask the user to
isolate a specific string from each of 100 emails.
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.
The thing about technology is that it must be learned to be useful. In common terms, the wheel *was* invented, or at least, discovered, and the useful application of the same was invented.
There is a learning curve with a stapler, as any first-grade teacher will tell you. There are even third-grade teachers who probably have to remind children against the excesses of overstapling papers.
How many people here figured out, all on their own, how to use a hammer without banging their finger?
We go around thinking that we're so much smarter than the average guy because we can type or create web pages or recompile the kernel whenever we feel like it, and we completely forget that we have been taught most of these things.
objection: "I wasn't taught. I studied."
-And I suppose you studied 100% primary sources. Never once used a textbook or cliff notes, or even a dictionary. You, of course, who were never taught, discovered, without relying even upon the word of any language teacher, who it was who coined each individual word in this post, and what each word originally meant in the context in which it was first used. Come on, people, research was done over google and on the shelves at whatever bookstore we liked, but the real research in many cases was not done by the individuals reading this message.
objection:
"We just need a common interface, and everyone will adhere to it." like cars? What part of the road do people use in England? USA?
"It depends on what your definition of 'is' is."
Language is shaped by the people who use it. Some of the funniest jokes are takes of double-meaning, as are some of man's greatest tragedies.
There is not an idiot-proof interface to anything man has made! The wheel, mentioned above, in its myriad iterations, has run over countless body parts and inanimate objects, causing real damage! Now I don't have the statistics to prove that there have been injuries due to misinformation about how to use the hammer, but there must have been some.
My point is that the use of the simplest of human tools, those which couldn't be made simpler, must be taught. They also must have been learned.
That's why UIs like Emacs, Blender, GCC, etc. are both uglier and more efficient than WordPad, whatever, and Visual Studio.
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.
Err...read what you've just said, and then reflect on the reason for this article's existance.
For myself, reading the Apple HCI guidelines in ~1992 has stood me in reasonable stead, as has the HCI course I did at my final year in university. These things change of course - much of the Apple HCI guidelines of that time have been rewritten or superceded, but it was a good start.
Cheers,
Ian
For your application to be user friendly, it has to actually be friendly to the user.
This means that:
- There is no way to create, let's say, a user-friendly interface for product activation because activation is in itself a distrustful, user-hostile goal.
- If you want to avoid describing to the user what the computer is doing, whether that's because it's something underhand or because you are an insufficiently skilled explainer to be able to describe it in understandable terms, then no matter how many windows and buttons and fancy animations you include it will be obvious that you are treating the user as stupid, which is not friendly.
- If you cannot give the user useful information because it is not technically possible to do so, then do not think that giving them some information using a component from a user interfacing handbook will make your app friendly. As an example, just because it is not possible for a web-browser to provide a true time-based progress bar (which rises at constant rate and completes immediately when full) does not mean that's OK to slap in a progress bar that displays a relatively meaningless value. (What is the average user supposed to do with the knowledge of how many parts of the network download and typesetting task have been completed, especially when the parts are decided arbitrarily by the system designer and never explained?)
Amen.
GUI's should be extreamly thin clients that wrap other functionality that is also available in another form.
GUI's should be modeled like opening a book. If you close the book everything that you wrote in that book is still there.
Decoupling the GUI from the actual application is the mark of an experienced programmer.
I find that an application should have multiple ways to access it. I like to have things running in the background and have the GUI be spawned later.
This would be for use with industrial control systems real-time automation.
If the GUI crashes the application should keep running. IE: the car doesn't crash if the navigation system reboots.
Also: if a GUI is designed correctly and the app is accessed by it and used by it, then you can run the GUI from pretty much anywhere.
The Maya solution can be taken too far. This is my major complaint about Blender. While it can be very powerful, my first impression was of menus appearing and disappearing, changing contents, controls showing/hiding based on selections in other drop-down boxes. It's so modal that it's hard to find functionality if you're not in the right mode, and it's hard to identify that your current mode is even the problem.
Granted, Blender's feature set is very rich so presenting all that functionality is an extremely tricky task... but it seems to me like an example of this idea taken too far. To be fair, I haven't specifically used Maya so I'm not sure how the UI compares.
This article doesn't really bother with "the analogues" or "digital immigrants," but simply with making our user interfaces better. There are times when the computer simply gets in the way of work getting done.
/. can adapt to each new bad interface, yes. But why the hell should we? Why must every obscure feature of a program be featured prominently in the application's main toolbar, rather than tucked away somewhere that it can easily be found if it's ever needed? Why should the computer get in my way and second-guess everything that I do, rather than just make it easy to undo mistakes?
What if you bought a cell phone with buttons ordered like this:
1 2 4
9 7 #
3 6 5
8 * 0
Regardless of how tech-savvy you may be, that phone is going to be a pain in the ass to dial on. The article brings up Konqueror. I consider myself a mostly-intelligent person, but it takes me a few seconds to figure out what all those buttons in the toolbar do, and I still have no idea what things like "print preview" and "paste" are even doing in the toolbar.
It also discusses stupid dialog boxes that say "The text you searched for was not found," or "Are you sure you want to do [insert piddly little thing here]?" These things condition users to blindly click "OK," which could pose a problem when something that's actually important comes up.
People like those of us reading
I am of the opposite opinion. I constantly accidently end up grabbing the border of a window when I intend to grab the scrollbar which results in me resizing the window instead of scrolling.
Switching desktops hitting the edge is not the thing for everyone. I tried that a long time ago in Afterstep (or WindowMaker, perhaps) thinking it would be cool but I switched it off because I realised that it was more usable for me to be able to use the borders to get to some icons in the dockbar. I love virtual desktops (and tabbed browsing) but I rather switch some other way.
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
I can't imagine a draw or paint program that
would put everything in menus and not provide toolboxes full of buttons.
If a user such as a graphic designer uses a piece of software for 8 hours a day I think that user likes the tool bars a lot more than the menu.
If you have just seen a program for the first time the tool bars can be confusing.
One of the biggest problems that I have had as a GUI designer is that I am often not using the product that I make.
So I interview the users on the factory floor or who ever it is that is using it and beta to them the products.
I listen to them, take notes, talk to them, poll them, empower them.
they are the ones who are using the GUI 24/7 and they need it to be good.
Read somewhere once that there are 4 different types of user interfaces.
Video games have the best ones, but they don't make an office worker productive.
Believe it or not one of the best discussions I ever saw about it was from the Microsoft press.
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.
It said it would be wise to move the closing button a pixel or two to make the closing of programs very simple. Well that doesn't concearn me very much. Thanks to Linux, I don't close any programs. Sadly everyone else closes my programs all the time. And I loose that one week tab collection. *sob*
Mainly the problem is that users don't often want to *learn* a new piece of software, but they do want to use it. They want advanced features, but they don't want to figure them out.
That being so, in designing your interfaces (and backend) you have to do a lot of hand-holding. You have to make the basic features obvious, and the complex features easy enough to use for the average user. Often this might mean anticipating how the user expects to use a program, or by filling different controls etc etc based on default behaviors.
1) CPU load. Much of the time, I want to have a stable, quick loading OS. There should be an option to reduce or remove fancy graphical features that slow down performance.
2) Command Line access. I can't stress this enough. There needs to be more integration between the command line and the GUI, and for Windows especially, it needs to be easier to access.
3) Long loading times when the OS is partially loaded. *cough*windows*cough* This is annoying. You double click an icon and nothing happens. Why? The desktop looks loaded. What the heck is the computer thinking? There should at least be some sort of indicator telling you how close it is to being ready.
-=Zeus=And=Hades=-
Thank you for your insights Mr. Poof. It's good to have an expert on all things gay around.
But it was implemented poorly..
---- Booth was a patriot ----
Free and Open-Source Software actually has an advantage over proprietary software where user interfaces are concerned: it can be the best thing to all people.
There is no single user interface that is best for everybody. You know that too: some people prefer CLI, others prefer GUI. This means that the optimal solution is for a program to have multiple user interfaces, one for each class of user.
Having multiple user interfaces for a single piece of software is easier for open-source software than for closed-source software. Anyone can take the code and bolt on a different user interface. This does not cost the original developer anything (beyond the cost of making the software open-source).
Some F/OSS already does this. E.g. emacs can be used from the console and with a GUI, VLC has different GUIs using different toolkits, IceWM can be configured with a text editor or with a dedicated GUI app, etc.
Let's exploit this advantage and show the real potential of F/OSS!
Please correct me if I got my facts wrong.
...because everyone knows that only complete idiots couldn't adapt.
Take cars for example...I'm sure most people could adapt if you moved the trottle to the left foot. The "bipedal interface" is obsolete anyways. One only needs a single pedal on the floor for the brakes. I say we should try a hand-operated throttle instead.
And who's idea was it to arrange the gears on an automatic as PRNDL? They might be easier to find if they were sorted alphabetically--DLNPR. And what's with the antiquated idea of a steering wheel? Lets use a joystick and have a trigger for the throttle and a button on top for the horn. I also thing that the gears in a manual transmission should be arranged in a circle instead of "H" or "H with a line in the middle" pattern. Or maybe in all cases we could get high-tech and have gear selection on a pull-down menu in a touch screen on the dash.
Also, this left and right hand drive thing is dumb. Drivers should always sit in the centre of the vehicle, straddling the console.
There...much better. I'm sure there would be no confusion or resistance to these changes. Of course we could also make the automotive interface skinnable so each person could play with the positions of all the controls. I know a few people who would really love to drive from the back seat. Then everyone would be happy.
The drivers license test might be a bit more complex, but I'm sure it wouldn't be any more involved than MCSE certification.
On the first issue, I switched to using Firefox full time about a month ago (previously using Mozilla 1.x , having abandoned even touching IE for many years). As browser UIs go, Firefox is quite excellent. There are numerous little things that are delightful and easy to use. Only of few of which include:
1. SSL URLs are highlighted in yellow - much better than the "traditional" lock icon you can never find or notice
2. Just discovered the "find text" feature - joy! the highlight button is excellent. Well implemented IMO
3. Compared to IE, it goes without saying that tabbed browsing is far quicker if you power-surf a lot - just an issue with learning it up front
Overall, based on ~30 years experience with software, I'd put Firefox up on a pedestal as an example of what to emulate when doing UI compared to most OSS or even commercial software. Yes, BTW I use Mac OS X when I want the computer to "get out of my way so I can get something useful done".
On the second issue, this paper seems like the result a university lower division computer science class assignment, or he just heard a lecture on these UI concepts for the first time and decided he was an expert now.
UI design is very much a "right brain" activity (yes, I know there isn't technically such a division - stop being so left-brained!). There is as much art as science to any type of design. Being good at it is difficult if you are either "left-brained" or are forced by professional/economic circumstances to be primarily "left-brained". Like most things, you can't do "right-brained" things well without lots of practice (or "left-brained" things either). There's also usually a switching cost/delay going from one to the other unless you are well-toned in both.
In general, design is a fuzzy business. Even when you design concrete engineering things like analog circuits or software. The best engineering designers always identify themselves as/with artists as much as they identify as/with engineers. Design is always about solving an underspecified problem, so there are always extra degrees of freedom that require making unschooled guesses, engineering judgements and/or aesthetic judgements to get things done. The word "sufficiently" shows up a lot for a reason.
If you don't have a nature affinity to being an artist or thinking of yourself as an artist, you probably won't be a good UI designer. That's perfectly OK as absolutely no one is good at everything - only don't expect much when you do UI implementations without someone who is good at it.
Virtual desktops have been and gone - exposé is where it's at these days ;)
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.
What most makes sense to me is to distinguish between programs and applications. Simply-put, programs are written with the computer in mind; applications are written with the user in mind. It's the difference between NASM and Python.
Applications, at their best, are repackagings of several programs, grouped by functionality rather than by origin. An example would be:
*programs would be written to check DNS records, trace the route to a machine, check what IP addresses are connected to your computer and so on.
*An application would be written with a big button saying "find out about who I'm connected to".
The programs such as traceroute, netstat, etc are written very much to explore the computer's capacities. The application described would be written to explore the user's needs.
Applications don't have to be graphical, although this can make it far easier for the user. An excellent example of a non-graphical application is NMap - reasonably user-friendly and built around the needs of the user not the machine.
For the love of God, please learn to spell "ridiculous"!!!
If X is the new Y, and Y is "X is the new Y", solve for X.
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.
Your comments about Expose are confusing to me. By default, Expose can only be activated by pushing F10, F11, and F12. You have to go and change the settings manually if you want it to activate with a screen corner. You shouldn't have been experience this unless you explicitly asked for it, and a newbie won't accidentally trigger it unless he's playing around with his F-keys.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
This is exactly the reason that so many UIs suck so much. You have to differentiate between design for looks and design for function. Users care about pretty pictures for about one minute. After that, if your application is impossible to use (no matter how many great features it has) they will choose the simpler application that helps them get their task done.
Like everyone else I know of, my first experience with Mac OS X was on someone else's computer. =D
I recognize that it's not on by default, but it is still an excellent example of a horrendous UI bobble if your goal in UI design is to make the GUI or GUI feature as pleasant as possible for a naive user who suddenly encounters that feature for the first time.
You seem to be confused about how to apply Fitts' Law. It doesn't have anything to do with keyboard commands versus mouse commands. It's a way of comparing the speed and accuracy of commands issues by a two dimensional input device like the mouse. It doesn't have anything to do with the time required to switch between input devices, which is a different issue entirely.
Your argument that Fitts' Law has become unreasonably important doesn't make sense. It has nothing to do with whether or not there are visual shortcuts for keyboard accelerators.
You don't say how mouse gestures will "dramatically change the effects of Fitt's (sic) law". You're putting the cart before the donkey. The effects of Fitts law dramatically and positively effect the speed and reliability of mouse gestures. It sounds like you're trying to say the opposite. What do you mean?
Your statement that "The more you conform to established metaphores, the more easily you can make your product usable." is pure bullshit, but it's true that "Creating new metaphores is difficult, and getting them accepted is even more difficult."
In the field of user interface design, you should NEVER make a statement like "At no point should a person be presented with more than 9 items in a selection when one has to be chosen." That's "cargo cult design methodology", when you mindlessly repeat rules of thumb without understanting them, trying to imitate the successes of other systems by aping their surface features, but not understanding their underlying design. User interface design is all about trade-offs and context, not rigidly applying pedantic design rules you read somewhere without understanding them or pausing to consider the actual application.
Take a look and feel free: http://www.PieMenu.com
It's about none of that. It's about mimicing windows that's all. Everytime anybody tries to innovate a new GUI the masses scream that it does not look and work like "what they are used to" meaning windows.
evil is as evil does
The worst problems in the Linux/UNIX world come from user interfaces that deal with the state of the underlying system without knowing enough about what that state really is.
Printer configuration is an obvious one. Why should there even be printer configuration? When you want to print something, you should be presented with a list of available printers. Everything else should be automatic. Worst case, you might have to type in the name of a remote printer that's not on your local LAN.
1st,
the firefox button is already distinguished... by color! The button is already longer as well! it has the down arrow next to it!
Irregularly spaced items are tough to deal with...
(if he would have chosen the kde "K" button as an example, I would have been in agreement)
2nd.
Off by 1 pixel controls are very important. I don't want to accidentally blow away my work! Some tasks require extra attention, because they are extra dangerous.
3rd the other stuff seems resonable, thanks for bringing up the issue!
Please use [ informative / summarizing ] SUBJECT LINES
Flame me here
> Usability is really NOT about religion, CLI vs GUI
> or whatever, its about doing things the right way,
An obvious contradiction and why some of us tend to heckle those that are pretentious about user interface design.
A Pirate and a Puritan look the same on a balance sheet.
I see what you mean, and I get your point now. I adore Expose, but I can see where a novice might be confused. In Expose's defense, it is always deactivated when you click, no matter where, so a bit of flailing around should always get the user back to a usable state.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
THANK YOU for hitting on my biggest computer peeve... interruptions.
I won't even talk to my parents if they interrupt me, and I sure as hell can't stand when my computer does.
An appropriate dialog to pop up a box in front of me while I am working is one that says "Your computer is on fire. Please put out the fire." Anything less than that just doesn't count.
Firefox, do I care even the smallest, tiniest bit if tab 22 didn't load while I'm looking at tab 6? ABSOLUTELY NOT!! WTF.... NEVER interrupt me, firefox, and fuck you!!
This is not flamebait.. it just kills me. Can ANYONE justify that kind of interruption? Even from a person? It's disgusting. Leave me the hell alone.
Spoon not. Fork, or fork not. There is no spoon.
You seem to be confused about how Fitts' Law is applied. It doesn't have anything to do with keyboard commands versus mouse commands. It's a way of comparing the speed and accuracy of commands issues by a two dimensional input device like the mouse. It doesn't have anything to do with the time required to switch between different types of input devices like the mouse and keyboard, which is a different issue entirely.
Your argument that Fitts' Law has become unreasonably important doesn't make sense. It has nothing to do with whether or not there are visual shortcuts for keyboard accelerators.
You don't say how mouse gestures will "dramatically change the effects of Fitt's (sic) law". You're putting the cart before the donkey. Fitts' law predicts the dramatic and positive effect of speed and reliability of mouse gestures. It sounds like you're trying to say the opposite. What do you mean?
Your statement that "The more you conform to established metaphores, the more easily you can make your product usable." is pure bullshit, but of course it's true that "Creating new metaphores is difficult, and getting them accepted is even more difficult."
The Sims user interface incorporates pie menus (which Fitts' Law correctly predicts are faster and more efficient than linear menus), but it certainly doesn't confirm to established metaphores. Yet it's the top selling game of all time, and the interface has been reviewed by professional designers as "superb". So yes, it's quite possible to successfully apply Fitts' Law to user interface design, to implement an innovative, easily usable product, without confirming to established metaphores.
In the field of user interface design, you should NEVER make a statement like "At no point should a person be presented with more than 9 items in a selection when one has to be chosen." That's "cargo cult design methodology" when you mindlessly repeat rules of thumb without understanting them, trying to imitate the successes of other systems by apeing their surface features, but not understanding their underlying design. User interface design is all about understanding trade-offs and context, not rigidly applying pedantic design rules you read somewhere without understanding them or pausing to consider the actual application.
-Don
Take a look and feel free: http://www.PieMenu.com
Easy fix - the most commonly or most recently used commands automatically become toolbar buttons.
If my gigahertz computer can't handle this, then we're fucked.
Spoon not. Fork, or fork not. There is no spoon.
The guys/gals who were labelled this at my (fairly big) company, sucked at UIs.
:P)
They seemed capable of making pictures of UIs in Photoshop, and had backgrounds such as Bachelor degrees in History, etc.
But god forbid if you tried to deviate from their designs (i.e. the jpg images), as all hell would break loose.
Sorry, but as a developer, I could produce equally usable UIs, without any explicit UI training. (and my icons were better too
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
Yes, I know foober2000 needs customising to use it to it's full potential, but that doesn't mean that the 'out of the box' UI should be so awful that you have to change it!
for showing us how badly a browser can be designed... yes... except that Konqueror's primary function is as a filesystem browser, where the UP button makes perfect sense in it's location...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
``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.''
Of course there is. If it's useful to you, it's probably also useful to others. Or others might make it useful (if it's open-source). Releasing your software keeps the options open. I can only see that as a Good Thing.
Please correct me if I got my facts wrong.
Taking about Expose, I consider it something along the best invention I have seen in the GUIs on todays computers in the last years. Yes, it can be a bit annoying if you only have a slugish touchpad at hand and trigger it by excident and it might be confusing to new users, since its not obvious how it got triggered in the first place, but after all its off by default so no evil things happen.
The good thing of Expose is that it gives you one feature that everybody knows from the real world, but which is extremly seldomly seen in GUIs, I would call the 'step back' feature. With drop-down lists, tasksbars and even with different workspaces is way to easy to lose the overview, Expose gives you the freedoom to virtually step back and see whats on your desktop simply by zooming out and rearanging the windows so that everything gets visible. It makes navigating a whole heapload of windows way easier then anything else. In general the ability to 'step back' when losing the overview is what makes computers so much more inaccessible then a table and some pieces of paper.
Reason. Google doesn't cache images. ethen they arnt dum enought to provide a free webhosting capabilities with unlimited file size. They hold the text becuse they have to anyway, and people find it useful.
1 on a cli the most common way a program is used should be foo [input files] [output] with bonus points for foo [valid files in /.] [predefined output]
2 foo --settings should dump a complete settings file into .foo (or hkcu/software/) TO INCLUDE DEFAULT SETTINGS
3 noncritical dialogs should time-out (vanish after ~8 seconds)
4 a grey box skin should ship with the app
(i dont care if you are a MM program cute is only for PORNO/ kiddie programs)
5 make sure you can use your app with only a keyboard
Any person using FTFY or editing my postings agrees to a US$50.00 charge
So part of the game is figuring out how to manipulate the objects and people into the right state to enable the menu items you want.
Since The Sims game design requires that the menu items do change over time, that trumps the rule of thumb that pie menus should be used for static menus. User interface design involves weighing conflicting rules and making trade-offs according to the application and user requirements, so it's ok to break a few rules for good reasons.
An inactive TV set just has a "Turn On" menu item. When you activate it, the "Turn On" item disappears and is replaced by a bunch of items like "Turn Off", "Watch TV", "Change Channel," etc.
If you click on another Sim character, you get a menu of interpersonal interactions that the currently selected Sim can perform with the other Sim you clicked on. Those can change according to their relationships and moods.
The Dumbold Voting Machine is a free downloadable Sims object that lets your Sims vote using pie menus. The voting machine can be in different states: turned off, turned on and booted, and election started and voting. The items on the pie menu change according to the state. It also has other state variables like Printer Enable, Network Enable, Debug Mode, Voter Roll, and the Votes themselves, which you can change by monkeying around with the voting machine.
The items can vary according to the selected character: Each Sim can only vote once (unless some monkey reset the voter roll or left it in debug mode). After a Sim votes, when you click on the voting machine again, instead of getting a pie menu of candidate names, you just get an item that thanks you for voting, and reminds you can only vote once.
Pie menus are easier to use when they have eight or fewer items. But the game design requires that more than eight items be displayed some times.
So pie menus must be able to handle situations with more than eight items, and still be easy to use. The pie menus in The Sims cope with that situation in two ways: overflow items and paging. If you have more than eight items, the overflow items are put above and below the pie menu, so you can select them by pointing at them, but they're not selected as part of the pie. You have to actually move the cursor inside of the label to select the overflow items, while the pie items can be selected anywhere in their wedge shaped slices that extend to the edge of the screen.
If there are even more items than will fit in the top and bottom overflow areas, then it puts the extra items on another page that you can browse by hitting the tab key.
It's obvious how to use the overflow items, but the paging is quite obscure, with no visual indication that it's possible. It is documented in the manual and in faq's, but not many people know about it or use it, because it's rarely necessary.
The paging feature is badly designed and was put in as a last resort, more like an easter egg that can hide the last few items in overpopulated menus. But most menus don't have enough items to require paging (because that's a bad design in its own right), so it's rare that paging is ever necessary. Objects tend to put the most important menu items first, and paging was really only useful during game development when many extra debugging items were enabled.
-Don
Take a look and feel free: http://www.PieMenu.com
I know what you mean. The application our company is selling does -- or did -- exactly that, in the last version.
The first thing I did on the new version was to make all the window settings persist so that the window will appear in exactly the same state as it did the previous run.
Maximising all windows is like saying you don't want to use your entire 1600x1200 resolution as it was intended -- to display more stuff.
Karma: It's all a bunch of tree-huggin' hippy crap!
I have a number of beefs with the way Firefox does Find now.
Karma: It's all a bunch of tree-huggin' hippy crap!
Lots of mistakes are made in UI design on a conceptual level. The article touches that slightly by explaining the importance of only showing the information/controls important to the user. But it goes much further.
To show some examples from firefox: there are many settings to control privacy/security. Many users do like these settings, but not for each site. If they trust a site, they don't mind popups, images from other servers etc. But firefox does not place the site central, but the control. That's simply not how a user _thinks_.
I've got a lot of other grieves, but I'll let that pass for now. Normally I only comment on programs that I find of great use to me, also because I try not to use the others at all. The screen real estate that firefox leaves me is for instance fantastic, and it is very uncluttered.
> In programing, unexpected side-effects in functions is generally considered to be impolite. I think this applies to UI, too.
Ahhh, but don't you see, it's really the same thing. You only need to realize that the programming language is nothing but the most powerful and complex computer UI you're using.
-
Listen. Strange women lying in ponds distributing swords is no basis for a system of government.
This is not a technical problem -- it's a social problem. What's in it for a UI designer to "help" or "contribute" to an OSS project? He or she will still be a second-class citizen.
People who write code control OS projects (understandably enough) and other non-coder skill sets like UI design are second-class and after the fact or omitted completely.
Understandable because coders get you through times of no UI designers better than UI designers get you through times of no coders (apol to FFBros).
Coders are essential to having a project at all. Yet non-coders are essential to having a good project; or at the least, to getting a project out from behind the "geek curtain" and onto the desktop of ordinary folk.
But convincing coders to share power will be very difficult.
To use a Ted Nelson analogy, how were camera operators ever persuaded to give up control of movie making? Answer I bet: probably not "persauded", probably told by the guys who put up the money. Similar to commercial sfwr from good houses like Apple, where interface design is involved from the start because Steve says so.
"Go try Blender, then come back and tell us that..."
Go try Maya Unlimited, then come back and tell us that...
Go try Lightwave, then come back and tell us that...
Go try ProCAD, then come back and tell us that...
Go try [Insert powerful software here], then come back and tell us that...
Your argument is silly, because you expect powerful (and specialized) software to be designed for Ma and Pa Kettle, instead of the professional audiance it's ment for.
A PART (small part. There's no substitute for domain knowledge and experience) is good UI mockup tools. Frameworks with good interface rules embedded.
"There are multiple kinds of user, and the 'friendliest' interface is often going to be different for each type. We need to understand usability issues for all of the types, not just the commodity GUI."
Maybe a correlation between the various personality "types" and appropriate UI elements would help?
Wrong. Your configuration for changing active desktops is unique--it's your "personal" configuration. No systems I have used come by default configured that way.
My number one pet peeve about using Linux is that the the "Close" button in the top right corner is not "infinite." On my Windows box, I can slam the mouse up there and nail the button in a millisecond, without thinking. On my Linux box, I have to move there, check to make sure I'm lined up, and click it--it's much more tedious to close a window in Gnome than it is in XP.
I'm not saying that your configuration of changing active desktops isn't useful, productive, or even superior, it's just that systems don't come configured that way. They should be as user-friendly as possible when in their default setups, which would entail "infinite" scroll bars and border buttons.
This insinuates that all other text somehow be made harder to read all the time. When necessary, selected text would then become easier to read. Or perform a reverse highlight of sorts.
The idea is there but the proposed solution needs some work, for which I do not claim to have the answers.
http://www.gnustep.org/ GNUstep http://www.linuks.mine.nu/gnustep/ GNUstep
The user that the developer has in mind is himself. And for him, the software works perfectly.
What is necessary for the user community to get a good GUI design, that fits their needs, is to provide that GUI themselves. Then the users can share in the joy of creating something useful out of ethereal clay. I mean this in a positive way. In Open Source, if you want something, design it. Create it. Fix it. It is by far the fastest -- and believe me, the most fulfilling way to get what you want.
And one needn't be a software engineer. There are many ways to contribute. Storyboards of the GUI in action are an excellent start. L10N translations are wonderful.
A good example is contributing to UML design. Did you know that the simplest part of UML, the Use Case diagram, is usually the hardest part for the developer? That is because he is usually clueless about one of the basic parts of the program: what are the different ways in which this software will be used? The average user off the street can easily give this precious information.
Don't treat Open Source software like you bought it at a store, and are unhappy with it. Treat it like a fixer-upper, a do-it-yourself project, and opportunity to shine.
Of course, when you come to write the engine, the guts of your app, you need to think pretty hard what the machine's doing! But for the UI, you need to ignore most of that, and just think about the user: what are they trying to accomplish? What do they need to know to do it? How can you make it as easy as possible for them to do it? And so on.
So many bits of software clearly expect the user to have to learn how the guts of the software works, when that's rarely necessary. In the vast majority of cases, it's much better the other way around.
Ceterum censeo subscriptionem esse delendam.
Oh no another guru with a set of life changing observations. Go away...
/. news.
"Imagine users as very intelligent but very busy"
He's obviously never dealt with the same users as me or it would be "Imagine your users as 90% stupid and unmotivated/lazy, 10% intelligent and bored".
Use the edges and corners of the screen to make your controls virtually infinite
This reminds me of "When you catch the grasshoper then you will be ready to leave". What a bunch of balloni.
1. Don't put road blocks in the way of your users. 2. Only pop up a dialog if it contains useful information 3. If at all possible, use non-modal status indicators
We've gone from crptyic to obvious. I could add "4. Don't make the computer explode and kill your user". Duh!
Use the power of the computer...The computer is powerful: use the computer's power to help the user
You have never felt the power of the dark side. Join me Luke and I will complete your training!
Make similar items easy to distinguish between as summary of point 3 then in the next point...Make items easy to distinguish and find and Make items that do different things distinctive
This guy should be in charge of data backup - redundancy is a good thing there.
These five points represent a small but important part of UI design.
No sir these are the irrelevant, ill thought out prattlings of a PhD. student that have come into vogue and made it as
A better summary: Don't make your interfaces confusing by adding similar options that do very different things, and for goodness sake remember the user is trying to get something done and isn't necessarily interested in tech.
These posts express my own personal views, not those of my employer
Donald Norman's book The Design of Everyday Things
Jakob Nielsen's articles and newsletters on web design and usability testing:
Useit.com
Both are pretty good.
Do not dwell in the past, do not dream of the future, concentrate the mind on the present moment â" Buddha
Finally someone who gets it.
repeat after me: USABILITY EFFECTS EVERYONE.
One of the major problems with asking the programmer to think about usability is he's offering his time for free. And lets face it, usability isn't trivial. It could quite possibily (and i'd even go as far as to say most likely) take more time just getting the interface right than the whole rest of the program (depending on what it is).
This is where i can see something like XUL playing a great helping hand. The interface is decoupled from the code enough that any web designer can fix usability problems. It leverages the power of open source. I just wish more people would understand this and help with work on XUL (documenting/testing etc.)..
I'd like take this opportunity to post some advice spam to open-source UI designers (especially those affiliated with GNOME) :
QuickSilver for Mac OS X is the most useful new UI concept I have ever encountered. It has a smooth learning curve that's lets novices use it instantly and advanced users [I've been using it for a year] continue to increase it's utility long after most products reach an apex of mastery.
There needs to be an open-source clone of QuickSilver for GNOME or KDE!
I think that this would be an incredible boon to the open-source community, and have every desire to spam slashdot until it happens.
This annoyed me to no end. The reason I was browing with tabs was so that I could have many of them open at once, which probably means I didn't want to be interrupted when that tab did not load. My fix was to set
in about:configThis makes the pages give simple xul error pages with no dialog box, easily been the biggest improvement that about:config has given me in Firefox.
mcox.com - Useful Information re: IT, Running, Fitness, Finance, or Ann Arbor!
This thread is mostly a giant waste. The whole "complexity" issue is largely invisible in the Apple world, because Apple have made managing complexity a priority for twenty years. Meanwhile, the dominiant platform vendor, Microsoft, has made integration a distant afterthought for the last two decades. Why is anyone surprised that "complexity" is a problem on the MS side of the fence? Why would MIT's Media Lab need to start a project to "solve" this problem? The solution has been staring you in the face the whole time, but most are too proud/stubborn/macho to admit it.
Get A Mac. Believe me, Mac using workers do not lose a week a year (read the Economist article for cite) wrestling with their misbehaving computers. Mac networks are not down for an unplanned 175 hours each year. This is considered "normal" only in the Windows PC world.
"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?)."
There's what's wrong with program design. First keep in mind the primary goals of the program. Second have a holistic view of your program. Third keep your design as simple as possible, but no simpler.
Translating? Decisions further down in your program, can either complicate, or simplify the face presented to the user. Question all decisions in the face of the goals. Intelligent plugins, and scripting can shift some of the burden from you to others, and extends the life of your program.
... my parents took me (i'm from Austria) on a trip to the US (New York for a few days, then to Tampa, Florida, for a few more days) a few years ago (I was ~18 at the time).
We rented a car, which obviously was automatic. My father is an excellent driver, but he never drove an automatic before. He did pretty well, until he hit the "clutch" on the middle lane of the highway.
Pretty scary, but gladly no one got hurt.
Free as in mason.
I haven't used KDE for years and got curious when I saw a mention of this.
I'm also curious if anyone will know.
Sindri Traustason.
I don't understand what you're getting at. If it's a user option and not turned on by default, how is it a bad thing?
Some people like having Expose activated by moving the mouse to the corners, so be it. I don't happen to be one of these people, but I'm not going to fault people who want to work like this in OS X.
If I hide the taskbar in Windows, and a newbie comes along and can't find the taskbar, should he blame Windows for having bad UI design?
I'm the culprit. I posted the article because I liked it so much.
In my defense I'l say that I posted it four times to get it accepted, and the original version did have a link to the coralized copy. But alas! it got lost in the rewritings.
I found your article so clearly written and to the point that I felt that it should be seen by the Slashdot crew. In fact, I've tried once or twice to write a similar one myself (without success) so that every FOSS programmer would get a clue of what a good interface is. I hope that now at least they'll get rid of the evil alertboxes!
Sorry again for eating all your bandwith for a day.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
wrong, wrong, wrong, wrong, wrong, wrong, wrong.
You should really read something on GUI design before bitching about it. UI designers would tell you that you start with the user. Not with a widget, a gadget, a gear or a stick. The very first task of interaction design is understanding what the user needs and how is s/he going to try to get it done. You do it by making a prototype and letting the user handle it. THEN you design the interface that matches with the actions performed by the user.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Then you'll love to hear of Zoomable User Interfaces. Search for them in Wikipedia.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
In my opinion, the thing that XP's Start menu does right is providing both static and automagically-ordered shortcuts. If I start launching an application frequently, *BAM* it's suddenly at my fingertips, but the existing "All Programs" tree never changes without my explicit approval.
Granted, this approach consumes more screen real estate, but this could easily be drawn from the otherwise wasted trailing space in most menu bars and/or toolbars.
It's a freeware Windows utility called Push That Freakin' Button (PTFB). Drag the PTFB finger over a button on any annoying dialog, and it will automatically close it for you from now on.
Actually it is meant to work with standard Windows widgets, which Firefox does not use. But the PTFB author has cleverly supplied a way to push non-standard widgets: when you drag the PTFB finger over the button, hold down *both* mouse buttons - this will tell PTFB to click by *coordinate*.
Using this technique, you can make PTFB work with Firefox (or any other web browser) !!!!! Goodbye annoying login screens !!!!!
The article (and the FAQ) don't seem to escape the "user controls computer via clicking with a pointing device" mentality. Icons don't need to be large, they don't even need to be present. I'm happily using Opera with just an address and status bar, using mouse gestures and keyboard controls to navigate the interface. Mozilla supports mouse gestures too.
He also ignores the simpler interfaces that are actually very functional. Take emacs, for example. Arguably, it is a bitch to learn how to use emacs effectively; hence I expect that it would rate low on the "usability" scales. Yet it gets to the very core of point 0 (after removing the menu, tool, and scroll bars), while being inconsistent with Fitt's Law etc. In fact, if you assume the user is capable of using the keyboard (she's intelligent, after all) and a scroll wheel, points 1 and 4 are almost entirely redundant.
As for the problem with the taskbar, using a decent PS1 doesn't solve the problem, but it would be a start.