Same topic in earlier issue
Issue
Previous article
Article
SIGCHI Bulletin
Vol.27 No.2, April 1995
No next article
Article
Same topic in later issue
Issue

Gbldgk

Steven Pemberton

What a pity we're stuck with those stupid ugly URL's now. If only they'd given them to an HCI person first! The name of the things, "URL", is already enough to make you want to say "Actually, I'm not really a computer sort of person". Why not something human, like Web Address?

Look at the Web Address of my home page:

http://www.cwi.nl/~steven.
That stupid use of the word http! You may not know, but it stands for something like Hyper Text Transaction Protocol. Who cares what protocol is used?! Funnily enough, a Web Address for a news article starts with "news:", even though they could have used the name of the protocol they use there, NNTP, so they must have had an off day when they were thinking about that one.

And another thing about that word http is that I keep mistyping it as html, and I bet I'm not the only one.

And that wretched double //. Sigh.

If I'd had my way, my web address would have been more like: www:cwi.nl/Steven.Pemberton or web:cwi.nl/Steven.Pemberton.

Computer scientists are notoriously bad at devising notations. Luckily, after a few false starts, we actually have a quite reasonable email address format. My email address

Steven.Pemberton@cwi.nl
couldn't really be simpler or more obvious, although there is a group fighting a rear-guard action to get us to use
G=Steven; S=Pemberton; O=cwi; P=surf; A=400net; C=nl

as if anyone cared which carrier is used to deliver email to me. Luckily they don't seem to be having any success in their campaign.

Of course, not everyone has such a simple email address, but this is a problem with the implementation not the specification.

However, let us not praise email too broadly. If they'd thought about the content of email for 3 minutes instead of just for 2, we wouldn't see that strange word ">from" so often in articles, for instance.

But it's not only computer scientists who can't design notations. To take a random example, consider the two-letter codes used to identify states in the USA.

It is clear just looking at the codes for Georgia and Florida (GA and FL) that there is no actual design in the choice of codes. The only rule I can discover is: the first letter of the state name is the first letter of the code, and if the state name has two words, the second letter of the code is the first letter of the second word. After that it's anyone's guess.

The biggest user-interface problems with the codes chosen are that, in general, looking at a code you can't tell which state it is for, and given a state name, you can't derive the code for it. It is all memory, which as we all know, makes for bad interfaces.

For instance, is NE Nebraska or Nevada? It's Nebraska, but if they'd used NB, I'd never have had to ask. Similar problems would have been avoided if they had used MG for Michigan instead of MI (which has 4 possibilities), and MP for Mississippi instead of MS (which has 3).

But even if you could solve all the reading problems of the codes in this way, it still doesn't solve the problem of remembering them. To see if it was possible at all, I did a little investigating. I wanted to see if I could come up with a simple rule that would produce a unique set of state codes. The simplest rule I could come up with was this: Single word state names use the first and fourth letter with 4 exceptions, Illinois, Minnesota, Mississippi and Missouri (all 4 reasonably easy to remember: they are the only states with an i and a double letter in the first 4 letters) which use the 5th letter instead.

It can be done!

Fellow HCI'ers! Let us make it our task in the coming time to go out and persuade the world that they shouldn't only include us in the design of interactive computer applications, door knobs and direction boards, but also in the design of their notations.

Same topic in earlier issue
Issue
Previous article
Article
SIGCHI Bulletin
Vol.27 No.2, April 1995
No next article
Article
Same topic in later issue
Issue