[Sugar-devel] Initial implementation of toolbars design

[Simon Schampijer]

On 07/28/2009 08:03 PM, 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.

Agreed, about the space issue.

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

Agreed here as well. I think we do not want to show the activity toolbar 
by default. For some activities it might make sense to show a specific 
toolbar by default though.

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

Just because this comes up here: from my little experience in class the 
following happens when I tell the kids to close an activity (first hours 
of using sugar):
- find the stop button (we solve this with the toolbar redesign)
- what is this popup about? You have to explain that they can give a 
name for their activity instance there,
explain what the Journal is etc. None of my kids gave a name in the 
dialog :)

So the encouraging of giving a title did not really work in my cases. I 
postulate that giving good titles and tags is a second class action. Not 
something the kids do in their first Sugar hours. If they start to care 
- they do it in the activity (btw their is a bit of space in the 
activity toolbar now, maybe one can add a widget to add tags their) or 
in the Journal itself. I know the dialog is only triggered when not 
resuming an activity or the (title != default), but I was more annoyed 
in practice by the alert popping up so far :/

>> 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?
>
>> Ok, cool. Do you have the scissor icon already? ;p
>
> Yeah, I'll dig it up tonight when I get home.

Cool, thanks.

    Simon