Newsflash!

21 January 2000

…and about time, too.

This is the first time I’ve updated this on-line diary in almost three months. Pathetic. I know exactly why, too. It’s not because I haven’t had anything to say (it has been a very full three months). It’s not because I haven’t had the time (I’ve had plenty of that, but I’ve chosen to spend it elsewhere). It’s because I fell victim to a particularly nasty programmers’ disease: Get It To Work (GITW).

My main goals in designing these new pages for the sunpig site were:

1. I want to have a diary page (the thing you’re reading now) that automatically directs the viewer (that’s you) to the latest entry. Whenever I add a new entry, that will be the one you see at www.sunpig.com/martin.
2. I want the viewer (you again) to be able to move back and forth through the diary entries.
3. I want the diary entries to be stored in plain HTML format rather than in a database. HTML is a nice, portable format that can be converted to whatever system I might use in the future.
4. I want to gain some experience with programming CGI scripts in perl.

I did all of these things. It works. So what did I do wrong? I forgot to add in step 2: Make sure the system allows me to easily add and edit diary entries.

Too often, you hear programmers say, “Okay, so it may be a bit hard to understand, but once you get familiar with it….” This is not what you want to hear about a new piece of software. What you want to hear is: “It’s simple to learn and use right from the start, and once you get more familiar with it, you can do all of these other fabulous things!”

“Hard, but”, versus “Easy, and.” It’s a bit of a no-brainer, really. Make the interface hard to start off with, and you will start off with users resenting the system, complaining about it, and, worst of all, not using it. If users don’t see the pay-off from your system straight away, there is an excellent chance they will go back to the old version of whatever they were using, or they will find some other, simpler way of doing it. Or they won’t do it at all (like me).

Wrong way to make a user create a new diary entry:

1. Create an empty text file
2. Write the diary entry, using HTML formatting tags (e.g., <h1>, <p>, <b>, etc.)
3. Save the text file with the name of the current date, i.e. 20000121.html
4. Use an FTP tool to upload this diary entry to a particular location on the target web site

Initially, this seemed to be a reasonable way of doing things. I’m a bit of a wiz with a text editor, so creating files should be a snap. I write HTML for a living, so no problems there, either. Uploading the file to the web site? Doddle.

Except that it’s a pain to actually do. It means I have to have a text editor available. It means that I have to have an FTP tool available. I can’t just go into a web cafe and write me a new entry, as I would like to have done while we were in California in November. (Were it not for the fact that Kinkos charge $15 an hour for web access. Even the most expensive web cafes here in Britain aren’t that expensive.)

So, the good way to make a user create a new diary entry is this:

1. Go to the diary creation web page
2. Enter your user name and password
3. Write the entry on the web page
4. Press the “save” button

I don’t have to worry about what name I give the file–I don’t even have to think about that fact that it *is* a file. All of that technical stuff is hidden from the user. Which, come to think of it, is probably one of Martin’s rules of User Interface:

Rule 2:

The user should not have to know anything about the underlying technical implementation.

Example: In a system I’ve been working on recently, there is a database table with a field called “date_1“. (Tip: never call a database field “date_1”. It causes any programmer who works on the system after you to want to hunt you down and rip your fingers off, one by one.) The table holds account details. The field “date_1” holds either the start date or the end date of an account, depending on the account type. (Tip: never ever do this. In addition to the programmer who comes after you, the Gods of Software will also want to vent their wrath upon you.)

When I started work on this system, I wrote a web page for entering account details. On the page, there was one field for this “date_1”. If you changed the type of account (from a drop-down list box), the caption of the field would change from “start date” to “end date”.

Bzzt, wrong. But thanks for playing.

If the user isn’t aware that the “date_1” field should contain different dates, they will go in to the web page, and see “start date” as the default. They will then change the account type to one that requires an end date, and then merrily enter a start date in the field, because that’s what was asked for when they looked originally

Sure, users would learn about this, “once they get familiar with it,” but until then, they will make mistakes, complain about the system, and resent it. If you’re in the business of building software, user dissatisfaction quite simply equates to reduced sales.

Unfortunately, if you write this stuff for yourself (i.e., this diary system), you have three choices:

1. Resent yourself
2. Buy, or bring in a system from outside
3. Don’t use it

I’m too vain to resent myself, I’m too proud to buy in something like this (which I could write myself–this is what I do), so I just haven’t been using it.

So one of my next projects is going to have to be writing a few PHP pages to act as a new diary entry/edit mechanism. Now all I need to do is learn PHP…

(And while I’m at it, I might do a little calendar thing to show what dates have diary entries on them. Because at the moment, if you click on the “previous entry” hyperlink on this page, you have no idea whether it will take you to an entry from last week or last year. So you don’t know if you’ve missed anything unless you actually scroll all the way back. A bit useless, I’m sure you’ll agree.)

-Martin.