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/
etoys-dev@lists.squeakfoundation.org