[Design] [cosmo] [sum] [bug 7633] [bug 8397] Edits and saving in
the Web UI
Mimi Yin
mimi at osafoundation.org
Wed May 16 15:17:49 PDT 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070516/241d1170/attachment.html
More information about the Design
mailing list