[Design] Edits and saving in the Web UI

[Jeremy Epstein]

Mimi Yin wrote:
> Hi Jeremy, please see in-line...I think there may be some 
> misunderstanding about what is being proposed?
>
> Jeremy Epstein wrote:
>>>> Also, we've talked about app-response times in general, but what's 
>>>> a reasonable amount of time for users to wait, when waiting for a 
>>>> *'Saving operation' *in particular?
>>> Now I am going to separate "overt saving operation" where a user is 
>>> in control, from a "covert" save operation where a user does no know 
>>> that is what is happening.
>>>
>>> *For a "covert" operation, a "hidden save", a "background save", an 
>>> "auto save":*
>>> According to the literature and hard research ( I hope your ACM 
>>> SIG-CHI membership is current) *its tied to human 
>>> perception*(evolution is pretty slow in responding to paradigm 
>>> shifts). About 1/10 of a second if it requires redraw. And no, I am 
>>> not talking about games or simulation where the number is 1/30-1/60 
>>> of a second with all (sonic, visual, haptic) responses fully 
>>> coordianted and synchronized to avoid motion sickness.  Otherwise, 
>>> be prepared to explain what is happening or offer the user a way out.
>>> *ICal *(and other non-modal editing apps such as photoshop, 
>>> illustrator, or lightroom, autocad, alias, flash) *generally 
>>> responds within 1/10-2/10 of a second.Try it.*
>>>
>>> If you want to break new ground with a non-modal editing style, go 
>>> for it! But you need speed to make it work. If you have an old copy 
>>> of the Apple Human Interface Guidlines, its a good introduction. I 
>>> can probably lend you my copy.
>>>
>>> Its not generally possible on the web if you need to listen to a 
>>> response,and redraw the screen. Not even close. With most companies 
>>> that do not have the resources of google (multiple oc3's to avoid 
>>> mae west etc...) the latencies alone are bigger than that. Not to 
>>> mention server processing time, client processing/rendering time....
>
> I don't think covert-save in the way you describe is on the table as a 
> proposal. I believe we're talking about user-activated auto-save with 
> feedback to let the user know that the web app is saving their changes 
> to the server.
There's no misunderstanding. I think you are trying to split hairs. I 
interpret a "covert save" as any time the application elects to take 
such an action without the user explicitly telling the application to do 
so. By "explicitly" I mean:
1) the user clicks a "save" button when presented with one
2) the user selects a "save" or "save event" option in a menu-bar while 
the event has focus
3) the user enters a keyboard shortcut for "save" indicated by the menu 
while the event has focus.
if its not one of those explicit actions, its covert. If the Detail 
View(DV) has focus and a user goes to minical to look ahead a week, they 
probably are looking ahead a week. If the UI is trying to be smart and 
saves, then it takes control from the user. Calling it "user-activated 
auto-save with feedback" doesn't change the fact that the user did not 
know in advance that their action might result in a delay, or how to 
stop whatever they did. They might draw the conclusion that minical 
forces saves, because that's the last thing they clicked on. They may 
also think twice about ever experimenting again if the system 
automatically exacts a "save penalty" enough times.

> If we really think the app will be unreasonably slow, we can even make 
> the 'save' process modal...disallow users from interacting with the 
> app until the save is done. 
That is similar to Matthew's position: the app will be unreasonably and 
unpredictably slow in enough situations to justify making the edit 
process modal.

> I'm asking why we need to ask users to explicitly click save with a 
> dialog when we can use the same interaction cue we use to pop-up the 
> dialog to automatically kick-off save.
Because its about notifying the user and putting them in control of the 
situation. Which is what allows you to make save "overt". If the action 
were "instant" that would not be an issue in my mind.

>>> *An "overt" save its a little different because the user feels they 
>>> know why a delay exists.* 
>>> This buys you a couple of seconds -- you can fake a spinner with an 
>>> hourglass. Much longer than a few seconds and you owe the user an 
>>> explaination as to why its taking so long, how long you think it 
>>> will take, and allow the user to cancel too.
>
> I think user expectations probably vary depending on the amount of 
> data they are saving. Editing location I would expect to be quite 
> zippy. Expanding a recurrence rule to be 100 occurrences instead of 3 
> occurrences understandably takes longer. How long does it currently 
> take us to process creating a new event on the calendar?
You are expressing an opinion, and you are certainly entitled to it.

