Hi Matthew, Thx for writing this up. Please see more questions in-
line...
On May 7, 2007, at 7:58 PM, Matthew Eernisse wrote:
1. Periodic auto-save in the browser won't be mostly instantaneous
and painless like it is in a desktop app. There will be noticeable
lag when the front-end talks to the server -- and the UI will
suddenly go sluggish for what appears to the end-user to be no
reason. (And since it's supposed to be happening invisibly in the
background, I presume there would be no 'talking to the Mothership'
status message.)
Just to clarify, I'm suggesting we only 'auto-save' in cases where
the user would need to explicitly click 'Save' anyway, aka when they
"click away from the item and the DV changes what it displays". I'm
not proposing that we auto-save at regular time intervals or every
time the user commits out of a form field or every x-number of
characters the user types, etc. In other words, the the web client
won't be pinging the server any more than it would anyway with an
explicit-Save design.
2. Some changes to data require a subsequent data-fetch. For
example, when the user makes a change to a recurring event, we need
the new recurrence expansion back from the server to repaint the UI.
Could we display a 'Processing...' message the way we do when we d-
click to create new events on the calendar?
3. Data loss becomes more of a possibility if the user closes the
browser and doesn't bother to read the dialog we would pop up to
warn of unsaved changes.
Could we auto-save using the same cue we would use to pop-up the dialog?
Browser crashes would mean likelihood of more lost data because
users would not be explicitly saving changes incrementally.
Well, I think the problem we're facing right now is that we fear
users won't remember to save at all. Given the use cases we usually
talk about, I'm not sure that the kinds of edits people will be doing
in the Preview timeframe will span enough time such that users will
be hitting Save multiple times within a single edit session.
+ Adding PTO time
+ Updating your status on a task
+ Adding an agenda item to a meeting
Now, if someone were composing a long message or writing up meeting
notes in the Notes field, then yes I agree with your analysis. But I
don't think we're expecting that for Preview.
Those are the main issues I can think of off the top of my head.
Can anyone else think of any other potential problems?
If we can come up with some clever (and bulletproof) solutions to
all of them, I think it would actually be a feature worth working on.
Thanks.
Matthew
Matthew Eernisse wrote:
Mimi,
There are both technical and design-philosophy reasons that would
make implementing something like that potentially problematic in a
Web UI. At this point, I lean very heavily toward not wanting to
go that route.
That question gets us into the autosave can of worms (opened by
the idea of implementing edit-in-place on the lozenge) that I
alluded to in the last e-mail. I'll write up a detailed post which
attempts to describe what I see as the issues, and the potential
solutions and their benefits/drawbacks.
Thanks.
Matthew
Mimi Yin wrote:
This is great Matthew. I'm wondering if we can push this even
further. Is there a technical reason we can't try and 'do the
right thing' and commit changes to the server whenever users do
something that would make the detail view either disappear or
change to display the details of a different item? This would
basically mean:
+ Clicking on a different item in the summary pane
+ Switching collections in the collection pulldown
+ Logging out
+ Leaving the Hub UI altogether
+ Closing the browser window
Mimi
On May 2, 2007, at 12:08 PM, Matthew Eernisse wrote:
After some further thought -- and a bunch of chitchat with
Jeremy Epstein that was really helpful -- I see that there's a
better solution to the first of the two scenarios that doesn't
involve throwing up a dialog at all.
The two scenarios are:
1. Users click on the lozenge for the same event they are
editing in the item detail form
A dialog box is actually not needed here, because the user's
intent is clear.
The UI should just do the right thing in that case, and apply
edits from the form along with the changes to start and end time
caused by moving/resizing the lozenge. (If the changes in the
form include a change to start/end, then the move/resize changes
would overwrite them.)
2. Users click on the lozenge for a different event.
Here we still need the dialog to ask users if they want to apply
changes, discard changes, or cancel the change of selection to
the new event.
This seems to me like a fairly obvious improvement in the case
of number 1, so unless there are some objections, I'll take this
tack when doing the fix for this bug.
On a related note, in talking about this with both Priscilla
(and later Jeremy as well), some interesting questions came up
regarding the behavior of saving changes to items in the
Chandler Server Web UI. This can of worms was opened up by the
question of how to implement edit-in-place for the event title
directly on the lozenge. (There's an open bug, no. 7849, for this.)
I'll address that stuff in a separate e-mail to the list.
Matthew.
Matthew Eernisse wrote:
I agree that 'Discard' is better. I'd also like to propose a
change to the prompt that makes it clearer why the dialog has
popped up. I propose the following:
You have made changes to the currently selected item. Do you
want to save your changes?
[Cancel] [Discard] [Save]
I do kind of like the addition of the word 'Changes' in the two
right-hand buttons. (And I'm usually a fan of one-word button
labels.)
It makes it totally clear what the choices are, even if the
user doesn't really bother to read the prompt. It also
underlines more clearly the difference between discarding the
changes and proceeding, and canceling and going back to the
state you were in before.
I do however think the button labels are perfectly usable as-is.
Matthew
Priscilla Chung wrote:
Last call…? -Priscilla
On Apr 24, 2007, at 12:37 PM, Priscilla Chung wrote:
If people don't feel strongly about the proposed buttons,
then let's finalize a decision on this proposal. ---
Save changes?
[Cancel] [Discard] [Save]
-----------------------------------------------------------------
-------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
