[Design] Edits and saving in the Web UI

Mon May 7 19:58:08 PDT 2007

Design folks,

This is my promised message trying to explain about the idea of 'magic' 
saving or auto-save in the Web UI.

The basic issue is that in a Web app, users' data is far away from where 
they are. That means there is a much bigger cost than with a desktop app 
for accessing and updating data -- and it takes longer to happen.

A lot of what you do to make a normal Ajaxy Web app feel like a desktop 
app is kind of slight-of-hand -- status messages, animations, and so on, 
to tell the user that the app is talking to the server. This makes it 
feel more responsive. The idea with auto-save to try to take a different 
tack, and instead have the Web app save changes at intervals in the 
background, or when the user changes from one view to another.

Here are some problems with this approach:

1. Periodic auto-save in the browser won't be mostly instantaneous and 
painless like it is in a desktop app. There will be noticeable lag when 
the front-end talks to the server -- and the UI will suddenly go 
sluggish for what appears to the end-user to be no reason. (And since 
it's supposed to be happening invisibly in the background, I presume 
there would be no 'talking to the Mothership' status message.)

2. Some changes to data require a subsequent data-fetch. For example, 
when the user makes a change to a recurring event, we need the new 
recurrence expansion back from the server to repaint the UI.

3. Data loss becomes more of a possibility if the user closes the 
browser and doesn't bother to read the dialog we would pop up to warn of 
unsaved changes. Browser crashes would mean likelihood of more lost data 
because users would not be explicitly saving changes incrementally.

Those are the main issues I can think of off the top of my head. Can 
anyone else think of any other potential problems?

If we can come up with some clever (and bulletproof) solutions to all of 
them, I think it would actually be a feature worth working on.

Thanks.

Matthew

Matthew Eernisse wrote:
> Mimi,
> 
> There are both technical and design-philosophy reasons that would make 
> implementing something like that potentially problematic in a Web UI. At 
> this point, I lean very heavily toward not wanting to go that route.
> 
> That question gets us into the autosave can of worms (opened by the idea 
> of implementing edit-in-place on the lozenge) that I alluded to in the 
> last e-mail. I'll write up a detailed post which attempts to describe 
> what I see as the issues, and the potential solutions and their 
> benefits/drawbacks.
> 
> Thanks.
> 
> 
> Matthew
> 
> Mimi Yin wrote:
>> This is great Matthew. I'm wondering if we can push this even further. 
>> Is there a technical reason we can't try and 'do the right thing' and 
>> commit changes to the server whenever users do something that would 
>> make the detail view either disappear or change to display the details 
>> of a different item? This would basically mean:
>> + Clicking on a different item in the summary pane
>> + Switching collections in the collection pulldown
>> + Logging out
>> + Leaving the Hub UI altogether
>> + Closing the browser window
>>
>> Mimi
>>
>> On May 2, 2007, at 12:08 PM, Matthew Eernisse wrote:
>>
>>> After some further thought -- and a bunch of chitchat with Jeremy 
>>> Epstein that was really helpful -- I see that there's a better 
>>> solution to the first of the two scenarios that doesn't involve 
>>> throwing up a dialog at all.
>>>
>>> The two scenarios are:
>>>
>>> 1. Users click on the lozenge for the same event they are editing in 
>>> the item detail form
>>>
>>> A dialog box is actually not needed here, because the user's intent 
>>> is clear.
>>>
>>> The UI should just do the right thing in that case, and apply edits 
>>> from the form along with the changes to start and end time caused by 
>>> moving/resizing the lozenge. (If the changes in the form include a 
>>> change to start/end, then the move/resize changes would overwrite them.)
>>>
>>> 2. Users click on the lozenge for a different event.
>>>
>>> Here we still need the dialog to ask users if they want to apply 
>>> changes, discard changes, or cancel the change of selection to the 
>>> new event.
>>>
>>> This seems to me like a fairly obvious improvement in the case of 
>>> number 1, so unless there are some objections, I'll take this tack 
>>> when doing the fix for this bug.
>>>
>>> On a related note, in talking about this with both Priscilla (and 
>>> later Jeremy as well), some interesting questions came up regarding 
>>> the behavior of saving changes to items in the Chandler Server Web 
>>> UI. This can of worms was opened up by the question of how to 
>>> implement edit-in-place for the event title directly on the lozenge. 
>>> (There's an open bug, no. 7849, for this.)
>>>
>>> I'll address that stuff in a separate e-mail to the list.
>>>
>>>
>>> Matthew.
>>>
>>>
>>> Matthew Eernisse wrote:
>>>> I agree that 'Discard' is better. I'd also like to propose a change 
>>>> to the prompt that makes it clearer why the dialog has popped up. I 
>>>> propose the following:
>>>> You have made changes to the currently selected item. Do you want to 
>>>> save your changes?
>>>> [Cancel]    [Discard] [Save]
>>>> I do kind of like the addition of the word 'Changes' in the two 
>>>> right-hand buttons. (And I'm usually a fan of one-word button labels.)
>>>> It makes it totally clear what the choices are, even if the user 
>>>> doesn't really bother to read the prompt. It also underlines more 
>>>> clearly the difference between discarding the changes and 
>>>> proceeding, and canceling and going back to the state you were in 
>>>> before.
>>>> I do however think the button labels are perfectly usable as-is.
>>>> Matthew
>>>> Priscilla Chung wrote:
>>>>> Last call…? -Priscilla
>>>>>
>>>>> On Apr 24, 2007, at 12:37 PM, Priscilla Chung wrote:
>>>>>
>>>>>> If people don't feel strongly about the proposed buttons, then 
>>>>>> let's finalize a decision on this proposal. ---
>>>>>> Save changes?
>>>>>>
>>>>>> [Cancel]     [Discard] [Save]
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>>>
>>>>> 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
> 