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

[Eben Eliason]

On Fri, May 16, 2008 at 4:04 PM, Marco Pesenti Gritti
<mpgritti at gmail.com> wrote:
> On Fri, May 16, 2008 at 8:14 PM, Greg Smith (gregmsmi)
> <gregmsmi at cisco.com> wrote:
>> Hi Simon, Marco, Eben et al,
>>
>> I think the key decision is to default the frame on or off. In addition
>> we should have a long term vision for the frame. For example, is it a
>> short cut to find things or a first place to look for key features?

The Frame is certainly not designed to be a "shortcut", but a critical
element of the UI which transcends any particular activity or view.
Elaboration below...(and also at wiki.laptop.org/go/Designs/Frame)

> Eben, correct me if I'm wrong, I think we went through various
> iterations of this.
> I think the idea is that the frame is a bridge between the various
> activities and views (the only thing which doesn't exactly fit are
> devices)

It's intended to serve both as the "status element" and as the "glue
between views/activities".  In effect, it is the part of the UI which
communicates the State of Things at any given moment: the running
activities, the people you are collaborating with, the items you are
carrying around with you between places, and the current status of the
laptop and any connected devices.  To your question, Marco, I think
that devices are actual a natural fit for the frame, since they remain
relevant from anywhere (any place, zoom level, or activity) in the UI.
 Moreover, the Frame's purpose as a status element is extended by the
notification system, which makes it the place to receive invitations
to new activities, information about people joining or leaving the
activity, or important system information such as a low battery.

>> My main concern is that it pops up. When you don't have good cursor
>> control that's a challenge.
>
> Something I would like to understand is that if the main cause here is
> the poor trackpad on the XO. A little usability testing might clear
> that up.

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
it also might be that some tweaks to the behavior (such as a short
delay) could serve to greatly minimize the symptom in practice.  In
either case, I also hope that the repurposed frame serves a much more
integral role in kids' interactions with Sugar in the future as well.

>> If we default off you can still activate it via key stroke. That would
>> be my preference.  That way you get "expansion" of space without the
>> mouse control issues.
>
> I tend to think that's the safest bet on the short time. But it will
> affect discoverability some. Either we come up with ideas on how to
> make the key more discoverable, or we try to evaluate how much of a
> problem discoverability will be in the field.
>
>> I hope this is not seen as a negative criticism of your work. The UI is
>> great overall. We can live with whatever frame solution is agreed and
>> there is a solid case to be made on all sides. Let's get the maximum
>> info to make an informed decision, then its your call :-)

Not at all.  In fact, I greatly appreciate any and all feedback, and I
especially appreciate the calm and collaborative manner in which you
propose considering possible solutions.  I hope that the upcoming
builds will give us a clearer vision of the tradeoffs to be made so we
can truly arrive at a system which best serves everyone.  Thanks!

- Eben