Talk:Designs/Toolbars

Importance of a "Common" interface

I believe a lot of the success of the Apple personal computer came from the fact that Apple imposed a *single* interface that all applications had to adhere to. Once an user learned how to interact with one application, that knowlege could be applied towards interacting with the next application.

A number of the OLPC Activities have been "ported" from other platforms, and have brought their own (_not_ OLPC) toolbars with them. I realize that OLPC is very short of development resources. Nevertheless, I feel that OLPC should establish a "sugarization" group of developers, whose task it would be to "rework" those Activities which have their own toolbars - to use instead a "common" OLPC toolbar interface (and appearance).

By the way, I'm someone who is "scared off" by the multitudes of toolbar icons that some desktop drawing programs (and word-processing programs) provide. In my opinion, OLPC Activities ought to strive to simplify how many toolbar icons they show by default.

Sharing and Publishing Tools

Every activity should offer the ability to share the activity by: a) send email - subject automatically filled in, recipient remembered, content is link to current url b) submit activity to news channel - subject automatically filled in, content is link to current url c) publish activity to RSS/ATOM service - <description> automatically filled in, payload is as escaped html is link to current url

a 'current url' is automatically established - a possibility of sharing the current journal to email, news channel, RSS/ATOM

Changing the size of the non-toolbar widget(s) is bad

On sugar@/devel@, Gary pointed out that changing the size of the non-toolbar widget(s) will cause redraw events, and this will lower performance (tangent: will compositing change this cost?).

If redrawing/shifting the main widget(s) is the issue, and the un-shifted (original toolbar upon/within which the new toolbar button is situated) cannot be used at the same time as the extra toolbar strip, then one solution would be to obscure the (temporarily unusable) original toolbar strip with the extra toolbar strip. A bit like Apple's Sheets (Document Modal Dialogs), but only modal w.r.t. to the original toolbar.

MartinDengler 17:09, 25 March 2008 (EDT)

labels for extra toolbars icons

Someone already pointed this out in the sugar mailing list, but on this design, the extra toolbar icons have no labels, which doesn't happen anywhere else in Sugar. Even, like you said, if the icon and the options inside the toolbar make it clear what the toolbar is for, having a simple word to clear any doubts (or initial doubts) would be good. This will be even more important on activities with non-typical extra toolbars. Trying to decipher all of them from their icon, will be hard and will make it harder to get a general overview of the activity features (organization). You also can't expect everybody to refer to them as "the toolbar with the wavy icon","scisor", etc. all the time. But then again, I may be wrong! Right now, the names of menus of typical desktop applications don't always make sense, so getting rid of them takes away this defect of them (of the inability to perfectly categorize with simple labels all the features within). Oh, another idea. What if you reuse one of the icons of the extra toolbar for its "opener" icon? It would be a sort of "preview", or "sample" of the contents within the toolbar, and would eliminate the need to iconically represent loose categories. Just a thought, I don't know how workable would it be. It would mean, for example, that browse would use for its extra toolbar icons, a scissor and a magnifying glass. They could be confused as normal toolbar buttons... Perhaps a better indicator that they open toolbars would be best, rather than just the small arrow? - HoboPrimate 14:34, 29 March 2008 (EDT)