[etoys-dev] Re: [sq-everyone] etoys suggestions from bill
timothy at squeakland.org
Mon Aug 31 12:21:37 EDT 2009
Added this issue:
On Jul 18, 2009, at 10:52 PM, Milan Zimmermann wrote:
> Without forwarding the "fault", I wonder if some of the problems is
> related to
> Sugar immaturity, and hardware problems such as "stuck alt key". I
> had a
> stuck Alt key on my XO and Etoys behavior in this situation was
> unpredictable, with lockups one of the prime results. For the
> longest time I
> did not believe it was the stuck alt key as it was unpredictable.
> But once
> fixed, things got much better. The other problem is definitely the
> touchpad -
> I stopped using XO without a mouse.
> What Sugar version these XOs use?
> But we need to go through the system identifying when fonts or "target
> clickable areas" should increase. Tim, do you have some concrete
> suggestions -
> we should turn this into BUG ...
> Also, maybe we (etoys developers) can setup a mechanism (or just a
> of describing how to save a project with errors and send it (ftp/
> to Squeakland.
> Commenting inline on some of the issues.
> ---------- Forwarded Message ----------
> Subject: Re: [sq-everyone] etoys suggestions from bill
> Date: June 23, 2009
> From: Yoshiki Ohshima <yoshiki at vpri.org>
> To: everyone at squeakland.org
> Thank you for the comments. Critical comment is always welcome.
> One thing that would have really helped was to know that there is a
> kind of emergency stop feature; pressing Alt-. stops all running
> scripts, and often breaks out "locked up" situations.
> Other things are fair points. The menu bar once didn't halo but it
> was put back (probably for a wrong reason) and things are (still) too
> small on XO.
> -- Yoshiki
> At Tue, 23 Jun 2009 08:13:53 -0400,
> Timothy Falconer wrote:
>> Begin forwarded message:
>> From: william at waveplace.com
>> Date: June 22, 2009 9:05:41 PM EDT
>> To: Timothy Falconer <timothy at squeakland.org>
>> Subject: Re: [sq-everyone] software team meet, 22-june-2009
>> Hey Tim -
>> Read this email after another tough lesson for the teachers with
> I'm not sure if the developers realize the
>> ramification of user issues in the field.
> Probably not fully, but we have some experiences. I gave the XO to
> my fellow
> developer, who seemed to be little deliberate in trying to break the
> experience , but in any case he managed to make not only Etoys, but
> also Sugar
> unusable within minutes almost every time. Starting multiple
> clicking randomly, make the system really crawl or stop. I guess
> part of it is
> due to hardware low power, part due to immaturity. I think already
> the later
> versions (e.g. Sugar on the stick), are more stable then the XO
>> Today was a lesson in frustration as I was just trying to teach
>> a simple
>> Test lesson. Everyone was quietly working. After they had some
> with it for a while I asked if there were any
>> problems. Sure enough everyone had one. When I went to look it
> just painful
>> One project was completely locked up, even after I spent five -
> minutes trying to fix it. Nothing but the
>> cursor would move.
> Was the author able to switch to another Sugar application?
>> Could not begin to see what was wrong or even save it as the
>> most of the
> scripts were partially
>> off the page and the viewer blocked the keep icon. So I forced
>> quit -
> loosing everything.
> Alt . (Alt and dot preseed) are sometimes the only way out. Although
> I need it
> much less with the later Sugar releases and after alt key was
>> Another teacher had a
>> slowly rotating book, which had bogged down the system,
>> requiring a slow
> and tedious process of trying to switch off
>> scripts as they were revealed and disappeared. (The rotating book
> blocked the etoys tool bar so no way to get into
>> the supply bin for stop all scripts commands.)
> Would it make sense to force the Navigation Bar to stay always up
> exaplicitly requested). What do others think about that?
>> Another project just had minor errors, fixed those and it still
>> didn't work. Some more trouble shooting finally revealed that
>> the sound
> system of the entire XO had ceased working.
> I have experienced this as well, but have no idea where to start. It
> Sugar related clearly
>> All this took time that could of been spent learning etoys. I
> even get to the next two computers with
>> problems. Everyone was frustrated and fried and it started to
>> pour and
> they had to head home as the roads get
>> pretty bad in the rain - and we all just agreed to meet again
>> early in
> the morning.
>> Anyways wrote this suggestion list immediately after. Cutting and
> pasting it here -
>> Am writing from the front line of the eToys battles, in this
>> case the
> small remote fishing village of Petite Riviere
>> Des Nippes in Haiti, where I have been training kids and
>> teachers for
> the past week.
>> Believe me when I say that I have witnessed the horrors of eToys
>> in the
> hands of untrained professionals.
>> Specifically those who have never touched a computer before and
> with a language other than English. More
>> times than I care to remember, I have watched the dream of
> constructionism die a cold hard death in a nightmare of
>> locked up XOs and scattered and lost tiles and sketches and
>> First it is imperative for the programmers to actually work with
> on the XO to get an idea of the problem.
> Most of us do qute a lot (although I admit, not full time myself). I
> am sorry
> for your frustration.
>> is is much more difficult to use it there than on a PC or Mac.
> Everything is smaller and requires much more skill
>> to find and manipulate, especially with the XO's less than perfect
> trackpad. Plus they should preferably test out
>> eToys on the XO by creating a book with at least a dozen pages and
> filled with numerous sketches and scripts. (And
>> then have a number of those scripts contain errors.) Keep in
>> mind that
> a PC or Mac is many many times more
>> powerful and can take up that slack - but that scenario on an XO
> I have books with 6-7 pages with flashing and turning objects and
> they run
> quite well on the XO. I wonder if during the traing, is possible,
> when you
> experience a problem to save the project and send it to etoys-dev?
> I will as I said create a "personal stress test projects and
> process" for
> Etoys on future Sugar releases. Hope that will uncover some problems
>> So first off there needs to be an emergency save and exit keyboard
> command - when everything goes to hell and eToys
>> locks up.
> As above - Alt and dot pressed at the same time is sometimes the
> only way out
> - please try it and let us know.
>> As the viewer is over the keep and exit icons when it's up,
>> that's not
> an option. Also - sometimes you
>> can close and save eToys from the sugar frame, but usually not.
> Hmmm this seems Sugar or speed related. But I have seen it as well.
> version of Sugar these XOs use?
>> Also the active area for clicking the Halo icons needs to be
>> larger. As
> it is it is too easy to miss the icon -
>> thus closing Halo and having to start over. The heading arrow is
> especially hard to click. Also when you click
>> with left button by mistake to open the halo - you are suddenly
>> in pick
> up mode and need to click the left button
>> again to get out of it so you can then click the right button.
>> Would be
> nice if the right button could just cut
> I am not I understand but think this would prevent regular mouse use
> for other
>> Also - manipulating the halo icons requires switching back to
>> the left
> button. Would be nice if either left
>> or right button worked worked for that.
>> As for the book. Difficult to impart the pain I've gone through
> of that removable navigation bar.
> This is corrected in latest Etoys release.
>> just one wrong click to remove it from the book. In theory you
> re-embed it again, but that too is fraught
>> with danger. One it's a pain to explain and do - specially for
>> a kid.
> Plus the last time I did it, it only let me
>> embed it to a page, not to the book. So as soon as you turned
>> the page,
> it was goodbye to the navigation bar - as
>> well as to ever being able to turn the page again - thus
> destroying the book.
> Fortunately, this should no longer be a problem in the latest Etoys
> The question is how to get it on your XOs...
>> On that same note, if you right click the eToys main navigation
>> bar, you
> get the halo along with the delete icon.
>> If you then accidently click the delete icon, the main
>> navigation bar is
> deleted. Why in God's holy name is this
>> even possible? What purpose does this serve, other than tears
>> for the
> child and to drive people like me insane
>> while trying to rescue the project?
> This is in spirit of "authoring always on". But I agree with you.
> There should
> be na *option* to never remove the Navigation Bar - another BUG
>> Anyways I have many, many more suggestions from the field to
>> make eToys
> better, but for now these are the ones to
>> address right away.
>> It is important to keep in mind the circumstances that etoys
>> will be
> used under. It's not always an air conditioned
>> classroom filled with new Macs. Instead it may be a hot humid,
> and falling apart area with no electricity
>> or lights, with kids and teachers fighting frustration as they
>> try and
> make it all work on a tiny, low powered XO.
>> To make the dream work for them, eToys has to become less about
> challenge of physically making it work and more
>> about the challenge of discovering what they can do with it.
> Thanks for you feedback, we need to hear it, good and bad.
More information about the etoys-dev