[Design] Edits and saving in the Web UI

[Pieter Hartsook]

One of the nice things that Google added to Gmail a while back was an
autosave feature. You still have the Save Now and Discard buttons when
creating a message, but about every minute, the message you are typing
(like this one) is autosaved. There is a status message next to the
Save Now/Discard buttons that updates to "Draft autosaved at 4:02 pm."
 or whenever the last save was. The autosave is almost instantaneous
and doesn't seem to interfere with my typing. I can't really notice
any lag in my typing for example during the save.

If I try to navigate away from the message with unsaved changes I get
an error popup asking if I want to abandon the changes.

Pieter

On 5/8/07, Matthew Eernisse <mde at osafoundation.org> wrote:
> Mimi,
>
> Good questions, all. Responses below.
>
> Mimi Yin wrote:
> > Just to clarify, I'm suggesting we only 'auto-save' in cases where the
> > user would need to explicitly click 'Save' anyway, aka when they "click
> > away from the item and the DV changes what it displays".
>
> Ah, good. I'm glad we're not talking about some kind of background-save
> process.
>
> But in trying to imagine how the auto-save described above would work,
> it seems to me that we are trying to gloss over something in the process
> that has huge significance -- the time it takes to save the data. In
> trying to hide it, we're going to create an app that feels horribly pokey.
>
> The best way to make a Web UI feel snappy is to give the user immediate
> feedback when they take some kind of action. In the case of clicking on
> an event lozenge, the user's intent is to *select a new event.* They
> click on the lozenge, and boom, it's there. Right now all that is
> instantaneous, and the app feels nice and snappy.
>
> If we were to implement that kind of auto-save, then sometimes clicking
> on a new event would give you selection of the new event
> instantaneously, and sometimes (if there have been changes) there would
> be a really ponderous waiting process while the *previously selected
> event* goes into a processing state, and the app does it's
> chug-chug-chug talking to the server, before the new event is finally
> selected. That's not going to feel snappy, it's going to feel really slow.
>
> > Well, I think the problem we're facing right now is that we fear users
> > won't remember to save at all.
>
> I can see that being a genuine concern. There is a very simple step we
> can take to avoid that -- prompting users about unsaved changes when
> needed. That's standard practice in Web UIs.
>
> Anyone who has worked with a Web app for any amount of time generally
> understands fairly quickly that they need to send their changes to the
> server for them to be saved. It's a really relevant fact of the end-user
> experience with a Web app, and I don't think it's something we really
> can, or should try, to hide from them.
>
> > Now, if someone were composing a long message or writing up meeting
> > notes in the Notes field, then yes I agree with your analysis. But I
> > don't think we're expecting that for Preview.
>
> That makes good sense. I understand there are different targeted
> use-cases for Preview.
>
> However, whether it's just for Preview, or for the longer-term when we
> anticipate there being people doing the majority of their work in the
> Web UI, I feel very strongly that we should let the Web app be a Web
> app, and leverage existing Web conventions unless there's some big value
> in throwing them out.
>
>
> Matthew
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>