On Tue, Jul 28, 2009 at 10:12 PM, Gary C Martin<g...@garycmartin.com> wrote: > On 28 Jul 2009, at 19:03, Eben Eliason wrote: > >> On Tue, Jul 28, 2009 at 12:07 PM, Simon Schampijer<si...@schampijer.de> >> wrote: >>> >>> On 07/28/2009 03:48 PM, Eben Eliason wrote: >>>> >>>> On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijer<si...@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).
I'm not sure that's entirely true. I think keeping the "generic" activity functions all in one place, separate from the primary toolbar, makes it easiest for developers to use the primary toolbar to their greatest benefit. I don't think there needs to be any rules requiring specific feature sets to be present in the primary toolbar—some developers may well choose to place solely toolbar buttons in the primary toolbar; Others may choose to place basic controls there as appropriate. An example of the former kind might be write (or any activity with lots of tabs). Browse (and perhaps even paint), on the other hand are examples which clearly illustrate the benefits of keeping primary controls in the primary toolbar. First, it means that they are exposed up front, and second it means that they can be used in combination with other sets of secondary tools. In Browse, it remains possible to navigate the web even if you want to have edit or view controls visible. In paint, it's possible to change the drawing tool while also keeping a palette of colors available. This choice should be seen as a benefit, not a burden. > 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. Another point here is that we really wanted secondary toolbars to be essentially optional in most activities. That is, the primary toolbar would be plenty for "basic usage" (for some definition of that term). Obviously, as you mention, there is a tradeoff between the amount of primary tools and the amount of secondary toolbars that can be shown, but there's only so much room after all. If the primary toolbar contains only toolbar buttons, the secondary toolbars are always required and consume more screen real estate than the old tab design. In practice, we noticed that many activities (and Write is a clear exception here) made use of only one, or perhaps two toolbars in addition to the activity toolbar. Many such activities won't have a problem defining primary controls just one or two toolbar buttons for supplementary functionality. But again, there is choice. If filling the primary toolbar with toolbar buttons only is the best fit for the activity, then that's certainly fine. > 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. Simon, I forgot to dig up the scissors. Sorry! I'll definitely find it for you tonight. Eben _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel