[Sugar-devel] Initial implementation of toolbars design

[Simon Schampijer]

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.

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

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

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