Slashdot Mirror
Software Usability As A Technical Problem
An anonymous reader writes "Let's face it. Poor user interface design is a big problem in software today, particularly in the Open Source world. A recent article on NewsForge addresses this problem from the perspective that software usability is a technical issue that Open Source developers can and should face and conquer, just as we have conquered other technical problems that have stood in our way." (Slashdot and NewsForge are both part of OSDN.)
How is this much different from this article posted just four days ago?
It's a collection of 20 or so stories about where human factors problems caused injuries and, in many cases, death. Poor documentation, unclear designs, and poor handling of expected user situations (for instance, the reactor technician being pinned to the ceiling by a control rod because there wasn't a safety stop to prevent supercriticallity) is serious business.
There's more to usabillity and human factors then just 'that guy is too stupid to use linux', it can literally be the difference between life and death.
O'Reilly has a book about Gimp and a also a pocket reference. I think the pocket reference is about $10. The pocket reference might be the way to go.
Apple's Human Interface Guidelines is a good place to start, and is online for free.
It represents many years' worth of HID research. It's not the end-all, be all of HID, but it's one helluvalot better than nothing.
-- Cerebus
IBM had some interface nightmares of it's own. Good to see they learned their lessons.
I have to use XP at work, and what I found made it much more usable is TweakUI from the Windows XP Power Toys. It exposes a lot of interface options that are hard to adjust otherwise.
r toys/xppowertoys.mspx/
http://www.microsoft.com/windowsxp/downloads/powe
[OT:] I also really, really like the desktop manager. Virtual desktops are one of my favorite features of Linux and it's really nice to have at work.
"Seek first to understand." - Socrates
Most likely a flawed "usability study" which said people want less complexity. But taking something complex and leaving it complex while hiding the options to be "discovered" at some random future time is not really reducing the complexity: it's increasing it.
To speak practically, here's what I do every time I install XP (I'll be thorough since I've already done it, so I'll just list the options the way I like them which shows the most information):
Right-click on taskbar, Properties.
Right-click on background, Properties.
Hit WindowsKey+E (to start Windows Explorer).
That's all I can remember, but then there are also settings within applications that you'll want to remove, such as in Outlook XP, select menu item Tools, Customize, Options tab: check "Always show full menus". Other applications will have similar settings.
I hope this helps. I would bet that these are all Registry entries somewhere; perhaps if I have some downtime (ha!) I'll make a .REG file out of these so the next time I set up a machine or VM I can just double-click the .REG file and be done with it. Enjoy!
I feel fantastic, and I'm still alive.
From the article:
Bulls***.
There are numerous books and resources on usability. For example:
It's not actually true - some babies have to be taught to suckle.
Pretty much all of them need some training, in fact. The rooting response, which is what causes them to seek the nipple when something touches their cheek, is instinctive, as is the sucking action once they're in place, but they have to learn how to latch on to the nipple effectively. They actually have a much easier time with the longer artificial nipples, a real breast requires them to open their mouth very wide and to place their lips well to get a good seal.
Most new mothers also don't know how to do it, simply because they've never really seen the process, in detail, for real. Hospitals have a nurse come in and teach both mother and baby how to make it work.
So, no, the nipple isn't very intuitive. There's actually very little that humans can do instinctively, and if you're ever around premature babies you quickly learn that they can do even less. They can't manage stuff like breathing, regulating their own temperature and body chemistry, etc.
Face it: Outside of the stuff that's run by the autonomic nervous system, everything people do is learned.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Is it just me or are video games way ahead of other apps on user interface.
I think it's just you, but let's take a look.
Let's take an old RTS, say Command and Conquer. The designers figured out how to make a USEABLE virual desktop that DOESN'T SUCK! You can navigate around this huge screenspace and the radar keeps track of where you are.
The goals of C&C are not that of a desktop. You can do C&C-style virtual desktop stuff by just having an enormous virtual desktop under xorg -- move your mouse to the side of the screen and it scrolls. It's not that popular -- people usually use multiple viewports. Among other things:
C&C has a very simple imaging model -- just the locations of some static sprites. It doesn't have any sub-processes running. To try to scroll a pixel at a time in xorg or Windows (assuming you aren't using the abovementioned large virtual desktop), and you'll have a ton of different processes having to redraw windows. You could use the Mac OS X approach of buffering everything, but that consumes huge amounts of memory.
C&C users are always using their mouse. They never need to type for a while, and thus have no reason to "throw their mouse to the side of the screen", as many windowing environment users like to do.
The tasks windowing environment users are doing are frequently more complex than C&C users (such as working on data in both a web brower and a word processor). Certain configurability is provided to help deal with this, like the ability to layer windows and place them spatially close to each other, so that no edge flipping is required. In C&C, if one is working with two things on different parts of the map, there is no dragging -- one must scroll.
You can navigate around this huge screenspace and the radar keeps track of where you are.
Almost every virtual desktop environment that I've seen has a pager.
Also, how do they handle things similar to launching apps? Well there's a sidebar full of big easy to distinguish one click icons, and a set of tabs at the top that switches what set of icons is displayed by type (units, buildings, etc). Seems pretty easy to figure out to me.
People have added docks to windowing environments. Basically, the main problem is that unlike C&C, one doesn't require very-low-latency access to start apps (one doesn't start apps as frequently as one queues up more units in C&C). One does use the additional screen space effectively, though. Also, even in C&C, scrolling the dock could become a problem, and I have vastly more applications than C&C does buttons.
Want to quickly get back to the thing you were last working on? You can designate hotkeys with ctrl+number an then pressing the number jumps back to it.
Not a bad idea. A few window managers can do this.
One of the things that keeps me happier with windows than linux is the at least moderate effort at standardized interfaces. Most apps of simlar types have similar interfaces and I don't have to relearn all the terms that someone decided to use THEIR names for.
Ironically enough, Microsoft makes up quite a bit of unnecessary terminology for their own software.
Every time I see a custom media player or something with this horrible neo-future interface on windows I cringe, because it's such a bad idea.
That's ironic -- I would have said that Linux is ahead here. Of the media players that I know of for Linux, there is xmms (pretty much identically bad to Winamp 2, and Winamp 3 is much worse from a consistency standpoint, much like Sonique). Other than that, most people use a *single* other application under linux (mplayer or VLC or xine) that plays all their media with the same interface. Under Windows, users need to learn QuickTime (bad interface), Windows Media Player 9 (bad interface), RealPlayer (really bad interface), and whatever their DVD players is (thus far, all the DVD p
May we never see th
It's a good example, but not for the reasons you are thinking. GUIs don't do this because it's a completely uncommon task.
I disagree that it's at all uncommon. I think it's very common. The reason end users don't demand it is because it's foreign to their way of thinking about computers and how to use them. I've seen people many times searching through a document, looking for some word and then writing something about each location. About the only thing unusual about the example is that it presumes that only a single line of context is required.
Really, I think the way most end users think about how to use computers is a negative result of the document-centric model. They don't think of data as really manipulable, because they're used to looking at a document surrounded by icons and menus that define the totality of what can be done with it. I don't know that that's really correctable without an inordinate amount of education, but I think that it's fallacious to look at the features provided by common apps and assume that anything not in the list isn't something people do often. It may very well be something they don't realize they can do, or wouldn't understand how to use effectively if it were given to them. But something that would be useful if they had it and understood it.
However, the CLI Fanclub can't get past the the idea that a GUI is crippled because it can't do the stuff nobody really wants to do anyway. They are completely confused between the concept of a "user" interface (make everyday tasks easy) and a "programmatic" interface (be infinitely flexible).
I use both GUIs and the CLI, bouncing back and forth all day long, using each for the tasks for which it's best suited. I don't think either is inherently better for all common tasks (and, of course, the CLI excels at many uncommon tasks which aren't worth coding a GUI for).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
One of the features of RDP is that you can automagically not have it show the remote desktop image. So I suggest you allow yourself to have something pretty on the background of your monitor when no applications are running.
bananas like monkeys.
I use fluxbox, and I hardly ever use submenus. If you don't want submenus, just edit your menu so it doesn't have them.
Find free books.
Keyboard shortcuts are useful. The Delphi IDE is a good example. For me, it is routine to press Ctrl-S (save) before I press F9 (run). You know, during debugging the IDE can crash, and you don't want to loose your changes with that, do you?
One could do the same thing by clicking the Save button and then the Run button, but it simply takes more time, even if the buttons weren't as small as they are now. So if one would throw away the keyboard shortcuts from Delphi, I would probably never save anymore before running (takes too much time). And we all know that isn't a very good idea.
On the other hand, for keyboard shortcuts to work, they should be consistent, very consistent. For example, take Windows 98. In almost all applications you can use Control-S to save your document. There is one exception to this, and it is called Notepad. If you press Ctrl-S in it, nothing happens. And this is very bad, because I have often been editing webpages with Notepad and asked myself why Internet Explorer wouldn't show me the things I changed.
The user should never have to tell the computer something it already knows. This is basic, and routinely violated in the Open Source world. The user should never have to fill in a blank when the computer can find out what goes in that blank. Offer a choice if necessary. Yes, much of this comes from UNIX's crappy approach to system administration. Work on that.This point is a very true one. If you use Windows and want a good example of this, look at the top two of these screenshots. On the left one, you configure the ports and IP addresses on which the server starts listening. Then, on the right you can map folders to these sockets. Now look at the right screenshot, and especially at "On IP address:". Does it make sense that there is an edit box after it?
As I developed this UI, I thought it does make sense. You could either enter an IP address from the Ports tab to do real virtual hosting, or you could enter a domain name for HTTP header based virtual hosting (now that I look at the sources again, I removed the HTTP header based virtual hosting...) However, it is still bad usability. It is used for two kinds of entries, and what do we have for that: the radio button. So if this would be properly designed, you could choose the appropriate virtual hosting method with a radio button, and then you could either enter a domain name, or choose an IP address from a drop-down list. And of course the entry that you shouldn't use is grayed out.
Great that I have now found out one more usability problem in my application, but I only did because of this article. Normally you, as a developer, code and make sure the UI works for you, and maybe you even make sure that it looks clean and simple. Yet looks can certainly be deceiving.
I like to think I've got enough theory in my head to have a good whack at user-interface design, but of course I'm not going to claim to be an expert. There are two main skills we need for user interfaces in open source software:
The second of these is the easier of the two, and I think most people can make some constructive comments about the pros and cons of a user interface designed by someone else. The first item, however, is the hardest part. To start from scratch like that requires quite a lot of background, and while some developers make a reasonable stab at it, usually by responding to how other developers handled a similar situation, that can't work for all cases.
Until such a time when we have qualified UI engineers contributing to open source projects, I think it's useful to increase the feedback between the two tasks above. The original developer uses some simple UI background to design an initial interface, then throw it to other developers and interested users and invite feedback on the interface specifically. The developers, in their role as developers, will probably point out some inconsistancies with the simple rules they have learnt, but the developers can also take the role of users and see what they find hard to do in the software.
Once that is fed back, the user interface can be refined just like the rest of the software until it's good to go. This refinement process works for the innards of the software, where perhaps the set of people able to make good comments is smaller, but everyone can have a point of view on a user interface because everyone knows what they are trying to do and what's obstructing them from doing it. Of course, we have to remember not to go overboard as some goals will be more "common" than others, but we make decisions like this in software design every day so applying similar priorities to the UI suggestions should come naturally to any seasoned open-source developer.