[sugar] An experience report with joyride-1916

[Eben Eliason]

Thanks for the time spent with it, and the feedback!  Responses to
some items follow...

On Fri, May 2, 2008 at 5:46 PM, Michael Stone <michael at laptop.org> wrote:
> Dear sugar@,
>
>  I played with some of your recent work in joyride-1916 for a few hours
>  yesterday and I took notes on things which surprised or bothered me.
>  Here they are, in no particular order:
>
>   * I had a Browse-87 in /home/olpc/Activities and Browse-86 in
>    /usr/share/activities. (I installed Browse-87 by manually unzipping
>    it, then restarting Sugar). I starred Browse-87 and attempted to
>    launch it. Browse-86 was launched.

That does sound like a problem indeed!

>   * It takes a _very_ long time to populate the list view. Feedback
>    is needed. (In particular, why can't we draw items incrementally as
>    we discover them?) [This confused Carla when I showed her the new
>    UI.]

This is unfortunate.  Obviously loading them async would be the best
solution, and will have to be the implementation in the long run,
since the list view is explicitly meant to be the scalable one which
could hold many activities.  I recall hearing a reason that this was
presently infeasible, but I don't recall what it was.  It would be
even nicer if this could be done in the background, so that unless you
switched immediately to list view it would be populated by the time
you got there.

>   * It's hard to figure out that you need to visit the list view in order
>    to populate the ring view. I have a couple of suggestions on how to
>    deal with this.

This is the number one point of confusion with the new UI, and it
wasn't a problem we even thought could arise when designing the new
UI.  At the time, we were anticipating a set of "core activities"
which shipped with the build would always appear here as a default.
Naturally, this is high on the list of things to fix to make the new
UI shippable.

>       a) If no activities have been starred, display a graphic
>       indicating that starring activities will put them in the ring and
>       give a big, prominent button that takes you to the list view.

Interesting possibility.  You could also start in list view, of
course, but then we potentially skip the quintessential view of the XO
laptop on a child's first experience with it, which I don't enjoy.
Moreover, I'd strongly prefer to always have *something* in the ring
by default.  It seems counter to our goals to require "management"
interaction of any kind before jumping into activities.  One click
from Home should be made a goal, *especially* for first time users.

>       b) If no activities have been starred, include an icon for a
>       tutorial activity which, among other things, teaches you how to
>       star more activities.

I'm not as excited about this option.

>       c) Pressing the "home" zoom key (i.e. the circle with a single
>       dot) multiple times should cycle through the ring and list views.
>       (And maybe the Journal as well? The Journal is much more
>       shell-like than activity like at this point.)

This is another interesting idea that Ben also brought up last week in
a more general sense, and I think it sounds like a good idea to adopt.
 Basically, we intend to later have list views for all zoom levels in
the future (and, potentially, other views as well!).  We also have,
potentially, a number of activities open.  Thus, we can interpret all
of the zoom level buttons as first switching to the level, and
secondarily cycling through the available views or activities.

d) The option regarding the lack of default activities is one that I'd
personally like to solve via the activity packs (is this a formal term
for them?) which countries will use to install activities in the base
builds.  This format should include a mechanism for choosing a default
set among those installed, so that kids always see them in the ring,
first thing.  Discussion was held around future activity pack installs
(which could include a new set of defaults, for instance, for a new
school year), and we determined that the best approach would be to
star the installed activities as an OR of those the child already has
starred and those the activity pack specifies to be starred.

>   * Activity icons stop pulsing _long_ before a window is mapped onto the
>    screen. This is a big problem. Eben has proposed one method for
>    solving it; however, there's not nearly enough visual feedback
>    connecting the pulsing icon in the corner with the icon I've clicked.
>    I really think that visually representing the queue of activities
>    being launched and visually moving the icon of the activity being
>    launched into that queue would be a good idea independent of big
>    pulsing activity splash screens.

I'm still in favor of the big splash screen, myself!  It looks nice,
and should solve the problems of instant feedback, and impatient
multiple launches.

>   * Stopping one activity from the home view should not cause another
>    activity window to be foregrounded.

Interesting observation, and I agree.  Only if one is already in the
activity zoom level should the next window be foregrounded.  I suspect
this requires a solution very similar to the one which will prevent a
newly launched activity from being foregrounded unless one is looking
at its "splash screen" when it finishes.

>   * We should use the "stop-sign" icon for both stopping activities and
>    for disconnecting from the mesh. [Carla's suggestion]

Yeah, getting the semantics correct there is tricky.  So far, I
believe we're using the 'x' button on all devices to mean stop/turn
off, and the check button to reactivate them.  I'm hesitant to bring
the activity stop/resume semantics to this, actually, but I'm
certainly up for other alternatives as well, or more discussion on
this suggestion.

>  Thanks,

Thank you!

- Eben