[Sugar-devel] Initial implementation of toolbars design

Simon Schampijer simon at schampijer.de
Wed Jul 29 03:55:05 EDT 2009


On 07/29/2009 04:12 AM, Gary C Martin 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).

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

Gary, I am not sure I get your arguments right :/ Can you elaborate? 
What I conclude of all the answers, I think that space in the primary 
toolbar is an issue. So we need to decide what to put there. Does 
activity icon and stop icon sounds good to you as well?

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

Ok, it works out for me, thanks. I used the mockups from Eben 
(http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11) and added 
the activity toolbar on the left and the stop button on the right.

Icons:

view: I found device/camera.svg in sugar-artwork. I guess we can use it 
for the edit toolbar. It looks maybe a bit small next to the stop button.

edit: would be nice to get the scissor icon in artwork. As I understood 
Eben has one laying around already.

Thanks,
    Simon


More information about the Sugar-devel mailing list