Re: OLPC's bizarre behaviors
You don't need a person to keep the community in the loop if the community fora (as opposed to the water cooler and the hallway) are *religiously* maintained as being the loop. -- John. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC's bizarre behaviors
On Thu, May 22, 2008 at 2:29 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On 5/22/08, John R. Hogerhuis [EMAIL PROTECTED] wrote: You don't need a person to keep the community in the loop if the community fora (as opposed to the water cooler and the hallway) are *religiously* maintained as being the loop. And who does that maintenance? --scott Everybody at 1cc. For the people outside 1cc this rule enforces itself. There is no backchannel. For the small set of people inside, they must police themselves. The rule would be, if it doesn't happen on the mailing list or IRC, then it doesn't happen. It works for software, anyway, as can be seen in pure open source projects. There's a little bit of backchannel direct emails but the policy is to quickly push the discussion to the mailing list. I can't say this would work for hardware given ECR/ECO process but with enough thought, probably possible. -- John. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XP on OLPC - a contrarian view
Sameer Verma sverma at sfsu.edu writes: Yeah, its probably #1. Boot up times become moot if children simply rely on suspend and resume with topping up the battery whenever possible. Its the actual performance of the environment that really matters. I would say both are important in a classroom setting, though UI responsiveness is more important. Even with Ubuntu on my Thinkpad laptop I do have the occasional lockup or need for reboot. If a kid is working on a collaborative activity and on top of the time it takes to notice and react to the freeze/lockup you need to spend another minute or so rebooting, that time comes directly out of productive learning time. And, in his frustration he may need help which could stop the whole train until the issue is dealt with. I think in classrooms full of 20-30 kids, that happening enough to notice is a significant probability. -- 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 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
Re: OLPC: Open Organized Transparent
Denver Gingerich denver at ossguy.com writes: I've never seen one of these holier than thou e-mails you mention. It certainly doesn't seem to be like any of the staff I've communicated with to do such a thing. Sorry, but this impression on users (and I share it too) is inevitable. The problem is not having an open mailing list. The problem is backchannels of communication. My opinion is, if it doesn't happen on the list, or in a logged IRC session, then it didn't happen. Oh we had a hallway meeting or we had a little conference and anyone that happens to be around can come is Not OK if you really want to be a community-driven, open project. Without naming names, though I was excited to help at first, that kind of insider-outsider issue made me lose interest as a direct contributor fairly early. I felt, if they are going to run this like they're a proprietary company where they excercise full control, why should I bother? In the end my opinion won't really matter, so why waste my breath? Of course all projects have a leader. But the arguments need to happen in public, stay in public, and the decision needs to be made and come down in public from a trusted individual as though there were no other backchannels. Even if a background conversation happened, I don't want to hear about it. -- John. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XP on OLPC - a contrarian view -- followup
Robert Myers rmyers7 at mindspring.com writes: I just saw the Microsoft video of an XO running XP. In it the XO single boots from an 'insyde' BIOS. The MS guy says that XP doesn't fit on the flash, and is installed on an SD card. In this case, I'd guess the flash is just being used as a home for the BIOS. I can see why techs at MS did this to get a working prototype rather than having to wait for (or worse yet, contribute to) the OF V2 bootloader/BIOS. Wasn't the Insyde BIOS what shipped temporarily on Rev A boards? Maybe that's just what they had? But yeah, they would have to put in some dev hours to port to OF. -- 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 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\Windows won't ship
Albert Cahalan acahalan at gmail.com writes: The next demand is obvious: eliminate Sugar. Well I think the more likely thing is that a Sugar (shell only) ends up as an icon on the Windows desktop. In fact until Sugar is a little more mature I don't think it would be the worst thing in the world if XO's shipped with a lightweight Linux desktop and Sugar as a launchable application. It would deal with speed and bleeding edge science project UI complaints. It wouldn't do anything to address unaccountable rambling FUD from NN about Flash or whatever. Then teachers and students alike would have a real choice and we could see what they choose to do when given the freedom to. -- John. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Usability testing
I can echo all of that, and posted recently about my 4 year old. All the same problems with paint: hard to guess what to click on to set the color, popover frame gets very frustrating, two handed drag is a persistent issue for her, speed of opening applications is too slow (in the initial release) and she gets tired of waiting, thinks it isn't working. Too many words as the only way to do things (words are fine, she's learning to read but it would be nice for some of the simpler apps to have icons reminiscent of the function for everything). -- John. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re:
Let me take a crack at it... The closest thing to a valid criticism here is that bitfrost does not protect political dissidents from government monitoring and control. Similarly, a valid criticism of my shampoo is that it doesn't protect me from falling satellites. Which is the bigger threat to 6-12 year olds? Retribution by the government for political activism or certain elements of the general society targeting them over the Internet for whatever reason? The XO security model has always seemed more concerned with the latter. I'm sure there are a few, but I haven't met many 9 year old revolutionaries. (But, if you're out there: probably you should reconsider unencrypted communication between government provided laptops to plot your subversive activities!) Is it even possible to design a system that both provides anonymity and permits close teacher oversight? Has anyone every tried in a public school system, typically a state-run affair staffed by employees of the government to seriously protect the students from government eyes and ears? Would any teacher or school system want to deploy laptops to their students that puts measures in place to lock them out of doing their job of taking care of their charges? This paper is half-baked. Generally their arguments almost get to a point but instead they leave you wondering how and why they bothered to get where they went. The authors need to go back to the drawing board and bring some more serious arguments to the table. -- John. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: UI usability for 4 year old (was Re: Call for Papers/Talks/Ideas!)
. K. Subramaniam subbukk at gmail.com writes: On Sunday 23 March 2008 3:59:31 am John R.Hogerhuis wrote: .. (actually it's not all that pleasant for me either given the button placement below the trackpad). Something modal or pressure based would be better. If a key on the keyboard held down were the up/down button that would be resolution of the dexterity issue. Though, some thought would need to be given to make this discoverable. It is tough for young children to use trackpad like a mouse - with a single hand. Using it bi-manually with two index fingers is not only easier but also prepares them for typing on the keyboard later. The child can use one index finger (say right) on the trackpad and the other index finger (say left) to click buttons. Older children can use index fingers for the trackpad and thumbs for the buttons. Subbu Based on my daughter, she does use two hands to paint. The problem is the need to constantly hold down the button (drag) while painting. With a mouse this is natural for her, but with the trackpad she has difficulty. Maybe the issue is bumping the hand, or coming close to bumping into the hand holding the button? This raises another possibility though: use the left or right hand trackpad segments for the brush up/down. If she just rests her left hand/finger on the left side of the trackpad to draw, lifting it to stop drawing, that would be much easier for painting since her left hand is in a more natural position and does not interfere with the right. Are the left and right panels pressure sensitive? If so, they could be used to dynamically adjust the brush size/weight depending on how hard she pushes. -- John. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Call for Papers/Talks/Ideas!
John Gilmore gnu at toad.com writes: The second thing is basic UI usability. The pop-around menu border makes the UI thoroughly unusable with the trackpad http://dev.laptop.org/ticket/4910 covers this issue and more. Yeah there's an awful lot in your ticket and I didn't notice it mention any of our particular problems. I don't think the frame is evil... my problem in this regard is simply popover frame + trackpad. You don't have the fine granularity with a trackpad that you do with a mouse and a younger child's fine motor skills are still developing in any event. Based on observing my daughter, it's not much of an issue with a USB mouse. But that's not the usual mode she works with the laptop. She pulls it off her shelf and sits on the couch with it on her lap. A mouse isn't an easy option. If anyone asks and thinks they won't be redundant I will enter a couple narrowly focused tickets. (popover frame + trackpad, and reading required.) I know the slow-activity-start bug (5228) is already being tracked, though I am surprised it wasn't considered high enough priority to be triaged for update.1. If I had to pick a single most important high profile problem with the XO, the slow-activity-start bug would be it. It's impossible not to stub your toe on this one within the first 15 minutes of use. As a programmer, the problem calls into question the basic software architecture of the XO, in particular the choice of heavy use of Python and abstraction layer-type packages like Telepathy which weren't purpose built for resource constrained machines like the XO. That was likely a conscious gamble. My gut feeling though is that, directly addressed, this is fixable. Just a matter of setting development priority. -- John. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
UI usability for 4 year old (was Re: Call for Papers/Talks/Ideas!)
Marco Pesenti Gritti mpgritti at gmail.com writes: I have not seen a good analysis of the frame problem yet. For example I know that at some point the trackpad jumped to the corners very often, and that obviously aggravated it. Also in my experience the thing is nowhere so annoying on my work laptop (still using a trackpad), why? Finally, when this happen, is the mouse left still in the corner or do kids just touch the corner momentarily... It's not a problem of the cursor moving randomly. What happens to Kailea is that she'll try to get to the activity menu or the color tool at the top left hand side. Just due to lack of good control of the trackpad she ends up getting the popover frame. Once it comes up, she tries to escape the mode by randomly moving her finger on the trackpad. This doesn't usually work which raises her frustration level. On paint, specifically, a couple of other observations, now that I think about it: between Kailea, 4 and my wife (an elementary school teacher) helping her, they had difficulty figuring out how to set the color in the paint program. Maybe if the color icons had a color rainbow or something it would be more obvious. Also holding the button down and dragging as a normal operation (as it is in Paint) is a tricky concept and physically difficult in terms of dexterity for my 4 year old (actually it's not all that pleasant for me either given the button placement below the trackpad). Something modal or pressure based would be better. If a key on the keyboard held down were the up/down button that would be resolution of the dexterity issue. Though, some thought would need to be given to make this discoverable. Tomeu managed to reduce startup up time to 2-3 seconds in the faster branch using an approach similar to maemo launcher: https://stage.maemo.org/svn/maemo/projects/haf/trunk/maemo-launcher/README If we don't find any blocking problems with this approach, I think we can make startup pretty much instantaneous. I'll try it out. That would be a big improvement. Instantaneous would be 150-200 milliseconds, but I'd guess anything under 5 seconds would not frustrate her. Python was chosen mainly because it's a good development tool for kids. I think the few performance problem it's causing are all solvable, it's just that no one had time to focus on it until now. How is that working out in the field? I certainly agree that kids developing/altering their own tools is a fantastic idea for the =9 year olds. Are kids scripting? What is the process they go through to learn the language? I remember as a kid how I learned BASIC. The computer came with 2 1-inch thick friendly (lots of cartoons, short example programs) programming manuals that I devoured in the first 2 weeks I had the machine. Also, they used to have type-in programs in the home computer mags I got for my TRS-80 Color Computer. I'd type them in but they wouldn't work. So, I would have to walk through line by line and fix them. Looking at the code while debugging exposed me to different programming concepts like modularization (GOSUB/RETURN), keeping code organized for understandability, etc. Further the mags themselves often had introductory articles on programming, walk-throughs, ... That challenge is to make Pippy permit natural, incremental, discoverable baby steps into programming. Probably it needs to be highly integrated with html tutorials and tips Pippy meets Clippy ;-) -- John. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
