Re: [Sugar-devel] Design mockup of a different activity launcher
On Sat, Oct 17, 2009 at 11:18 PM, Paul Fox p...@laptop.org wrote: i agree with others that the new proposal isn't nearly as nice, or as much fun, as the current pulsing icon (though i think other aspects, like the close button, are good). i think that avi is spot on when he says: Ok, seems like there are opinions in both directions - big surprise :) I for one was a bit offended when the pulsing icon appeared. Activities were taking 30 seconds to launch on XO and it seemed wrong to blow a bunch of CPU time on animation when the poor machine was obviously overtaxed! But, I guess the lesson is Bling given, cannot be taken away, which makes sense. The close button is already posted as a separate patch: http://dev.sugarlabs.org/ticket/1447 (That's why I was in the code) I'm going to shelve the dots for now, but if someone from design wants to take it over and produce an official spec I'd be happy to implement that. Best, Wade PS- Eben, I didn't realize it, but I think I was actually arguing against the progress bar! Never really liked those things; always halting at weird places, and never accurate. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
Le dimanche 18 octobre 2009 à 17:23 +1300, Tim McNamara a écrit : My experience with the GCompris applications in SoaS is that all of the controls are horribly rendered. It comes across as unprofessional, especially when introducing Sugar to teachers parents. Hi, For information, this problem in GCompris is in most part due to the fact that we use gnomecanvas and that it does not perform anti aliasing while rescaling images. The GCompris branch 8.5 which is in beta right now uses the goocanvas which provides a much better looking images when rescaled up. An option I am thinking of is porting GCompris to 1024x768 resolution instead of our native 800x600 which is almost no more used. By the way with the goocanvas based version we can now downscale GCompris to run it in smaller resolution, you can even resize the windows dynamically but yes, Sugar doesn't need of that. Concerning SVG, in moving to goocanvas I also use SVG much more. For example our skin is now in a single SVG file that I manipulate at run time by using SVG elements IDs. If someone is willing to make a test of our 8.5 branch (named gcomprixogoo in gnome's git) on Sugar, this would definitely help. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
I think if you want to represent the passage of seconds, it's better to use the conventional way that 60 seconds equals one complete turn, to assist in the interpretation of the clock, and not show a contradictory representation Gonzalo Odiard On Sun, Oct 18, 2009 at 10:05 AM, Wade Brainerd wad...@gmail.com wrote: On Sat, Oct 17, 2009 at 11:18 PM, Paul Fox p...@laptop.org wrote: i agree with others that the new proposal isn't nearly as nice, or as much fun, as the current pulsing icon (though i think other aspects, like the close button, are good). i think that avi is spot on when he says: Ok, seems like there are opinions in both directions - big surprise :) I for one was a bit offended when the pulsing icon appeared. Activities were taking 30 seconds to launch on XO and it seemed wrong to blow a bunch of CPU time on animation when the poor machine was obviously overtaxed! But, I guess the lesson is Bling given, cannot be taken away, which makes sense. The close button is already posted as a separate patch: http://dev.sugarlabs.org/ticket/1447 (That's why I was in the code) I'm going to shelve the dots for now, but if someone from design wants to take it over and produce an official spec I'd be happy to implement that. Best, Wade PS- Eben, I didn't realize it, but I think I was actually arguing against the progress bar! Never really liked those things; always halting at weird places, and never accurate. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard Responsable de Desarrollo Sistemas Australes ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
Tim wrote: This may be an area where the interests of Sugar Sugar on a Stick may diverge. Sugar on the XO-1 has a determined size. Bitmaps will be fine. Sugar on a Stick requires vector-based images, because we don't know what screen size we'll encounter. My experience with the GCompris applications in SoaS is that all of the controls are horribly rendered. It comes across as unprofessional, especially when introducing Sugar to teachers parents. I've already considered this issue, and really don't think that the situation is as you say. In the case of an installed environment, screen size can be known at install time and is, generally speaking with a few exceptions, fixed for the lifetime of most installations even on machines other than XOs. Even if it isn't known before the very first run, it is certainly known at most subsequent runs, even allowing for screen resolution changes (transient external monitors, portable boot drives, etc). Consider a scenario where the first launch generates a more efficient format from the SVG, and then it never gets re-generated until the resolution changes. I think that would be far better than the current method, and I seem to remember that the code is already there to cache like this. I think the cached images just don't get saved and recalled for some reason. I like Wade's idea of re-working the launch status indicator, but only if the reason is to provide more valuable information to the user or to make the current one as efficient as I think it can become. The rationale that a new method is better because it would save CPU cycles only makes sense if it can be shown that it isn't possible to accomplish the same cycle reduction by making the current process smarter. With that said, I'd of course much rather see a launcher infographic similar to what I proposed earlier than see any effort put into making the current one (or one similar to the current one) more efficient without providing any better indication of launch status and probability. - Avi ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
Tim McNamara wrote: I am thinking of when a child uses the home computer, Dad's computer at work, the grand parents's second hand machine, a friend's computer and then maybe one of several computers that are running at school. Resolutions and hardware are consistently changing. I don't know if reliance on the first bootup meets the goals envisaged of SoaS (as I understand them!), to provide portable computing everywhere. Ah, I didn't mean the first boot to be the perfect solution, just something that I see as a common use case scenario for both SoaS and XOs. To be sure, it does nothing to solve the problem that it doesn't give any meaningful information to the user. The nice thing (at least from just a performance optimization perspective) about the proposed mechanism that checks the resolution and only generates new images when it needs to is that in all the cases where resolution actually is fixed, it is equivalent to only ever doing it once, whereas in even the most extreme switching case it is no worse than the current slow method. I think it could safely work for both standard Sugar and SoaS instances. It's clearly not the best solution, as the best solution would work equally well for all scenarios and would be more informative, but I think it would be very simple to put into practice, since it should require very little change to existing code. - Avi ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
On Sat, Oct 17, 2009 at 4:59 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: I like it, especially if it takes less CPU. I would tweak the presentation a bit, and I'm curious as to what happens when the circle completes, but I would nonetheless be happy with this behavior committed. I agree. It is a nice approach to the problem. What is the behavior for activities that have a long launch time (I am thinking for example of the first time you launch Turtle Art, when it has to generate a lot of artwork for the data directory)? Also, there has been some discussion about making a journal entry for failed launches. Is that part of this patch? thanks. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd wad...@gmail.com wrote: http://www.youtube.com/watch?v=OvDdN1t-0yE I was in the code and have wanted to try this for awhile! If anyone else thinks it would be better than the pulsing icon, I'll clean up and post the patch to a Feature on the wiki. Rationale: 1) Less flashy Perhaps, although the screen actually feels busier to me. Perhaps with some visual tweaks it would work (smaller ring, maybe?), since showing how long it will take to launch is useful feedback. I lament the loss of the pulsing icon, though. This approach doesn't retain the transition from outline to fill that's important to the activity paradigm. Could we retain that, or is that the flashy part you aim to eliminate? 2) Clock theme represents time I don't understand how we know how long the launch is going to take. Is that something that we can estimate to a reasonable degree? Or do you plan to estimate the average launch time across many launches? 3) Ability to count how many seconds the launch takes I'm not sure I see usefulness in knowing how long it takes overall; knowing how much longer it will take is definitely something a kid will want to know, though, so it's good to show that. 4) Close button (instead of timeout) when there is an error This is definitely a big improvement. I like this a lot, and think we should also add options for looking at the crash reports and/or submitting a bug containing them to the maintainer of the activity, eventually. 5) Possibly less startup overhead; needs to be tested on XO True. If CPU is a concern, I'd vote to simply blink the icon between stroke and fill states, instead of pulsing, in order to reduce the animation overhead while retaining the visual metaphor. Eben -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
On Sat, Oct 17, 2009 at 5:43 PM, Walter Bender walter.ben...@gmail.com wrote: What is the behavior for activities that have a long launch time (I am thinking for example of the first time you launch Turtle Art, when it has to generate a lot of artwork for the data directory)? Heh, the mockup stops adding dots after 12 seconds :) It seems like there is enough interest to clean it up though; I'll come up with something and post a longer video including edge cases. Also, there has been some discussion about making a journal entry for failed launches. Is that part of this patch? I'll include it. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
2009/10/18 Wade Brainerd wad...@gmail.com http://www.youtube.com/watch?v=OvDdN1t-0yE I was in the code and have wanted to try this for awhile! If anyone else thinks it would be better than the pulsing icon, I'll clean up and post the patch to a Feature on the wiki. -1 to removing the pulsating icon. I really like it. I think it's something really unique and special about the Sugar approach. To be honest, I found it one of the most attractive, colourful and playful features I first encountered. Most of the rest of the UI is grey, it's great to have something dynamic and interesting. +1 to the close button. Being unable to cancel is a real pain in the XO-1. Some of the apps seem to hang when loading, and there's no way to know what's going on. Also, it's quite easy to load up a second application, because the menus are not always as responsive as they could be. timClicks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
Hi Eben, thanks for the feedback! On Sat, Oct 17, 2009 at 7:27 PM, Eben Eliason e...@laptop.org wrote: On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd wad...@gmail.com wrote: http://www.youtube.com/watch?v=OvDdN1t-0yE I was in the code and have wanted to try this for awhile! If anyone else thinks it would be better than the pulsing icon, I'll clean up and post the patch to a Feature on the wiki. Rationale: 1) Less flashy Perhaps, although the screen actually feels busier to me. Perhaps with some visual tweaks it would work (smaller ring, maybe?), since showing how long it will take to launch is useful feedback. I'm happy to make any tweaks to the layout, colors, sizes of the dots, spacing, etc. If design can provide a mockup, that would be great! But if not, I'm happy to take suggestions and try to improve it. I lament the loss of the pulsing icon, though. This approach doesn't retain the transition from outline to fill that's important to the activity paradigm. Could we retain that, or is that the flashy part you aim to eliminate? I wanted to stop drawing something big every frame while the activity is trying to start; that's the supposed performance improvement. Blinking would be fine, or a brief fade in at the beginning. 2) Clock theme represents time I don't understand how we know how long the launch is going to take. Is that something that we can estimate to a reasonable degree? Or do you plan to estimate the average launch time across many launches? No - the clock just displays one new dot per second. So an activity which launches in 3 seconds shows 3 dots. I could implement some estimation capacity, but that would mean the dots appear faster or slower. I prefer to let the user see there is a different amount of work involved in starting each activity, instead of implying that the same amount of work is being done at a different rate. 3) Ability to count how many seconds the launch takes I'm not sure I see usefulness in knowing how long it takes overall; knowing how much longer it will take is definitely something a kid will want to know, though, so it's good to show that. The way it's implemented now, the kid has to remember how many dots an activity takes to start up. But I think that could aid children who are learning to count :) (WARNING: Heresay!!) 4) Close button (instead of timeout) when there is an error This is definitely a big improvement. I like this a lot, and think we should also add options for looking at the crash reports and/or submitting a bug containing them to the maintainer of the activity, eventually. I did some work towards this, with a patch ready for 0.88, in http://wiki.sugarlabs.org/go/Features/Problem_Reports. I will definitely make it automatically save the activity log to the Journal, though. 5) Possibly less startup overhead; needs to be tested on XO True. If CPU is a concern, I'd vote to simply blink the icon between stroke and fill states, instead of pulsing, in order to reduce the animation overhead while retaining the visual metaphor. Blinking would definitely be ok. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
On Sat, Oct 17, 2009 at 8:10 PM, Wade Brainerd wad...@gmail.com wrote: Hi Eben, thanks for the feedback! On Sat, Oct 17, 2009 at 7:27 PM, Eben Eliason e...@laptop.org wrote: On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd wad...@gmail.com wrote: http://www.youtube.com/watch?v=OvDdN1t-0yE I was in the code and have wanted to try this for awhile! If anyone else thinks it would be better than the pulsing icon, I'll clean up and post the patch to a Feature on the wiki. Rationale: 1) Less flashy Perhaps, although the screen actually feels busier to me. Perhaps with some visual tweaks it would work (smaller ring, maybe?), since showing how long it will take to launch is useful feedback. I'm happy to make any tweaks to the layout, colors, sizes of the dots, spacing, etc. If design can provide a mockup, that would be great! But if not, I'm happy to take suggestions and try to improve it. I lament the loss of the pulsing icon, though. This approach doesn't retain the transition from outline to fill that's important to the activity paradigm. Could we retain that, or is that the flashy part you aim to eliminate? I wanted to stop drawing something big every frame while the activity is trying to start; that's the supposed performance improvement. Blinking would be fine, or a brief fade in at the beginning. Yup, I suppose both could work. The reason to blink, I suppose, is to illustrate the intermediate state throughout the launching phase. We use the same metaphor for connecting to networks, as well. 2) Clock theme represents time I don't understand how we know how long the launch is going to take. Is that something that we can estimate to a reasonable degree? Or do you plan to estimate the average launch time across many launches? No - the clock just displays one new dot per second. So an activity which launches in 3 seconds shows 3 dots. Oh, hmmm. That makes this a bit less useful, and even potentially misleading. I don't think it's a good idea to show a determinate progress indicator for something that takes an indeterminate length of time. Even if we mapped the ring to the time we wait before a fail launches, I think the visual would imply to the child that success, rather than failure, was imminent, which could be frustrating. I could implement some estimation capacity, but that would mean the dots appear faster or slower. I prefer to let the user see there is a different amount of work involved in starting each activity, instead of implying that the same amount of work is being done at a different rate. Hmm, it seems like you're arguing against the progress bar, as we know it. =) I guess it's just the difference between an absolute and a relative measure of progress, and the use of an absolute makes some sense if we can't know how long an activity is going to take to launch, but it still strikes me as the wrong metaphor. As I mentioned before, I think it's much more important to the child how much longer the launch will take (not how long it's taken so far). In either case, perhaps we can get the same type of feedback by counting the number of times an icon blinks. You could set the frequency to 1 second. 3) Ability to count how many seconds the launch takes I'm not sure I see usefulness in knowing how long it takes overall; knowing how much longer it will take is definitely something a kid will want to know, though, so it's good to show that. The way it's implemented now, the kid has to remember how many dots an activity takes to start up. But I think that could aid children who are learning to count :) (WARNING: Heresay!!) Heh. 4) Close button (instead of timeout) when there is an error This is definitely a big improvement. I like this a lot, and think we should also add options for looking at the crash reports and/or submitting a bug containing them to the maintainer of the activity, eventually. I did some work towards this, with a patch ready for 0.88, in http://wiki.sugarlabs.org/go/Features/Problem_Reports. I will definitely make it automatically save the activity log to the Journal, though. Actually, I don't think this should be automatic. I would recommend the options (report bug), (view logs), and (stop). This would give the child the option to look at the logs if they wanted, but wouldn't otherwise put items in their Journal they don't want or need. I'm not sure if reporting is possible given the current infrastructure, but it could be useful, in the long run. 5) Possibly less startup overhead; needs to be tested on XO True. If CPU is a concern, I'd vote to simply blink the icon between stroke and fill states, instead of pulsing, in order to reduce the animation overhead while retaining the visual metaphor. Blinking would definitely be ok. Yeah. It doesn't have quite the same appeal, but it would be less CPU intensive. Incidentally, how does the launcher perform on the XO 1.5 units? Has anyone had a chance to try
Re: [Sugar-devel] Design mockup of a different activity launcher
Wade wrote: Rationale: 1) Less flashy 2) Clock theme represents time 3) Ability to count how many seconds the launch takes 4) Close button (instead of timeout) when there is an error 5) Possibly less startup overhead; needs to be tested on XO My responses to this in order are: 1) I don't see how flashy is the actual problem with the activity startup process. 2) It also represents a progress meter, which is something that you cannot do correctly in this case without making it less apparently determinate. You've produced something which appears, at least to my brain, to be trying to complete the circle. Once the circle completes I expect the activity to launch. With an undetermined amount of time remaining, the idiom used should be one that doesn't appear to accumulate toward a goal. I'd be happier with sweeping dots if the previous ones faded away. 3) I think this is a fine rationale, but the given demonstration does not accomplish that task sufficiently well in my opinion. 4) I'm not sure I like the idea of adding an extra step between failure and trying again. Perhaps another way of indicating progress and occasional failure would eliminate the need for a short circuiting of a too-long timeout. 5) The current ridiculous startup overhead is not because of the visual idea; it is because of the implementation. A little bit of thought put into optimization would probably solve the overhead issue. For example, use pre-computed bitmaps instead of that astoundingly inefficient SVG-based algorithm. Also verify that the available hardware is being used effectively. Eben wrote: Oh, hmmm. That makes this a bit less useful, and even potentially misleading. I don't think it's a good idea to show a determinate progress indicator for something that takes an indeterminate length of time. Even if we mapped the ring to the time we wait before a fail launches, I think the visual would imply to the child that success, rather than failure, was imminent, which could be frustrating. This basically mirrors my thoughts in (2) above, and I think it's a really important objection to the presented metaphor. What about the following idea? Rather than displaying an appearing-to-approach-completion meter or an otherwise uninformative indeterminate-activity-indicator, gather launch time statistics for all activations of an activity and present that information in an appropriate infographic that gives much more information and assurance to the user. One infographic that might work well is a graph of the probability distribution (pdf) of the activation's duration in the range from seconds 0 to arbitrary kill point. A sweeping beacon, like the icon of the loading activity, could show the user where along the time axis the startup process is currently, how long until the activity gets summarily executed, and about when success should be expected (after which, success becomes less and less likely). The graphic could be made approachable by all users by iconically labeling important concepts like fast, slow, dead, and now. This approach would give the user complete information about what is going on and what to reasonably expect. It would also give children a unique learning opportunity to understand how experiences they accumulate over time can, for at least partially deterministic processes, be used to understand the world and predict future outcomes. It also gives a way for describing their experiences visually and numerically in a way that can easily be compared. It would also let activity authors better understand the loading behavior of their activities. As an example of the kind of graphic I'm thinking of, scroll through: http://donsbot.wordpress.com/2009/09/27/fast-mutable-collections-for-haskell-more-benchmarks/ - Avi ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
i agree with others that the new proposal isn't nearly as nice, or as much fun, as the current pulsing icon (though i think other aspects, like the close button, are good). i think that avi is spot on when he says: 5) The current ridiculous startup overhead is not because of the visual idea; it is because of the implementation. A little bit of thought put into optimization would probably solve the overhead issue. For example, use pre-computed bitmaps instead of that astoundingly inefficient if this is true (re: the current implementation), then it sure seems like the current visual paradigm could be mostly preserved, but in a way that might be much cheaper to render. [1] paul [1] says he who hasn't even looked at the problem. =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
2009/10/18 Avi fiendi...@gmail.com wrote: Wade wrote: Rationale: 1) Less flashy 2) Clock theme represents time 3) Ability to count how many seconds the launch takes 4) Close button (instead of timeout) when there is an error 5) Possibly less startup overhead; needs to be tested on XO snip /A little bit of thought put into optimization would probably solve the overhead issue. For example, use pre-computed bitmaps instead of that astoundingly inefficient SVG-based algorithm. Also verify that the available hardware is being used effectively. This may be an area where the interests of Sugar Sugar on a Stick may diverge. Sugar on the XO-1 has a determined size. Bitmaps will be fine. Sugar on a Stick requires vector-based images, because we don't know what screen size we'll encounter. My experience with the GCompris applications in SoaS is that all of the controls are horribly rendered. It comes across as unprofessional, especially when introducing Sugar to teachers parents. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
