[sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)

[Eben Eliason]

On Tue, Mar 25, 2008 at 4:20 PM, Nate Ridderman
<nate.ridderman at gmail.com> wrote:
> 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.

Thanks for bringing this up.  This is a secondary issue that we've
been tackling in conjunction with the new toolbar designs.  The main
reason that I don't see that it must be solved in conjunction with
this proposal is because, in the worst case, we can add an "activity
toolbar button" at the far left of the primary toolbar which contains
within it a place to keep, stop, name, tag, etc, just as we have now.

On the other hand, we have been contemplating the possibility of
removing this required element, instead attaching this functionality
to the palettes for the running activities in the top of the Frame.
This change would come with another, which would attempt to improve
titling/tagging/describing of activities by gently prompting for some
or all of this info *only* when a) the activity instance in question
is "new" (was just started from scratch) and b) it hasn't yet been
titled in another manner.  It's uncertain if this prompt would come as
a non-modal alert when starting the instance (which has the advantage
of giving something a title before it gets shared on the mesh), or as
a modal alert when stopping the activity it is hasn't yet been named.
In both instances, it would happen before an entry with a
non-meaningful title wound up in the Journal.

Thoughts are welcome on these issues as well.

>  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.

Well, referencing the original mockups for calculate (and I think the
more recent versions of the actual activity), you'll see that I
actually did use "text" buttons, though they were in a more graphical
forms than plain text.  I think that this will be fine in some
instances, on a case by case basis.  Calculate is one such example,
since "sin" and "cos" are more distinguishable than an image of a sin
wave with the phase shifted by PI/2.  Additionally, clicking these
buttons actually inserts the text shown on them into the calculation,
so using text makes sense.  I don't think, however, that resorting to
simple text-only buttons as a fallback is really something we should
be too willing to accept on this platform, which explicitly aims to
provide strong iconic visual cues for everything in the interface.

Localization of icons is another point, and one that isn't necessarily
exclusive to icons containing text.  It is, however, a simple thing to
do, as the path to the icon within the bundle can simply be localized
in the normal fashion.

>  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.

This is a fair observation, and one we've known would be hard for
some.  We hope that as an open source project there will be many
people (occasionally myself included) willing to offer up this type of
assistance when needed.  We do also hope to have a pretty good
collection of stock icons eventually.  Finally, knowing that this
would be a point of some difficulty, I created a python script for
assisting in the creation of proper sugar icons, and a wiki page with
a tutorial (not quite complete yet).  You can find more info here:
http://wiki.laptop.org/go/Making_Sugar_Icons.

Thanks for the feedback!

- Eben