Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
User Interface Design (for Programmers)

By codemonkey_uk in MLP
Fri Nov 03, 2000 at 09:06:01 AM EST
Tags: Technology (all tags)
Technology

Do you ever do interface design? Do you ever use an interface? Do you ever wonder why things are done the way they are? Do you ever wonder why some people love the command line, and others love a GUI? MacOS vs Windows? GNOME vs KDE? How can we make things better? Why is changing OS so hard? Then read this.

PS Not just for programmers...


ADVERTISEMENT
Sponsor: rusty
This space intentionally left blank
...because it's waiting for your ad. So why are you still reading this? Come on, get going. Read the story, and then get an ad. Alright stop it. I'm not going to say anything else. Now you're just being silly. STOP LOOKING AT ME! I'm done!
comments (24)
active | buy ad
ADVERTISEMENT
This is pure MPL. There is no extended write up, baecause I couldn't say it better than it is said here: http://joel.editthispage.com/stories/storyReader$51

Of course, once you've read it, your sure to come back and discuss the issues it raises. I'll start you with an essay question:

When should an interface model that is more efficient/powerful/flexible be chosen over the simple/obvious/natural user model?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Off Topic Polls
o Suck 24%
o Rule 16%
o Oh the irony 59%

Votes: 79
Results | Other Polls

Related Links
o this
o http://joe l.editthispage.com/stories/storyReader$51
o Also by codemonkey_uk


