Steven Pemberton : Views and Feelings ←↑→

March 2001

The Design of Notations

There is an amusing platitude that goes "A camel is a horse designed by committee". This is of course an insult to camels, which are perfectly designed for their environment. You just trying putting a horse in a desert and see what happens.

Something that wasn't designed by a committee as it happens is the <img> tag in HTML. This element specifies an image for inclusion in a page, and has the form

<img src="pic.gif" alt="Me, en route for France">
  1. This was badly designed in three ways:
  2. It wasn't backwards compatible: browsers that didn't know about <img> just showed nothing at that point.
  3. It didn't allow for any fallback apart from the 'alt' text. In other words you can only use a type of image (GIF or JPEG usually) that all browsers understand. This has seriously held back the acceptance of PNG images, which have far superior user-experience properties to either GIF or JPEG.

The alternative text is just plain text: you can't mark it up in any way to make it italic or whatever.

If <img> had been designed well, firstly it would be called <image> (contractions are OK, but there's no need to overdo it: why <img> when you have <blockquote>?), and secondly it would have a fall-back possibility like this:

<image src="pic.png">
   <image src="pic.gif>
      Me, <em>en route</em> for France
   </image>
</image>

This would display a PNG graphic if the browser knew about them, otherwise a GIF graphic, and if all else failed (or images were turned off) the marked-up text. Browsers which have never heard of the <image> tag would still display something sensible.

This is why the <object> element was later added to HTML (by a committee), with exactly these properties (and handling other types of things than images into the bargain, such as MPEG movies).

Another thing not designed by a committee, but just added to a product without consultation, was Frames. These are widely infamous in the interaction community for their lack of user-friendliness, initially and principally for the way that they broke the use of the [back] button. But I have tried to identify all the problems with frames, and this is what I have come up with:

  1. The [back] problem (which still exists, even if it is not as bad as it was originally).
  2. You can't bookmark a frameset in the combination of pages it holds.
  3. 'Page up' and 'page down' usually don't work properly: even if there's only one frame that is scrollable, you usually have to click in it before you can use the paging keys.
  4. If you do a 'reload', you often get a different result than you started with.
  5. There are some security worries, when people combine pages from different sites in one frameset.
  6. Occasionally you can get trapped in a frameset, or you can get nested framesets, and it can be really difficult to get out.
  7. Search engines only find the pages included in the frames, so you get your search results without the navigation intended.
  8. Almost no one provides <noframes> content, so searches with search engines like Google are seriously weakened.

In fact I can only find two compelling uses for frames:

  1. A search and display interface, where the results of some time-consuming search operation are shown in one frame, and clicking on those displays the resultant page in another frame.
  2. When scripting variables need to be kept over a series of pages.

All in all a pretty damning charge sheet, and therefore surprising that Frames are so widely used. What is also surprising is that if Frames had been designed in a slightly different way, most of the problems would disappear. If they had been designed not as a variation of HTML, but as a separate sort of document with the content HTML documents as parameters, such as

http://www.example.com/home.frm?nav.html;main.html;banner.html

many of the usability problems mentioned above would never have arisen.

My conclusion? Firstly that "Many eyes make all bugs shallow" also applies to user-interface design bugs, and that user interface people should be involved in the design of notations.

© Copyright Steven Pemberton, Amsterdam, 2001. All rights reserved.

First published in ACM/Interactions, March 2001

Steven Pemberton : Views and Feelings ←↑→

Other Posts