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