[Etoys] Some comments on the olpc Etoys (interface)

[Eduardo Silva]

> Eduardo,
> 
>   Thank you for the comments and suggestions!
> > In various parts of Etoys, there is balloon help,
> > which is really nice, especially the programming
> > tiles. But I think the balloon help for the
> > interface
> > is many times is too verbose.
> 
>   Ah, yes. I sometimes agree with it.  But, can you
> give us some more
> your thoughts on *why* verbose balloon help is not >
preferable?

I'm not sure. I just think that there are times when
you are using an interface, and want a few tips to
continue, others when you those tips aren't enough,
and you want to fully understand it. So, a difference
between interface tips (like desktop tooltips), and
interface help.

 Perhaps there could be 2 help balloons? The first
gives a short sentence explaining the function/button,
the second only appears after some more time hovering
over the object, and gives a bigger and more thorough
explanation. I've had this idea, or the idea of more
advanced bubbles from the game "The Movies", where the
first bubble help allways showed basic information
plus urgent ones, and if you waited, or clicked the
bubble, the main bubble would have its own bubbles
giving full info about the object. See these
screenshots:

As an aside, Scratch doesn't have tooltips for code
blocks. Instead you can right click one, and choose
Help, which opens up a view, with a piece of text, and
illustrations right from the reference guide,
explaining that specific code.
Perhaps one of these would be a good idea for future
versions or programs you will develop.

On the other hand, I understand how better help can be
good, especially how I see them work in KDE, a desktop
I use. Preferences windows have a ? button, with which
you click on the options and get a 3-4 line
description of that option, which is really usefull.

> > New Project Button -> balloon text should only say
> > "New Project" instead of "Start a new project"
> >
> > Save Project icon -> balloon text should say "Save
a
> > Project. Hold down button to reveal additional
> > publish
> > options" . Take away the "Click here to", and
"Hold
> > down _this_ button". In both cases the kid knows
> > that
> > it is a clickable button (all activities have
> > clickable buttons on top), and which button the
> > balloon text is referring to (the one bellow his
> > cursor). This looks like how people used web links
> > many years ago, "click _this link_ to go to my
> > homepage".
> 
>   That would be a good observation.  Some of the
help messages indeed any years old!1 
> > Find Project icon -> "Find a Project. Hold down
> > button
> > to reveal additional options".
> 
>   I would think that these are more or less
reasonable suggestions.1
> Once our native speaker colleague gets spare time, >
this may happen.
> 
> > Undo icon - When I click it once, it undoes, then
> I
> > click it again, and it Re-does? There should exist
> > an
> > Redo button next to this one instead.
> 
>   I'm not sure about this (having an extra button
for redo),
> especially because we don't have multi level redo.
But it's confusing. The undo button won't act the same
as the other activities in the olpc, and the redo
function is the opposite of undo, so making it do-able
using the undo button seems wrong to me.

> 
> > Flags icon -> "Change Language"
> >  
> > Neighbourhood and Close icons -> I thought these
> > where
> > in the top frame. Or will etoys replicate the
> > outside
> > frame?
> 
>   As of 466, there is no close icon in the "top
frame".  Share is not
> in the "top frame".
Ah, ok, I haven't played with recent builds of sugar.

> > And the neighbourhood is way verbose. If the look
> > for
> > the badges are that unobvious that their function
> > should be detailed here, then they probably need
> > improvement? But won't they be XO icons with the
> > friends colors. If so, kids by then will now what
> > they
> > mean. And extra help like "drag objects to give to
> > your friend" could be in the badges themselves.
> 
>   These list shows the neighbors icons in their
colors.  The ideal
> situation is that an accompanying document explains
> what would really
> happen, and then the verbose explanation becomes
really unnecessary.


> > Display icon -> "Select Display Mode", but not
sure.
> > 
> > For the interface, the text doesn't have to
explain
> > in
> > detail every button's function, because most of
them
> > are not destructive, and so through experimenting
> > kids
> > will work them out.
> 
>   Or they simply ignore.

Yes, but too much explaining, all the time, is also
suffocating to use. It's like having a parent which,
every the child asks about something in the world, he
goes on for half an hour explaining
(non-interactively) the ins and outs of it. After a
while, you don't like to ask about things, even if you
wanted to know them, because you don't care for
another big lecture. Other times you may want a
lecture. But etoys allways gives a pseudo-"lecture".

> 
> > I've noticed that when you create a new window,
its
> > thumbnail is colored, then when you go inside, the
> > background is gray, and then out and it remains
> > gray.
> > 
> > Having multi-colored backgrounds for new Etoys
> > projects was something that I found nice in the
> > past,
> > and even made the environment fun too look at. It
> > would probably be the same for kids. If the
problem
> > is
> > contrast, then couldn't you choose less saturated
> > colors, so they became light green, light
> > blues,etc.?
> 
>   The first one probably can be and should be fixed
> (i.e., the newly
> created project thumbnail bear the background color
> of the project).
> In regards to Multi-colored backgrounds... that
would certainly make
> the documentation effort harder.  (it would not be >
a bad idea of
> course).
Why would it make documentation harder? Because it
already exists and is using the gray backgrounds? Oh,
but colored are much more fun!
 
