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.