[Design Patterns] pattern for marking changed items before save

[Sean Keesler]

Interesting...It seems that this pattern assumes that a user is savvy enough
to know that merely changing things on this page does not commit them, but
that the same assumption about other pages can¹t be made.
I realize that there may be a greater potential for error if a user forgets
to save before leaving the entire page, but can the user be prompted to save
before navigating away from the entire page? (I¹m purposefully ignoring the
backend state issues for the moment, assuming that it COULD be worked out)

(Sorry, just really interested in how these sorts of decisions about designs
are made...other than observing lots of users¹ behavior).

Sean



On 12/11/07 1:43 PM, "Eli Cochran" <eli at media.berkeley.edu> wrote:

> Sean, the pattern that you suggest is a particularly difficult one in web
> applications since state is difficult to carry from page to page, and if the
> user forgets to save then data is lost since there isn't a local copy. I'm not
> saying that's impossible just that both the technical and user model are
> tricky. For example, Sakai handles the back-end for this pretty well, but I
> suspect that most users are clueless as to what tasks they've completed and
> what tasks they've left in an unfinished but partly saved state. 
> 
> - Eli 
> 
> On Dec 11, 2007, at 10:29 AM, Sean Keesler wrote:
> 
>>  If the task at hand is to ³edit things that are related to each other or
>> think about your changes before committing them², then I would argue that you
>> might want to be able to ³edit things² across multiple pages of the document
>> and think about them before committing.
>>  
>>  However, it looks like this design requires the user to  ³save² changes on
>> the current page before  they can edit anything on any other page.
>>  I like the general idea though.
>>  
>>  Sean
>>  
>>  
>>  
>>  
>>  On 12/11/07 1:08 PM, "Barbara Glover" <barbara.glover at utoronto.ca> wrote:
>>  
>>  
>>> Hi Eli
>>>  Thanks for sharing this.  It's quite interesting.  I like the idea as well
>>> for times when you may want to think about something before it's actually
>>> committed.  
>>>  
>>>  The little red triangle is an interesting cue marker as well.  And this
>>> allows the person as they work on the data to keep track of cells they've
>>> changed.  This approach might be especially good for large data sets like
>>> shown here.
>>>  
>>>  One thing I found difficult was determining how to save.  It took me some
>>> time to notice the Save icon in the upper left corner.  I had been looking
>>> in the lower right.  
>>>  
>>>  I think this could be another inline edit "pattern".
>>>  
>>>  Barbara
>>>  
>>>  On 10-Dec-07, at 12:15 PM, 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
>>>>   
>>>>  
>>> 
>>>  
>>>  
>>> 
>>> _______________________________________________
>>>  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/20071211/4ed66652/attachment.html>