A few days ago I uttered a rant on user-interface problems in the Common Unix Printing System. I used it to develop the idea that the most valuable gift you can give your users is the luxury of ignorance — software that works so well, and is so discoverable to even novice users, that they don't have to read documentation or spend time and mental effort to learn about it.
This rant made it onto all the major open-source news channels, so I was expecting a fair amount of feedback (and maybe pushback). But the volume of community reaction that thundered into my mailbox far surpassed what I had been expecting — and the dominant theme, too, was a bit of a surprise. Not the hundreds of iterations of "Tell it, brother!", nor the handful of people who excoriated me as an arrogant twerp; those are both normal features of the response when I fire a broadside. No, the really interesting part was how many of the letters said. in effect, "Gee. And all this time I thought it was just me..."
Here are representative excerpts. Hostnames have been removed to guard respondents' privacy. As you read these, notice that there are a cluster of themes emerging that bear not just on CUPS but on the wider state of user-interface design under Linux.
johnrgregg: >You rock! Amen brother! I got a linux box a year and a half ago. I am >a dyed in the wool geek, a programmer by trade, assembly, C, C++. I >should have linux up in no time, with my eyes closed, right? Oh my >god, what a humbling experience. *Everything* was difficult. And I >always had this sense that I was being stupid or lazy, even though I >swear I'm neither. This sense radiated out of the mailing lists, my >friends, some corner of my own mind. I have taken notes, and I plan >to write a rant of my own, very much like yours. Reading yours was >like visiting a childhood home - around every corner, on every shelf >in every closet, there was a rush of familiarity, of recognition. [...] > >If Aunt Tillie can't run your software, scolding her for being a >brainless luser [...] buys you exactly nothing. Nothing but a 0% >market share. Aunt Tillie is *right*, you are *wrong*. She votes with >her feet. [...] Thanks for being a voice, and one with the street cred >not to be dismissed as a (sneer) newbie. rdparker: >I just wanted to say a big thanks for writing your rant. CUPS has been the >bane of my existence over the last year. Despite ~20 years of *nix >experience, I have found setting up a printer under CUPS to be an exercise >in frustration, both mine and my wife's. I seem to never be able to >configure it successfully on the first N attempts and she can't understand >why it takes me a blasted week to setup a new printer. > >Heaven forbid, I got a new USB printer and wanted to plug it into my >Linux desktop for wireless use from our Mac notebooks. I made the >mistake of doing this during finals. Ack! CUPS, even locally, seems >to have a theme of swallowing your print jobs without telling you >where they went, without giving any reasonable errors and without any >direction whatsoever as to how to correct the problem. How in the >world can a program not know that the bytes never reached the LPT >port? wmb: >Somebody pointed me to your essay about configuring CUPS after seeing a >similar rant I had posted to a company newsgroup. I've spent most of my >career working on Unix systems and opposing M$, but lately I've been >sorely tempted to go over to the dark side after wasting incredible >amounts of time trying to administer Linux systems. howe.david.act: >Utterly on the money (of course). Since I began using Linux I have been >extremely pleased with the technical improvements but utterly depressed by the >inability of Linux builders to understand the mentality of Joe Public. Your >essay could easily be applied to almost the entire Linux application base. > >I suggest that as programmers or designers, some critical useability tests >should be mandatory in a given project. Useability is an important criteria >and until this criteria is satisfied then a project is incomplete. >Functionality without useability is in most cases (when dealing with users) >totally useless. jecoleman >I'm a self-taught Linux user who usally does pretty well with whatever >I set out on but CUPS was hopeless. I felt all the more terrible about >my failure after reading all the "CUPS is great" and "CUPS is easy" >accolates on the web. I feel a bit better after reading that an alpha >geek of your status had similar difficulties. Thanks for the article >(I'm keeping it as a HOWTO). I hope it's well received. matt: >Just the other day, I went into work where I design Windows user >interfaces (flames to /dev/null I used to code in Motif but it was >clear MS cared more about UI than Unix, so I left the Unix camp. >[...] I mean, these [Unix] people worshiped at the sendmail.cf altar, >which is NOT cool in 2004. What I realized is that Linux is not a >code base. Or a distro. Or a kernel. It's an attitude. And it's >not about Open Source. It's about a bunch of people who still think >vi is a good config UI. leue: >Whoahahah! I nearly laughed myself sick while reading your essay. It is too, >too true. And I am as guilty as the next d00d at creating just such mishigoz >in my own GUIs. You should seriously consider emulating J.S. Bach and >having this one engraved in copper to stand as a warning for all eternity. >Made my day :-) housepig: >I am trying to cram some knowledge so I can get off of >MicroSoft's teats, but it's very frustrating to sit at >a box with a lovely GUI KDE desktop, and try something >simple like running Mozilla or printing a document, >and find yourself spending an hour pulling out your >hair because you didn't grow up running from the >command line. > >It's reassuring to know that even the wizards can get >lost, and get just as frustrated. There might be some >hope for me yet. jerryk: >Well, screw! Your "Luxury of Ignorance" post really struck a chord with >me... > >I did this myself for my first (and so far only) time last summer. And >I made *exactly* the same assumptions coming in to every step of the set >up (this was admittedly on RH9 and not Fedora, but your points still >seem to apply back there) as I did, along with the same (what eventually >turned out to be) mistakes... > >Although it did only take an evening to get it figured out, just a >little bit more clarity on what the vocabulary and semantics of the >entities in the CUPS printing universe really meant, both in the written >docs and in the parts that had UI, would have made this the five minute >job that it should have been... And one soluble with only the online >help of the tools involved or their manuals, rather than going to Google >and playing "Find the last jackass who has this exact problem and >pattern match..." neil: >this is your most significant peice since a) Cathedral >and b) Discovering Python. It is THE central issue for >Linux adoption. I hope you can persuade the masses - >the Linux Masses, that is, to DO SOMETHING ABOUT IT. Judah: >http://www.catb.org/~esr/writings/cups-horror.html was a WONDERFUL piece. >I relate to this piece very much because I have periodically tried *nix >OSs at home (solaris, Linux) and each time discover that for the kidns of >things your home PC needs to do, it just 'aint worth it'. Despite a degree >in CS and spending my days at IBM Research, getting simple things done in >Linux are just too time consuming to bother. abacaxi: >Thanks. Every time I mention - and I did so publically on Linux World >last spring - that those who merely want to USE Linux should not be flamed >for their reluctance to delve into the innards of the config files ... I >get flamed for wanting a user friendly setup. I'm glad to see that it's not >just me who sees room for improvement. bill: >Thanks for writing about CUPS, and its soul-stealing, mind-eating, >designed-by-a-crack-fiend-on-acid gui. > >All this time, I thought it was me.
And, for those of you who thought it was all Red Hat or Fedora'a fault and I was being too hard on the CUPS developers, here's what the lead guy on CUPS had to say:
Michael Sweet: >Overall, I really liked your piece about the problems you've had with >CUPS. It underscores several things in CUPS that we were not aware >of (you're the first to say them), but also a lot of things that Red >Hat might want to address in future Fedora releases.
I am informed that an RFE covering the issues I raised has been registered on Red Hat Bugzilla. But quibbles over who is responsible for which piece of the CUPS-configuration mess are, as the letters above reinforce, not merely beside the point but evasions of the actual problem, which is a systemic one that affects thousands of other projects and our entire community.
Up to now, we haven't been willing to do the real work of making our software usable. It doesn't matter whether the the failure of the browsing defaults in CUPS to match the documentation was a CUPS-team screwup or a Fedora screwup — Aunt Tillie doesn't care which direction that finger points, and I don't either. No, the real problem is that whoever changed the default didn't immediately fix the documentation to match it as a matter of spinal reflex.
It also doesn't matter a damn whether the shoddy and unhelpful design of the printer-configuration tool came out of a CUPS brainpan or a Fedora brainpan. What matters is that whoever was responsible never audited the interface for usability with a real user.
The CUPS mess is not a failure of one development team, or of one distribution integrator. In fact, it makes a better example because the CUPS guys and the Fedora guys are both well above the median in both general technical chops, design smarts, and attention to usability. The fact that this mess is an example of our best in action, rather than our worst, just highlights how appallingly low our standards have been.
It's time for that to change. And the really heartening thing I got from the community response is that maybe we're ready for it to change. "I thought it was just me" — many, many of you out there are already dissatisfied with the poor quality of open-source UIs. but each of you has tended to think you were alone. No longer. It's time for each and every one of you out there to become public champions for the luxury of ignorance.
Good UI design is not a result of black magic, it just requires paying attention. Being task-oriented rather than feature-oriented. Recognizing that every time you force a user to learn something, you have fallen down on your job. And that when Aunt Tillie doesn't understand your software, the fault — and the responsibility to fix it — lies not with her but with you.
Let's go back to the queue type selection screen. Remember that one? It looks like this:
Locally connected
Networked CUPS (IPP)
Networked Unix (LPD)
Networked Windows (SMB)
Networked Novell (NCP)
Networked JetDirect
This is a feature-oriented menu, not a task-oriented one. The
attitude it exhales is Oooh! Look how cool it is that we support
all these printer types!
But you know what? Aunt Tillie doesn't
care. She doesn't want to know about all the world's printer types,
she just wants to make her printer work.
A task-oriented configurator would have logic in it like this:
The technical details of these tests aren't important, and anybody who writes me arguing for a different set will have fixated on the wrong level of the problem. The point is that, unlike a command tool for techies that should give them lots of choices, the goal of a GUI is to present the user with as few decision points as possible. Remember the Macintosh dictum that the user should never have to tell the machine anything that it knows or can deduce for itself.
As few as possible decision points
is another way of stating
the guiding principle of good UI design for end-users: Allow the
user the luxury of ignorance. This does not mean that you can't
reward acquired knowledge with more choices and more power; you can
and should do that. But the user should also be able to choose to
remain ignorant and still get all their basic tasks done. The more
thoroughly software developers internalize the truth that real users
have better things to do with their time and attention than worship at
the shrine of geek technical prowess, the better off everyone will
be.
One respondent to my earlier essay observed, perceptively, that I seemed to be trying to raise the reputation value of being good at UI design. That's quite right; I think we should make a conscious effort to raise the standards of quality we demand from each other, so that blunders like the CUPS configuration mess become deeply embarrassing to all involved and are less and less often permitted to persist.
It's been twenty years since the GNU Manifesto and nearly seven
since The Cathedral and the Bazaar. I think it's time we
stopped congratulating ourselves quite so much on our dedication to
freedom and our ability to write technically superior code, and began
more often to ask What are we doing to serve the real users?
Good
UI design, and doing the right thing by Aunt Tillie, ought to be a
matter of gut-level pride of craftsmanship.
But if that's too abstract and idealistic for you, think of this. No matter how skilled you are, there are many times when you will be the end user. By learning to demand good UI from others, the time and sanity you save will ultimately be your own.
Note: Comments are owned by the poster. We are not responsible for their content.
I think that the problem with the first part was that ESR's rant mode sent other people in rant mode also.
This part gives a fine and understandable conclusion of what he really meant.
FOSS developers like to pride themselves that they are not driven by marketing, and thus have the time to release bugfree code. This is right up to a certain point.
I have worked as a programmer in an administrative environment, and I got the same complaints from my boss on the conclusion of my first assignment, that it was flawless, but too technical and did not take into account the requirements of the user.
I did not rewrite the application, but I spent more time in other applications talking with the people who needed them. All following applications where perceived as better and the users also gained confidence that they could ask me much (not anything) and that they would get a good solution in a reasonable time.
This is not an easy process. This means that you have to do more work. Not only functional requirements are needed, but also user requirements. The functional part of the software can be (mostly) written and tested on its own, but for the user interface the ability to build and present prototypes is a big requirement.
I think that the Linux Documentation Project should have something about user interface guidelines. That would be a big advantage.
I'll beg to differ on the blanket nature of this statement. I think it's safe to say some GUI's are completely crippled, some suck, some are clumsy but generally workable, but some Linux GUIs are downright slick. Frankly, it's the ones you don't even think about that are the best designs. I think we should spend less time complaining about the crippled UI's and more time thinking about the good ones, and what makes them good. I think ESR's statements about "discoverability" (is there such a word?) are pretty spot-on, but there are plenty of other well known patterns for designing good interfaces.
So, what is your favorite Linux application UI, and what makes the UI good?
Actually, he said "fewer decision points", not fewer choices. The idea being minimize questions he has to answer, not the number of possible answers. The very first question ESR should have had to answer is "Is the printer connected to this machine or another one?" That question would have eliminated most of his problems and the interface could eliminate the questions that don't make any sense to that answer. Once he answers "networked", the configuration program can then go look for computers with printers attached and suggest answers to the next question ("which computer is it on?") but still have the ability to put in the right answer if he happens to know it, even if the configuration program doesn't think it's right.
The problem with separating "newbie" interfaces from "advanced" interfaces is that there is going to be a large number of people who don't fit in either category. People whose printer setups don't fit neatly into the "wizard" setup but will be completely lost in the advanced setup.
Asking the right questions, in the right order, and suggesting likely answers without eliminating the unlikely (because they may still be the right ones) is the way to make it work. Having the computer eliminate options simply because the programmer doesn't think they're possible usually ends up in more frustration, not less.
This attitude is tired. Let's end it. You do pose an interesting question regarding the general direction of Linux however. But I am afraid the Jinni is out of the bottle on this one. So those that believe like you are going to have to focus on projects dedicated to the ideals you mention. I believe they are out there. That will in no wise slow the forward progress of making Linux more user friendly, too many people want this so it will happen.
Consider how one became a member of this group. Since the number required was small, only the most motivated and qualified individuals were needed, (think 4yr CS degree, working on Masters). With small numbers of these individuals working together , often one on one, the art of the sysadmin was passed along through what amounts to a cross between oral tradition and on-the-job training. This is essential to grasp. With users being numerous, sysadmins being few, and computers being rare and expensive, the LAST thing that would be allowed to happen is to have some green/PFY/newbie set himself down at the system console to see what he could do.
You just did not get to that point of control without FIRST knowing what you were doing. This is the root of our current difficulty with FOSS *nix software. Since Linux draws architectural inspiration from the unix world, it obtains cultural sensibilities from unix as well. One of the most pervasinve of these is that any time you need some information with which to manage the system YOU NEED TO GET IT FROM SOMEWHERE ELSE.
An example: I recently installed RH9 on a friends computer (not a multi boot.) In going through the install, I was presented with option of accepting a pre-defined partitioning scheme or specifying my own using the expert mode. If I took the easy route, the rationale for the scheme was hidden from me. If I chose the expert mode, then I was dumped off at a partitioning manager without so much as a recomendation as to what a sane partitioning scheme might be. What I would like to avoid is the following scenario:
1. get new computer
2. partition drive
3. install Linux
4. get on the internet
5. go to tldp.org and read the partitioning howto
6. learn what I should have done
7. go back to step 2
What I'm saying here is that the developers at RedHat KNEW I needed to partition my drive and yet, the options provided were: (1)"We'll do it for you, don't worry your purty little head." or (2)"You can take it from here right? Good Luck!"
How about a third possibility? A nice
"I-don't-know-what-the-hell-I'm-doing, but-I'm-a-quick-study. Please-present-me-with-relevent-information- so-I-can-make-some-reasonable-decisions."
option would be wonderful to have.
This is not dumbing the os down, but rather smartening the user up. Under the current system, what you're supposed to do is go somewhere else. That somewhere can be anywhere (google, Barnes & Noble, local guru or neighbor's dog) just go away and don't come back until you know what you're doing.
I'm not saying that becoming a competent sysadmin no longer should require in depth training. No, what I'm saying is that the vast majority of *nix systems are now single user, user administered PCs. These systems have a finite set of common problems. Problems that could largely be dealt with through user education, provided the users don't have to seek out the information through trial and error.
Perhaps a better way to frame the issue would be from the developers perspective. Consider this as an itch to scratch:
- Designing a program's UI to
- use the PC as a teaching tool to
- teach the user about the PC
- so that the user may apply that knowlege to better manage the PC
It's an interesting problem. I'm confident that powerful solutions will be found.
best regards
briber
One obvious example coming from real life which refutes this is the evolution of the modern day automobile.
You reasoning has a fundamental flaw in it: a car, or any automotive device of any kind or size or complexity you could think of, is an object that does only one task: getting your ass from point A to point B. Everything else (car stereo, air conditioner, secutiry devices, etc.) is optional, and has nothing to do with the nature of that object.
A computer is a tool that potentially could do everything a user wants to do, given skill and time. It is the way a computer was meant to be, it is the way a computer is built. Otherwise it wouldn't have been programmable, extendible and everything that makes a computer useful in everyday's use.
While ESR has a point in saying that some user interfaces are built with hackers in mind, instead of end users, never - never - think that a computer should be dumb enough to match the inherent stupidity of every "Aunt Tillie" that comes in the way. A computer is a tool: even a dumb tool like an hammer requires proper studying to avoid hurting your thumb with every stroke, or using it to saw instead of nailing down something.
So, please: stop saying that a computer should be like a car, like a microwave oven, like a toaster or like a VCR: a computer is a computer. It will never be "dumb", otherwise it would be called "PlayStation".
I don't have the resources or the time to create such a thing, but it seems to me that this issue deserves some more attention and could therefore benefit from a permanent web presence. http://www.luxuryofignorance.com seems to be available. On it there could be a core description of the issue at hand (very similar to your initial rant) a blog dedicated to the topic, a way to post UI stories and vote projects into the hall of Fame or Shame, respectively. This would enable people to draw much-needed attention to the failures of UI design and reward with praise the successes.
I don't see anything like that on the web, so it'd be nice to see such a thing built.
evildarkie
For that reason, don't blame them if the manual assumes different defaults. Blame RH.
>Many evangelists of OSS are Linux administrators and/or server-side application developers.
True. Administrators of large, strange networks, where users ask for the strangest things to work.
>These folks relish their mastery of the Unix/Linux command line arcana and feel this is part of their core skill set.
True. If they didn't know command line arcana, they couldn't be user-friendly and fix strange tasks.
> So it's not surprising that there is resistance to "dumbing down" the UI to be comparable to what "M$" has - perhaps there's a bit of nagging fear that the helpless users might be able to figure out how to do lots of things for themselves, w/o the IT expert constantly on call?
Not true. Most admins would love that their users were able to help themselves, but they are not. Don't blame the administrators! We need their skills, because ESR is completely right: the user interfaces are inconsistant, poorly documented, too many descision points and so on. It's not about GUI or CLI, it's about UI and documentation.
Donald M. Norman and Jacob Nielsen have written great books and articles about user interface design, guidelines and so on. I suggest the community go to the library this week.
An afterthought: I think the needs of the original community (configurability beyond belief) can be met, whilst the new - and much larger - "Just work, dammit!" community are happy as well. 2004- the year of UI!
It's long past time our computers started learning how to be used by us, instead of us learning how to use them.
Then they could reproduce themselves, move to a place where they can raise their descendants, christen that nation as ZeroOne, and move war against the nations of men.
Please, wake up from your dream: a tool is a tool. It is not entitled to outsmart me, you, or Joe Average User. It should do want I want it to do, the way I want it to be done, and if I have to study for achieving this, I do not see anything special in it: it happens all the time, at school, at work, at home; don't know why with computers this should be any different.
I noticed an email in the article that mentions vi as something for dinosaurs. Not so. I, in the last 4 months have come to love <A HREF="http://www.vim.org/" TITLE="vim.org">vi(m)</a vim.org>. Not because I'm a masochist but of orginal necessity and now of love.
Basically all I want to say is that those who love <A HREF="http://www.vim.org/" TITLE="vim.org">vi(m)</a vim.org> are those who love to read and type, like me, love <A HREF="http://www.vim.org/" TITLE="vim.org">vi(m)</a vim.org>'s power, like me, or they are some sort of sysadmin who doesn't have the luxury of a GUI when they login to some server under their care, be it one local or remote, like me.
Granted, I'm not freshly installing/configuring software in my job. That is another animal all together. But, in all of my computer experience:
When given the choice between making configration changes by mouse or keyboard, the keyboard is faster and more efficient. At least with <A HREF="http://www.vim.org/" TITLE="vim.org">vi(m)</a vim.org>.
All this is not to take away from the problem at hand.<A HREF="http://www.google.com/search?q=cache:P_5JAJb1384J:www.yahooligans.com/search/ligans_se%3Fp%3Dnum%253As15713+%22De+ning%C3%BAn+modo%22+%22in+no+way%22&hl=en&lr=lang_en%7Clang_pt%7Clang_es&ie=UTF-8" TITLE="google.com"> De ningún modo</a google.com>. I was already a good typist when I learned more about <A HREF="http://www.vim.org/" TITLE="vim.org">vi(m)</a vim.org>'s subtleties [translation = powerful]. Yet, it wasn't until I picked up on just how powerful [translation = quick and convenient] <A HREF="http://www.vim.org/" TITLE="vim.org">vi(m)</a vim.org> really is that I decided <A HREF="http://www.vim.org/" TITLE="vim.org">vi(m)</a vim.org> has it's place with me and my regular use at home and work.
Work isn't the only place I need to use <A HREF="http://www.vim.org/" TITLE="vim.org">vi(m)</a vim.org>. I also find it convenient for my use in my programming class at <A HREF="http://www.uta.edu/" TITLE="uta.edu">UTA</a uta.edu>.
The UNIX Printing Nightmare Continues
Posted by: Anonymous Coward on March 01, 2004 11:19 PMFor ages, UNIX printing was about arcane shell scripts in special directories and everything pretending to be a line printer from the 1960s. The only thing that seems to have happened in the last decade is that people have added another badly connected layer on top and pretended that they've solved the usability issues.
Go into a shiny dialogue, click a few buttons - who knows whether it's all doing anything underneath? Because it might as well not be doing anything at all.
#