Its my personal expectation, based only on my personal experiences, that 
both operations should be instant. As I wrote this I opened up outlook 
and created, then modified a daily repeating event with no end date, at 
least a hundred recurrences. I've done this many times in the past. I 
then changed the location. Both operations completed instantly ( i.e. 
within the 1/10 of a second it would take for me to notice) Without hard 
quantitative data I might suggest that within the modest demographic 
group of U.S. based white collar office workers outlook's performance 
sets one acceptable lower bar for performance. Ical may perform even better.


>
> Just to clarify: The slowness will happen if you edit the Title field 
> and then click in the summary table view to resort the list. This is 
> because the Title changing affects the sort order? Does that mean that 
> the UI will only be slow if the user resorts the list by the Title 
> column? <OR> Resorting by any column will be slow?
>

Hmm no. let me clarify with two examples:
*example 1: *
1) we have a list sorted (a-z) by title, showing the first page of data, 
items 1-10 of 100.
2) user clicks on the first item whose title is "Apple". 
3) in the Detail View, the user changes the title to "Zoo"
4) user clicks on the second event. This causes the first event to save. 
In saving its now on the page 10, and the first page of ten items now 
has a new entry. This may require a request to the server to refresh and 
reorder the first page of data.

*example 2:
*1) we have a list by title sorted (a-z) by title, showing the first 
page of data, items 1-10 of 100
2) user clicks on the title header (or a menu etc...) changing the title 
sort from (a-z ) to (z-a). This may require a request to the server to 
refresh the data.

In both cases the web UI has a buffer of items to display in the dash 
but a user action causes those items to go stale (because of the edit) 
or be irrelevant (because of the sort).  Even with all the  "AJAX" 
goodness  the server still does the heavy lifting. You really need to 
have Matthew or Bobby chime in for a definitive answer here. I do not 
know all the specifics of the persistence layer.

The only reason I mentioned location and notes as possible exceptions is 
that they do not show up in any view (to my limited knowledge) where 
they may modify data that may be used in generating or making sense of a 
view, as described above with a dash example. If in the future you can 
navigate items with a map, then location might also require server love.
> The attributes that show up in the table are:
> + Task stamp
> + From and To (if there are any)
> + Title
> + Start date/time
> + Triage status
>
> To summarize, the 2 scenarios we've identified that will make the UI 
> respond sluggishly are:
> 1. Editing fields that appear in the Dashboard and then resorting the 
> list; and
Please see my example above.
> 2. Editing the recurrence rule / recurrence
There may be requirements around non-recurring events as well. I'm not 
sure off the top of my head.  Keep in mind that requiring the item save 
mechanism to be fully aware of which combinations of view, state, and 
stamp allow for a "covert" save makes things very fragile and makes it 
very difficult for contributors to cleanly extend items with novel types 
of stamps. Engineering-wise it might be better all or nothing.
> Perhaps we could offer more specific messaging than 'Processing...' We 
> could say:
> + Re-building sort index...
> + Expanding recurring event series...
>
> That might help set user expectations?
Any time you tell the user why there is a delay may help. Without 
objective test data I can't say for sure. I also couldn't justify the 
engineering effort.

>> Addressing fields are especially tricky-- When you auto save are you 
>> going to send new invites out?
>> You might want to explain yourself there, because changes to address 
>> fields carry very specific expectations, and could put you in a 
>> tricky spot.
> There is no in-band sending capability for Preview. For Preview, 
> editing addressing fields is like editing any other kind of text field.
I'm only suggesting that users will apply previous knowledge of similar 
systems in trying to understand how addresses work.  Every user decides 
what simliar means for themselves
( if you are so inclined lookup Endel Tulving and his work on cued 
recall and don't forget to look into analogy and its role relative to 
procedural and declarative knowledge)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070509/33396f70/attachment.htm