[Sugar-devel] Design mockup of a different activity launcher

[Avi]

Wade wrote:

 > Rationale:
 > 1) Less flashy
 > 2) Clock theme represents time
 > 3) Ability to count how many seconds the launch takes
 > 4) Close button (instead of timeout) when there is an error
 > 5) Possibly less startup overhead; needs to be tested on XO

My responses to this in order are:
1) I don't see how flashy is the actual problem with the activity 
startup process.
2) It also represents a progress meter, which is something that you 
cannot do correctly in this case without making it less apparently 
determinate. You've produced something which appears, at least to my 
brain, to be trying to complete the circle. Once the circle completes I 
expect the activity to launch. With an undetermined amount of time 
remaining, the idiom used should be one that doesn't appear to 
accumulate toward a goal. I'd be happier with sweeping dots if the 
previous ones faded away.
3) I think this is a fine rationale, but the given demonstration does 
not accomplish that task sufficiently well in my opinion.
4) I'm not sure I like the idea of adding an extra step between failure 
and trying again. Perhaps another way of indicating progress and 
occasional failure would eliminate the need for a short circuiting of a 
too-long timeout.
5) The current ridiculous startup overhead is not because of the visual 
idea; it is because of the implementation. A little bit of thought put 
into optimization would probably solve the overhead issue. For example, 
use pre-computed bitmaps instead of that astoundingly inefficient 
SVG-based algorithm. Also verify that the available hardware is being 
used effectively.

Eben wrote:

 > Oh, hmmm. That makes this a bit less useful, and even potentially
 > misleading. I don't think it's a good idea to show a determinate
 > progress indicator for something that takes an indeterminate length of
 > time. Even if we mapped the ring to the time we wait before a fail
 > launches, I think the visual would imply to the child that success,
 > rather than failure, was imminent, which could be frustrating.

This basically mirrors my thoughts in (2) above, and I think it's a 
really important objection to the presented metaphor.

What about the following idea?
Rather than displaying an appearing-to-approach-completion meter or an 
otherwise uninformative indeterminate-activity-indicator, gather launch 
time statistics for all activations of an activity and present that 
information in an appropriate infographic that gives much more 
information and assurance to the user.

One infographic that might work well is a graph of the probability 
distribution (pdf) of the activation's duration in the range from 
seconds 0 to <arbitrary kill point>. A sweeping beacon, like the icon of 
the loading activity, could show the user where along the time axis the 
startup process is currently, how long until the activity gets summarily 
executed, and about when success should be expected (after which, 
success becomes less and less likely). The graphic could be made 
approachable by all users by iconically labeling important concepts like 
fast, slow, dead, and now.

This approach would give the user complete information about what is 
going on and what to reasonably expect. It would also give children a 
unique learning opportunity to understand how experiences they 
accumulate over time can, for at least partially deterministic 
processes, be used to understand the world and predict future outcomes. 
It also gives a way for describing their experiences visually and 
numerically in a way that can easily be compared. It would also let 
activity authors better understand the loading behavior of their activities.

As an example of the kind of graphic I'm thinking of, scroll through: 
http://donsbot.wordpress.com/2009/09/27/fast-mutable-collections-for-haskell-more-benchmarks/

- Avi