Jonathan's Corner
(Sitemap)
> Orthodox Books Online, and More >
Technology >
Usability for Hackers
Previous
1
2
3
4
5
Next
Printer-Friendly Version
The open source community is largely driven by scratching itches, but scratching a programmer's itch is a terrible way to approach user interface design.
The story is told of a program used in an office where a popup window appeared and said, "Type mismatch." And the secretary obediently typed M-I-S-M-A-T-C-H, a perfectly appropriate user response to an inappropriate error message. (This kind of thing shows up in many more subtle ways, some of which are not so obviously wrong.)
Designing a user interface that makes sense to someone who understands its inner workings, and designing a user interface that makes sense to its intended audience, are not the same thing. A mechanic's understanding of how a car starts is very elaborate and detailed, but a user should be able to get by thinking, "I turn the key and press the gas, and the car starts" without necessarily thinking anything about what's under the hood. If users need to understand what's under the hood to operate the car, the car needs improvement.
The jargon file defines the extremely pejorative "PEBKAC" as:
[Abbrev., "Problem Exists Between Keyboard And Chair"] Used by support people, particularly at call centers and help desks. Not used with the public. Denotes pilot error as the cause of the crash, especially stupid errors that even a luser could figure out. Very derogatory. Usage: 'Did you ever figure out why that guy couldn't print?' 'Yeah, he kept cancelling the operation before it could finish. PEBKAC'. See also ID10T. Compare pilot error, UBD.
And the particular example is unfortunately revealing of an attitude user interface people need to avoid like the plague.
It is common enough in computer programs to have modal dialog boxes; the humble JavaScript alert("Hello, world!"); is one of innumerable ways to get them. And what they mean from an ordinary nontechnical user perspective is, "A box popped up, probably one that you don't want and may not understand. What is even more annoying is that it is blocking your work; you can't continue what you are doing until you get rid of it." And so an entirely appropriate way to deal with these annoyances is get rid of them as quickly as possible.
The example given in the jargon file's definition of "PEBKAC" is, "'Did you ever figure out why that guy couldn't print?' 'Yeah, he kept canceling the operation before it could finish. PEBKAC.'" For a long time, at least, attempting to print from a GUI gave something that looked like a modal dialog box, but for this "modal dialog lookalike", there is one important difference in behavior. When you click on the button to make it go away, it destroys your print job.
This is not a case of a problem existing between the user's keyboard and chair.
It is a case of a problem existing between the user interface designer's keyboard and chair. PEBKAC.
To pick on the jargon file a little more, "Drool-proof paper" is defined as:
Documentation that has been obsessively dumbed down, to the point where only a cretin could bear to read it, is said to have succumbed to the "drool-proof paper syndrome" or to have been "written on drool-proof paper". For example, this is an actual quote from Apple Computer's LaserWriter manual: "Do not expose your LaserWriter to open fire or flame."
Let's ignore the fact that this sounds less like a technical writer trying to be easy to understand, than corporate legal counsel trying to ward off ambulance chasers.
There is a very user-hostile attitude here, the basic idea that if your system is too difficult for your users to understand, the users must be too stupid, and making something user-friendly is a matter of stretching to meet people you shouldn't have to cater to. Stories and terms like this circulate among programmers. I might suggest that terms like these, for your software's audience, are little, if any, better than a racial slur. They reflect an attitude we don't need.
You do not really understand Python until you understand something about usability as it appears in Python. Usability is the soul of 'Pythonic'.
There is something genuinely different about Python, and to explain it I would like to discuss the advantages of C.
If you want to nano-optimize every ounce of performance you can get, there is little serious competition to C. You can write assembler for different platforms, or write in a C++ that is multiparadigm like Python and have some parts of your program use high-level features like objects, templates, and operator overloading, while still writing almost unadulterated C for parts that are performance-critical. And the group of programmers that "vote with their keyboards" for using C this way, includes Guido van Rossum, who created Python. The first and canonical Python implementation is written in C, and a Pythonista underscoring the point that Python's switch statement is a very efficient dictionary will explain that Python's dictionary is implemented in tightly optimized C.
But this kind of advantage comes at a price. In the canonical list of ways to shoot yourself in the foot in different programming languages, C is "for people who want to load their own rounds before shooting themselves in the foot." In one Python forum, a wannabe 133t hax0r asked how to write a buffer overflow in Python, and a wry Pythonista replied apologetically: "We're sorry, but Python doesn't support that feature." But C does support the "feature" of buffer overflows; its default string handling never leaves home without it. With manual memory management and manual handling of pointers, C also supports "features" including all kinds of memory leaks and subtle pointer errors that can be extremely difficult to debug. Python closes this Pandora's box, although Python is hardly the only language with the wisdom to do so. Python, PHP, Ruby, Perl, Tcl, and Java all close the Pandora's box that must be wide open if you are to have tightly optimized C.
C has been called a language that combines the power of using assembler with the ease of using assembler, and I know of no compiled language that surpasses C for power over bare metal, or for corresponding possibilities for tight optimization. However, this is not the only way to keep score. Python keeps score by another metric: programmer productivity.
The one overriding concern motivating decisions in Python is not how you can get the tightest control over the computer's productivity. It's how to let the programmer be most productive, and it has been said of this relentless pursuit of programmer productivity that capital sentences are passed with less thorough deliberation than obscure Python features. And if you've used Python, the difference you have experienced is precisely because of this one overriding concern, this relentless pursuit. The people in charge of Python have decided that Python isn't about what to do to optimize the computer; it's about what you do to empower the programmer.
If you're interested in usability, you have a good working example of usability to look at. To put Python's strength a little differently, Python is a language where the one overriding concern and relentless pursuit is usability for you, the programmer. If you are working on usability, you are working to give end-users the same kind of thing that Python gives you. You are making a product more Pythonic to use, as opposed to giving the more C-like experience of an interface that lets users load their own rounds before shooting themselves in the foot.
Usability is about how to go from giving C user interfaces, to giving Pythonic user interfaces.
The Case for Uncreative Web Design
So, You've Hired a Hacker (Revised and Expanded)
Usability, the Soul of Python: An Introduction to the Python Programming Language
Jonathan's Corner
(Sitemap)
> Orthodox Books Online, and More >
Technology >
Usability for Hackers
Previous
1
2
3
4
5
Next
Printer-Friendly Version