Human Engineering - Do you need it?

Posted 12 Apr 2002 at 10:56 UTC by shlomif Share This

Most Developers would agree that good human engineering is necessary for the success and acceptance of a project. However, most of them do not understand that human engineering transcends down to the product and design decisions.

Kindly answering questions of users is short-term human engineering. It is usually a necessity. However, what if for example, a user asks if a feature is present, and you answer him that he isn't? OK, the user would be happy to know that the developer is there for him, but he would also feel bitter that the feature isn't present. Now, long-term human engineering is about adding those features that user need most.

GUI Design is good human engineering, but human engineering also applies to the design of command-line programs or of APIs. If an API is hard to use or lacks some basic features that a user would expect, the user may decide to hack something of his own instead. Similarly, if a command line program is inconsistent, obscure or unnecessarily complicated, the user will abandon it.

Backward Compatibility should be maintained as much as possible to allow users to make use of new versions of the software, and to retain old code. Again, it should not be maintained at all costs. Sometimes, breaking it would eventually make users happier than writing kludgly interfaces that maintain it.

The choice of the license is an important human engineering decision. Some developers see the license as a statement of intent rather than a non-negotiable terms of use. For example, if you'll ask many developers of a GPLed library, to exempt it for you for use in a "proprietary" product, they may agree, even without charge. Some people automatically assume that the GPL is the best license for a software, and some confuse between making a software free and making it GPL.

In the making of Freecell Solver, I made some good human engineering decisions, and some bad. I corrected most of the bad ones, and learned from them. For instance, I supplied Win32 binaries from a very early stage, because I knew most Windows users would not know how to compile the source.

When Stephan Kulow integrated the library into KDE's kpat solitaire suite, he did not use the API I supplied for doing it, but rather used its more internal methods, which were subject to change in newer versions. I requested that he reverts to the standard API, and add methods as he see fit, and send me the patch. He eventually did it, and so my library was improved. I eventually, converted the executable itself to use it, so I make sure it has all the functionality of the executable.

In my (relatively vast) experience as an open-source user and developer, I encountered good cases and bad cases of human engineering. Most projects are not purely HE-correct or purely HE-incorrect.

One should note that it is impractical and inadvisable to add all the features users' may need at once. Usually, it is a good idea to delay some of the more obscure features later on. If you have an idea for a feature, but can't think of somewhere where it can be used, and it will unnecessarily complicate your code, then it will probably be a good idea to delay it or drop it altogether.

Long-Term human engineering does not preclude you from having short- term one. I.e.: having mailing-lists, IRC channels, publicizing releases (on Freshmeat or wherever), an organized web-site, a contact E-mail. But it is also a good idea to have a GNU Autotools- based building process, an up-to-date RPM and Debian package, and detailed documents that explain it (man pages, "--help" listing and the such). As Joel Spolsky noted, if a user cannot understand how to do a certain thing in a piece of software, he many times give up immidiately.

When writing GUI programs, it is important not to change the GUI in ways the user did not expect. When making a Linux distribution it is important that the system tools will be super-robust (RedHat 7.2 is a bad example for it, while Mandrake 8.1 is a good one). Again, a user expects some applications to crash, even in Linux. But the important thing is that he can on doing what he likes.

Another concept taken from Joel's site is the zero- bugs policy. What it says, is that at any stage of the development process, you fix the bugs, before implementing new features. Programmers, even extremely good and experienced ones, tend to write the first version of the code very badly, not because they don't know better, but because they want to get a working version of the code. That is acceptable, but when has to remember to refactor, and fix bugs later on.

To conclude: Human Engineering requires more than being nice to your users. It requires you to think that you are someone who is going to use your application or link against your library. Freecell Solver employed good human engineering practices. It is not the most important project as some projects dwarf it in both codebase size and importance. But it has its niche of users, and it is one of the best solvers around. And I'm happy it is so.

hm, posted 12 Apr 2002 at 14:56 UTC by i0lanthe » (Journeyer)

I expected this thread to be about, well, building humans in a more principled way. Need more coffee.

perseverance, posted 12 Apr 2002 at 15:03 UTC by badvogato » (Master)

Perseverance will get you where you what to go, pal! Yeh, monopolize advogato posting even just for a day or two is definitely an achievement. And Check this out!

Design involves knowing your priorities, posted 12 Apr 2002 at 16:46 UTC by Ilan » (Master)

It is the commonly held (and IMHO, correctly held) opinion among most usability people that one should always come up with the basic UI interaction model before they ever start writing a line of code. Unfortunately, most people start writing the code, add cool features they happen to think of along with way, and only after that do they try make the user interaction model somehow fit in with everything. A perfect example of this is some of the non-palm PDA's (PalmPC, Linux PDA's, etc), where they made the mistake of designing the hardware and the basic system software first, and then because they've devoted such little amount of time to thinking about how the user will interact with the device, they say "ah ha! Those interfaces like the kind you have on desktop PC's are perfectly easy for people to use. And people will already be familiar with them. So we'll just shrink them down 20 times and everything will be OK". Unfortunately, some things that are usable when you have a 17 inch monitor, a mouse, and half a day to do stuff become unusable on a 180 x 240 screen with a tiny stylus and 30 seconds to get down a phone number from the hottie you meet at your LUG. I think that a really good model of "human engineering" also takes a page from PDA history. When he was coming up with the idea for how the Palm should be designed, Palm PDA creator Jeff Hawkins fashioned a Palm-sized block of wood and carried it around with him everywhere he went. He refined the way that Palm Grafitti should work by interacting with the block of wood and scribbling on it with a pencil. And this was all done before they ever had a piece of hardware on the drawing board.

Here's a link to this wonderful story

Users are pampered, posted 13 Apr 2002 at 00:39 UTC by tk » (Observer)

If one starts a project with the primary objective of making it successful or accepted, then he's doomed anyway.

You don't start a project meant to be used by other people. You start a project for your own use/learning/enjoyment/etc. Then you polish it a bit and share it with the rest of the world. Not going by this route is a good recipe for burn-out.

Can you imagine anyone using this? Yet it was successful during its time.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page