[Design] Edits and saving in the Web UI

Tue May 8 17:29:52 PDT 2007

Whoops--
I spoke a little too soon:
If notes and location are not displayed in the dashboard list (and thus 
are not sortable) then you might get away with changing them.

Addressing fields are especially tricky-- When you auto save are you 
going to send new invites out?
You might want to explain yourself there, because changes to address 
fields carry very specific expectations, and could put you in a tricky spot.

Jeremy Epstein wrote:
> Hello Mimi,
> I wrote my response inline, following OSAF convention.
>
> Mimi Yin wrote:
>> 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
>   Well if you can change what fields you sort on in dashboard, then 
> *all of them*.
>
>
>
>> 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?
> Now I am going to separate "overt saving operation" where a user is in 
> control, from a "covert" save operation where a user does no know that 
> is what is happening.
>
> *For a "covert" operation, a "hidden save", a "background save", an 
> "auto save":*
> According to the literature and hard research ( I hope your ACM 
> SIG-CHI membership is current) *its tied to human 
> perception*(evolution is pretty slow in responding to paradigm 
> shifts). About 1/10 of a second if it requires redraw. And no, I am 
> not talking about games or simulation where the number is 1/30-1/60 of 
> a second with all (sonic, visual, haptic) responses fully coordianted 
> and synchronized to avoid motion sickness.  Otherwise, be prepared to 
> explain what is happening or offer the user a way out.
> *ICal *(and other non-modal editing apps such as photoshop, 
> illustrator, or lightroom, autocad, alias, flash) *generally responds 
> within 1/10-2/10 of a second.Try it.*
>
> If you want to break new ground with a non-modal editing style, go for 
> it! But you need speed to make it work. If you have an old copy of the 
> Apple Human Interface Guidlines, its a good introduction. I can 
> probably lend you my copy.
>
> Its not generally possible on the web if you need to listen to a 
> response,and redraw the screen. Not even close. With most companies 
> that do not have the resources of google (multiple oc3's to avoid mae 
> west etc...) the latencies alone are bigger than that. Not to mention 
> server processing time, client processing/rendering time....
>
>
> *An "overt" save its a little different because the user feels they 
> know why a delay exists.* 
> This buys you a couple of seconds -- you can fake a spinner with an 
> hourglass. Much longer than a few seconds and you owe the user an 
> explaination as to why its taking so long, how long you think it will 
> take, and allow the user to cancel too.
>
> One of the important things to keep in mind with UI is that the user 
> should always feel they are in control not the software. Random delays 
> take the "perception of control" from the user. Ever see a Java IDE 
> Garbage Collect? It sure would be nice if eclipse told you it was 
> about to garbage collect and how long it would take. Then you wouldn't 
> feel completely helpless, you might even know if you could go for a 
> coffee.
>
> The way browsers approach this is with the little spinner in the 
> corner (you know the little globe or e or fox) and a progress bar. It 
> works great with "old" web apps. Too bad asynchronous HTTP calls 
> "break" the spinner. (sometimes it never stops spinning, sometimes it 
> never starts)
>
>
>
>>
>> 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 
>>>> <mailto: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
>>
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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/5024cb79/attachment.htm