[Design Patterns] pattern for marking changed items before save
Eli Cochran
eli at media.berkeley.edu
Tue Dec 11 19:24:58 UTC 2007
Actually there are some nice ways to ask the user to save before
navigating away from a page.
Before saying what you can do I should say that there will always be
actions that a user can take that will lose data on the page (close
the window, hit the back button, quit the app, etc). Browsers vary on
which of these things they try to trap but for the most part they
don't even try.
But generally the technique is to set up a function that is called
when an elements data is changed and keeps track of what is dirty on
the page (Yep, that's the common nomenclature). Then any action on
the page (link, unload event, etc.) which causes navigation checks in
with the function prior to doing the action, and informs the user of
the state of things and provides them with the opportunity to save or
discard their changes.
I call this data-safe navigation. One of the components that we write
for Fluid should be a Javascript service that elements on the page,
both data and navigation elements, can use to manage data-safe
navigation.
Not fool-proof but something.
- Eli
On Dec 11, 2007, at 10:52 AM, Sean Keesler wrote:
> 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
>>
>>
>>
>>
>
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071211/a44f534e/attachment.html>