Re: [sugar] OLPC priorities for Sugar in the August release
On Wed, May 14, 2008 at 1:46 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: * More responsive UI - faster launch of activities Is the solution currently in joyride satisfactory for the August release? I use a recent Joyride on my G1G1. My average time to launch Browse (from the time I click in the F3 Activity Ring on the Browse icon, to the time when I can click on the entry field in Browse itself (so that I can start typing in an URL) is 25 seconds. Is that satisfactory ? Certainly not. Could you do an experiment for me? Can you kill the journal activity and then try launching? If my suspicion is correct, the journal+DS is competing for the cpu, so without the journal it should start much faster. Thanks, 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)
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
pyc files in activity startup time (was Re: [sugar] OLPC priorities for Sugar in the August release)
On Wed, May 14, 2008 at 4:37 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: One low-hanging fruit for faster activity start is having activity install compile .pyc files, with (tiny) extra points if the .pyc gets hints to not use jffs2 compression. Hi Chema, do you know how much this could improve startup of an activity like Chat? If you could find time to do some measurements, that would be great. Thanks, 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)
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)
On Sat, 17 May 2008, John R.Hogerhuis 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. 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)
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)
On Sat, May 17, 2008 at 1:26 AM, John R. Hogerhuis [EMAIL PROTECTED] 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 ___ 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)
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)
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)
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
Frame Decision (was [sugar] OLPC priorities for Sugar in the August release)
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=2t=154224p=546464hilit=fra me#p546464 http://en.forum.laptop.org/viewtopic.php?f=17t=154514p=547914hilit=fr ame#p547914 http://en.forum.laptop.org/viewtopic.php?f=2t=150573p=531274hilit=fra me#p525210 http://en.forum.laptop.org/viewtopic.php?f=3t=150343p=524796hilit=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
Re: Frame Decision (was [sugar] OLPC priorities for Sugar in the August release)
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=2t=154224p=546464hilit=fra me#p546464http://en.forum.laptop.org/viewtopic.php?f=2t=154224p=546464hilit=frame#p546464 http://en.forum.laptop.org/viewtopic.php?f=17t=154514p=547914hilit=fr ame#p547914http://en.forum.laptop.org/viewtopic.php?f=17t=154514p=547914hilit=frame#p547914 http://en.forum.laptop.org/viewtopic.php?f=2t=150573p=531274hilit=fra me#p525210http://en.forum.laptop.org/viewtopic.php?f=2t=150573p=531274hilit=frame#p525210 http://en.forum.laptop.org/viewtopic.php?f=3t=150343p=524796hilit=fra me#p524796http://en.forum.laptop.org/viewtopic.php?f=3t=150343p=524796hilit=frame#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/ http://dev.laptop.org/%7Eerikos/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. ___ 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)
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)
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)
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. 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: [sugar] OLPC priorities for Sugar in the August release
On Wed, May 14, 2008 at 8:41 PM, Simon Schampijer [EMAIL PROTECTED] wrote: 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. I'm not in agreement with allowing Frame activation from arbitrary corners. I think it's all or nothing, due to the use of each edge for independent items, and the position of notifications in each corner. If someone doesn't want it available in all corners, they should use the key instead. On the other hand, if you meant top of the screen to mean the top /edge/ (a la warm edges), I would move to make this again a global option (on all edges), with a separate delay adjustment. Warm edges would be off by default, while hot corners, I still think, could be on by default with a reasonable delay, at least until we get further testing feedback regarding the effectiveness of that solution. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
On Wed, May 14, 2008 at 11:48 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: * Datastore upgrade Which are the requirements for the DataStore in the August release? I think it was proposed to focus on backups for August and address stability concerns that way. At this date and with all the disagreements exposed by the thread about your rewrite, I think it's sadly the safest option. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
* More responsive UI - faster launch of activities Is the solution currently in joyride satisfactory for the August release? I use a recent Joyride on my G1G1. My average time to launch Browse (from the time I click in the F3 Activity Ring on the Browse icon, to the time when I can click on the entry field in Browse itself (so that I can start typing in an URL) is 25 seconds. Is that satisfactory ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
was that joyride or the faster build? -walter On Wed, May 14, 2008 at 7:46 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: * More responsive UI - faster launch of activities Is the solution currently in joyride satisfactory for the August release? I use a recent Joyride on my G1G1. My average time to launch Browse (from the time I click in the F3 Activity Ring on the Browse icon, to the time when I can click on the entry field in Browse itself (so that I can start typing in an URL) is 25 seconds. Is that satisfactory ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
One low-hanging fruit for faster activity start is having activity install compile .pyc files, with (tiny) extra points if the .pyc gets hints to not use jffs2 compression. This is on my gameplan with the bundle format update stuff, but I have gotten stuck on the signatures (openssl cannot read ssh public keys) so I am behind on that. I had hoped to finish it in my free time this week but starting next week I cannot be so sure I'll have time. On Wed, May 14, 2008 at 6:57 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Wed, May 14, 2008 at 1:46 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: * More responsive UI - faster launch of activities Is the solution currently in joyride satisfactory for the August release? I use a recent Joyride on my G1G1. My average time to launch Browse (from the time I click in the F3 Activity Ring on the Browse icon, to the time when I can click on the entry field in Browse itself (so that I can start typing in an URL) is 25 seconds. If you could download the latest joyride, time startup and open a ticket that would be useful. 25 seconds are too much obviously. Please take both time on the very first start and after a reboot, xulrunner does component registration on the very first start which could be expensive Thanks. Marco ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
Hi Tomeu, Walter, et al, FYI Uruguay already posted some presentations and training based on the existing UI. See: http://www.ceibalflorida.blogspot.com/ posts from April. I'm not up to speed on proposed Sugar changes so it may have minimal impact. 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. If you do take out the popup frame make sure to come up with a new copy and paste mechanism. Uruguay also has a multi-day training planned for June: http://www.inscripcioncursotics.8m.com/programa.htm They're probably OK with updating their docs but you should bring them in the loop ahead of time, if possible. BTW can you ask Peru to post their manual somewhere? Colombia just asked for Spanish documentation and I'm sure it will be useful for many other countries too. Thanks, Greg S * Message: 2 Date: Wed, 14 May 2008 08:29:39 -0400 From: Walter Bender [EMAIL PROTECTED] Subject: Re: [sugar] OLPC priorities for Sugar in the August release To: Tomeu Vizoso [EMAIL PROTECTED] Cc: OLPC Developer's List devel@lists.laptop.org, Sugar Mailing List [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 * New Sugar UI? Should continue with some specific goals on how to roll out the new features so it won't be difficult for people. Wad brought up the issue that Peru has already started printing a manual based on the old UI. I've been talking with the Peru folks about this too. The percentage of the user manual that is dependent on the old UI is only in a very few places. If the new UI really simplifies sharing, activity management, and notifications, then I think they'd be more than willing to accept the change. I'll talk to them again when I see them next week. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
One low-hanging fruit for faster activity start is having activity install compile .pyc files There are .pyc files here and there in the XO core software. I do not expect to myself be changing Activity code -- but if the OLPC is supposed to be easy enough for a kid to program - *someone* will. For myself, I don't have wireless at home; to make my communications setup work properly I need to patch some telepathy/presence .py files. [Having changed a .py file, I delete the same-name .pyc file, and reboot.] I'm not sure what created those corresponding .pyc files. I __wish__ there was an easy-to-find GUIDE explaining how and when the various .pyc files were installed. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
Has Firefox 3- B5 landed in Joyride? it is much faster starting up than the FF3B2 we had in the older systems (not to mention immensely better on memory usage). - Jim On Wed, 2008-05-14 at 14:57 +0200, Marco Pesenti Gritti wrote: On Wed, May 14, 2008 at 1:46 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: * More responsive UI - faster launch of activities Is the solution currently in joyride satisfactory for the August release? I use a recent Joyride on my G1G1. My average time to launch Browse (from the time I click in the F3 Activity Ring on the Browse icon, to the time when I can click on the entry field in Browse itself (so that I can start typing in an URL) is 25 seconds. If you could download the latest joyride, time startup and open a ticket that would be useful. 25 seconds are too much obviously. Please take both time on the very first start and after a reboot, xulrunner does component registration on the very first start which could be expensive Thanks. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
Pentagram and myself have been putting effort into solidifying designs for Sugar Groups. In a first rendition, it shouldn't require much more than an extension of the invitation framework to support group invites, and a simple UI for creating a group. I think even without advanced features such as bulletin boards, implicit group chats, and other details we've talked about surrounding the idea in the past, this will be a big way to improve the collaboration space even by making it extremely simple to say share with my group. I aim to have some screenshots which present this in a manner which might be feasible for August (if not, definitely Dec.) posted to the Designs page on the wiki by the weekend. - Eben On Wed, May 14, 2008 at 5:53 AM, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le mercredi 14 mai 2008 à 11:48 +0200, Tomeu Vizoso a écrit : * Groups, models for groups (Peru, Hernan) Is this groups in Sugar? Do we have some kind of requirements? There are some discussions about groups here: https://dev.laptop.org/ticket/4043 G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
Is the solution currently in joyride satisfactory for the August release? Personally I think it's OK. It won't hurt to try to do better if we have time obviously... Let me clarify. I think activities launch is OK. Stuff like frame responsiveness and activity switch should be improved. There are a handful of rainbow bugs that need to be fixed before we should actually ship the thing (specifically #6989), but I'm not aware of other major risks there. I still don't really have enough information about whether the incompatibilities in spool format that I mentioned before warrant bumping the spool-format version identifier from 1-2 (which would require a minor change to the DS). Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
On Wed, May 14, 2008 at 01:00:32PM -0700, John Gilmore wrote: I've often wanted the close-box to be in the Frame itself, so that there's a short and totally deterministic way to tell someone how to exit the current application. Providing an obvious close-button outside of the activity is a good idea for other reasons such as the ability to close misbehaving activities. (Some would argue that the activity-button's 'close' palette entry is adequate, but I think we can do better without much trouble.) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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
Re: [sugar] OLPC priorities for Sugar in the August release
On Wed, May 14, 2008 at 10:43 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: One low-hanging fruit for faster activity start is having activity install compile .pyc files There are .pyc files here and there in the XO core software. I do not expect to myself be changing Activity code -- but if the OLPC is supposed to be easy enough for a kid to program - *someone* will. For myself, I don't have wireless at home; to make my communications setup work properly I need to patch some telepathy/presence .py files. [Having changed a .py file, I delete the same-name .pyc file, and reboot.] I'm not sure what created those corresponding .pyc files. I __wish__ there was an easy-to-find GUIDE explaining how and when the various .pyc files were installed. Your wish is noted on the Wiki page for the Architecture Manual. mikus ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Chema Quinn wrote: | One low-hanging fruit for faster activity start is having activity install | compile .pyc files, with (tiny) extra points if the .pyc gets hints to not | use jffs2 compression. This is on my gameplan with the bundle format update | stuff, but I have gotten stuck on the signatures (openssl cannot read ssh | public keys) so I am behind on that. I had hoped to finish it in my free | time this week but starting next week I cannot be so sure I'll have time. Pretty small fruit. Based on my measurements (http://lists.laptop.org/pipermail/sugar/2008-March/004669.html), we are talking about less than 200 ms for typical Activities. The only Activities I know of with enough code for this to matter are the TamTam activities. Even the Journal spends much less than one second compiling. ~ Additionally, my measurements include the time to write the pyc file back into jffs2, so the real launch delay could be even less. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIK5JwUJT6e6HFtqQRAhbqAJ9jrt0gENi+ar1CCq0QU2O891SH7wCdFlsD JW1/uQlAarBii8WB7V4WVkA= =z9mP -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
