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

Gonzalo Odiard gonzalo at laptop.org
Tue Jun 25 21:09:40 EDT 2013


I don't know if we need replace the subtoolbars,
but I think should be good re evaluate the need of the use of timeuts
to open/close the subtoolbars when hover.
In fact, that does not works with touch devices,
and do code more complicate in places, like when interact with drag and
drop
in the journal.

Gonzalo


On Tue, Jun 25, 2013 at 4:37 PM, Manuel Quiñones <manuq at laptop.org> wrote:

> 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 ..
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130625/8ba19d43/attachment-0001.html>


More information about the Sugar-devel mailing list