[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [kidsUI] Pause and restart



Hi,

The insight that I was trying to communicate was 
something I noticed in trying to learn the 
Japanese Kanji (the ideographic symbols).  Essentially,
the pattern is the same:

1) Basic "obvious" graphics for concrete nouns.
	These become stylized to a particular form.

2) Combinations of "concrete nouns" to form more
	abstract concepts.

The problem is, that 

1) the symbols for even the most concrete things 
are not *that* obvious -- different drawings of 
the "same thing" look different, especially
if there are large cultural differences among the
artists.  This gets worse, not better as you simplify
the drawings, because different parts get emphasized.
For an example, a Westerner would probably draw
a cup as a teacup with a handle.  Far Eastern cups
don't have handles.  Maybe it's a guy with one ear?

'----`
|    |-`              '------`
|    | |   <- cup? -> |      |
\    /-'              \      /
 \--/                  \----/

and 

2) once you start combining things to communicate
even slightly abstract concepts, there is a
combinatorial explosion of different possible 
representations.

The Japanese (and Chinese for that matter) resolve
this by arbitrarily standardizing on particular 
symbols (some of which no longer make sense except 
in a historical concept), and by accepting the 
educational burden of teaching some 2000 symbols 
to students (more for Chinese) in order to be 
fully literate.

Computer icons differ from Kanji primarily in the
level of detail that can be sustained, since they
don't have to be duplicated by hand.  This reduces,
but does not eliminate the "arbitrariness" of
the symbols.

Furthermore, many computer concepts needed, such
as "Exit program" or "load file" are quite abstract,
and it's pretty clear that ten different programs could
represent them ten different ways.  If you have to
learn to recognize all of them, you haven't made
much progress over text labels (which have already
been standardized to a great degree).

To show what I'm talking about, one of the "pre-existing"
icon standards for Kids UIs, is the red-octagonal
"stop sign" as an exit.  This has NO concrete basis,
it simply adopts a traffic symbol that most
kids have to learn anyway.  This is the symbol my
kids have the least difficulty recognizing, by the
way.  Of course, if there are countries that don't
use this symbol, it won't work (I think the stop
sign is pretty international, but I haven't traveled
that much).

I think what helps kids most is not the "real-world
analogy" but rather the consistency of application.
Using bright colorful representations aids in 
distinguishing the symbols, because kids are more
comfortable distinguishing "pictures".  Also, if
the symbols have a consistent size and bounding shape,
it's clearer that they belong to the same set of
symbols.

Direct application to UI?  I suggest having the
icons derived externally to the program, allowing
the UI to establish the icons used.  Thus, for a
particular kid, the same symbol would be used in
many programs to do the same thing.

As possible development hook(s): I think some existing
programs, especially multilingual ones, access menu
titles externally. For English language programs, the
menus have fairly standard names.  I can imagine
having a substitute toolkit library that would sub
in iconic representations for the recognized text
symbols.  Thus a call to create an "Exit" button would
actually generate a "graphic stop sign" button.  I haven't
seen enough of the code to be sure this is feasible,
but it seems logical to me.  Maybe someone who actually
understands this should address this. :)

As far as reducing the stress with needing help to learn
a program, I think the best way is to not let the program
do anything irreversible and have "Undo"/"Redo" buttons
(you teach them those first).  Then, it's safe to let them
learn everything else by the "punch it and find out" method.
What's frustrating (and for adults, too), is when you can't
get back to where you were if you screw up.

Anyway, it's pretty clear we're all talking about
much the same thing here.  I think my point
was just that "consistency" is much more important than
"obviousness" in choosing symbols.  If we try to
revolutionize icons with a "newer, better, more
obvious" set then they will simply co-exist with the
old standards, increasing the total number of symbols
and symbol sets that users (including kids) have to
learn.

Thus is it really better to switch "file
folder" and "file drawer" to "book" and "bookcase"?
Or is it simpler just to teach a kid what the "file
folder" means?  After all, my kids have seen a file
cabinet, too.  Also, since adult programs tend to
use those symbols, the kids can apply what they
learn to a wider range of programs.  My four-year-
old is already expressing an interest in using
the adult interface programs, so I don't know
if there's that much value to a set of substitute
icons.

Alfredo Kengi Kojima wrote:
> 
> On Tue, 25 Apr 2000, Doug Loss wrote:
> 
> It took me a while to reply to this, due to lack
> of time, but here we go..
> 
> > Terry Hancock wrote:
> > >
> > > I would like to reemphasize that kids are actually very flexible about
> > > what they can learn on the computer. "Cognates" are mainly of use to
> > > people already proficient in a language.  When you're learning from
> > > scratch it doesn't really matter that much.
> > >
> >
> > But what we're trying to do is to make the initial contact with the UI as
> > "intuitive" as we can, right?  For that reason I thought it might be a good
> > idea to have the various active areas represent some physical equivalent
> > whenever possible rather than some a priori symbol.  I'm far from an expert in
> > such things, though, and would welcome more experienced comment.
> >
> 
> I agree with Doug. The analogies used in computer systems
> are meant to turn completely abstract operations done by
> the machine into something more concrete or "touchable" by
> people. They aren't meant to be an "emulation" of the real
> object.
> 
> As for the symbols, I read in a book from Piaget
> that children from 6-11 years have the tendency to "invent"
> connections or cause/effect relationships for anything,
> even things that do not have any intended relation.
> So, I think that's something we could use.
> Possibly by inventing a set of very distintictive symbols
> and always use them consistently, as a kind of simple language.
> These symbols would not be necessarily used on their own,
> but as additional hints for the meaning of another icon.
> 
> > >
> > > I think what is most important for kids is that the symbols for doing
> > > different things are clearly identifiable as symbols, and distinct
> > > from each other, the real explanation of what they do will become
> > > clear from use -- I mean the disk drive will never act _exactly_
> > > like a bookcase, and there may be simple things you want to do that
> > > have no "real world" analog, but that doesn't mean you can't do them.
> > >
> >
> > That's true, of course.  But if consistent analogies between the real world
> > and the UI can be used, it might make the process of learning to use the
> > system quicker and easier.  Where there isn't a real-world analog, we would
> > certainly have to come up with something "from the whole cloth."
> >
> 
> I agree with Terry, but as I said before, the point of the analogies
> is to make it easier to learn and to give clues from where you
> can draw conclusions without the need for constant help (someone
> telling you what does what). Of course, it's not always possible to find
> good analogies, in that case there would be the need to invent new symbols
> that depict such actions or objects.
> 
> --
> Alfredo
> 
> > --
> > Doug Loss                 Even if you're on the right track,
> > Data Network Coordinator  you'll get run over if you just
> > Bloomsburg University     sit there.
> > dloss@bloomu.edu                Will Rogers
> >
> >
> >

-- 
Terry Hancock
hancock@earthlink.net
http://home.earthlink.net/~hancock/index.html