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

[Eben Eliason]

On Sat, Oct 17, 2009 at 8:10 PM, Wade Brainerd <wadetb at gmail.com> wrote:
> Hi Eben, thanks for the feedback!
>
> On Sat, Oct 17, 2009 at 7:27 PM, Eben Eliason <eben at laptop.org> wrote:
>> On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd <wadetb at gmail.com> wrote:
>>> http://www.youtube.com/watch?v=OvDdN1t-0yE
>>>
>>> I was in the code and have wanted to try this for awhile!  If anyone
>>> else thinks it would be better than the pulsing icon, I'll clean up
>>> and post the patch to a Feature on the wiki.
>>>
>>> Rationale:
>>> 1) Less flashy
>>
>> Perhaps, although the screen actually feels busier to me. Perhaps with
>> some visual tweaks it would work (smaller ring, maybe?), since showing
>> how long it will take to launch is useful feedback.
>
> I'm happy to make any tweaks to the layout, colors, sizes of the dots,
> spacing, etc.  If design can provide a mockup, that would be great!
> But if not, I'm happy to take suggestions and try to improve it.
>
>> I lament the loss of the pulsing icon, though. This approach doesn't
>> retain the transition from outline to fill that's important to the
>> activity paradigm. Could we retain that, or is that the "flashy" part
>> you aim to eliminate?
>
> I wanted to stop drawing something big every frame while the activity
> is trying to start; that's the supposed performance improvement.
>
> Blinking would be fine, or a brief fade in at the beginning.

Yup, I suppose both could work. The reason to blink, I suppose, is to
illustrate the intermediate state throughout the launching phase. We
use the same metaphor for connecting to networks, as well.

>>> 2) Clock theme represents time
>>
>> I don't understand how we know how long the launch is going to take.
>> Is that something that we can estimate to a reasonable degree? Or do
>> you plan to estimate the average launch time across many launches?
>
> No - the clock just displays one new dot per second.  So an activity
> which launches in 3 seconds shows 3 dots.

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.

> I could implement some estimation capacity, but that would mean the
> dots appear faster or slower.  I prefer to let the user see there is a
> different amount of work involved in starting each activity, instead
> of implying that the same amount of work is being done at a different
> rate.

Hmm, it seems like you're arguing against the progress bar, as we know
it. =)  I guess it's just the difference between an absolute and a
relative measure of progress, and the use of an absolute makes some
sense if we can't know how long an activity is going to take to
launch, but it still strikes me as the wrong metaphor.

As I mentioned before, I think it's much more important to the child
how much longer the launch will take (not how long it's taken so far).
In either case, perhaps we can get the same type of feedback by
counting the number of times an icon blinks. You could set the
frequency to 1 second.

>>> 3) Ability to count how many seconds the launch takes
>>
>> I'm not sure I see usefulness in knowing how long it takes overall;
>> knowing how much longer it will take is definitely something a kid
>> will want to know, though, so it's good to show that.
>
> The way it's implemented now, the kid has to remember how many dots an
> activity takes to start up.  But I think that could aid children who
> are learning to count :)  (WARNING: Heresay!!)

Heh.

>>> 4) Close button (instead of timeout) when there is an error
>>
>> This is definitely a big improvement. I like this a lot, and think we
>> should also add options for looking at the crash reports and/or
>> submitting a bug containing them to the maintainer of the activity,
>> eventually.
>
> I did some work towards this, with a patch ready for 0.88, in
> http://wiki.sugarlabs.org/go/Features/Problem_Reports.  I will
> definitely make it automatically save the activity log to the Journal,
> though.

Actually, I don't think this should be automatic. I would recommend
the options (report bug), (view logs), and (stop). This would give the
child the option to look at the logs if they wanted, but wouldn't
otherwise put items in their Journal they don't want or need. I'm not
sure if reporting is possible given the current infrastructure, but it
could be useful, in the long run.

>>> 5) Possibly less startup overhead; needs to be tested on XO
>>
>> True. If CPU is a concern, I'd vote to simply blink the icon between
>> stroke and fill states, instead of pulsing, in order to reduce the
>> animation overhead while retaining the visual metaphor.
>
> Blinking would definitely be ok.

Yeah. It doesn't have quite the same appeal, but it would be less CPU
intensive. Incidentally, how does the launcher perform on the XO 1.5
units? Has anyone had a chance to try it out? I imagine that on most
netbooks, and even the new XOs, the pulsing wouldn't be too much of an
issue. (I don't want to discount the existing multitude of XOs, of
course; blinking may still be a safer choice in the short term.)

Eben