[Sugar-devel] Appearance Customization
Aleksey Lim
alsroot at member.fsf.org
Tue Nov 2 08:40:13 EDT 2010
On Tue, Nov 02, 2010 at 04:17:12PM +0800, C. Scott Ananian wrote:
> I don't think you need to do any studies about whether kids want to
> customize their computers. This has been a constant message from
> deployments since day 1. The first thing kids did with the very first
> XOs fielded was slap stickers all over them to customize them.
>
> Unfortunately, kids have no sense of taste or decorum, and so their
> desire to have a hello kitty home screen (or whatever) is historically
> countered by NN's desire to be like Apple, all clean and elegant.
> This was supported by the UX design team, which wants a design which
> wins awards, not one that is plastered with kids favorite soccer
> players or whatever.
>
> Walter has tried to bridge this divide in the past by presenting it as
> a teaching opportunity: make one of the first XO lesson how to
> customize the code to change the XO man in the home screen or change
> the colors. This gives them incentive to learn how to hack the code.
> It's a very interesting compromise, and maybe it's even the right
> thing.
>
> Anyway, I think we should let the kids customize their machines easily
> -- certainly to change the colors. But this discussion is an old one.
> I wonder how it will turn out this time, maybe we've finally moved
> past some of the old bugbears.
This is exactly the core[one of not many, at least] problem of current
situation around sugar core development. After forming SL, nothing
principally was changed, the same vertical organizational system
was just moved (dunno how it was in OLPC, created otherwise) to another
conditions.
People in the field need futures, developers are willing to implement
them.. nothing happens. In my mind core issue is that no one are willing
to take responsibility because people who might take this responsibility
are the same developers and that there is always a chance to get "Are
you have the full picture of needs to make such invasive decision?".
In my mind, solution might be:
* open minded Core Team[1], to create trends in sugar
* open minded development in Universe[2] projects, who might/might-not
follow Core Team trends; some development might fork particular
Universe projects (only projects, starting sugar-window-manager, not
sugar because there is not way to fork a community)
* until that, nobody asked themselves, "Am I doing right,
implementing/designing/thinking-about this, so invasive, feature?"
implementing/designing/thinking-about is the real core (in comparing
with [former] Development Team), preventing that means shooting in the
foot^W head.
* move all responsibilities about how product[3] (not sugar as a set of
Universe projects) looks to Platform Team [4]. It will accumulate all
efforts about facing deployment needs and particular implementations
that are part of the product[3].
[1] http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture#Core_Team
[2] http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture#Sugar_universe
[3] http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture#Sugar_distribution
[4] http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture#Platform_Team
--
Aleksey
More information about the Sugar-devel
mailing list