Stardate 20030829.1843

(Captain's log): I spent many years making tools for other engineers; directly or indirectly that's what I spent most of my career on. The last job I had, at Qualcomm, was the only time I ever worked directly on a consumer product (cell phones); everywhere else what I was doing was to either build test-and-measurement tools (such as logic analyzers) or to help build equipment intended to be used in factories to produce stuff.

I never formally studied ergonomics, the science and technology of what we at the time referred to as "man/machine interfaces". (Later, that became a politically-incorrect term – sexist, you know.) The term ergonomics was invented after I got out of school. However, I have been involved in it for a long time, because "ease of use" was always a marketing goal and a feature touted in the advertising, even if it wasn't true.

While I was at Tektronix, I helped develop two different logic analyzers: the 7D02 and the 1240. For those not familiar with the term, a logic analyzer is a tool which has probes which can be attached to digital signals in a circuit and which will sample the value on those signals; it can store what it sees, and it can use what it sees as part of a triggering program which controls when it stops storing so that the user and see what it captured. This gives an electrical engineer the ability to look at what the circuit is doing in ways an oscilloscope cannot, for at least two reasons: a logic analyzer always has a lot more channels than a scope, and it can use a far more complex triggering event.

The ideal for any tool like this is for it to vanish. The user ceases to be aware of the tool entirely; it becomes an extension of them instead. I wrote about this in much greater depth about two years ago in an essay I titled "Beige is Beautiful".

I learned about ease-of-use the hard way, because the 7D02 was not at all easy to use. The next time, the 1240, I did a lot better.

All engineering is tradeoffs; and there are a lot of goals. Needless to say, you want your tool to work correctly; and you want it to sell well. You want it to be possible to manufacture it and distribute it, and you want it to cost much less than customers are willing to pay for it so that you make a profit selling it. You want it to be reliable, and you want it to be easy to learn to use, and easy to use (which is not the same thing). It has to be possible to complete the design with the staff you have, in the development time you've been granted, within the budget which was allocated. And you want it to vanish when in use; you want it to become an extension of the user.

Someone will buy your tool if it expands their abilities. That's what tools do; people use tools because they can accomplish things that would be much more difficult or completely impossible without them. Or they may buy your tool because it makes it easier to do things than the tools they already have.

Within all the other practical constraints, your goal in tool design is:

1. To give the user as much capability as possible,

2. To make that capability congruent to things that he actually wants to do,

and, 3. To make it as convenient as possible for him to use your tool in order to do those things.

Unfortunately, some tool designers get religion. They're on a mission to make the world a better place, and to force their users to follow the true path to enlightenment and virtue. (Other times they're just thoughtless.) So they design their tool to force the user to solve a problem in a particular way; they limit the flexibility of the tool, and only expand the user's capabilities in carefully-channeled ways.

I just ran into that with the new release of CityDesk. The composition box for articles has two display modes. In one, you enter text as if you were using Word, and the text is formatted. That's called Normal View. The other shows you the raw HTML code, and it's called HTML View. (This is similar to two of the three views in Frontpage. Missing is what Frontpage calls "preview".)

There is something associated with the HTML View mode which I've started referring to as the "HTML fixer-upper" which evaluates the code and "fixes" it. For instance, it looks for unbalanced tags and appends closes for them, which I guess is reasonable.

But it goes a lot further than that; it is taking HTML code which is completely legal and rewriting it according to what it seems to think is the "right" way to do things.

That is a fundamental philosophical mistake in designing a tool. When there are many ways of solving a problem, the tool should permit as many of them as possible rather than trying to force the user to do it one and only one way.

Part of the problem with that is that it makes the tool unvanish, by forcing the user to cease thinking about the problem and start thinking about how to make the tool solve the problem. It's hard enough to come up with a solution to the problem, without having to worry about the fact that the tool won't permit me to use an approach which would actually work.

But another reason why that's bad is that the "best way" that the tool designers chose may not actually be best for everyone. Sometimes there are particular tradeoffs which some particular user may face which cause a different approach to be better.

The CityDesk 2.0 HTML fixer-upper now rewrites a lot of HTML in ways I wish it didn't, because what it's doing is distinctly