[Sugar-devel] Initial implementation of toolbars design

[Gary C Martin]

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.

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.

Regards,
--Gary