Talk:Designs/Toolbars: Difference between revisions
(Changing the size of the non-toolbar widget(s) is bad) |
|||
| Line 15: | Line 15: | ||
a 'current url' is automatically established - a possibility of sharing the current journal to email, news channel, RSS/ATOM |
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 ([http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_18_section_7.html#//apple_ref/doc/uid/20000961-CJECBHJE Document Modal Dialogs]), but only modal w.r.t. to the original toolbar. |
|||
Revision as of 21:09, 25 March 2008
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.