Wednesday, November 09, 2005

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

5 comments:

michaelo said...

Damn straight. There's something just so fundamentally broken about the whole idea of "save".

"Load" I get.

The need to name a piece of content so it can be identified, I get - metadata is important (I never metadata I didn't like).

But "save" is just so...so...WordStar. So Ctrl-K-S ferfuggsake.

Understandable, I guess, in the CP/M days - but what the hell is it still doing hanging around in our super duper mega WinXP/Web2.0/LAMP/waddayaalgot world?

Requiring users to make a conscious physical act to save every so often is unnecessary and just plain buggering wrong.

And yes, this should work just as well in a Web/App 2.0 world as it does on the desktop. Better. Look at the new grooviness in the latest updates to Gmail. Damn thing autosaves your email drafts every few seconds. You never gonna lose a thing.

Um...

Sorry. You got me onto one of my favourite rant topics. Think I should go register "KillSave.org" and start a campaign to stop this insanity. Or something.

Anyway, thanks.

Mike Warot said...

Okie dokie... I took the ball, and ran with it.

michaelo said...

Fantastic!

I'm going to get cracking on the "KillSave Manifesto" just as soon as I clear the decks of all this other workaday stuff I'm supposed to be doing today.

w00t!

wasabi said...

The two things that MS has technically over open source applications in the office sphere, these are:
- track changes and
- meeting scheduling.

In a large organisation working with collaberative documents and lots of meetings, these are both crucial.

The latter is probably going to be chanllenged by Chandler, http://wiki.osafoundation.org/bin/view/Projects/WebHome

If a proper 'tree view' could generate a great track changes (seeing who did what and when), this would eclipse the MS model. Checking versions of documents would be a great feature and seeing who did what would be better.

Steven Fisher said...

Microsoft Word on Mac has a pretty decent AutoRecover, but it is set to only function every 10 minutes...

I put a similiar feature in my software, where it saves to a temporary file every five minutes. If you crash, when you restart the program it recognizes that it crashed and loads the temporary file. Five minutes is too long, though. I should decrease it. Thanks for the reminder.