Activity Launch Notification

Eben Eliason eben.eliason at gmail.com
Tue Apr 15 15:07:06 EDT 2008


>  I'm not sure what zoom level means or what the frame will look like in
>  this case. Regardless, if the kids can still launch other activities you
>  may want to check this design to ensure it covers the basic challenge
>  raised by Carol in the SouthBronx class. That is, does it prevent kids
>  from clicking on lots of things because they run out of patience while
>  waiting for the first to load then end up with too many activities
>  running and the whole system slows to a crawl?

Well, this is a "yes and no" answer.  I think that it will greatly
reduce the phenomenon, since it will "take away" all of the icons
which allow them to launch more activities by default, requiring them
to explicitly return to the other views to launch more.  Kids won't
just be able to click the next icon they see on screen.

>  My impression is that it will help a lot. Still, it does sound like a
>  good candidate for a trial with a few real kids. If you can mock it up,
>  maybe Carol can take it back to the class for a sanity check.

Absolutely.  There are a few changes iin the newer builds we'd love to
get direct feedback on.

>  Its certainly better than the blinking icon so even without a trial you
>  should probably just do it. Seems like a sure win unless there is some
>  other negative side effect (greater memory or disk usage, launch time
>  much longer, harder to code new activities, other?).

The pulsing could potentially slow the launch slightly, but I think it
will be minimal.  It's a very small area to redraw, and we can cache
the frames.

>  BTW I am starting to ask users if they like the "hot corners" frame
>  popup thingy. Let me know if you are open to feedback on that and if you
>  have any alternative design proposals to share or specific questions you
>  want answered.

We've recognized that accidental activation of the Frame is a problem,
but haven't had time to implement any of the proposed changes.  The
simplest change we hope to add is a tiny delay, to prevent accidental
activation when attempting to reach a button or element near the
corners.  Even a very small delay of, perhaps, 1/5 second should help
reduce this.  We'll likely add a slider to the control panel allowing
this value to be adjusted from instantaneous to off.  Other ideas are
welcome, as is any feedback that indicates the common causes for the
accidental activation. (Is it the jumpy trackpad?  attempts to hit
buttons in toolbars?  activities with canvases such as paint? etc.)

- Eben

>  -----Original Message-----
>  From: Eben Eliason [mailto:eben.eliason at gmail.com]
>  Sent: Tuesday, April 15, 2008 10:35 AM
>  To: Greg Smith (gregmsmi)
>  Cc: devel at lists.laptop.org
>  Subject: Activity Launch Notification
>
>  >  What if the activity "hangs"?
>  >
>  >  I have seen that several times with Xaos fractal builder activity and
>
>  > possibly others. I remember one case in Nepal where it took 20 minutes
>
>  > to launch eToys.
>  >
>  >  I think the UI suggestion is great and will help prevent kids from
>  > clicking on many activities while they wait for the first to launch.
>  >  Just want to cover the case where the first one takes a very long
>  > time  or doesn't launch at all. We need a way to abort (kill -9?) or
>  > go on  with other work if the activity is not coming up.
>
>  Well, there are two parts to this problem.
>
>  First, this launching screen will take the place of the activity zoom
>  level for the launching activity, before the activity window itself
>  appears. The Frame will remain available, allowing the kids to switch
>  away from the launch, in order to continue working in another activity,
>  launch additional activities, or browse the other zoom levels.  As such,
>  they'll never be "locked in".
>
>  Second, there's the issue of "force stopping" activities.  I brought
>  this up as something I'd like to support a while back, but found that it
>  is complicated by the manner in which activities are launched, since we
>  don't necessarily know the process ID it's running under during launch
>  (or something like that...Marco can clarify).  In any case, if we can do
>  it, we should, offering a "Stop" button in the palette for the launching
>  activity.  If we can't, it's still not a showstopper, since it's
>  possible to switch away, and the launch will timeout eventually,
>  preventing the pulsing icon from forever haunting the Frame.
>
>  - Eben
>



More information about the Devel mailing list