[Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Tue, Jul 28, 2009 at 10:12 PM, Gary C Martin<gary at garycmartin.com> wrote:
> On 28 Jul 2009, at 19:03, Eben Eliason wrote:
>
>> On Tue, Jul 28, 2009 at 12:07 PM, Simon Schampijer<simon at schampijer.de>
>> wrote:
>>>
>>> On 07/28/2009 03:48 PM, Eben Eliason wrote:
>>>>
>>>> On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijer<simon at schampijer.de>
>>>>  wrote:
>>>>>
>>>>> On 07/18/2009 04:17 AM, Gary C Martin wrote:
>>>>>>
>>>>>> Hi Caroline,
>>>>>>
>>>>>> On 17 Jul 2009, at 22:14, Caroline Meeks wrote:
>>>>>>
>>>>>>> We can put it in front of actual kids once you get a sample working.
>>>>>>> We could even try playing the video for our existing classes. I don't
>>>>>>> know if they'll be able to give you feedback from just seeing the
>>>>>>> video. Might be interesting to find out.
>>>>>>
>>>>>> Yes that's an interesting one... I have more understanding of
>>>>>> usability
>>>>>> studies with literate adults, where you can have a controlled
>>>>>> environment. With the idea that you set goals/tasks to be completed
>>>>>> with
>>>>>> the interface and ask the user to vocalise what they think they are
>>>>>> doing ("I'm clicking this because I think it's the search button...").
>>>>>> You only interact with them once they are clearly stuck, to help them
>>>>>> get back on track. Asking for any-ones opinion is usually frowned upon
>>>>>> in usability studies, as opinion is almost always different from
>>>>>> actual
>>>>>> behaviour – but some opinions are better than nothing, which is why I
>>>>>> keep asking :-)
>>>>>>
>>>>>> Perhaps I should work with Walter and Aleksey's initial toolbar code
>>>>>> and
>>>>>> make an identical test clone of TA but with the new toolbar design (I
>>>>>> can use Aleksey's Write mock-up code as an example)? Then you could
>>>>>> let
>>>>>> the class (or a random selection of the class) use it for some tasks
>>>>>> and
>>>>>> watch how well (or not) they manage with the new interface?
>>>>>>
>>>>>> Simon: have you used TA yet in your lessons?
>>>>>
>>>>> Yes, the problem is, that I won't get into class before September again
>>>>> -
>>>>> we
>>>>> have summer holidays :/
>>>>>
>>>>> About the design - as already noted, the current implementation does
>>>>> not
>>>>> match gary's mockups. I think the mockups are more consistent in using
>>>>> icons
>>>>> in the primary toolbar. Having the text entry field (activity name)
>>>>> present,
>>>>> could help the users that know Sugar already. They would not feel that
>>>>> much
>>>>> lost.
>>>>
>>>> I think that the title, sharing, keep, and other buttons (perhaps with
>>>> the exception of stop, since I know many want this on the primary
>>>> toolbar...) should live inside a secondary "activity toolbar", in much
>>>> the same way we have an activity tab now. The icon for the activity
>>>> toolbar would be the activity icon itself, colored, and always placed
>>>> at the far left of the primary toolbar.
>>>>
>>>> The primary reasons for this are 1) consistency across activities and
>>>> 2) saving space in the primary toolbar for the activity itself.
>>>
>>> Hmm, giving a title could be seen as a "first class" action. We want the
>>> user to give a title (naming alert), so it can be found more easily in
>>> the
>>> journal. Maybe this should be in the top toolbar as well? I know this has
>>> issues space wise.
>>
>> It's true, but those buttons consume a lot of valuable real estate in
>> the primary toolbar, and the user is unlikely to name or share more
>> than once, and should never really need to keep manually. That means
>> that about half of the ever-present controls shown aren't important
>> for regular use of the activity.
>
> With my ActivityTeam hat on; you do realise this is the option requiring the
> most rework for authors and maintainers? It puts them/us back in the hot
> seat task for re-designing the toolbar layouts fairly extensively (at least
> for any non trivial cases).

I'm not sure that's entirely true. I think keeping the "generic"
activity functions all in one place, separate from the primary
toolbar, makes it easiest for developers to use the primary toolbar to
their greatest benefit. I don't think there needs to be any rules
requiring specific feature sets to be present in the primary
toolbar—some developers may well choose to place solely toolbar
buttons in the primary toolbar; Others may choose to place basic
controls there as appropriate.

An example of the former kind might be write (or any activity with
lots of tabs). Browse (and perhaps even paint), on the other hand are
examples which clearly illustrate the benefits of keeping primary
controls in the primary toolbar. First, it means that they are exposed
up front, and second it means that they can be used in combination
with other sets of secondary tools. In Browse, it remains possible to
navigate the web even if you want to have edit or view controls
visible. In paint, it's possible to change the drawing tool while also
keeping a palette of colors available.

This choice should be seen as a benefit, not a burden.

> But glad this is finally being discussed, it was pretty much the first
> feedback I was after, and Aleksey also I think – his Write toolbar test was
> closer to your original designs, but didn't manage to get all the buttons in
> ;-b
>
> FWIW: Picking the top level tool set is going to be a real tough call in a
> number of cases as we loose toolbar space for each extra tab, plus the
> activity icon on far left (essential for Activity recognition), plus the
> stop icon on far right (essential, no questions, no doubts). The features
> that actually fit in the remaining space may seem quite an arbitrary
> hotchpotch.

Another point here is that we really wanted secondary toolbars to be
essentially optional in most activities. That is, the primary toolbar
would be plenty for "basic usage" (for some definition of that term).
Obviously, as you mention, there is a tradeoff between the amount of
primary tools and the amount of secondary toolbars that can be shown,
but there's only so much room after all.

If the primary toolbar contains only toolbar buttons, the secondary
toolbars are always required and consume more screen real estate than
the old tab design. In practice, we noticed that many activities (and
Write is a clear exception here) made use of only one, or perhaps two
toolbars in addition to the activity toolbar. Many such activities
won't have a problem defining primary controls just one or two toolbar
buttons for supplementary functionality.

But again, there is choice. If filling the primary toolbar with
toolbar buttons only is the best fit for the activity, then that's
certainly fine.

> Simon: I'd started on the Browse mock-up, do you need me to continue (I
> though my tabs to icons process was pretty transparent, requiring close to
> zero redesign of existing tool layouts, other than some new svg's for the
> replacement buttons)? Happy to continue, could post later tomorrow if that
> helps the decision process.

Simon, I forgot to dig up the scissors. Sorry! I'll definitely find it
for you tonight.

Eben