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
