Hi,
I'd like to try and summarize this conversation as there might be
some confusion around the issues.
So currently we have a bug 8397 [https://bugzilla.osafoundation.org/
show_bug.cgi?id=8397] targeted to future for auto save on the web UI.
If I may, I'd like to table any discussion for auto save, because
that particular feature is not scheduled for preview.
---
The thread originated because of bug 7633 [https://
bugzilla.osafoundation.org/show_bug.cgi?id=7633], if the user starts
to create an item in the detail view, then changes focus and clicks
on a lozenge in the calendar canvas, the user will lose their initial
edits in the detail view.
The last call/decision of the proposal on the list are:
http://lists.osafoundation.org/pipermail/design/2007-May/007084.html
1. The web UI will be able to preserve edits made in the detail view
(do the right thing) when the user clicks on a lozenge for the *same
event* they are editing in the detail view. If the user then
manipulates the lozenge,(say to change the start time) it will save
both the result of the manipulation, and the edits made in the detail
view. (originally proposed: http://lists.osafoundation.org/pipermail/
design/2007-April/006842.html).
2. A dialog will appear when the users clicks on a *different event
or anywhere else on the application*. The currently proposed dialog
will say: You have made changes to the currently selected item. Do
you want to save your changes? [Cancel] [Discard] [Save]
---
*The short summary*
*Based on the proposal for bug 7633, the question is:*
If it's possible to have explicit saves when the user clicks off of
the lozenge for the selected event, why is it not possible to do the
same thing if we list out specific items in the web UI. Could we also
allow 'explicit save' (and do the right thing) without the need of
popping up the dialog box?
*Answer:*
Eventually the lozenge for a selected event and the detail view will
need to link to each other, ie. bug 7849, to allow the user to edit
in place on the lozenge. This work includes linking the selected
event lozenge to the detail view. This is work that is needed to be
done eventually so it made sense to move forward with the explicit
save—only for the lozenge for the selected event.
No other items in the UI share in the special relationship between a
selected event's lozenge and the selected event's in the detail
view. All other items in the web UI are not going to trigger a save
and will trigger a dialog to ask the user what to do.
Note: The user has to either move and release the selected lozenge or
click 'Save' in order to save the detail view of the selected event.
Clicking on the selected lozenge with out moving it will *not save*
the detail view, but it doesn't discard it, either.
So for preview, the proposal (as noted above) for bug 7633, still
stands.
---
*The long summary of the discussion:*
Matthew: Addresses the problem of auto save on the web UI. 1.
Periodic auto-save in the browser won't be mostly instantaneous and
painless like it is in a desktop app. 2. Some changes to data require
a subsequent data-fetch. 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.
Mimi: In response to Matthew, clarifies in #1, this is to not request
for auto-save, ie periodic auto-save. If the user has to explicitly
click 'save' in a dialog box, instead of prompting the dialog box
with a 'save' button, save anyways as the default action when the
user clicks off of the detail view. #2, To display a 'processing…'
message similar to double clicking to create a new event. #3, asks if
it's possible to just automatically save instead of having a pop up
to explicitly save. Addresses the concern about users not saving at
all. Lists out the kinds of edits users might be doing in the preview
timeframe: adding PTO time, updating status and tasks and adding an
agenda item to a meeting. There is no expectation for long meeting
notes in the description field on the web UI.
Mikeal: Asks Matthew in regards to #2, change to data require
subsequent data fetch, to clarify if the UI will become totally un-
functional or just 'sluggish' and 'slow'. Likes the 'Processing…'
message, but would like to see it visually out of the way.
Jeremy: Responds to Mikeal's questions, certain browsers processing
request may tie up the browser until the payload is processed. This
greatly depends on what the user is doing. A small amount of data
change could freeze the browser. In response to 'sluggish' or 'slow',
identifies a few rules of thumb: 1. if you can manage it make it
happen within 90ms ( fast enough to percieve its instant). 2. if it
takes between that and about 10 seconds, use an hourglass -- tells
the user it may take a minute. 3. if it takes more than that use a
progress bar and update it frequently so the user doesn't think your
app froze. Comments that it's a convention in both web applications
and desktop applications to explicitly save, listed examples, but
noted that there are always exceptions to the rule, ie. iCal.
Matthew: Responds to Mimi, delighted we're not talking about some
kind of background-save process. List out some issues with auto-save.
Adds that prompting users about unsaved changes is standard practice
in web UIs. Confirms about writing long messages in the notes field
is not currently not the targeted use-cases for preview.Feels
strongly about making sure the web app leverage web app conventions,
unless there is a big value in throwing them out.
Jeffrey: Asks Matthew, if he could explain why the save can't be done
asynchronously with different callbacks depending on whether the save
failed, time out, or succeeded while normal rendering the event
handling continues for the user? Adds the disclaimer that he has not
used Javascript in ages.
Pieter: Comments about Google/Gmail had added an auto-save feature a
while back, but still have the 'Save', 'Now' and 'Discard' buttons
when creating a message. About every minute, there is a status
message next to the buttons of when a draft is auto-saved. The auto-
save is instantaneous and doesn't interfere with Pieter's typing, nor
does he notice the lag time. An error appears when navigating away
from the message with unsaved changes.
Mimi: Replies to Matthew addressing higher lever issues. Enumerate
some issues about web conventions. Enumerate factors that contribute
to the auto-save vs. explicit-save. Notes, the explicit save workflow
is fine for preview. Trying to understand the technical challenges
for implementing 'auto-save when users would need to explicitly save
anyway'. Does the web app slow down when the users does an explicit
save? Or is it faster by having an explicit save?
Jeremy: Replies to Pieter noting the activity of 'auto-save' on
Google/Gmail is actually checkpointing. A web UI 'auto-save' differs
from Gmail because there are multiple edits in the detail which need
to be rendered where as Gmail has very little to re-render.
Mimi: Responds to Jeremy, asking if there is a way to isolate where
the auto-save needs to fetch the data from the server. Lists out the
scenarios and asks what is the reasonable response time for users to
wait for a 'saving operation'.
Jeremy: Replies to Mimi, describes 'overt' save operation and
'covert' save operation. References research from AMC SIG-CHI on
response time is tied to human perception. Enumerate a couple of
examples about response time. Continues to explain that it is
important for the user to always feel like they are in control, not
the software. Random delays take the 'perception of control' away
from the user. In a follow up e-mail Jeremy addresses the slowness
and explains the complication of specific items in Mimi's list where
the user could potentially click off of to auto save.
Matthew: Replies to Jeffrey that his implementation suggestion is
already implemented with the current lozenge to drag, drop and grab
another lozenge. Comments that XHR calls do not block the UI, but
make the app feel sluggish and unresponsive.
In a follow up e-mail, replies to Jeremy and +1 the comment about
garbage collection as an example of sluggishness in the web app.
In another follow up e-mail, replies to Mimi, agrees the 3 pane
layout is unconventional and comments that other web apps side step
the issues where it forces users to make an explicit save by taking
the user to a new screen. Agrees users do not think along the
technical lines of there should be an explicit save, but in building
the application, there is still a practical need for having the user
to make an explicit save even in using Ajax. Comments that iCal is a
desktop application and does not have to deal with network latency
issues a web app has to deal with. Adds that perceived performance of
speed in the web app is another factor that contribute to auto save
and notes that it's difficult to make the web app feel snappy. Adding
background save has the potential to make the application slower.
Mimi replies to Jeremy, confirms the way he's described covert save
is on the table for discussion. Clarifies if the interaction is to
explicitly save with a dialog, then it is possible to do the same
interaction cue (to explicitly save) without popping up a dialog.
Continues to expand on user's expectations depends on the amount of
data they are saving. Questions how long it currently takes to create
a new event on the calendar?
Jeremy replies to Mimi, restates what explicitly means and if it's
not one of the actions examples listed then it's a covert save. The
concern is that if the UI is trying to be *smart* and saves, then it
takes control from the user. Agrees with Matthew's point about the
unpredictable slowness in situations to justify making the edit
process model. Answers the question about why we need to explicitly
save with a dialog instead of doing the same interaction with out the
dialog. Notifying the user and putting them in control, such as an
overt save model. Notes, if the action were instant it would not be
an issue. Believes user's expectation of operations on the web UI
should be instant on editing a location and expanding a recurrence
rules per Mimi's examples.
Clarifies the question about the slowness if you edit the Title field
then click in the summary table view to resort the list. Enumerate
some examples of how the web app would need to make a request to the
server to refresh the data on the page. The web UI keeps a small
amount of data to draw the display. It's easy to do thing which force
the web UI to ask the server for more data or more up-to-date data.
Sorting a big list or editing events require the web UI to ask the
server.
Matthew responds to Jeremy, about covert save, adds in the web UI,
the user drags to move or resize the calendar lozenge and drops it on
the canvas. Agrees with Jeremy that if there are large set of data,
pagination and sorting will be done on the server.
Mimi replies to Matthew. Acknowledging the risks that Matthew and
others have raised and explain how they might play into how we decide
these design issues. Noting all the issues to may not be needed for
preview, but is useful to understand in the longer term. Agrees about
technical risk and wonders if the three pane layout may be a strong
factor then the network latency issues in influencing users
expectation around save. Acknowledging the discussion has been
helpful to isolate the actual risk vs. the general risk. Adds that it
would be useful to get numbers in terms of performance risks for
specific use cases which are common in the preview time frame. Post
preview it will help weigh the performance risk against the user-
expectation and workflow concerns.
Did I captured everyone's comments fairly? Or if I'm missing anything?
Thanks, -Priscilla
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
