[Sugar-devel] [DESIGN] Web: subtoolbars or palettes?

[Manuel Quiñones]

For Sugar Web, I would like to revisit subtoolbars, considering the
usage in GTK activities and the nature of the web.

In GTK we have to deal with two issues:

- toolbars allow a limited amount of buttons
- the subtoolbar shrinks the canvas when it is triggered

The first one is specially bad in vertical screen, aka portrait mode.
The second one can be handled, but I saw activities like Paint dealing
with it.  Having your work area shrinking and expanding all the time
is not fun.

And I'll add a personal opinion here: I think many controls around
make the activity look too complex.  Toolbars were a great discovery
in UI, but soon the idea distorted and went overused.  See Microsoft
Office 98 for a bad example.  We need to provide a clean view to the
user, make only the important items visible, hide the advanced
options, and let the user find them through discovery.

So I was wondering if palettes could be the general solution for
controls.  This is aligned to what I see in android and ipad apps.  I
think custom palettes was a limitation in GTK, but in web we can add
more powerful palettes to our toolkit.  For a good example of powerful
palettes, see CScott Nell Colors activity:

http://cscott.github.io/nell-colors

One contra regarding palettes is that they can occlude the canvas.
For example, in Measure Activity you want to see how the wave changes
while you tweak controls.  I think in this cases, the controls should
be moved to the main toolbar or to the cavas itself.

I discussed this with Lionel and Suraj, and the latter is already
working on an Activity Palette that contains the title and description
entries.  But I wanted to open a design discussion.  Comments?

Lastly, an implementation detail.  There are important differences in
how GTK layouts widgets, compared with the web.  In web apps, the
layout tends to be scroll-oriented.  In windowed apps like the GTK
activities, the layout tends to be window-oriented.  I mean: if you
add a Gtk.Box with buttons inside to a Gtk.Window, you end with an
array of buttons covering the window.  Instead, if you add <div> tags
with <button> tags inside an html page, you end with those buttons in
the corner of the page.  To make the elements fit the canvas while it
shrinks and expands activities, we need to do the maths in the
Javascript code.  I mean, is not following the nature of the medium.

--
.. manuq ..