Talk:Sugar design review 3

like Squeak Etoys

This is starting to sound like you are moving in the direction of the Squeak Etoys interface. At a recent Python conference in Europe, Alan Kay said that he expected that it was likely for OLPC to reimplement some of the ideas of Squeak in the Python language rather than simply adopt Squeak.

I wonder if this is what you are conciously doing.

Have you considered publishing some scope documents on the Wiki, i.e. hardware goals, basic software set goals, Sugar goals, etc.? --Memracom 15:33, 8 July 2006 (EDT)

Has there been any thought on single click vs. double click?

Fragmede 11:58, 21 July 2006 (EDT)

Double-click should never be required, and should never cause an immediate harmful action. As long as those two rules are never violated, double-click should be available as often as possible. (the same would go for middle-click and right-click if these were possible on the touch pad) AlbertCahalan 12:28, 24 February 2007 (EST)

Blog vs. Diary

"Part of it [blog] (the explicitly posted diary entries most likely) will be visible to the other kids"

I'm confused. Are you saying that:

Blog = personal journal

Diary = public journal

Shouldn't it be the other way around?--Hal Canary 17:08, 23 July 2006 (EDT)

I'm wondering if there is a need for both a public and private journal/diary? If we are assuming that children will find the concepts of marking some documents as public and some as private easy to understand, would it not make more sense to allow them to keep everything in one journal, and pick which entries are public and which are private?

--LittleJim 11:05, 2 January 2007 (EST)

States of sharing

I don't fuly understand how the system will work, specifically in regards with private versus public content created by a kid, so here are some of my ideas.

I think that there should exist 3 states for content, changeable on a document basis: Private, Show to Others, Share with Others. Kids would be able to easily and at all times switch between these states for each activity they do, journal entry they write, document they work on, etc.

Private - By default, everything a kid does on their laptop should be private, i.e., only they can see it and modify them. It may take a while until a kid understands and learns the laptops interface, and its sharing capabilities. So, by default, the software should assume that what a kid does with the laptop, the things he writes, draws, etc., are intended to be viewed only in his laptop. The method to switch to another state would be easily available, and a kid would be able to switch back and forth between them in real-time.

Show - Kids may want to show what they do on the laptop to other friends who are not with them physically, or to everyone, but not necessarily allow others to change them. For example, their drawings, writings, etc.

Share - Kids will want to show others what they have done with their laptop, and will want others to change them.

There will also be cases where a kid will want to show and share something with some friends, but only show to others.

Some example cases for the Private and Show states:

- Diogo received his laptop at school on that year's first day of class. Even after the teacher's explanations on the its sharing features, he doesn't fully understands how they work. He comes back home and begins writing a personal entry in his diary, exposing some of his intimate thoughts, fully thinking that what the writes in his laptop will stay "inside" his laptop. He will be right, because the laptop will function like that by default.

- Susana has been writing a diary for weeks. At the end of one day, she writes in it an entry detailing a funny adventure she had with some of her friends. She makes the entry "showable" to her friends.'s friend will have her birthday. She makes a drawing on her laptop of her friend. Later that night, she finds her friend on-line, and shows her the drawing.

Of course, perhaps there are better words than Share and Show.

 --81.84.103.48 07:16, 26 August 2006 (EDT)

Some GUI suggestions

These relate to build185 so it may be that you have changed these things:

At the moment, the frame is the same shade of grey as the borders of most activities. This can make it a little confusing to see when the frame is in view, and also looks cluttered when overlapping the activities - see here:

Also I wonder if closing an activity and shutting the system down should use different icons - at the moment they both use a circled X - maybe the shut down could use a circle with a vertical dash through the top, or a sleeping face or something? --Tomhannen 11:44, 7 December 2006 (EST)

arbitrary delays, smoothness, and dangerous defaults

No way should a user have to wait 5 seconds for an app to start. That is really annoying, yet also not long enough! No delay will ever be enough for the slow kids. Any delay will annoy the fast kids.

Yeah, I know you want to encourage sharing apps, but opt-out is as wrong here as it is with spam. Opt-out isn't fail-safe. (which reminds me, the C language API for showing/sharing is not published anywhere I can find)

As a general rule, arbitrary delays and timeouts need to be eliminated. Probably the main valid exception is the delay caused by a brief and informative animation, such as an app quickly getting sucked down into an icon. (as fast as the eye can follow)

Smoothness is an important concept. Things that appear/disappear instantly are not smooth, because the user can't see where they came from or went to. Perfect sharp right-angle corners are not smooth; the eye more readily follows a corner with a bit of a curve.

AlbertCahalan 12:49, 24 February 2007 (EST)