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