[Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Thu, Jul 30, 2009 at 9:21 PM, Gary C Martin<gary at garycmartin.com> wrote:
> On 30 Jul 2009, at 20:46, Simon Schampijer wrote:
>
>> On 07/29/2009 07:03 PM, Gary C Martin wrote:
>>>
>>> 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.
>
> OK, next nit pick (apologise as it is clearly a design oversight not
> implementation issue).
>
> Are we suggesting we make all the lovely, really simple, Activities (the
> ones who have managed to avoid tabs and just a "title", "keep", "stop", and
> perhaps sharing) now show a 95% empty top bar (with just the activity icon
> at one end and the stop over at the other). And require popping up and
> potentially adjusting the canvas sizes to fit the Activity sub toolbar? Just
> did a very (very) quick/rough dig through.

That's an interesting question. I'll have to take a look at some of
these activities. I actually find it odd that so many wouldn't have
any use for buttons or other controls. Perhaps a number of them are
revealing these controls in the canvas below instead of using
toolbars?

For what it's worth, I have always found it a bit odd when activities
embed their own custom controls amidst the cross-activity controls.
Perhaps we could institute a rule by which the primary toolbar will BE
the only toolbar (not a toolbar button) if and only if the activity
adds no toolbar controls at all. If, on the other hand, the activity
wants their own controls, these would appear in the primary toolbar to
the right of the activity icon.

> Pippy (though we could finally move "run" and "stop" into the toolbar).

That would be great!

> Maze
> IRC
> Chat
> Typing Turtle
> EToys (has title, sharing, keep, stop, and other buttons, )

Etoys has always behaved slightly differently since it's not using GTK.

> Most (all?) of every MaMaMedia (Slider Puzzle, Jigsaw Puzzle, Poll builder,
> Story builder Joke Machine, etc...)
>
> et al...
>
> Ideally I'd like to see an activity icon, and its journal title appearing,
> so you have the best chance of knowing 'what' you are currently looking at.
>
> OT: Activity icon followed by title makes an activity instance look like the
> Journal entry row it came from, which would be a good thing, but I couldn't
> find a reliable design for that formula.
>
>> 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 know what you mean. I did wonder once if a modal activity alert style
> pop-up, below the activity toolbar, would be less intrusive, and more in
> context with the activity than a pop-up dialogue that hides most of the
> Activity context.

That's a possibility, but as a general rule those alert "bars" are
non-modal. However, clearly any naming alert when stopping the
activity must be modal, since it needs to prevent the action from
taking place until the dialog is settled.

>> 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.
>
> +1
>
> Extremely good icons are essential or else WE FAIL and walk backwards here.
> :-( At least this is something we can iterate on before the 0.86 official
> release that gets documented and pushed out to deployments.

Yup. I think providing a fairly extensive set of default icons would
be a good thing, both to help activity developers out, and for
consistency in the UI. I'd be happy to help out with this. It would
also be nice to extend the default icon set further in general. There
are lots of common icons that we should be providing, for the same
reasons as above, that just never made it. I have a list, and perhaps
many even designed already, somewhere.

>> 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?
>
> My vote is for no right align. Put those icons (share with, keep) left
> aligned near any other icons (perhaps a tag feature can show here in
> future). My main concern here would be for a child trying to drive the mouse
> all the way over from the far left of the display, to the far right to hit a
> target.

Again, this depends on the context, and where a given toolbar buttons
resides within the toolbar. I'm quite hesitant to spec alignment based
on this alone. However, I agree that in this case left align makes
sense anyway.

Eben