A lot of thought has gone into the present tabbed toolbar design, with goals of balancing valuable screen real estate with extensibility of the design. Still, we've come to find some drawbacks with the current design, including the sole use of text (which is secondary to icons in the rest of the UI), the smaller height of the buttons which can make them harder for children to click on, and the fact that, despite the smaller height which was designed to save screen real estate, many activities with few tabs may find them to be wasteful of space.
Taking these concerns to heart, I'd like to propose an alternate to the tabbed toolbar design which attempts to address these new concerns with the current design, again making some tradeoffs but hopefully coming out on top in the end. The core component of the new approach is the introduction of the "toolbar button", which you can see mockups of at http://wiki.laptop.org/go/Designs/Toolbars. There is no text with the mockups yet, but I'll add it later. In the meantime, please consider the following advantages: 1. Toolbar buttons use icons instead of text as an identifier. Beyond the icon, we depend on the content of the toolbar to help define the tab, with a textual name being superfluous. This makes localization easier (well, free) and prevents text from being cut off in due to translation. Toolbar buttons will reveal their toolbars temporarily on rollover, as palettes do, allowing one to preview the content of a toolbar without toggling it on, for discovery. OLPC will include icons for a handful of common secondary toolbars in artwork for developers to use. 2. Toolbar buttons are the size and shape of other buttons in the UI, giving them a larger target area and making them easier to click on. 3. Rather than residing in a secondary region solely for tabs, toolbar buttons are first class citizens in toolbars; when clicked, they reveal a second tier toolbar beneath the first, visually attached to the toolbar button. For activities that have few toolbars, this offers the advantage of providing space for a "basic control set" in the main toolbar, in addition to several auxiliary toolbars which can be shown in conjunction with the primary toolbar, only when needed. 4. When a given activity needs only a few toolbars, this design saves screen space during normal use of the activity. A good example is Browse, which needs some basic edit and view controls to remain available, but certainly not at all times during normal use. Here we save space for the content by eliminating the "tab bar". This is a tradeoff, though: advanced activities with many tabs may require the primary toolbar to contain solely toolbar buttons, with the second tier toolbar becoming the place where all the actual controls live. In these cases, we lose a small amount of screen space (30px, vertically, to be exact). 5. As a slight upside to the aforementioned tradeoff, the iconic design of the toolbar buttons allows for up to twice as many toolbars as the previous design, providing more extensibility in activities that really need the space. Naturally, we expect the majority of activities to be in the class which actually benefits from (4), having only a few toolbars, and the HIG will still recommend against bloat. Nonetheless, we think that the added extensibility is a plus. As this is an issue that effects every developer, I think that the mini-conference provides a fine opportunity to expose these ideas and discuss the pros and cons of the approach to come to a final decision on our direction. Thanks! - Eben _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar