[Design Patterns] pattern for marking changed items before save
Shaw-Han Liem
shawhan.liem at utoronto.ca
Thu Dec 13 15:33:54 UTC 2007
Coming into this a bit late, but I thought I'd throw this into the mix
re: 'Confirming Unsaved Changes' with Javascript.
The implementations I've seen use the unBeforeUnload() event to catch
browser closing, which as far as I know isn't actually part of the w3c
standard (did not work in Safari the last time I tried it). Has anyone
seen another way of doing this that plays nice across the target browsers?
Shaw-Han
Eli Cochran wrote:
> 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
>> <mailto: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
>>>> <mailto: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 <mailto:fluid-work at fluidproject.org>
>>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> fluid-work mailing list
>>>>> fluid-work at fluidproject.org <mailto: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
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
--
Shaw-Han Liem
Adaptive Technology Resource Centre
University of Toronto
shawhan.liem at utoronto.ca / 416-946-0423