Added this issue:
http://jira.immuexa.com/browse/SQ-312
and
http://jira.immuexa.com/browse/SQ-313
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 completely 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 "process") of describing how to save a project with errors and send it (ftp/ http/email) 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@vpri.org To: everyone@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@waveplace.com Date: June 22, 2009 9:05:41 PM EDT To: Timothy Falconer timothy@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 eToys.
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 applications, 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 default installations.
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 time
with it for a while I asked if there were any
problems. Sure enough everyone had one. When I went to look it was
just painful
One project was completely locked up, even after I spent five - ten
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 unstuck...
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 (unless 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 seems Sugar related clearly
All this took time that could of been spent learning etoys. I didn't
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 working
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 scripts.
First it is imperative for the programmers to actually work with eToys
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.
It 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 is
painful.
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. What 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
in.
I am not I understand but think this would prevent regular mouse use for other situations
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 because
of that removable navigation bar.
This is corrected in latest Etoys release.
Takes just one wrong click to remove it from the book. In theory you could
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 essentially
destroying the book.
Fortunately, this should no longer be a problem in the latest Etoys release. 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 candidate?
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, cramped
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 aboutthe
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.
Milan