Happy Birthday(s)

I'm 42 today. I had a wonderful dinner and celebration with Noran and our friends. It was a VERY nice break after a stressful week.

When I got home, I found that Michael O'Connor Clarke had sent me the first draft of the KillSave Manifesto, which is going to get us off on a very good start in our campaign to kill one of the more offensive or relics from the past, the need to be a save slave. I consider it to be another nice birthday present.

Doc's been doing his web log for 6 years, so that's another birthday, of a sorts.

It's 2am.. time for sleep.

Thanks to friends and family, and you, gentle reader. This is a truly happy Birthday for me.

--Mike--

App 2.0, day 2

So, A co-worker lost an hour or two of work… and I’m ranting about it.

I find it completely unacceptable that we’ve got computers with processors capable of doing 2 BILLION operations per second, and Microsoft Word couldn’t be bothered to save about 20k of text every once in a while. It’s a design failure of the first order, resulting from a culture of good enough thinking, and settling for what’s available.

There is no technological impediment, which caused this loss. Even a humble MS-DOS program can handle things like saving in a background thread. We’re talking small amounts of text here, folks… why did this have to happen?

You could blame the user, because he didn’t happen to pick a file name BEFORE he knew what he was writing… but I’m not falling into that trap. It’s the applications responsibility to make sure it never loses the users work. It’s the Operating System’s responsibility to make sure it never loses the files entrusted to it by applications and users.

It’s pretty simple, we have a failure to fulfill an obligation, of the first order. Now, let’s see what steps could have been taken to prevent this.

User Training:

This is a “blame the victim” strategy. It’s unreasonable to expect the user to know where they want to save something before they begin to compose it. A compromise is to supply default names like, Document1, Document2, etc.

This approach works well, except when a user needs to close a multi-pane application, and is then asked if they want to save changes in Document1, Document2, etc… How are they supposed to know? The binary choice at a moment of stress is bad UI design.

Big Brother:

One could record everything the user types, and save it, as part of the operating system. In this case, it might have sufficed, because the work was pure text. The loss of context, means that this value of this strategy would probably be lost in most other cases.

Saving every step:

My personal favorite, save every keystroke, relevant clock tick, and file operation. This creates a tree of all states of the document, from the root when it is created, or loaded from somewhere without history, until the present, including all alternate futures. An alternate future can arise when you undo, then do something different. It would be quite interesting to have all the states of a document available in a Tree view, with the most recent versions on top. Most operations would have one child node, so the tree would be very deep and not very wide.

If a user gets a chance to undo, it’s merely selecting a different state from a tree.

There are a few ways to take it… blaming the user usually wins, though.

Conclusion:

Here we are in the year 2005, we’ve had interactive text editors for more than 35 years, and we’re still losing things. I’m going back to my text mode roots to explore this problem, though it’ll probably have a windows face on it.

Next steps:

On the Desktop front, I’m going to build an editor that saves all states, from scratch. I’ve got some other ideas about Rich Text which are going to be overlaid on it once the basics work.

I’m unsure of programming language to use. I’ve got Turbo Pascal 7, Delphi 5 Pro, which I’m quite comfortable with. I’m tempted to go with Python, but have to learn all the GUI stuff to do that. I’d like to go cross platform, now that I’ve got a Mac to play with, and Delphi doesn’t do that.

On the Web 2.0 front, I’m going to blog this. I’m also going to inquire with the folks at 37 signals, to see what they think can be done about a web form that uses AJAX to keep the server updated in real time.

In either case, the goals remain the same:

• Never lose the users work
• Always show the current save path
• Always autosave to a working folder, and alert when this fails
• Allow the user to pick up their context across invocations of the editor
• Focus on pure text, and get the fundamentals right
• Test the hell out of it
• Make it open source

Written on the train on the morning commute.

Mike Warot, November 9, 2005

What year is this again?

I was on the train today, trying to pay attention to Doc not paying attention, when I was, of course, distracted by events of yesterday. I had to tell one of the people I help with computers that, yes... he lost an hour or two of work because a certain Word processor allowed him to edit a document with no path....

The podcast goes on, and I'm distracted more than usual by the thought...
It's 2005 and we're still losing work due to bad UI design?

Someone on the podcast then notes that it's 2005, and a huge majority of all text entry on the internet is still done in a TextArea box on web pages.
It's 2005 and most Web isn't Wysiwyg?

So, with those thoughts in mind... here are Mike's challenges to Windows AND Web 2.0:

• Always show the path and status of the document
  
• NEVER permit a user to do work that can't get saved automatically in the background
  
• ASK a user if they want to allow work that can't be saved to the source path
• ALWAYS have a full path available in a RESTful manner
• Random disconnection is a fact of life, NEVER lose work because of it, EVER!

Always show the path and status of the document

The user is multi-tasking, they have a full plate of things to do. They need to know, at a glance, if their document has been saved back to the web server (if it's AJAX, etc) or the file server (Desktop). Provide this info, and keep it current.

NEVER permit a user to do work that can't get saved automatically in the background

Windows applications ALWAYS have a local drive or home folder to save things into, they have no excuse for losing things. AJAX software has the web server to write back to, if the link is down, it's a read-only copy, or some other reason, DON'T LET THE USER PROCEED.

ASK a user if they want to allow work that can't be saved to the source path

If you're going to allow the user to save the document into a namespace (file system on Desktop) and the destination is unavailable (connections get unreliable even in offices), ask the user if they want to proceed working until the resource becomes available, provided you have a secure store to autosave into while waiting.

ALWAYS have a full path available in a RESTful manner

The user should ALWAYS be able to bookmark a document to return to it later. Aside from possible User Authentication, no further hoop jumping should be required to get back to where they were, and keep working. This applies to Windows users as well.

The user should be able to copy this path, and type it into any reasonably competent workstation and pick up where they left off.

The user should be able to read this path over the phone to a co-worker, so they can pick up the same place as well.

Random disconnection is a fact of life, NEVER lose work because of it, EVER!

Years ago I was working on an application that used some ruggedized industrial handheld computers. During a demonstration of retrieving information from the unit, the client asked:

What happens if I disconnect this right now?

I stuttered, and realized I had never thought of that... I took it on faith that it wouldn't happen. It turns out that it deleted all of the users work and left things in a bad state. I rewrote the routines in such a way that the absolute last thing done, (after downloading, parsing, and verifying all of the users data and making sure it was in the database) was to delete the data off the handheld. I did this back in 1989... why can't we do that in 2005?

There has to be SOME way for a user to save their work locally if the original path disappears... plan for it, and test it.

Summary

The desktop and "web 2.0" both have to face the same challenges. The first one to meet ALL of my above conditions will win in more ways than one. The environments pose different challenges, but it's the applications that will make or break the winner.

Thanks for your time and attention.