Eben, By no means do I consider myself a user interface expert, but I have a few comments. In general, I agree that this proposal is better for localization and may take up less screen real estate. Would there still be default buttons to share, keep, and/or stop the activity? I believe it's important to have an easy way to stop the current activity, but maybe you have this accounted for elsewhere in the frame redesign. I haven't had a chance to build and test Tomeu's branches yet. It looked like activities could be stopped from the frame, but no preference was given to the current activity.  I'm not sure if this is convenient enough. If a stop button is required, and perhaps a share button and a keep button, this will eat up space and require most activities to use a secondary toolbar. Another concern would be porting an activity like Calculate that has numerous tabs of text based buttons. It's reasonable to create graphical icons for the tabs (Edit, Algebra, Trig, Booleans, Constants, Format) but not for some of the actual buttons (sin, cos, tan, asin, acos, atan, sinh, cosh, tanh) Are you proposing that all text should be removed from the toolbar or is it acceptable to have some text based icons? If text based icons are allowed, do we need the option of localizing them? I'm not sure, for example, how trigonometric functions are represented in other languages. Finally, this requires someone with good graphical design skills to create icons for complex activities that can't just reuse the template icons. My point is that it's easy for programmers to create text based buttons, but graphical ones will require more (and a different kind of) work. Thanks, Nate <div class="gmail_quote">On Tue, Mar 25, 2008 at 10:47 AM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 <a href="http://wiki.laptop.org/go/Designs/Toolbars" target="_blank">http://wiki.laptop.org/go/Designs/Toolbars</a>.  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 <a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a> <a href="http://lists.laptop.org/listinfo/sugar" target="_blank">http://lists.laptop.org/listinfo/sugar</a> </blockquote></div>