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

[Karl Ramberg]

John R. Hogerhuis wrote:
> On Sat, May 17, 2008 at 9:26 PM, Gary C Martin <[EMAIL PROTECTED]> wrote:
>   
>>  - Do the 'frame reveal corner arrows' only appear when you hit the corners,
>> or when your mouse is over the corner area (discoverability)?
>>
>> 
>
> What is the difference between hit the corner/over the corner area?
> What I was thinking was to pop the frame icons when you enter the
> corner area that is now used to activate the frame. But the frame
> wouldn't activate until a click.
>
> I think we would need to be able to distinguish between entering the
> corner on the drag of an object and drag of not-an-object (like a
> paintbrush).
>
> In fact, just doing that right would resolve the worst Frame
> interaction with Paint since the Frame would not activate if you enter
> the corner with mouse down but you are not dragging anything.
+1

Karl
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[John R. Hogerhuis]

On Sat, May 17, 2008 at 9:26 PM, Gary C Martin <[EMAIL PROTECTED]> wrote:
>  - Do the 'frame reveal corner arrows' only appear when you hit the corners,
> or when your mouse is over the corner area (discoverability)?
>

What is the difference between hit the corner/over the corner area?
What I was thinking was to pop the frame icons when you enter the
corner area that is now used to activate the frame. But the frame
wouldn't activate until a click.

I think we would need to be able to distinguish between entering the
corner on the drag of an object and drag of not-an-object (like a
paintbrush).

In fact, just doing that right would resolve the worst Frame
interaction with Paint since the Frame would not activate if you enter
the corner with mouse down but you are not dragging anything.

-- John.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: 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 <[EMAIL PROTECTED]> wrote:
> On Sat, May 17, 2008 at 1:26 AM, John R. Hogerhuis <[EMAIL PROTECTED]> 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.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Gary C Martin]

On 18 May 2008, at 04:45, Eben Eliason wrote:

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

Yes, this has promise I think (and there's even a set of corner frame  
arrows kicking around from old joyride build). A couple of random  
thoughts:

  - Do the 'frame reveal corner arrows' only appear when you hit the  
corners, or when your mouse is over the corner area (discoverability)?

  - If you're dragging something to an object in the frame (could be  
to clipboard, or content to a user icon for sharing a document etc)  
does the frame revert to auto reveal (you're dragging so can't click)?  
If it auto reveals when dragging it could still appear unintentionally  
(but I guess a low probability once the twitchy track pad gets fixed).

  - A simple check of 'is mouse down and in corner' would probably be  
too simplistic as a paint/draw type activity would likely often  
trigger the frame unintentionally. Would need to be a click or a mouse  
known to be dragging an object.

> Agreed that an attempt at a fix has taken too long.  You're also  
> rightthat 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.

Yes, I use them in OSX all the time also, however I soon added a key  
constraint so I have to hold the Command key + hit a specific corner.  
Without that I was always accidently triggering Expose or the  
Dashboard and momentarily wondering where everything went. Having to  
hold a key down also seems to provide some mental/tactile action  
reinforcement - panning an image while holding space seems such a  
natural action (Photoshop, Preview with an image) when you compare it  
to having to select a specific 'hand' tool first (Preview with a PDF,  
Grapher).

Looking forward to the day that the grab keys start to work for  
panning ;-)

It's a pity the current frame key is in such a distant place, having a  
key on the bottom row that you hold to reveal the frame (and/or press  
once to toggle) would have likely solved a number of issues.

--Gary


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: 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 <[EMAIL PROTECTED]> wrote:
> Eben Eliason  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
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Tomeu Vizoso]

On Sat, May 17, 2008 at 8:22 AM, Neil Graham <[EMAIL PROTECTED]> wrote:
> On Saturday 17 May 2008 5:26:06 pm John R.Hogerhuis wrote:
>> 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.
>
> A concern for me is the redraw required as the frame retracts.  On
> particularly heavy load windows the redraw can take some time. If the repaint
> on frame retract  could be avoided(by overlay or even a clever save-under
> scheme) then that would be a benefit.

We can have composition on the XO, see the experimental 'faster'
builds, they have a version of Matchbox with its simple composition
manager activated. That avoids window redraws and the UI seems much
more faster as a result. There are some issues to fix before we can
consider using it, though.

Regards,

Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[david]

On Sat, 17 May 2008, John R.Hogerhuis wrote:

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

it's definantly not just the trackpad, people using external mice have 
also had problems with this

David Lang

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Neil Graham]

