[Sugar-devel] Initial implementation of toolbars design

[Tomeu Vizoso]

On Sat, Jul 11, 2009 at 16:53, Eben Eliason<eben at laptop.org> wrote:
> 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...

I think that Aleksey's sugar-port addresses well that problem. The
downside is that when someone files a bug for an activity, we won't
know at first if the activity was running code in a copy of sugar-port
or in sugar-toolkit, but well... Perhaps sugar-toolkit should be
maintained by the Activity Team, so they can make these decisions with
more knowledge of cause.

Regards,

Tomeu

> Eben
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>