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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
