[Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Sat, Jul 11, 2009 at 10:23 AM, Gary C Martin<gary at garycmartin.com> wrote:
> On 11 Jul 2009, at 14:40, Aleksey Lim wrote:
>> On Sat, Jul 11, 2009 at 11:12:31AM +0200, Simon Schampijer wrote:
>>> a) DESIGN: discuss the design further and get some mockups
>>> together, one
>>> question that came up is: do we always have a one line secondary tool
>>> bar?
>>
>> Do you mean hiding sub-toolbars like palettes?
>> I'm using new toolbar in Memorize, and should say - its much useful to
>> have persistent sub-toolbar(and not auto-hiding them like palettes)
>
> Ebens designs describe both interaction methods:
>
> 1). If you hover over one of the new tab replacement buttons the
> palette appears (over the top of the canvas) and will auto-hide if you
> move the mouse way (just like any normal palette)
>
> 2). If you click one of the new tab replacement buttons the palette
> appears (and shifts the canvas down the screen) and is locked in
> place. Clicking the button a 2nd time unlocks it so it behaves like a
> regular palette again.

Yup, that's the idea. I think it should be up to the activity, by the
way, to decide if any of the secondary toolbars are "locked in" when a
new activity instance is created. For instance, Paint might decide
that making the colors available by default is the wise choice.

We should also institute policy for retaining toolbar state in the
metadata for a given activity entry in the Journal, so that resuming
restores that context. Perhaps this is something that the toolkit can
do so that activity doesn't have to think about it.

>>> How would more complex widgets like the color chooser look like
>>> http://wiki.sugarlabs.org/go/File:ColorToolButton.png ? Or would they
>>> open from the secondary palette?
>>
>> I'm personally, +1 for
>> http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11

Just to be clear, this new toolbar design is in no way intended to
replace palettes in general. Instead, it's provided as a unique
alternative to tabs that allows palette-like interaction, but also
allows these secondary toolbars to be locked in place persistently,
which can be of great usefulness. Therefore, we needn't ask ourselves
"how does <this palette> look/work in the new toolbar design?" at all.
We should be asking "which of <these palettes>" would work better
functionally as a secondary toolbar?".

I think that Paint, for instance, would gain heaps of usability if the
colors were a secondary toolbar, and that were shown by default. That
doesn't mean that Write, for instance, necessarily needs to replace
the current color chooser palette. It's should be up to activities to
decide what parts of the UI are best suited to the two modes.

Both primary and secondary toolbars can have as many normal "palette
buttons" as desired.

> I guess one unanswered question is do you allow the stacking of more
> than 2 rows of toolbar... And, how much work is going to be needed on

This is something we tossed around a little bit while designing them.
I think the answer is no, personally, since it adds a lot more
complexity to the UI, and also begins to consume too much of the
screen. I'm hoping that [primary toolbars > secondary toolbars >
palettes] are sufficient for most use cases here; we don't want to
wind up with MS Word-like feature complexity!

That said, if we do support it, I think the rule is basically that
closing any parent toolbar hides all of its children, and reopening a
parent toolbar that had child toolbars open when it was last hidden
should reveal all those same children open as they were. But again,
I'd much rather just support one level of secondary toolbars.

> all the Activities if you start hand redesigning and customising each
> edge case. I think the current colour palette in Write would work as

Yup.

> is, at least that's how I was going to show it in a mockup, Activity
> bar -> text bar below -> existing drop down colour palette from its

One advantage of this design is that the primary toolbar is always
visible, and secondary toolbars can be shown or hidden as needed. The
mockups of Browse and Paint try to illustrate how useful this can be
in defining a set of "core tools" that are always—or nearly
always—applicable to interacting with the activity. In the case of
browse, the forward and back buttons, address bar, and bookmarking
button are always available in the primary toolbar. In Paint, some of
the core painting tools are surfaced.

So, the idea here is to define a primary toolbar which contains a) the
"core" set of tools/controls and b) toolbar buttons for the secondary
sets of tools/controls.

In the case of Write, I'd expect some of the basic text editing
controls (bold, italic, underline, font-size, font, for example) to be
surfaced in the primary toolbar, while tables, images, paragraph
formats, and other secondary features each had a secondary toolbar of
their own. In this way, it would be possible to reveal the table
controls, while retaining the basic text controls, which is clearly
quite useful since you can edit text within a table.

> icon.
>
>>> Maybe we should step through some of
>>> the activities and just remodel them to see what would work and
>>> find out
>>> about the edge cases (think gary is already working on that)
>>>
>>> b) API: we need a rock solid API. This is public API and will be
>>> used by
>>> all the activity authors, so very important to get this right - so
>>> we do
>>> not need to change it again afterwards
>>
>> So, we need activity authors use new toolbar in their activities
>> I guess they could add toolbar.py to activity project(like sugar-port)
>> if they want activities be runnable in <0.86 environment
>
> As an Activity author, this is what breaks my heart. 99.5% or more of
> our users will be unable to get the benefits of new Activity releases.
> That's real tough psychology, and very de-motivating for volunteer
> authors.

Yeah, that's a hard one to get around. We've had these designs since
the first release of Sugar, but there just wasn't time or resources to
make it happen. On a positive note, these new designs were developed
based directly on feedback from kids and teachers, and address a
number of issues that they found frustrating or confusing. Based on
the enthusiastic responses to the designs among all of you as well, I
think we're onto something good.

I wish I had some suggestions on how to avoid the backwards
compatibility problem, though...

Eben