[Design Patterns] pattern for marking changed items before save
Allison Bloodworth
abloodworth at berkeley.edu
Wed Dec 19 04:32:55 UTC 2007
Thanks to everyone for the interesting discussion of some of the many
different types of patterns surrounding editing, confirming, saving &
undoing! I've added all these to a "Pattern Suggestions" page (http://
wiki.fluidproject.org/display/fluid/Pattern+Suggestions) I just
created on the Fluid wiki for the Open Source Design Pattern Library.
For those of you who are just itching to get some pattern work
started before we kick off the new OSDP Library Pattern Development
working group after the first of the year, feel free to add more
suggestions on patterns that you think would be helpful to Fluid
applications here. Perhaps we can then vote on which patterns we
think it makes most sense for the group to start working on together?
I've also added a new working group to the main Design Patterns page
(http://wiki.fluidproject.org/display/fluid/Design+Patterns) where
you can sign up to be part of the OSDP Library Pattern Development
group.
Cheers,
Allison
On Dec 13, 2007, at 9:15 AM, Eli Cochran wrote:
> 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
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
abloodworth at berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071218/0668a3c5/attachment.html>