> > The color picker to choose a project's world color
> > is
> > very small and different than all the other
windows
> > (the button to "pin" the window is tiny, for
> > example).
> 
>  Any color picker is really bad.  It should be
fixed.

> > I think trash should be present in new Projects.
> 
>   Can you explain why?  I usually delete the
trashcan before publish a
> project.
Right, but I'm thinking about the beginning of a
project. To be honest, I forget many times that you
can delete an object on the cross halo button, but I
think that you can assume that every kid starting a
fresh project will want to discard/delete things
inside of it, and having a trash already present (with
the ability to be removed of course) just makes their
task easier . (Then having to go get a trash object
everytime they start a new project, or not even
knowing about its existence)

> 
> > When you colapse a morph with the circle halo, it
> > stays collapsed on top of the sugar bar, and uses
> > different button icons.
> 
>   There is an argument for removing the collapse
handle altogether.
> What do you think?

I'm not sure. I think that the collapse button is
good, a quick way of getting something out of the way.
But I originally had some ideas about organization of
the halos. For example, making the 4 corners be used
by the most important and most used functions .
I'll check my notes, and etoys as well, and tell what
I think.
> > In the script windows, there are two buttons which
> > show some repeated tiles, the chest button and the
> > menu button. The ones they repeat are:
> > Self title, random number title, button down?,
> > button
> > up?, repeat title.
> > 
> > The chest icon doesn't follow the style of the
> > neighbours.
> 
>   That is exactly correct.  The redesign of scriptor
is on our list,
> and making the header line similar to sugar-bar and
> our supply bin
> would be a good idea.
You mean making the "toolbar" of scriptors black and
white? I had thought about it, but was wondering if it
would be too much a change, or if it would make the
interface look too "somber". But I think it's maybe a
pretty good idea. It makes the function of those bars
a lot obvious (that they can be manipulated), since
they follow the look of other toolbars in the system. 
If you think about it, having all the menus (from the
halos for example), use that same look would also give
the environment visual tidy-ness. But this could be
tested.

> 
> > Also, in the Object Catalog, in the Scripting
> > category
> > there is repeat, button up? and button down? 
> 
>   Yes.  Is that bad?

Hm, I think so! It's unorganized :) Why did those
specific code tiles where chosen? Because someone used
them a lot, and wanted them there? Well, but some kids
may want other often-used stuff in there. Let each of
them decide, by making it clear that you can drag
almost everything to the object catalog.
Also, I think that it's a bit confusing initially,
especially when learning about the environment. If
things are duplicated around, it's harder to make a
sense of it all (Object catalog has this stuff,
Scriptor toolbar has  this other stuff). You might
say, harder to make a mental understanding of the
organization of the environment and its tools when
they aren't very tightly organized.

> > Finally, It would be really handy if there was a
> > button which sent to the trash all of the method
> > tiles
> > scattered on the "desktop". While I'm doing a
> > project/etoy, it becomes tiresome to have to
allways
> > trash
> > them, so I just drop them anywhere out of the way
> and
> > continue my thing.
> > After a while I have a big mess of tiles on
screen. I
> > think kids may also behave like this in the
beginning,
> > when they are just messing with and trying new
tiles
> > (exploring?). But perhaps the Button tiles and
> > "values" tiles could stay.
> 
>   I also see many kids delete a tile as soon as they
drag out from a
> scriptor.  What do you think if the multi-selection
> feature is easier
> to use (such as, just click and drag the background
> to initiate
> multiple selections)?

Ah yes, that would be good for all the objects. Also,
perhaps I'm not thinking this fully, but would this
make sense:
Dragging a code title to the Object inspector (where
all the draggable code is), would delete it? Sort of a
"sending to its maker" thing. This is how Scratch
works, besides being able to delete each one
individually. It would also make it easier to dispose
of code blocks, since the area to drag them to is
bigger. (But could it also happen to loose codes
unintentionally? Better test if before committing to
it)
> 
>   Again, thank you for the comments!
> 
> -- Yoshiki

You're welcome! It is my "desire" to make etoys as
streamlined as possible, that is, to make the
interface as obvious and clear as possible, so as to
make the real difficulty go into programming the
etoys, and not into dealing with the interface (and
with an eye towards the common sugar interface, make
it behave as similar as possible to the other
activities so it becomes more "natural" to use,
through habit).

Eduardo

OH MY ... http://www.geocities.com/jobezone/index.html


       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/