[Design Patterns] pattern for marking changed items before save

[Eli Cochran]

Andrew,
Nice blog entry, and a nice example. Reminds me a lot of gMail, when  
you do a destructive action, there is an Undo link that becomes  
available at the top of the screen. The gMail pattern only allows for  
one level of Undo, the next action will make the Undo unavailable but  
it's better than nothing.

Sample screen shot enclosed.

- Eli



On Dec 11, 2007, at 2:49 PM, Andrew Petro wrote:

> Daphne,
>
> [
> For simpler changes, the heuristic I tend to think about with  
> explicit save is how difficult it is to "undo".   If it's as simple  
> as unchecking a box or using an undo action then the extra click is  
> less needed in most cases.
> ]
>
> As a quick example of the sort of change that's simple and easy to  
> undo and thereby allows skipping the extra click of an interstitial  
> confirmation, I've blogged (with screenshots) about development  
> issue vote removal and un-removal in Unicon's cooperative support  
> Web UI:
>
> http://www.unicon.net/node/875
>
> Hope that helps a little bit to motivate discussion of the patterns  
> and when to use them here. [1]  I'm enjoying lurking on fluid-*@  
> and regret that I don't find time to be more involved.
>
> Andrew
>
> [1]: Or at least helps to raise visibility of Fluid and the sorts  
> of discussions that are happening here.
>
>
>
> Daphne Ogle wrote:
>>
>> This is interesting.   And I think you identify the kinds of  
>> interaction that could benefit from the extra action to  
>> save...particularly if changing bits of information affect other  
>> information and the user really needs to understand changes  
>> together before saving.
>>
>> For simpler changes, the heuristic I tend to think about with  
>> explicit save is how difficult it is to "undo".   If it's as  
>> simple as unchecking a box or using an undo action then the extra  
>> click is less needed in most cases.
>>
>> The mix of using these 2 patterns is a tricky one.  I think it's  
>> hard to set up different expectations for similar kinds of  
>> actions.  It does seem like a complex spreadsheet like this  
>> example may be different enough from other simpler form-like  
>> editing that users may be able to learn different behaviors?  It  
>> depends as always.  In thinking about Sakai, one of the consistent  
>> usability issues is around users seeing the action buttons.  Many  
>> times they are below the fold so users don't even have a cue that  
>> another step is required.  The demo you refer to asks users if  
>> they want to save changes if they've tried to go someplace else  
>> before saving any changes.  That helps and is something that  
>> continues to come up as something we need the system to be able to  
>> do.
>>
>> -Daphne
>>
>> On Dec 10, 2007, at 9:15 AM, Eli Cochran wrote:
>>
>>> I stumbled an interesting twist on inline editing. Most of the  
>>> time that I encounter inline editing the pattern is to save the  
>>> data immediately after it's edited. But this example marks each  
>>> edited item and then the user has to explicitly save the data.  
>>> The design has a lot of problems but I like the idea of it, and I  
>>> like the way that they mark the changed bits.
>>>
>>> Double-click a cell to edit (like I said, there are issues).
>>>
>>> http://creamarketing.net/jqgridview/demos/demo5/
>>>
>>> For complex data where you might want to edit things that are  
>>> related to each other or think about your changes before  
>>> committing them this is a great pattern.
>>>
>>> It brings up an interesting question though. Can you mix a save  
>>> on edit pattern (which is great for lightweight data) with this  
>>> edit and then explicitly save pattern and have it make sense?
>>>
>>> - Eli
>>>
>>> . . . . . . . . . . .  .  .   .    .      .         .              . 
>>>                      .
>>>
>>> Eli Cochran
>>> user interaction developer
>>> ETS, UC Berkeley
>>>
>>>
>>> _______________________________________________
>>> fluid-work mailing list
>>> fluid-work at fluidproject.org
>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> daphne at media.berkeley.edu
>> cell (510)847-0308
>>
>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

. . . . . . . . . . .  .  .   .    .      .         .              .     
                  .

Eli Cochran
user interaction developer
ETS, UC Berkeley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071212/1bac7e9a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gamil-undo-example.png
Type: image/png
Size: 19422 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071212/1bac7e9a/attachment.png>