Just to be clear, this thread was purely a fact-finding mission and
not intended to change our plan of record around save-behavior for
Preview.
The goal was simply to come out of it with a better understanding of
the issues and a solid summary.
Thx!
Mimi
On May 16, 2007, at 10:57 AM, Mimi Yin wrote:
Hi,
Thx Priscilla for pulling together this long thread. I'd like to
take this opportunity to pull out some of the takeaways from our
conversation. I think we made a lot of progress on this topic and
when we revisit it Post-Preview, we will be able to pick up where
we left off with a much better understanding of scenarios, risks
and factors.
Please review the list below to make sure I haven't left anything
out or misunderstood something.
Original Proposal:
+ In the few cases where we plan on popping up a Save dialog, save
the user's changes automatically instead.
+ Provide visual feedback to explain to the user that their edits
are being saved. (e.g. Processing...)
+ Potentially remove the explicit Save button altogether from the
Detail View form.
Technical Risks we take on if we go with this Proposal
1. Anytime we commit edits to the server, we will slow down the UI.
2. Users may not know why the UI is all of a sudden, moving slowly.
The experience may just feel broken.
3. There is potential data loss because there is no way to
checkpoint changes
Ways we might be able to mitigate the above risks
1. Anytime we commit edits to the server, we will slow down the UI.
What if we narrow the scenarios under which you auto-save?
+ Only auto-save when users would otherwise *have to* explicitly
save; or IOW
+ Only auto-save when we would pop-up a Save dialog
Specific scenarios are:
+ Changing collections
+ Changing what item you're viewing in the summary pane
+ Logging out
+ Closing a tab/window
+ Going to a different URL
2. Users may not know why the UI is all of a sudden, moving slowly.
The experience may just feel broken.
What if we provide user feedback about what the UI is doing?
+ Saving changes to recurrence rule...
+ Fetching 300 new occurrences...
Note: There is disagreement about whether such visual feedback
would be enough to address user confusion issues.
What are the specific scenarios where the commit would seriously
slow down the UI?
+ Changes to recurrence rule on an event
+ Changing an item's triage status and then resorting the Dashboard
by triage status
Note: I think we need some way to roughly quantify 'slow' and
probability of 'slowness' to better understand this risk.
3. There is potential data loss because there is no way to
checkpoint changes
Given our use cases, are there any workflows that involve long edit
sessions? Is explicitly checkpointing changes a common scenario?
What if we kept the explicit Save button around, but removed the
requirement that it needs to be prominent in the UI?
Additional Data Loss risk
1. Users may lose data in the following scenarios:
+ Users may try to log out, which kicks off auto-save. There is an
error with auto-save, but the user has walked away from the
computer, but they are still logged in.
+ Users close the tab/window which kicks off auto-save. There is an
error with auto-save. There is a marginally higher chance with auto-
save that edits won't be successfully saved.
+ Browser crashes, which kicks off auto-save. There is an error
with auto-save. There is a marginally higher chance with auto-save
that edits won't be successfully saved.
Ways we might mitigate this risk: Isolate the scenarios where auto-
save poses these usability risks and pop-up an explicit Save dialog
instead.
For the IRC transcript of a discussion re: risks with mde, please
see: http://wiki.osafoundation.org/script/getIrcTranscript.cgi?
channel=cosmo&date=20070515
(Conversation starts at 15:06)
User Experience Issues the Proposal is attempting to address:
+ Users have an expectation of auto-save functionality because of
the our unconventional 3-pane layout where the DV appears
concomitantly with the summary view.
+ Users find it annoying to have explicit save every time the
dialog pops up because they almost never want to discard changes.
Ultimately, I think all of these risks and proposals will need to
be evaluated wrt use cases and actual usage.
Things to keep track of to help us answer the above questions:
+ How often do users explicitly Save?
+ What kind of edits are being Saved?
+ How long does the average Save take?
+ How many times do users explicitly Save within a single edit
session? (aka without switching what they see in the DV)
+ How often does the Save dialog pop-up because the user forgot to
explicitly Save?
+ How often do users want to Discard changes?
Conclusion: There are clearly additional design and schedule risks
we take on if we attempt any kind of pseudo-auto-save workflow.
However, from a purely technical / implementation perspective, it
does not appear to be a huge delta between implementing auto-save
versus popping up an explicit save dialog. There are however
uncertainties around select scenarios that might require us to
iterate in order to deal with unforeseen edge cases.
Mimi
On May 10, 2007, at 3:04 PM, Priscilla Chung wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