On Saturday 17 May 2008 5:26:06 pm John R.Hogerhuis wrote:
> 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.

I had been pondering if that could be done as a solution also but to do 
something like that would require somethink like a compositing WM. I have a 
vague feeling it could be done with some low level geode hacking, but a 
simple overlay is tricky because it's the size of the screen with a hole in 
the middle.  I wouldn't actually be opposed to the frame being some sort of 
special class citizen with specific driver support myself since it's a single 
unique and integral component (much like the mouse pointer being a hardware 
sprite).  Of course The person who would have to implement this would 
probably be spitting tacks at the thought of it :-)

A concern for me is the redraw required as the frame retracts.  On 
particularly heavy load windows the redraw can take some time. If the repaint 
on frame retract  could be avoided(by overlay or even a clever save-under 
scheme) then that would be a benefit.

It would also allow a solution by where the time it takes for the frame to 
retract is decided as proportional to how long the pointer has been in a 
trigger-zone. so if you just bang the mouse into the corner and away again 
(something my daughter does all the time) The frame starts to appear but 
disappears just as quickly.
  
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[John R . Hogerhuis]

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

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.

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.

Also, you need an objective third party here that can weigh the cost/benefit
impact to users... the implementors of the Frame concept shouldn't be the ones
deciding whether it stays in. As a programmer, I can say there's no way a
programmer can be totally objective about a pet feature. In a proprietary
company QA and/or marketing gets to make calls like this, not engineering. For
an open source project, maybe that voice of reason is the project Leader or just
other informed voices on the mailing list.

-- John.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: 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
<[EMAIL PROTECTED]> wrote:
> On Fri, May 16, 2008 at 8:14 PM, Greg Smith (gregmsmi)
> <[EMAIL PROTECTED]> 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
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Marco Pesenti Gritti]

On Fri, May 16, 2008 at 8:14 PM, Greg Smith (gregmsmi)
<[EMAIL PROTECTED]> 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?

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)

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

> 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 :-)

It's a problem that we tried to solve many times and everyone is
frustrated about it. Any attempt to move forward on it is welcome :)

Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Carol Lerche]

Considering that a whole key on the key board is dedicated to the frame, why
not use one of its meta modes (shift, alt) to be the toggle for default
off/on of the corner sensitivity?

