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 <[EMAIL PROTECTED]> 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
