[Design] Edits and saving in the Web UI

[Mimi Yin]

Ah! This is very helpful Jeremy. So can we isolate the scenarios  
where auto-save needs to fetch a lot of data from the server?

Edits to the recurrence rule are one of them.
+ Changing the rule
+ Changing the end-date

What are some others? Will any of these be especially slow?
+ Stamping and Unstamping
+ Editing text fields seems equivalent to Pieter's gmail scenario and  
probably won't take a long time?
- Addressing fields
- Title
- Location
- Notes
+ Editing date/time fields
+ Editing time zones
+ Editing event status

Also, we've talked about app-response times in general, but what's a  
reasonable amount of time for users to wait, when waiting for a  
'Saving operation' in particular?

Mimi

On May 8, 2007, at 4:36 PM, Jeremy Epstein wrote:

> The activity you are talking about is sometimes called  
> checkpointing. Its a little different than the auto-save Mimi and  
> Priscilla are referring to, because their auto-save could  
> dramatically affect the data presented in the calendar and dash  
> views. GMail does not need to re-render very much to do its "auto  
> save". But the OSAF Web UI does, especially if the user edits the  
> time,changes the triage, or removes (un applies?) a stamp.
>
> GMails auto-save is intended to prevent data loss during a long  
> editing session. GMail doesn't do anything with the data beyond  
> sending it to the server in case of a disconnect. The confluence  
> wiki I use at one of my client sites does the same thing, for the  
> same reason.
>
> One reason for the delay in the Web UI case is to fetch new events  
> which may now show because your edit changed where an item appears  
> in a display.
>
>
> Pieter Hartsook wrote:
>> 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
>>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070508/b8b0420b/attachment.htm