[Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

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.

One alternative is to start activities with the activity toolbar shown
beneath the primary toolbar, but again that would mostly just serve
for naming. I hesitate to do this, since I'd much rather, again, allow
the activity to decide if it wants a secondary toolbar to be shown by
default. For instance, I think Paint should show the secondary color
selector toolbar by default, so that both colors and the basic drawing
tools are visible when entering the activity.
(http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11)

I think the current naming alert behavior is probably sufficient,
unless feedback indicates that it's not helping in practice.


> In any case, would be nice to sort this one out sooner then later. We want
> to push a first version on Thursday, that people can test the redesign out -
> ideally in class. Feature Freeze is approaching:
> http://wiki.sugarlabs.org/go/0.86/Roadmap#Schedule

OK, time is tight! Christian any thoughts?

>>> Can we get mockups for Browse? I would do the changes then there.
>>
>> We have them! Browse was the first activity I worked with when working
>> up the new toolbar designs. The activity icon I spoke of above is
>> notable absent from my early mockups, but that shouldn't have much of
>> an effect on things. Here they are:
>>
>> http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars
>
> Ok, cool. Do you have the scissor icon already? ;p

Yeah, I'll dig it up tonight when I get home.

Eben

>>> When doing testing we should maybe do tests for people that have used
>>> Sugar
>>> before already, and probands with no knowledge of Sugar at all.
>>>
>>> Regards,
>>>   Simon
>>>
>>> Btw: I was lost a bit with that the canvas is only shifted down when the
>>> toolbar is locked. But I guess it makes sense, in order to have not
>>> shifting
>>> the canvas down when you search for an option and pulling down the
>>> different
>>> toolbars. Not sure, yet.
>>
>> Yes, this is by design. The theory here is that it's possible to use
>> them like palettes, for occasional actions, without locking into place
>> and changing the canvas. I suppose the effect could be a little
>> strange when they become locked, but I'd suspect it would be even
>> stranger to have the canvas constantly shifting back and forth while
>> hovering over toolbar buttons.
>>
>> Eben
>
> Ok, sounds good then.
>
> Thanks,
>   Simon
>
>
>