Yesterday, I linked a claim by Dave Winer that users like to
use Web
browsers as their UI, and a note of frustration by Paul
Snively, who
lost some work on his blog, and blamed the "Web browser as
UI"
approach. Paul has since retracted
his original post, but I think there's a deeper issue that
deserves to
be explored. I've lost a fair amount of work posting to
Advogato as
well, so let that be the whipping boy rather than Radio.

Using the Web browser for the UI has a different set of
design
tradeoffs than a traditional desktop app. Some things get
easier,
others get harder. Lots of things can lead to a bad (or
good) user
experience, including things not foreseen by the software's
designer.
I know I didn't pay a great deal of attention to robustness
when
designing Advogato.

I'm not going to try to catalog all the advantages and
disadvantages
of Web-based UI's - that's a daunting task. Instead, I'll
focus on
robustness, or the risk of losing work.

I used to lose coding work fairly frequently. Now I don't,
because I
do lots of things to improve robustness. First, I use an
editor with
good robustness features. Second, I check my work into a
remote CVS
server. Third, I back up the repository to CD-R every week.
I also
frequently copy local working files to another machine on my
network,
and send patches to mailing lists. As a result, it's been
quite a
while since I've lost any coding work.

I still lose Advogato posts, though, most recently about
a week ago. Why? For one, Netscape 4.7x's text entry box
doesn't
have any of the paranoia that real editors have about
losing
work. In fact, pressing Alt-Q (the same command as "format
paragraph"
in Emacs) is a quick shortcut for "lose all state and quit".
This
could be fixed in the client, but as the designer of
Advogato, I don't
have much say about that.

There is more I could do but don't, though. I could
make the
"Preview" button store the draft in a log, persistent for a
day or so
and then garbage collected. You could, if you chose, edit in
the
browser and click "Preview" regularly, much as I regularly
press
Ctrl-X Ctrl-S in Emacs. In fact, I rather like this idea, as
it has
other advantages. For example, you could share the draft
link with
others.

Similarly, I could implement something like version control
for diary
entries. When you post a new edit, it saves the old version
(or,
perhaps, the diffs) somewhere. Thus, if you clobber your
work (as I
did a few days ago), you can get it back. Again, there are
other
advantages to this approach. This is basically ReversibleChange,
one of the "soft security" ideas popular in the Wiki world.

A very high-tech client might even be able to implement
something
analogous to the autosave feature of Emacs. It would
periodically
upload the current state of the text entry to the server for
safekeeping. However, this would require some pretty major
changes to
the way the Web works, so I'm not holding my breath.

In the meantime, there are alternatives. For one, it's
possible to use
an XML-RPC client instead of a Web browser. Many of these
clients
encourage you to use your favorite editor, which helps with
robustness. The client could also keep a log of everything
submitted.
Such an approach would be complementary to the server-side
tweaks I
mentioned above.

In the meantime, I now generally write my diary entries in
Emacs, then
simply cut-and-paste into the browser. It's not perfect, but
it works.