Display: Sort:
User Interface Design (for Programmers) | 35 comments (34 topical, 1 editorial, 0 hidden)
The APIs suck (2.75 / 8) (#2)
by evvk on Fri Nov 03, 2000 at 07:35:37 AM EST

User interface toolkits are too complex, I don't want to learn a dozen different and complex API's that suck anyway. I'd rater concentrate on the algorithmic side (or directly hack the hardware like in the good old days). Sometimes user interfaces other than command line arguments and scanf are good to have though. It'd be much nicer to deal with them (as I have suggested in my previous posting), if one could just, in a _simple_ language structure (keep that xml crap away from me!) describe the contents of the UI in general with stuff logically grouped and let the libs completely take care of how to display it and what kind of controls use for what kind of option. Be it scanf, curses, gui widgets or whatever. This approach would not work for all kinds of programs, but it should work for many programs that first get themselves configured and then do something. With a "canvas" extension for programs that display graphics (or text or whatever) even more programs could be written this way. After all, most programs have the controls and then the drawing area - text editors, news readers, word processors, browsers, etc. And the user could have exactly that kind of interface (s)he wanted, and consitent between programs. (Yes, I hated writing UIs, but I dislike modern GUIs even more so I have thought about this..).

Users usually don't think like you do (3.28 / 7) (#3)
by jmj on Fri Nov 03, 2000 at 08:21:59 AM EST

Great article.

The point about limiting user choices is a big one : over the past months I've had to adapt several of my UIs (Java Swing and HTML) to limit the number of wrong choices a user can make.
I allowed the choices in the first place because I thought the user would know what he was doing and would want that kind of flexibility, after all it was his every day job (in this case it was building Quark Xpress pages from database data). But my colleagues who did the user training reported that users made the wrong choices time after time because they didn't even think about what their choice meant.

I find it very difficult to imagine not asking myself how a program works, how much information it has, which things it can't decide for itself, ... But those are the things a typical user has no clue about, and more importantly doesn't want to be bothered with.

Users don't think like programmers. You might sometimes prefer it while redesigning/rewriting your "completely logical" user interface, but it's just not going to happen.



UI == GUI ? (2.27 / 11) (#4)
by dabadab on Fri Nov 03, 2000 at 08:25:14 AM EST

This essay seemingly makes the assumption that UI==GUI.
He also makes the assumption that programs should be optimised for ignorant novices.
(OK, in that space he makes lots of useful observations)
Well, is it just me who finds this trend disturbing?
--
Real life is overrated.
not really. (3.80 / 5) (#5)
by Defect on Fri Nov 03, 2000 at 08:55:05 AM EST

He doesn't so much as make the assumption that programs should be "optimised for ignorant novices" as he does that programs should follow what people already know and love.

For the "ignorant novices" this could be an emulation of real life (using his magnifying glass=zoom example) or say, if you were writing a program that will be used primarily by Be or Mac users in a windows environment, this could be closing a window by clicking the upper left hand corner instead of the upper right. Just those "little things" that reduce frustration.

And he may have focused on the graphical part of a user interface, the general concept (emulate what the users know) can be used in any UI.
defect - jso - joseth || a link
[ Parent ]
consistency (4.33 / 3) (#14)
by YellowBook on Fri Nov 03, 2000 at 11:49:05 AM EST

And he may have focused on the graphical part of a user interface, the general concept (emulate what the users know) can be used in any UI.

Hear, hear! If you are writing a command-line program, use getopt! Accept GNU-style long options as well as POSIX-style short options, and don't require special formatting (=, :, spaces or their absence) between options and their arguments. Allow the bundling of options that don't take arguments.

If you're writing a program with an interactive shell-like interface, use readline. Your users will thank you!

Good UI design isn't restricted to GUIs.



[ Parent ]
formatting of command-line options sucks (3.50 / 2) (#27)
by Delirium on Fri Nov 03, 2000 at 04:34:57 PM EST

Definitely! One of the worst parts of using a CLI is not only figuring out what options or combination of options to use with a particular program, but how to format them. The formatting is often done in exceedingly arcane ways, and I find myself having to look up how to use the options in many but the most-frequently used programs before I can do anything useful (even looking up the options help takes some trial and error: sometimes it's --help, sometimes it's -h, sometimes it's -?, and sometimes it's just h or ? with no hyphens). Not to mention that when I use DOS (or win32 command-line utilities) I have to remember which programs use a POSIX-style hyphen for options (like ping) and which use the old DOS-style forward slash (like dir).

[ Parent ]
Good Observations (3.62 / 8) (#6)
by farmgeek on Fri Nov 03, 2000 at 09:02:15 AM EST

Actually was a good piece and it made me think about what my programs do and how they behave. I did find it ironic that the 'next chapter' link was to the left of the 'previous chapter' link though. Considering that he kept referring to the article as a book it would have made more sense to stay consistent with the book metaphor.

I think one of the more important points of the article was that changing options should be deliberate. And that once the options are changed, you should be able to copy them from one machine to another. That way, the power user can customize one machine that he uses and have an easy way to make all the machines he uses behave the same way. Yes, I realize that this is available in some applications (long live the .ini), but is woefully absent in most.

In answer to the essay question: When it is intended for my own use. Otherwise, both should be implemented. You can use the command line model for testing to make sure the functionality is there and then design the interface to present it in the easiest way possible, but leave the command line in! Hide it if you want, but make sure it is still available if needed and make the darn thing scriptable from outside the program so that onerous tasks can be automated.


Further Reading (2.80 / 5) (#7)
by greyrat on Fri Nov 03, 2000 at 09:05:24 AM EST

As much as I don't like him or his writing style, Alan Cooper has important things to say on this subject. look for About Face and The Inmates are Running the Asylum at your local book store.

If you're interested in how to do UI better, and more on how the end-user operates, these are great starts.
~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

Excellent Article (3.00 / 8) (#8)
by Ranger Rick on Fri Nov 03, 2000 at 09:05:54 AM EST

I really enjoyed it, although the bit about Mozilla changing all the UI controls annoyed me.

The reason (or so I've heard) that they implemented their own controls is because of the need to have the interface be the same on EVERY OS that Mozilla runs on. The newest HTML/CSS/etc. specifications are very specific about placement and such, so they would have had to do a "special case" control for most everything anyways.

Witness Netscape on UNIX with it's massive Motif controls that mess up a lot of web pages that try to put pull-down bars and buttons inside toolbars.

It's not Mozilla's fault they had to rewrite all of the common controls, it was for portability and consistency with existing standards.

:wq!


New media sucks (2.25 / 4) (#11)
by evvk on Fri Nov 03, 2000 at 09:44:23 AM EST

Yeah, it is not mozilla's fault, it's the fscking web "designers'" fault. Why is is so damn hard to make pages that would not depend on a platform? I actually prefer the elegent, massive, and therefore clean motif widgets looks over the others, if I have to use a widget-based program. And I don't need stinking page design, just the content.

[ Parent ]
And... (3.00 / 3) (#13)
by Ranger Rick on Fri Nov 03, 2000 at 10:14:59 AM EST

I don't need stinking page design, just the content.

Well then you're never going to be happy. Whether those of us who just want the information like it or not, HTML has become a layout "language", not a content (hrm... markup!) language.

Just because most people have no taste doesn't mean they're gonna change it to make us happy. :)

:wq!


[ Parent ]
Why? (4.66 / 3) (#17)
by B'Trey on Fri Nov 03, 2000 at 12:06:06 PM EST

Why was it important that the interface be the same on EVERY OS? Of the people who use Mozilla, what percentage of them use it on more than one OS? (And even of those that do, is it really beneficial to have the UI uniform? I use multiple OS's, and I find that I have a set of expectations that changes depending upon the OS I'm using. I don't expect an X-windows program to behave the same way a Windows program does.)

Does having it the same benefit the user or the programmer? This brings up the question of whether a UI should even be portable. Different OS's tend to have different default behaviors. Users of those OS's therefore have different expectations. If you try to make the UI portable and identical on all OS's, you run into the situation Joel described of the Windows user trying to use a Mac.

Personally, I tend to think that programs should be written with the front end and back end as distinct from each other as possible. Port the back end, but rewrite the front end from scratch when you move to a new OS. More work? Possibly. (Trying to keep code portable is often nearly as much work as just writing it twice anyway.) But it also results in programs that are probably more comfortable and easy to use because they behave the way the user expects them to behave.

[ Parent ]

Ermmmm... (4.00 / 1) (#24)
by Parity on Fri Nov 03, 2000 at 02:57:48 PM EST

Mozilla does not act -exactly- the same on different platforms; for example, in this text box I'm in right now, at home on my Linux box, CTRL-A would put me at the beginning of the line, but here at work, under NT, CTRL-A selects all text in the box. The list goes on...

The level at which the things are the same, I believe, is in the API calls to create a pulldown menu, a pushbutton, etc, and the reason for making -that- the same on all platforms is so that the platform-specific dependencies are largely hidden from the Mozilla programmers. The reason, in turn, for that, is to prevent duplication of effort, increase reliability (if the same code runs on ten platforms, then a bugfix for any platform will fix it on all platforms), and so on.

I'm just a Mozilla user/occassional bug-reporter, not really a developer, so I don't know all the ideas behind it, but I'm sure you can still find the rationale behind the philosophy in the Mozilla developers documentation and discussion archives.

Parity None


[ Parent ]
wrappers? (none / 0) (#26)
by Delirium on Fri Nov 03, 2000 at 04:29:07 PM EST

Couldn't hiding platform API dependencies be more easily done with some wrappers rather than defining an entirely new API? You could call drop_down_menu() or whatever, but instead of implementing that yourself just have it call the standard win32 or X or Mac API to drop down a menu. Of course then your UI wouldn't be as skinnable, but I don't see that as a major advantage.

[ Parent ]
Won't work. (5.00 / 1) (#28)
by Parity on Fri Nov 03, 2000 at 05:43:36 PM EST

You can't guarantee that every environment will have a pull-down-menu, popup-menu, etc, widgets, or that they'll take the necessary arguments. You could find that you have a SomeEnvPDMenu that doesn't allow nested menus, or only takes ASCII strings, making internationalization impossible, or whatever, or they might accept only particular formats for images to put on your buttons, or.... whatever. Look at any widget and you can probably come up with a problem for it.

Also, X doesn't have a standard pulldown-menu... You'd have to 'standardize' on one of Athena, Qt, XForms, GTX+, Motif or another. Any choice you made would annoy somebody. (Lesstif would probably be the expedient choice, but I seem to recall another thread complaining about Motif widgets not working right because of the way web pages get written, which doesn't quite make sense to me, but let's leave it at 'there are concerns some people have' on that.)

Parity None


[ Parent ]
Rationales (none / 0) (#31)
by B'Trey on Sat Nov 04, 2000 at 06:29:46 AM EST

I understand their rationale. I'm just not sure that it's sufficient justification. First, it seems that interface design decisions were made to benefit the programmer rather than the user. Second, I have a hard time believing that creating an entire API and porting it to each OS is less work than rewriting the UI on each OS.

[ Parent ]
Brutal Irony (3.00 / 7) (#9)
by Hillgiant on Fri Nov 03, 2000 at 09:06:28 AM EST

For all of his talk about user expectaions and meeting those expections, he really mucked up his web page design.

The page numbers at the bottom are ordered left to right, but the navigation ``buttons" are ordered:
Next Chapter | Previous Chapter

Aren't these normally set up ``Previous|Next"? Am I the only one who finds this irritating? Why didn't Joel notice this? Is it a Mac thing?

-----
"It is impossible to say what I mean." -johnny

Most common useage (3.50 / 2) (#15)
by B'Trey on Fri Nov 03, 2000 at 11:52:14 AM EST

I'd think that the most common useage would be to read the chapters consecutively. Therefore, "Next Chapter" is the most used button and placed first.

[ Parent ]
The psychology behind it (5.00 / 2) (#22)
by loner on Fri Nov 03, 2000 at 01:28:35 PM EST

Ideally, the entire article should be displayed in a single web page, with markups that indicate separation of chapters to the browser (unfortunately such markups/browsers do not exist yet). After all, most visitors will view the article on screen, through a scrollable viewer, therefore there is no limitation to the length of a single page.

Instead Joel decided to break down the article into several "pages". As soon as this done, the typical user (not all, but most) will enliken the entire document to a book or a magazine article. Now in books/magazines written in English, one usually grabs the right part of the right page to flip to the next page, whereas one grabs the left part of the left page to flip to the previous page.

That is why usually "Previous Page" is displayed on the left and "Next Page" is displayed on the right. Because the typical user readily makes the connection between mulltiple "web pages" and a book/magazine article. Also, most web sites (most software programs in fact) use the convention Previous|Next and as Joel points out himself, breaking this convention (whether right or wrong) will lead to user frustation.

[ Parent ]

K5 links (none / 0) (#32)
by rusty on Sat Nov 04, 2000 at 04:32:04 PM EST

Note that the links beneath each comment here are:

[ Parent | Reply to this ]

This is the same concept-- "parent" will back you up a level, and "Reply" will add a new level, which IMO, is more or less a "Previous | Next" paradigm. On Slashdot, the links are reversed, and in the early days, a few people did complain about the fact that they continuously hit the wrong one here, just out of habit. Nevertheless, I stuck with our layout because I think /. has it backward.

Point of all this being that UI design is important for *everyone*, all the time, and that I do think about these things, sometimes a little over-obsessively. ;-) And also that I think you're right, it should be "Previous | Next", for English-speakers anyway.

Question: If I were writing a Hebrew web site, would the "natural" order of those be reversed?

____
Not the real rusty
[ Parent ]

Hebrew order (none / 0) (#33)
by royh on Sat Nov 04, 2000 at 10:13:27 PM EST

Question: If I were writing a Hebrew web site, would the "natural" order of those be reversed?

Yes. Note that Hebrew books have the binder on the right side and flip the other way.



[ Parent ]

Right-to-Left Languages (none / 0) (#34)
by loner on Sun Nov 05, 2000 at 04:02:12 PM EST

Not only that, in many right-to-left languages/cultures, people prefer everything to be R-to-L, including stuff like the vertical navigation bars on a typical web page. And this causes a big headache when internationalizing some software.

[ Parent ]
Good Read (3.00 / 7) (#10)
by Slamtilt on Fri Nov 03, 2000 at 09:34:32 AM EST

Not that I agree with all of it, though. He's wrong about alt-tab, for example. The behaviour he approves of (simply stepping sequentially through the list of open windows) is almost useless if you have more than a few windows open; at this point, something closer to a most-recently used way of doing it is a much more sensible approach.

Of course, this might mean changing the user model of how things should work, which he says is 'hard'. How hard, though, isn't discussed, or whether it's ever worthwhile (I would say in this case it is). Anyone got any experiences with this?


Also... (2.40 / 5) (#12)
by Slamtilt on Fri Nov 03, 2000 at 09:55:23 AM EST

... he's utterly wrong about Deja, which is now complete crap. (Sorry, just had to get that in!)

[ Parent ]
Deja... (4.00 / 1) (#29)
by B'Trey on Fri Nov 03, 2000 at 07:06:40 PM EST

I too thought the redesign of Deja stunk. I won't say that the site is utter crap, since I now use a link directly to the advanced search page on a near daily basis.

Before you can really comment about the redesign, however, there's a more basic question that needs to be asked: what is the purpose of Deja? If your answer is "to provide useful, convenient, searchable access to usenet archives," then the redesign was a dismal failure. If, however, your answer is "to provide a popular web site which will attract page views and earn advertising dollars" then the redesign was probably considered much more successful.

[ Parent ]

good and bad (3.75 / 4) (#16)
by Anonymous 242 on Fri Nov 03, 2000 at 11:55:16 AM EST

Mr. Spolsky has some good points, but he also makes some big mistakes.

It's easy because you usually don't need algorithms more sophisticated than how to center one rectangle in another. It's straightforward because when you make a mistake, you immediately see it and can correct it. It's fun, because the results of your work are immediately visible. You feel like you are sculpting the program directly.

Hmm. This implies to me that Mr. Spolsky hasn't done very much complicated GUI work on very many platforms. GUI work can be straightforward and easy to find bugs in, but it can also be a royal pain. This is especially true if one is doing maintenance for legacy code for someone that didn't do things in quite the expected fashion.

It's hard enough to make the program model conform to the user model when the models are simple. When the models become complex, it's even more unlikely. So pick the simplest possible model.

This is another no-no. The simplest model is rarely the best model. A much better maxim would be to pick the simplest appropriate model. With many types of software (and of hardware) the simplest model diminishes flexibility. A case in point, the Unix shells are much more complicated than the DOS/Windows command prompt. The complexity added by shell expansion, job control, named pipes, etc. also add tremendous flexiblity. Mr. Spolsky's article in fact raises a point where the simplest solution isn't the best solution.

On Windows, when a message box pops up, you can hit enter or the space bar to dismiss the message box. On the Mac, space doesn't work. You usually need to click with the mouse. When Pete got alerts, he tried to dismiss them using the space bar, like he's been doing subconsciously for the last six years. The first time, nothing happened. Without even being aware of it, Pete banged the space bar harder, since he thought that the problem must be that the Mac did not register his tapping the space bar. Actually, it did -- but it didn't care! Eventually he used the mouse. Another tiny frustration.

[snip]

Right, Pete. We know better. His feelings come despite the fact that the Macintosh really is quite easy to use -- for Mac users. It's totally arbitrary which key you press to close a window.

The ability to assign an arbitrary key press is much less simple than mapping the space bar to triggering a control. Mr. Spolsky seems to be arguing that the less simple decision is superior. In doing so, Mr. Spolsky invalidates the rule he later tells the reader to adhere to.

There will always a trade off between functionality and and simplicity. An automobile with an automatic transmission is simpler for most users to operate. On the other hand, starting the automobile with a dead battery, driving in inclement weather and accelerating at maximum rates are all handled more adroitly by a manual transmission.

There is a lots of good stuff in there, but one has to wade through with a critical eye in order to dig it out.

(Way off topic, but...:) (3.50 / 2) (#18)
by trhurler on Fri Nov 03, 2000 at 12:13:33 PM EST

. . . accelerating at maximum rates are all handled more adroitly by a manual transmission.
This isn't necessarily true anymore. It was, and it still can be, but the best performing automatic transmissions shift a lot faster than any human being ever will, and certain(rather expensive) models have some disturbingly sophisticated heuristics (and sensors to feed them,) for when to shift and when not to(the latter being the more important one; spurious shifts are a real pain to someone trying to really push a car.) Most of us have neither use nor desire for such things, but on certain race circuits, they're a necessity, and a few of the really amazing supercars have them because, quite frankly, no human being can reliably react fast enough to properly handle those cars with manual transmissions. ("What? It blows through first gear in 3/4 of a second?!") Other supercars simply make the low gears really long and rely on insane hp/torque numbers to make it feasible; I'm aware of one that can actually hit 60mph in first gear and therefore has a human-usable manual(Lamborghini Diablo 6.0, for anyone who cares.)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
[OT] 60 MPH in 1st gear (3.00 / 1) (#20)
by Anonymous 242 on Fri Nov 03, 2000 at 12:27:20 PM EST

I'm aware of one that can actually hit 60mph in first gear and therefore has a human-usable manual(Lamborghini Diablo 6.0, for anyone who cares.)

Hmm. Impressive.

Then again, when young and stupid I found out that my battered old four speed 1982 Toyota Tercel/Corolla could hit 60 MPH in 1st gear.

It didn't sound very happy doing it either, but it survived intact. The transmission didn't fall out until well over a year later. ;)

[ Parent ]

Ok... (none / 0) (#23)
by trhurler on Fri Nov 03, 2000 at 01:30:09 PM EST

I admit, I should have said "without risk of firing pistons through the hood." :)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
If You're Going to Go 60 (2.00 / 1) (#21)
by greyrat on Fri Nov 03, 2000 at 12:35:32 PM EST

You should do it in SECOND gear. the torque band is a bit better there.

Did I mention that this was for the Toyota? #;^)
~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

[ Parent ]
Not quite so bad... (4.00 / 1) (#25)
by B'Trey on Fri Nov 03, 2000 at 03:28:08 PM EST

I don't think any of the points you indicated are really "big mistakes".

First, Mr. Spolsky's description of GUI programming us usually correct. Certainly, it CAN occasionally get hairy, particularly if you're working on a system where, for whatever reason, you can't use standard widgets. But MOST GUI programming is done via a widget library of some sort which makes it quite straightforward.

Second, I think the idea of picking the simplest model which performs the job needed is inherent in Mr. Spolsky's advice. The corrolary of this is to make sure that you really need the power you're providing. I don't think DOS would have been improved had it included the arcane power of a *NIX shell. DOS was intended for the business user - the target market for the first desktop computer systems. They didn't NEED all of that power, and the much steeper learning curve would have likely hindered sales. The success of utilities such as Norton's Power Tools indicated that the DOS command line was probably a bit too sparse, but it's simplicity seved it well for that particular market.

Finally, I'm not sure exactly what you mean when you say "The ability to assign an arbitrary key press is much less simple than mapping the space bar to triggering a control. Mr. Spolsky seems to be arguing that the less simple decision is superior." Mr. Spolsky wasn't referring to remapping the keys. The decision of which key to press to close a Window is an arbitrary decision of the programmer, not the user. Alt-F4 is no better or worse choice than F-7. If, however, a particular key press is standard on a particular platform, you need to use that particular key because that's what the user expects. Switching OS's is frustrating precisely because so many such decisions are arbitrary on the part of the programmer and/or system designer and the user has to learn new expectations.

The trade off between functionality and simplicity is discussed through out the work. How often do you need to start a vehicle with a dead battery or accelerate at a maximum rate? A clutch is better in inclement weather only if you're a skilled enough driver to use it effectively - many drivers aren't. Is the increase in functionality, which only applies in a small fraction of situations, worth the extra effort involved in the use of clutch all the other times? In most cases, no. For special purpose vehicles - sports cars, off road vehicles, etc, it might be. Mr. Spolsky addresses this when he talks about imagining a user. The typical user for a *NIX back-up utility is different than a typical user for a word processor. Design your UI with that typical user in mind.

[ Parent ]

Your question (2.66 / 6) (#19)
by loner on Fri Nov 03, 2000 at 12:19:00 PM EST

Sorry I haven't read the article yet, but let me answer your question with a good rule of thumb. First, "simple/obvious/natural" does not necessarily mean not "efficient/powerful/flexible", but I'm nitpicking. I believe you meant compromise ease-of-use for power. My personal rule of thumb is this:

If the program/function/object is used everyday by the same person, make it as complicated as necessary (without breaking any general UI rules) because then the user can justify taking the time to learn the program's operation.

But if that thing is used occasionally by non-specialist, then it should be simple and obvious (or at least have a simple and obvious mode), because the user does not want to, say, spend two hours every week learning to operate something for a few minutes.

Example: a CAD system is used by specialist on a daily basis, make it more complicated if that is the best way to provide better functionality, the CAD engineer will take the time to learn its operation. What would be nice is if all CAD systems were alike, kinda like bicycles: it takes a long time to learn to ride one, but then it becomes obvious how to ride most other bicycles.

As far as UI design in general, UI design is a special part of HCI (human computer interface) which is a special part of design in general. If you want to do UI design well, read the book "The Design of Everyday Things" by Donald Norman. Or better yet, read the book "The Design of Everyday Things" by Donald Norman.

As far as the linked web site itself, I had to scroll to the bottom of the page to find out that there are multiple pages to the story. Since I don't visit that web page everyday, this should have been made more obvious, say by duplicating the chapter[sic] links at the top of the page as well.

Which brings me to psychology which is a big part of UI design. The designer should try to anticipate the user's state of mind. For example, the linked article: it is quite possible that the visitor is in hurry and will just print the page to read it later on the bus. If it is not immediately obvious that this article is in multiple pages, the user might get a nasty surprise later on in the bus.

Anyway, sorry to ramble on. What I really want to say is: all UI designers should read the book "The Design of Everyday Things" by Donald Norman.

Patterns of Use: [the myth of] Simplicity vs Power (4.00 / 3) (#30)
by gnomon on Fri Nov 03, 2000 at 10:46:42 PM EST

I read over the full text of this article (what can I say, Fridays at the office are slow) and thought that it was quite an interesting read, even if I don't agree with several portions of it. It sparked an entire group of areas on which I wish to comment, though, so I ask you in advance to please forgive the topic-jumping into which this will probably descend. I'll try to keep the different sections distinct.

<p class="sectionbreak">Patterns of Use

I've got to admit, right off the bat, that I'm an entrenched computing elitist. I have no illusions about the fact that my habits are widespread or even optimal (I tend to compulsively shift-J (vi: join line, for all you who have not yet seen the light ;) text with hard linebreaks between paragraph tags when editing HTML, for example. This stems from my twin beliefs that ((a) the menial job of line-wrapping should be left up to the computer), and ((b) if I'm editing text in an editor that is 300 columns wide, I damned well want to see lines that contain as near to 300 characters as possible. If I did not, I would have resized my editor to begin with)), so I don't think that everyone should adopt my style (hell, if everyone did, the world would explode).

This being said, there is still some truth that I can see by comparing (or, as is more common, contrasting) my style of use with those of others. Everyone tends to have a specific group of actions performed sooner or later during the course of running a program. I normally tend to examine the command-line options (if they exist), read through the configuration files (whether or not they are binary - there are some gems hidden in there sometime. Has anyone every bothered to look through the executable file for Dark Forces (the first one)? Scroll to the very end (shift-G) if you get the chance), thoroughly read through the documentation, cycle through some common tasks once or twice and then customize the hell out of it. I tend to avoid pointing devices in general, and try to ensure that my hands spend as much time on the keyboard as possible (in fact, my adoption of this discipline normally makes people think I'm an expert user with any program I use, even though it may be the first time, simply because I can operate the program in such a frictionless fashion). I read all dialog boxes and pop-up messages (at least the first time), but I also tend to quickly build up a library of "recognizable" boxes that can then be safely acted upon without delay.

My pattern is almost the exact opposite of the one alluded to in the article, which sums up at one point that "Users don't read stuff; Users can't use the mouse (where he actually argues that users can't use the mouse well, not that they eschew the little desk rodent entirely); Users can't remember anything" (see the bottom of page 8 for reference). However, there is still insight to be drawn - people tend to fall into patterns of use that persist across sessions, programs and even entire environments (I tend to read the manuals of electronic devices and other toys that I buy; friends of mine who religiously ignore pop-ups and alert boxes often begin answering test questions before having fully read them). Via these patterns, they - we - develop the expectations of which Joel Spolsky writes: witness the anecdote of a Windows user trying to help a friend with her Macintosh (on the first page, search for "iBook") who is frustrated because it does not work the way he expects.

Now, unlike the author, I am not saying that what the majority of people expect is uniformly right. If my fellow geek friends used their computers like everyone else I know, I'd end up carrying around a baseball bat as an educational aid. By all means, make any program obey convention - make it behave like everything else on the market. But for the love of $DEITY, do not force me have to conform to the patterns of some other demographic! If I care enough about different defaults to change them, I will either already have the technical know-how to do so or I will quickly learn! Offer defaults, but don't enforce them. Frankly, if every program that presently features "skinnability" would instead allow the modification of the interface (hell, I'd settle for keyboard remapping, given that the studded oblong board is my physical interface of choice - but again, that's just me), I'd be ecstatic.

<p class="sectionbreak">The Myth of "Simple (limited; many new converts) versus Powerful (general; hardcore zealotry)"

There's this persistent belief that something can either be simple or powerful. People bring it up all the time during debates with huge topical ranges: *nix vs. Windows, Windows vs. Macintosh, manual transmission vs. automatic, DVD vs. VHS (I kid you not, I've overheard arguments about whether or not it's worthwhile buying the DVD version of a film because of the added overhead of navigating through the menu to get to the film, whereas with VHS "you just stick it in and it plays"), multiple-choice (machine-readable "Scantron") vs. short-answer tests in school, N64 controllers vs. PlayStation controllers... the list goes on and on (note that I've focussed mainly on (perceived) technical dichotomies; the meme itself, though, of [simple, limited, with a large flock of new users] vs. [powerful, general, with a small core of dedicated fanatics] is very widespread. Take a moment or two to consider it in relation to any long-standing debate that comes to mind - it may be applicable, sometimes in a surprising fashion).

This dichotomy does not necessarily exist, though - it /is/ possible to build a simple, easily-approachable system that also contains great depth, power and subtlety to those who take the time to immerse themselves. Consider language - although daunting in its entirety, a foreign language can be partitioned into small, easily-digestable chunks: conversational guides and the like rely on this approach. You don't need to be able to create literary works of the depth and power of Dantes Inferno in order to ask where the bathroom is during your next visit to Italy. You don't need to understand the internal workings of the microcontroller at the heart of your VCR in order to watch a movie (hell, the profusion of blinking "12:00"s is evidence enough that you don't need to grasp an entire system in order to use it in an effective fashion). For many systems, it is not necessary to master all the quirks and complexities thereof in order to be productive or to accomplish your goals.

How about an example: a "search" function implemented in, for example, a web browser. Right now, I can't think of a mainstream (I don't count Lynx as mainstream, although I am fond of it) browser that offers more than a simple case insensitive match-search. Now, sometimes I yearn for full Perl-style regular-expression matching - especially when browsing through huge, hundred-plus-kilobyte documents. If I had the time and energy, I might even hack something together and drop into Mozilla (who knows, it may already have been implemented - everything else seems to have been (disclaimer: I'm a huge Mozilla fan, and have been among the first to cry "foul" when people unduly lambast it... but it is getting a little feature-rich these days)). You'd be hard-pressed, though, to find anyone who would suggest that any user wanting to search through text should be forced to learn regex syntax (well, OK, I'm sure we all know at least one curmudgeon who'd wholeheartedly support that idea, but you get my point). It is not necessary to make a black-and-white decision to support one or the other, however - there is plenty of middle ground to cover. You could implement a filtering system like the one present in Eudora Pro ("item contains [] ((and/or)(does/does not) contain [] ...)), which is a more powerful and flexible version of a full-text search, or you could implement Rebol-style parsing rules (pages 429 through 456 are relevant), which act like demystified regexes (I love regexes - I mean love them, which is probably unhealthy somehow. but I'll be the first to admit that they're cryptic. A non-programmer (test-case: my father) read and understood a Rebol parsing rule on the second try). Neither of these suggestions is the perfect balance between power and simplicity, of course, but I would go so far as to say that the Rebol solution is as powerful as a traditional regex while being comprehensible enough for relative neophytes to employ as a viable solution.

I'd also like to attack another commonly-held illusion: that of the balance between widespread acceptance and critical acclaim. It would be a pretty silly claim to make that most users consider (vi|emacs) to be their primary editor, but for those who do, it's a very personal and vigorously-defended choice (hey, everyone has to have a crusade, no?) ("Why would I want to download $Word_Processor? I can do my writing in LaTeX-mode, after which I can upload it to the space on my shell account via angeftp, filter it into HTML and re-read it via W3. Do that in WordPerfect!" ... "Why would I want to download $Word_Processor? I can do all my troff authoring in a task-specific, space- and CPU-efficient editor, do all my editing with a minimum of keystrokes and render the output without having to quit my program to free up the RAM. Hey, shut up - real users use troff. And vi. Well, I guess Vim is OK."). In this case, they're not terribly widespread (in general - I know that the intersection of (((vi) OR (emacs))-users AND (kuro5hin.org-readers)) is probably pretty large, but in this case I'm referring to all computer users - that includes your Mac-loving grandmother) but they have a dedicated and knowledgeable core of users. On the other end of the spectrum, there's Adaptec EasyCD Creator, which is just about as ubiquitous, widespread and beginner-friendly as you can get (although more advanced features have accreted over the past dozen or so releases, they remain mostly hidden). I don't know many people who take their CD burning seriously that use it, though - more often, they've graduated to Nero or CDRWin which, although more complicated, are substantially more versatile.

This doesn't mean that there are only two real classes of programs ("aimed at those who know no better" and "intended for hardcore users"), though. Winamp is a great example of a program that's very beginner-friendly and yet still has a great deal of customizability available to those that go searching for it. Internet Explorer (shudder) and Netscape more or less fit into the same category, although both are getting a little top-heavy these days. None of these examples offer a very smooth graduation curve from beginner to advanced - there's a plateau beyond which most beginners won't venture, and everything above this division tends to be aimed at the archetypal technical user, not the beginner who is looking to learn more - but my point is that it's not necessary to pander to one audience or the other.

<p class="sectionbreak">To Sum Up

The point of all this blathering is that it's not necessary to aim solely for the lowest common denominator. This article seems to reccomend that any interface should present the "path of least surprise" to every user in order to increase productivity. I would tentatively agree with this, but only if this is done without placing an artificial cap on the ease with which an expert user can manipulate the program - if someone writes a program that, for example, makes it really easy to put together graphs, and is really easy to pick up because it's only got six well-defined, round-edged buttons that make everything work, but that will only graph, say, bar-charts with ten or fewer samples, then by golly I'll take the time to learn Gnuplot or Maple or Mathcad. It's important to make a program easy to use and learn, but only if this is done without restricting power and generality. You can only simplify a task up to a certain point, beyond which you start losing potential power. It's like perceptual audio coding - you can only throw away so much useless stuff before you start seriously cutting into signal quality, no matter how clever your algorithms and heuristics.

Moral of the story: "Make things as simple as possible, but no simpler". (A. Einstein)

...

...

My God, I wrote a novel. I should have wrapped that up pages ago. Someone stop me before I post again.



Hmm... (3.00 / 3) (#35)
by Matrix on Mon Nov 06, 2000 at 07:00:09 PM EST

In general a good article, but I'm going to pick apart some points. Just for the heck of it. ^_^

Most advanced users use several computers regularly; they upgrade their computer every couple of years, they reinstall their operating system every three weeks. It's true that the first time they realized you could completely remap the keyboard in Word, they changed everything around to be more to their liking, but as soon as they upgraded to Windows 95 those settings got lost, and they weren't the same at work, and eventually they just stopped reconfiguring things. I've asked a lot of my "power user" friends about this; hardly any of them do any customization other than the bare minimum necessary to make their system behave reasonably.

Here, he's making too many generalizations. I know a lot of people (myself included, sometimes) who verge on obsessive when it comes to how their environment looks and acts. For me, its the interface I use when I'm using a computer. I've got certant things about an interface I like, and certant things I don't like. I prefer white text on a dark background. I like single-click-select, double-click-activate. I don't like excessive amounts of extra flash. I have certant key combos I expect to do certant things.

Yes, I understand that people don't want to be accidentally reconfiguring their environment. But please, please, please don't completely lock out those of us who like things done differently. Give us some way to set up things to fit our tastes.

The funny thing is that the very reason Emacs interprets Ctrl+Z as minimize is for "consistency" with that terrific user interface, csh, the C shell from UNIX.

I don't know if its me, but this sentance seems to be making it out to be wrong for a Unix program to act like other Unix programs... Pretty much every Unix command-line program I've seen has interpreted Ctrl-Z as "suspend." What, should they all change their interfaces to act like Windows? The Unix UI is perfectly friendly to those who don't already expect something else. Most Unix editors of a specific flavour generally work the same way. They've evolved to work this way over Unix's lifespan, and changing it would cause pain in a lot of people.

Don't even get me started about Netscape 6.

They've already addressed this. The current default skin acts almost exactly like Netscape 4.x's interface used to. Of course, I don't know if Netscape 6 has followed suit, and I really don't care. And, of course, he does take the opportunity to get started on Mozilla....

Netscape 6.0 goes so far as to reimplement every single common Windows control.

Yeah, and do you know why Mozilla does this? Because, in order to comply with the CSS and HTML standards, its actually easier to write your own widget set then it is to try and get pretty much any other widget set ever created to size things exactly right. Plus, with Mozilla, you get a fairly standard set of widgets no matter what platform you're on. And isn't that what he's saying is the best thing ever?

And this is, fundamentally, the reason why command line interfaces are just not better than GUI interfaces, no matter what your UNIX friends tell you.

Now that's just plain biased. I know a sizable number of people who are far more comfortable with a command-line or text interface than a fancy graphical interface. The way a CLI works just happens to mesh well with the way they think. Some even find GUIs unusable.

As for guessing what you want to type... I know very few people who like this feature. Even those who don't regularly use computers can't stand it. Personally, I think its good sometimes. But I like it how BASH gives me the option of doing it, through the Tab key. His generalizations about the number of people who can use Linux are equally biased, especially with projects like KDE and GNOME.

As for the poster's question... I'd say go for efficient/powerful/flexible. No matter what, the user is going to have to learn something to use the computer. If they have to learn a bit more, but can customize things to work the way they think and can do more through the interface, then it will almost always be better for them.


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett

User Interface Design (for Programmers) | 35 comments (34 topical, 1 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!