Frame Decision (was [sugar] OLPC priorities for Sugar in the August release)

[Eben Eliason]

On Sat, May 17, 2008 at 1:26 AM, John R. Hogerhuis <jhoger at pobox.com> wrote:
> Eben Eliason <eben.eliason <at> gmail.com> writes:
>> Right.  I think this is the biggest point of conflict between my own
>> thoughts for solving the issues and those of the community providing
>> feedback about it.  I certainly take the comments regarding accidental
>> invocation seriously, and seriously want to do what we can to
>> eliminate sources of frustration.  My inclination (I don't know for
>> sure!) is that the desire to completely abolish cursor activation
>> might be a treatment of the symptom and not the illness.  That is, it
>> could be that the trackpad plays a big role in the difficulties, and
>
> From watching my daughter I don't think there is anything going on with the
> trackpad. It's just that being near the edge pops the frame which is the design.

Indeed.  My other /suspicion/ (could be completely wrong, I admit!) is
that it's frequently bumped "in passing".  That is, the cursor briefly
overshoots a toolbar button near the corner and then very shortly
thereafter returns to it; one using a paintbrush makes a stroke that
goes beyond the lower right boundary of the screen; etc.  These issues
(in addition to the trackpad bug which could occasionally "warp" the
cursor to a corner) /might/ be lessened by the proposed delay.

> One possible idea: rather than popping up the frame when near the edge, pop up a
> translucent overlay in key places that looks just like the keyboard frame key.
> If the user clicks on it, then bring up the whole frame.
>
> This would hide much less of the screen so it would be less likely to interfere.
> It would also allow discovery of the keyboard key for the frame.

This is actually a very promising idea indeed.  I think this merits
some exploration for sure, and save the delay miraculously pleasing
everyone, something we should definitely try in the near future.
Someone mentioned this could be hard without compositing, but we can
certainly just toss up a (frame-colored) 75px square window in the
appropriate corner (or all of them?).

Another interesting addition to this idea would be to turn the corners
of the Frame itself into "retract" buttons.  If someone chose (and we
still support) instant corner activation one /did/ accidentally invoke
the Frame, a quick click would send it happily back off screen.  I
offer this mostly as an addition to your suggestion, though, since it
could be a nice reciprocal action. Eg. move to the corner and see the
frame icon with an arrow pointing "into" the screen, and click it to
reveal the frame; instantly see the arrow reverse to point "out of"
the screen, and click again to hide.  Thoughts?

> In general, I think the Frame points up a process issue: extremely new/radical
> GUI ideas require extreme testing. Basically the Frame is an experiment. It's
> good to experiment, it's important to experiment, but you need to test it on a
> limited sized group of kids, and it needs to be dealt with quickly when it
> causes a problem. This issue has gone on too long.

Agreed that an attempt at a fix has taken too long.  You're also right
that the frame is in several ways experimental.  Hot-corners have
certainly been used in other places (I admit, I use them in OSX all
the time), but never (as far as I know) made mandatory.  The design
goal for the frame itself, of course, is both to provide a persistent
interface element (which I think we all agree is needed for clipboard,
status, etc.) which doesn't consume precious screen real estate,
detracting from the activity (and more importantly doesn't steal an
edge of the screen, which by Fitt's Law is the best place for
buttons/controls since).  Anyway, my personal interpretation (other
feedback welcome!) is that the design goal is actual a successful one,
but that its method of activation is unsatisfactory to many.

- Eben