[sugar] perceived sugar performance

[Eben Eliason]

Preface:  I agree with all points below!

On Mon, Apr 28, 2008 at 5:01 PM, Mikus Grinbergs <mikus at bga.com> wrote:
> I'm neither a child nor a teacher, so this opinion is personal :
>
>  What you want to avoid is having the user decide "my intent has been
>  ignored", when in fact it is something "under the covers" that is
>  delaying the completion of his intent.
>
>  The best way I can think of to avoid the user making a wrong
>  decision is to give him "feedback" whenever the XO enters a
>  condition perceived as "as yet, nothing seems to be happening".

We have been lacking in feedback in many many places in the UI, mostly
because it takes time -- more than we had up front -- to properly
handle all of the cases and add the proper feedback.  I hope we put a
very large dent in this problem before the next release.

>  --------
>
>  You are probably asking about situations where responsiveness is
>  expected in seconds (let educators determine how long a wait needs
>  to be to cross the threshold into "too long").  What I believe is
>  needed is showing "Yes, something *is* happening".  Many operating
>  systems use the cursor appearance to tell the user "working on it".
>  [Eye candy might distract the user during unavoidable waits.]

We do indeed have a busy cursor.  I think we should make use of it
more when it makes sense to do so.  Right now, Browse is the only
place I think I see it in use.

>  If confirmation takes "too long", the user might end up confused.
>  For example, I restarted an Activity from the Journal (no longer
>  remember which one);  nothing seemed to be happening, so I used
>  alt-tab to switch to an existing Activity;  a while later, while I
>  was viewing its screen, the XO suddenly transferred the display to
>  showing the screen of the new Activity, which had finally started.
>  [A change to supply an unmistakable confirmation of "Activity
>  starting" has been described -- I wish it were available now.]

We have a completely different approach to activity launching in the
works (I've been hacking it up myself...I need some help from the pros
to finish it!)  The new design will perform a quick (really quick)
zoom-in effect into a white screen with a large pulsing activity icon
in the center.  It will be possible to switch away from this
pseudo-activity view to do other things during launch. Do to window
manager limitations, it's non-trivial (as I understand it) to prevent
the system from automatically returning to the newly launched activity
when its ready.  Of course, the much desired interaction would be to
allow the user to go elsewhere, *not* automatically return them, thus
pulling them out of their working context, and instead show a standard
notification to indicate that the launch was successful.

>  Harder to endure are the situations where it can take minutes to do
>  something.  I am (and I expect others will be, as well) too
>  impatient to sit still and wait for these to complete - I'll switch
>  my attention to something else, and will need to be informed of what
>  became of the thing I was waiting for. [For example, I believe that
>  if connectivity to a server is lost -- recovery might be soon, but
>  also it might take more than five minutes.]  I believe there should
>  be an ongoing indication (e.g., slow blinking of a front panel
>  light) that unambiguously shows the user "I'm slowly working on
>  this", with a specific how-it-concluded indication when this
>  "working" activity ends (e.g., light goes off for "connection given
>  up for good", or light goes steady for "connection properly
>  established").

Actually, I think this is how the new design is working in joyride now
(it is, at least, how it's supposed to be).  Martin D. has been
working on refining the devices in the frame, and AP/Mesh devices are
next on the list.  Anytime an AP connection is in progress, it should
be pulsing in the Neighborhood and in the Frame.  Any time a
connection state changes, a standard notification should appear to
indicate this, including when connection is lost, or when a connection
fails to be established.

>  [Shutdown is an example of where I feel the XO is a "drag" - it
>  takes me 40+ seconds.  I don't know if "closing the lid" while the
>  screen is still lit will cause problems, or if before packing up the
>  XO I have to just sit and wait until the screen goes dark.]

This is unfortunate. On the other hand, I don't expect it will happen
*that* often, and even when it does, it's not really holding up all
that much, right?  I'd much sooner spend time making the boot process
take 1/2 or 1/4 the time it does now instead.  And even before that,
I'd like to improve basic feedback and responsiveness in the rest of
the UI!

- Eben