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. 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.
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.
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?
One of the important things to keep in mind with UI is that the
user should always feel they are in control not the software.
Random delays take the "perception of control" from the user. Ever
see a Java IDE Garbage Collect? It sure would be nice if eclipse
told you it was about to garbage collect and how long it would
take. Then you wouldn't feel completely helpless, you might even
know if you could go for a coffee.
The way browsers approach this is with the little spinner in the
corner (you know the little globe or e or fox) and a progress bar.
It works great with "old" web apps. Too bad asynchronous HTTP
calls "break" the spinner. (sometimes it never stops spinning,
sometimes it never starts)
===
Jeremy Epstein wrote:
Whoops--
I spoke a little too soon:
If notes and location are not displayed in the dashboard list (and
thus are not sortable) then you might get away with changing them.
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?
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
2. Editing the recurrence rule / recurrence end-date;
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?
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.
Jeremy Epstein wrote:
Hello Mimi,
I wrote my response inline, following OSAF convention.
Mimi Yin wrote:
Ah! This is very helpful Jeremy. So can we isolate the scenarios
where auto-save needs to fetch a lot of data from the server?
Edits to the recurrence rule are one of them.
+ Changing the rule
+ Changing the end-date
What are some others? Will any of these be especially slow?
+ Stamping and Unstamping
+ Editing text fields seems equivalent to Pieter's gmail scenario
and probably won't take a long time?
- Addressing fields
- Title
- Location
- Notes
+ Editing date/time fields
+ Editing time zones
+ Editing event status
Well if you can change what fields you sort on in dashboard,
then all of them.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
