Quitting Etoys on an XO takes 1min30 sec with our old Epaati setup, because etoys does some saving on shutdown. To me this is not a feature, but actually diminishes functionality, because there's no way to quit without saving. I know there's a magic incantation involving holding shift or something, but I'm talking from a user/kid perspective.
The attached patch changes this behaviour to just quitting the image using the squeak quit primitive. Is there something to say for this approach?
/Ties
On 09.04.2008, at 05:04, Ties Stuij wrote:
Quitting Etoys on an XO takes 1min30 sec with our old Epaati setup, because etoys does some saving on shutdown. To me this is not a feature, but actually diminishes functionality, because there's no way to quit without saving. I know there's a magic incantation involving holding shift or something, but I'm talking from a user/kid perspective.
The attached patch changes this behaviour to just quitting the image using the squeak quit primitive. Is there something to say for this approach?
For? No.
It goes against the Sugar platform conventions. Stopping an activity needs to put its current state into the Journal so it can later be resumed. That is the fundamental assumption of how kids interact with the laptops - if you feel it is inappropriate, please discuss this on the Sugar list. Really, please do.
This is not to say I am satisfied with the current state of affairs. I find myself using the quit-without-saving feature a lot (hold down a bit on the stop button for this). It is much faster, and it does not clutter the Journal with "useless" projects. But I am not a typical user, just like you.
The typical use for Etoys would be to create projects. And when I use Etoys to create a project, the autosave is fine. It is not so nice when just "playing" a project, the save when quitting is unnecessary in that case, or even bad because the project might not be in the state the author intended.
One way out would be to ask an quit wether saving was desired or not. That is how Etoys handles this on other platforms. But the Sugar design strongly discourage this. Also, when quitting Etoys from the home view, the dialog would not even be visible.
Or we could detect if anything in the project changed that is worth saving - but due to the modeless nature of Etoys where "authoring is always on" this is impossible. Playing with an etoy means modifying it.
A nice compromise (besides obviously speeding up the saving) may be to hide the saving - just close the window so it looks like Etoys was stopped, but continue to save in the background. We could even display the progress of this in the Journal, just like Browse does while downloading.
Btw, so far we have not had feedback from the pilots or deployments that automatic saving is not what is desired. But then, we've had almost no feedback, so this does not necessarily mean anything.
- Bert -
On Wed, Apr 9, 2008 at 8:11 PM, Bert Freudenberg bert@freudenbergs.de wrote:
It goes against the Sugar platform conventions. Stopping an activity needs to put its current state into the Journal so it can later be resumed. That is the fundamental assumption of how kids interact with the laptops - if you feel it is inappropriate, please discuss this on the Sugar list. Really, please do.
In a few weeks time we should be getting some feedback from kids, so I will be able to form an opinion based on some actual data. I'll discuss it then if there's something to discuss.
A nice compromise (besides obviously speeding up the saving) may be to hide the saving - just close the window so it looks like Etoys was stopped, but continue to save in the background. We could even display the progress of this in the Journal, just like Browse does while downloading.
Yes, that seems like an excellent idea.
/Ties
A nice compromise (besides obviously speeding up the saving) may be to hide the saving - just close the window so it looks like Etoys was stopped, but continue to save in the background. We could even display the progress of this in the Journal, just like Browse does while downloading.
Yes, that seems like an excellent idea.
Yes, this is definitely a direction worth exploring further. When designing the "in progress" visual for Journal entries, it was definitely my intent to support save operations in addition to downloads and copies (https://dev.laptop.org/ticket/2555#comment:1). I have also reported a bug on the time taken to stop activities in general, arguing myself that it's the perceived speed that really matters in this case, and stopping an activity should feel instantaneous (https://dev.laptop.org/ticket/2523). Feel free to add comments to either of these tickets; I'd really like to make this approach common practice.
- Eben
On Thu, Apr 10, 2008 at 5:17 PM, Eben Eliason eben@laptop.org wrote:
A nice compromise (besides obviously speeding up the saving) may be to hide the saving - just close the window so it looks like Etoys was stopped, but continue to save in the background. We could even display the progress of this in the Journal, just like Browse does while downloading.
Yes, that seems like an excellent idea.
Yes, this is definitely a direction worth exploring further. When designing the "in progress" visual for Journal entries, it was definitely my intent to support save operations in addition to downloads and copies (https://dev.laptop.org/ticket/2555#comment:1). I have also reported a bug on the time taken to stop activities in general, arguing myself that it's the perceived speed that really matters in this case, and stopping an activity should feel instantaneous (https://dev.laptop.org/ticket/2523). Feel free to add comments to either of these tickets; I'd really like to make this approach common practice.
Yes, do you need any help to make that happen in etoys?
Tomeu
On Thu, Apr 10, 2008 at 12:14 PM, Tomeu Vizoso tomeu@tomeuvizoso.net wrote:
On Thu, Apr 10, 2008 at 5:17 PM, Eben Eliason eben@laptop.org wrote:
A nice compromise (besides obviously speeding up the saving) may be to hide the saving - just close the window so it looks like Etoys was stopped, but continue to save in the background. We could even display the progress of this in the Journal, just like Browse does while downloading.
Yes, that seems like an excellent idea.
Yes, this is definitely a direction worth exploring further. When designing the "in progress" visual for Journal entries, it was definitely my intent to support save operations in addition to downloads and copies (https://dev.laptop.org/ticket/2555#comment:1). I have also reported a bug on the time taken to stop activities in general, arguing myself that it's the perceived speed that really matters in this case, and stopping an activity should feel instantaneous (https://dev.laptop.org/ticket/2523). Feel free to add comments to either of these tickets; I'd really like to make this approach common practice.
Yes, do you need any help to make that happen in etoys?
So, clearly Etoys (and other activities, as needed) will have to handle the smart save on their own. However, is it possible for Sugar itself to enforce the perceived immediate close on it's own, detecting "stop" events and immediately hiding the window (not without first allowing the activity to disallow this via some handler, of course)?
- Eben
On Thu, Apr 10, 2008 at 6:35 PM, Eben Eliason eben@laptop.org wrote:
On Thu, Apr 10, 2008 at 12:14 PM, Tomeu Vizoso tomeu@tomeuvizoso.net wrote:
On Thu, Apr 10, 2008 at 5:17 PM, Eben Eliason eben@laptop.org wrote:
A nice compromise (besides obviously speeding up the saving) may be to hide the saving - just close the window so it looks like Etoys was stopped, but continue to save in the background. We could even display the progress of this in the Journal, just like Browse does while downloading.
Yes, that seems like an excellent idea.
Yes, this is definitely a direction worth exploring further. When designing the "in progress" visual for Journal entries, it was definitely my intent to support save operations in addition to downloads and copies (https://dev.laptop.org/ticket/2555#comment:1). I have also reported a bug on the time taken to stop activities in general, arguing myself that it's the perceived speed that really matters in this case, and stopping an activity should feel instantaneous (https://dev.laptop.org/ticket/2523). Feel free to add comments to either of these tickets; I'd really like to make this approach common practice.
Yes, do you need any help to make that happen in etoys?
So, clearly Etoys (and other activities, as needed) will have to handle the smart save on their own. However, is it possible for Sugar itself to enforce the perceived immediate close on it's own, detecting "stop" events and immediately hiding the window (not without first allowing the activity to disallow this via some handler, of course)?
I think all this is possible, but complex enough to be delayed a couple of releases, in my opinion.
Regards,
Tomeu
At Thu, 10 Apr 2008 10:46:45 +0545, Ties Stuij wrote:
On Wed, Apr 9, 2008 at 8:11 PM, Bert Freudenberg bert@freudenbergs.de wrote:
It goes against the Sugar platform conventions. Stopping an activity needs to put its current state into the Journal so it can later be resumed. That is the fundamental assumption of how kids interact with the laptops - if you feel it is inappropriate, please discuss this on the Sugar list. Really, please do.
In a few weeks time we should be getting some feedback from kids, so I will be able to form an opinion based on some actual data. I'll discuss it then if there's something to discuss.
How much "user state" do you want to keep in/for EPaati across the sessions? I saw some versions and it is many interactive contents/games loaded into on demand. If in fact, there is not much differences in user perception between saving the entire project precisely and just quit (or devise a new data format for it and it only contains the last visited project name, etc), it'd be ok to go with user proposal in Epaati (not in Etoys, though).
-- Yoshiki
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eben Eliason -
Ties Stuij -
Tomeu Vizoso -
Yoshiki Ohshima