[sugar] naming

[Eben Eliason]

On Wed, Oct 8, 2008 at 6:06 PM, Yamandu Ploskonka <yamaplos at bolinux.org> wrote:
> <snip>
>>
>>  I hope that this naming
>> problem (lack of naming, lack of tagging, laborious naming process,
>> poor default names, buggy name updates, etc.) can be nearly if not
>> completely cleared up in the next major release.
>>
>> - Eben
>>
>
> I appreciate your agreement as to easier to use alternatives.
>
> I am afraid that part (or the origin?) of the naming/tagging problem is
> philosophical / ideological / aesthetic.
>
> There is a major current of "icons only" confectioners :-), folks who
> believe the typical user  is illiterate, that cannot read text accompanying
> the icons, i.e pre-schoolers.  Or they suppose localization will be easier,
> as icons don't need translation?  Or is it just the look of the thing
> overriding its use?

To clarify my position on the matter, several considerations did
factor into the current approach.  The text was kept secondary mostly
due to lack of space on the screen, and only in small part because we
thought (really young) kids might react better to less text, at first.
 Pushing the text into the palettes allowed us to make both the icons
and the text bigger, which we thought was important, both so the icons
could be read more easily and so the clickable areas were easier to
hit, especially with the imprecise touchpad.

I don't expect all kids using Sugar to be illiterate, and more
importantly, I sincerely hope that Sugar will actually aid in teaching
children the associations between word and image. It was very
important to me that we didn't simply abandon the text altogether;
Connecting the text to each object/button/whatever provided a way to
keep the interface light, while providing the additional context when
needed.

Localization certainly isn't any less needed in this modality, as the
strings still exist, but it does certainly minimize the impact that
localization inflicts upon the layout.  Some languages have
substantially longer strings for various words and phrases, which can
pose difficulty on a screen with space constraints.

Additionally, some layouts are affected by this much more than others.
 In the activities, many of the buttons are self evident, or become so
after trying them out once (we encourage exploration, and aim to make
it easy by also making it just as easy to undo something).
Additionally, most standard applications I know don't show text with
buttons in the UI (though the menu system is a different story), and
instead depend on tool-tips to reveal what they do upon hover, much
like our palettes.  In views such as the Neighborhood, of course, you
have a valid point.  The search field is a partial solution, but we
also aim to provide list views in places like the neighborhood, which
will reveal both icon and text, ordered and perhaps even sortable, so
that finding things can be approached more directly.

> Then there's those of us who believe in usability and shout "fertilizer" to
> cutesy-pooh post-modern fashion statements that block actual results.  (oh
> my, I will be tagged for flaming...)

He heh.  I hope my explanations make you consider the approach as
slightly more valid than just cutesy-pooh, even if you still disagree
with it.

> Anyway, another one:  a NEED (yes, I mean to shout it) is that 'file' names
> or whatever you call them BY DEFAULT carry the author / child / machine ID,
> so that when that file ends up in the teacher's machine, he can figure out
> which one of the 35 'Write Activity' that were submitted is Roberto's.

Yes, I think making this part of the Sugar default naming scheme makes
prefect sense, and also humanizes it a bit more.  "Eben's Painting 1"
sounds much better than "Untitled 1", even if "Painting of my House"
might be more appropriate.  The tickets I linked to  before include
this in description of the default name.

Additionally, metadata is something that's still being perfected in
Sugar, but all activities actually store their author (and, actually,
all participants) in metadata, so it should be possible to see who
worked on what even without having it in the name.  I think some work
needs to be done to properly retain and/or expose this type of
information.

> Now, this is one of the serious, serious missing links when it comes to
> using the XOs for actual schoolwork.  Teachers assign homework.  Kids do it.
>  In a contemporary-ideal setup :-( these pieces of work are sent to the
> teacher for evaluation.  This has maybe a 50-50 chance of working if the
> teacher can follow up and figure who's who.  Otherwise, it will never fly.
>  (oh yes, the /untrained/ teacher could train kids to name and tag files)
>
> Yes yes, in an _ideal_ world teachers do not evaluate schoolwork...

I think evaluation is good, but perhaps not in the A,B,C,D scale.
Reflection on work, and discussion of progress, is certainly part of
learning.  I wrote up some thoughts about how we might begin providing
better structure for giving and submitting assignments in another
recent thread on "narrative".

It's true: In my ideal world, a kid would come look through her
Journal together with the teacher, discussing projects, lessons,
improvement, moments of enlightenment, etc.  The Journal should be a
portfolio of thoughts, ideas, failures, successes, experiments, and
creativity.  However, for Sugar to achieve it's lofty goals, it needs
to make it possible -- actually, quite easy (admittedly, it doesn't do
this yet!) -- to move information around, regardless of what that
information is or where it's moving from and to.  This should
certainly include making it entirely feasible to use it to give and
turn in assignments in a conventional manner.

- Eben


> Another religious issue there, should XOs be used for contemporary
> schoolwork?

> Yama
>
>>
>>>
>>> Could we have some of that, please? and be able to see the name of an
>>> Activity at least when the mouse hovers, if not even better right there
>>> under the icon?  Yes, usabilitity criteria should be more important than
>>> the minimalist look, which is a rather empty artistic statement rather
>>> than a practical, useful design decision.
>>>
>>> Since we're at it, let also be plainly visible with a plain old number
>>> which is which of the 3 circles that represent the mesh networks.  That
>>> would save some useless hovering around when several kids are trying to
>>> get on the same one.
>>>
>>
>