On Fri, May 16, 2008 at 11:14 AM, Greg Smith (gregmsmi) <[EMAIL PROTECTED]>
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 only key feature I have heard so far is copy and paste. Task
> switching is more commonly done with the function keys. What else is
> central to the frame concept?
>
> My main concern is that it pops up. When you don't have good cursor
> control that's a challenge. All activities have UI elements at the edge
> so you spend time trying to get the cursor on the "keep" button without
> popping the frame. Lastly, its a sudden, in your face thing that happens
> without you really knowing why. Setting a longer hover time or only
> opening on some edges helps but it makes the problem of discoverability
> worse (aka user wonders "why did the computer do that?")
>
> 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.
>
> Initial research shows that there are FAQ entries for how to disable
> this. I also found these relevant threads in the forums saying they want
> it default off:
>
> http://en.forum.laptop.org/viewtopic.php?f=2&t=154224&p=546464&hilit=fra
> me#p546464
>
> http://en.forum.laptop.org/viewtopic.php?f=17&t=154514&p=547914&hilit=fr
> ame#p547914
>
> http://en.forum.laptop.org/viewtopic.php?f=2&t=150573&p=531274&hilit=fra
> me#p525210
>
> http://en.forum.laptop.org/viewtopic.php?f=3&t=150343&p=524796&hilit=fra
> me#p524796
>
> http://olpcnews.com/forum/index.php?topic=935.0
>
> http://olpcnews.com/forum/index.php?topic=904.0
>
> Several degenerate in to complaints about having to use the CLI :-). So
> enable/disable should be configurable via GUI but we should design with
> an assumption about the default install.
>
> We need more input from users (e.g. a small usability study would be
> great!). I think Nepal is on record to make it default off. Any other
> comments?
>
> BTW we brought up a new e-mail list for Spanish speakers in multiple
> countries: http://lists.laptop.org/listinfo/olpc-sur A dozen teachers
> have already commented saying they want to share experiences.
>
> Can someone who writes Spanish well can post a question there to get
> feedback from teachers re: frame experiences? I'll use a translation
> tool to do it myself if no one gets to it by the end of next week.
>
> 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 :-)
>
> Thanks,
>
> Greg S
>
> -Original Message-
> From: Simon Schampijer [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 14, 2008 8:42 PM
> To: Marco Pesenti Gritti
> Cc: Greg Smith (gregmsmi); devel@lists.laptop.org
> Subject: Re: [sugar] OLPC priorities for Sugar in the August release
>
> Marco Pesenti Gritti wrote:
> > On Wed, May 14, 2008 at 6:26 PM, Greg Smith (gregmsmi)
> > <[EMAIL PROTECTED]> wrote:
> >>  Thinking about the "hot corners" pop-up frame thingy, Nepal asked
> >> that  be deprecated and I agree based on my personal experience and
> >> that of my  kids. The only thing I have heard people use it for is
> >> the copy and  paste functionality. Waveplace lead mentioned that and
> >> its used in the  Uruguay training presentation linked above.
> >
> > Simon is working on making this an option. We would still need to
> > decide about the default obviously...
> >
> > Marco
>
> These sugar rpms include a control panel option to set a delay for the
> frame activation and an option to toggle the top of the screen to
> activate the frame.
>
> http://dev.laptop.org/~erikos/cp/ 
>
> You need to install sugar and sugar-toolkit (rpm -U [package] should
> work fine). I tested on joyride 1918.
>
> The control panel can be accessed with the palette on the XO in the home
> screen.
>
> Best,
>Simon
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



-- 
"Always do right," said Mark Twain. "This will gratify some people and
astonish the rest."

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

[Greg Smith (gregmsmi)]

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 only key feature I have heard so far is copy and paste. Task
switching is more commonly done with the function keys. What else is
central to the frame concept?

My main concern is that it pops up. When you don't have good cursor
control that's a challenge. All activities have UI elements at the edge
so you spend time trying to get the cursor on the "keep" button without
popping the frame. Lastly, its a sudden, in your face thing that happens
without you really knowing why. Setting a longer hover time or only
opening on some edges helps but it makes the problem of discoverability
worse (aka user wonders "why did the computer do that?")

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.

Initial research shows that there are FAQ entries for how to disable
this. I also found these relevant threads in the forums saying they want
it default off:

http://en.forum.laptop.org/viewtopic.php?f=2&t=154224&p=546464&hilit=fra
me#p546464

http://en.forum.laptop.org/viewtopic.php?f=17&t=154514&p=547914&hilit=fr
ame#p547914

http://en.forum.laptop.org/viewtopic.php?f=2&t=150573&p=531274&hilit=fra
me#p525210

http://en.forum.laptop.org/viewtopic.php?f=3&t=150343&p=524796&hilit=fra
me#p524796

http://olpcnews.com/forum/index.php?topic=935.0

http://olpcnews.com/forum/index.php?topic=904.0

Several degenerate in to complaints about having to use the CLI :-). So
enable/disable should be configurable via GUI but we should design with
an assumption about the default install.

We need more input from users (e.g. a small usability study would be
great!). I think Nepal is on record to make it default off. Any other
comments? 

BTW we brought up a new e-mail list for Spanish speakers in multiple
countries: http://lists.laptop.org/listinfo/olpc-sur A dozen teachers
have already commented saying they want to share experiences.

Can someone who writes Spanish well can post a question there to get
feedback from teachers re: frame experiences? I'll use a translation
tool to do it myself if no one gets to it by the end of next week.

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 :-)

Thanks,

Greg S 

-Original Message-
From: Simon Schampijer [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 14, 2008 8:42 PM
To: Marco Pesenti Gritti
Cc: Greg Smith (gregmsmi); devel@lists.laptop.org
Subject: Re: [sugar] OLPC priorities for Sugar in the August release

Marco Pesenti Gritti wrote:
> On Wed, May 14, 2008 at 6:26 PM, Greg Smith (gregmsmi) 
> <[EMAIL PROTECTED]> wrote:
>>  Thinking about the "hot corners" pop-up frame thingy, Nepal asked 
>> that  be deprecated and I agree based on my personal experience and 
>> that of my  kids. The only thing I have heard people use it for is 
>> the copy and  paste functionality. Waveplace lead mentioned that and 
>> its used in the  Uruguay training presentation linked above.
> 
> Simon is working on making this an option. We would still need to 
> decide about the default obviously...
> 
> Marco

These sugar rpms include a control panel option to set a delay for the
frame activation and an option to toggle the top of the screen to
activate the frame.

http://dev.laptop.org/~erikos/cp/

You need to install sugar and sugar-toolkit (rpm -U [package] should
work fine). I tested on joyride 1918.

The control panel can be accessed with the palette on the XO in the home
screen.

Best,
Simon
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel