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)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
