On Thu, Jul 16, 2009 at 12:18, Christoph Derndorfer<[email protected]> wrote: > Sayamindu Dasgupta schrieb: >> >> On Thu, Jul 16, 2009 at 11:10 AM, Christoph >> Derndorfer<[email protected]> wrote: >>> >>> Caroline Meeks schrieb: >>>> >>>> ==Avoid surplus Activity launching== >>>> Don't let the user keep opening activities until the machine crashes or >>>> is driven to its knees. Make it less likely that a user who is >>>> impatient will end up opening multiple copies of an activity. >>>> * Priority C for GPA >>> >>> +1 >>> >>> In my (very) limited classroom experience this is quite an issue and out >>> of 20 children you will always have 2~3 which have launched several >>> activity instances bringing their XO to an absolute standstill. >>> Restarting Sugar takes quite a bit of time and very much disrupts the >>> classroom workflow. >>> >> >>> From a technical perspective, could we use libunique[1] here ? >> >> -sdg- > > I think that generally we don't want to forbid running multiple instances of > an activity because there are many use cases where this makes sense. > > What we much rather need (IMHO) is some sort of way to guess whether the > user really wanted to launch a separate instance or not. A primitive > heuristic could be to disable launching an activity while an instance of > that same activity is being started.
We did that before we had the launcher screen. We didn't reimpemented it after the move because our user experience goal was avoiding several consecutive clicks when launching activities. > Another, though related, issue is trying to keep users from launching too > many activities at the same time. From my experience the XO-1 seems to > handle approx. 4 activities in parallel quite well but quickly becomes > unresponsive once more activities are launched. This is why I really liked > the activity ring in the early days of Sugar as it gave some sort of visual > feedback when too many activities were running at the same time. I think that when we get to this level of detail in the user experience, we need to be more rigorous when explaining the problem or we risk making changes in every release and missing the mark every time. Who can do a good write up of the problem and its causes? Then we can move to propose solutions. Thanks, Tomeu > Christoph > > -- > Christoph Derndorfer > co-editor, olpcnews > url: www.olpcnews.com > e-mail: [email protected] > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
