[Design Patterns] pattern for marking changed items before save
Eli Cochran
eli at media.berkeley.edu
Thu Dec 13 17:15:03 UTC 2007
As far as I know there isn't a sure-fire way to block navigation
using onUnload or onBeforeUnload (which, as you say, isn't even
canon) or any other event. But I'll do a little research.
I've always considered this one of those things that you live with in
a browser environment. Something you can make better but never make
right.
- Eli
On Dec 13, 2007, at 7:33 AM, Shaw-Han Liem wrote:
>
> 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
> _______________________________________________
> 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/20071213/0632344e/attachment.html>
More information about the fluid-work
mailing list