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

[John R. Hogerhuis]

On Sat, May 17, 2008 at 8:45 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
> On Sat, May 17, 2008 at 1:26 AM, John R. Hogerhuis <jhoger at pobox.com> wrote:

> 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.
>

Yes, a debounce of the frame activation might help. How long would the
delay be? I would think it would have to be < 150ms to not cause a
noticeable delay. I'm generally opposed to things that take a
noticeable amount of time since in aggregate all of these little
delays make the system "feel" slow.

But then, I think with the Frame key available, once discovered, no
one will use the corners. But like all of this, that's definitely a
WAG.

>> 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?).
>

I think it makes sense to pop it up in all corners. This would teach
the user that she can use any corner to activate the Frame.

> 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?
>

Yes this would provide symmetry which is always satisfying and usually
a good thing.

My first thought would be to make it a frame icon initially, and a
frame icon with an X in the middle to cancel it. But the in/out arrow
might make sense. Perhaps it deserves to be tried both ways to see
which is more easily understood.

A instantaneous way to deactivate the Frame would be a big improvement
over the current situation, where once you've accidentally summoned
the Frame, you drag the cursor back to the middle of the screen and
wait for it to go away. There's a frustration cost there... the user
is already frustrated about the Frame coming up, now she has to wait
for the machine to figure it out rather than indicate directly what
she wants.


> 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.
>

Yeah, sorry for being imprecise, Eben. I have no problem with the
Frame concept itself, just activation. I was trying to make a general
process recommendation on the more radical ideas. These innovations
ought to be vetted by actual users early and often. Now that there are
some 600,000 XO's out there, and many of them in the hands of people
on this list with kids, the project would benefit from some fast-turn
test cycles with experimental builds.

-- John.