[Sugar-devel] Initial implementation of toolbars design
Eben Eliason
eben at laptop.org
Thu Jul 30 20:18:09 EDT 2009
Here are the icons we used for the view, edit, and color toolbars,
Sugarized of course. If anyone has suggestions for other common
toolbars across activities that deserve icons in artwork, let me know.
Eben
On Thu, Jul 30, 2009 at 6:02 PM, Eben Eliason<eben at laptop.org> 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.
>
>> 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.
>
>> 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.
>
> 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.
>
> 2. We should fix the style for the text entry so it appears correctly
> on black backgrounds.
>
> 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.
>
> 4. But these are nitpicks. Fantastic work!!
>
>
>> Thanks,
>> Simon
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: toolbar_edit.svg
Type: image/svg+xml
Size: 1820 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090730/0c615155/attachment-0003.svg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: toolbar_view.svg
Type: image/svg+xml
Size: 1046 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090730/0c615155/attachment-0004.svg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: toolbar_colors.svg
Type: image/svg+xml
Size: 758 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090730/0c615155/attachment-0005.svg
More information about the Sugar-devel
mailing list