[Sugar-devel] Initial implementation of toolbars design

[Simon Schampijer]

On 07/31/2009 12:02 AM, Eben Eliason wrote:
> On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijer<simon at schampijer.de>  wrote:
>> On 07/29/2009 07:03 PM, Gary C Martin wrote:
>>> Hi Simon,
>>>
>>> On 29 Jul 2009, at 08:55, Simon Schampijer wrote:
>>>
>>>>> FWIW: Picking the top level tool set is going to be a real tough call in
>>>>> a number of cases as we loose toolbar space for each extra tab, plus the
>>>>> activity icon on far left (essential for Activity recognition), plus the
>>>>> stop icon on far right (essential, no questions, no doubts). The
>>>>> features that actually fit in the remaining space may seem quite an
>>>>> arbitrary hotchpotch.
>>>> Gary, I am not sure I get your arguments right :/ Can you elaborate?
>>>> What I conclude of all the answers, I think that space in the primary
>>>> toolbar is an issue. So we need to decide what to put there. Does
>>>> activity icon and stop icon sounds good to you as well?
>>> Sorry if that wasn't clear. Activity icon and stop icon are essential.
>>> The Activity icon is going to be critical for identifying what activity
>>> you are in at a glance, especially if the actual title name is hidden
>>> away in a sub toolbar. A downside if we loose the title in the primary
>>> toolbar is reinforcement of knowing what activity you are in (say you
>>> are copy/pasting between two similar Write documents)...
>> Ok, thanks for the explanation. The differentiation of the running instance
>> of two activities of the same type is a good point. But, does this happen
>> often? I guess many kids will run one activity of each type at a time, and
>> remember performance constraints ;p And one can use the frame to distinguish
>> the activities.
>>
>> Personally, I see more the issue of naming an activity, since as said in
>> another post I am not really convinced about the naming alert.
>
> I'll have to think about this idea more, but: we could also have the
> naming "alert" appear as a palette attached to the stop button,
> instead. It doesn't change the behavior too much (it requires 2 clicks
> to stop an activity for the first time if it hasn't been named), but
> the use of the palette might feel more consistent with Sugar in
> general. On the other hand, it could be strange to change the behavior
> of the stop button between the first and other cases.

The main problem I guess is, that the kids don't know what the naming 
dialog is for. The new Sugar users I had in class start by opening and 
closing activities and work away in them. Even though you explained them 
the concept of the Journal before, the relation with the naming dialog 
was not obvious for them. I think the naming and tagging of an activity 
instance is a more advanced feature, the kids will discover later.

Once they experienced the power of it, they can use the Journal itself, 
or the facilities in the activity to name and tag (has to be added to 
the toolbar) to fulfill that task. No need to have this extra dialog 
appearing, imho. I postulate that the 'enforcing' of naming an activity 
was a nice idea to pay attention to the concept, but I think in practice 
it does not work out well.

>> One little thing I am a bit worried about, is that we miss labels for the
>> sub-toolbars. I hope the icons are meaningful enough for the users - but
>> then labels can be misleading as well, and many of our users can't possibly
>> read.
>
> Yes, we had some thoughts. We'll hash it out some more.

Awesome.

>> About alignment (attached is a snapshot), should we align the 'share button'
>> and the 'keep one' to the left that the way to get to this button is not so
>> long, when revealing the toolbar?
>
> I think we should be thinking about this in the general case.
> Sometimes one will need to reach the other end to reach controls (and
> (though not for the activity toolbar) this depends on where the
> toolbar button sits within the primary toolbar). We should make sure
> that the palette behavior works well in these instances. For instance,
> it shouldn't disappear immediately on mouse-leave. Perhaps the delay
> should be longer than for normal palettes, due to their peculiar
> dimensions.

Yeah, the delay is an interesting point. While using I have been 
thinking this as well. When you hover over the toolbar button and then 
move the mouse to the far right, you likely will not always stay on the 
expanded toolbar (especially for young kids mouse interaction is not an 
easy task).

> That said, I'd be fine with aligning these buttons to the left in this instance.
>
> Eben
>
> PS a few notes on the design:
>
> 1. Is this screenshot showing the hover state of the toolbar button
> with the toolbar already locked in? If not, the small arrow beneath
> the activity icon should still be pointed downwards, to indicate that
> clicking on the button will lock it into place. It should appear
> pointing upward only when already locked in.

Fast, faster, Aleksey has changed this already.

> 2. We should fix the style for the text entry so it appears correctly
> on black backgrounds.

Aleksey is on that after discussing with benjamin.

> 3. I'll get you those scissors tonight, for real this time. Also, can
> we change the arrow to match those in the mockups? The one shown here
> competes with the icons themselves.

Thanks, pushed (even verified with the 
http://library.gnome.org/devel/icon-naming-spec/ icon naming spec after 
tomeu nagging).

> 4. But these are nitpicks. Fantastic work!!

Thanks to Aleksey and review master (even nitpickier then marco) Tomeu!

Cheers,
    Simon