On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijer<si...@schampijer.de> wrote: > On 07/29/2009 07:03 PM, Gary C Martin wrote: >> >> Hi Simon, >> >> On 29 Jul 2009, at 08:55, Simon Schampijer wrote: >> >>>> 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? >> >> Sorry if that wasn't clear. Activity icon and stop icon are essential. >> The Activity icon is going to be critical for identifying what activity >> you are in at a glance, especially if the actual title name is hidden >> away in a sub toolbar. A downside if we loose the title in the primary >> toolbar is reinforcement of knowing what activity you are in (say you >> are copy/pasting between two similar Write documents)... > > Ok, thanks for the explanation. The differentiation of the running instance > of two activities of the same type is a good point. But, does this happen > often? I guess many kids will run one activity of each type at a time, and > remember performance constraints ;p And one can use the frame to distinguish > the activities. > > Personally, I see more the issue of naming an activity, since as said in > another post I am not really convinced about the naming alert.
I'll have to think about this idea more, but: we could also have the naming "alert" appear as a palette attached to the stop button, instead. It doesn't change the behavior too much (it requires 2 clicks to stop an activity for the first time if it hasn't been named), but the use of the palette might feel more consistent with Sugar in general. On the other hand, it could be strange to change the behavior of the stop button between the first and other cases. > One little thing I am a bit worried about, is that we miss labels for the > sub-toolbars. I hope the icons are meaningful enough for the users - but > then labels can be misleading as well, and many of our users can't possibly > read. Yes, we had some thoughts. We'll hash it out some more. > About alignment (attached is a snapshot), should we align the 'share button' > and the 'keep one' to the left that the way to get to this button is not so > long, when revealing the toolbar? I think we should be thinking about this in the general case. Sometimes one will need to reach the other end to reach controls (and (though not for the activity toolbar) this depends on where the toolbar button sits within the primary toolbar). We should make sure that the palette behavior works well in these instances. For instance, it shouldn't disappear immediately on mouse-leave. Perhaps the delay should be longer than for normal palettes, due to their peculiar dimensions. That said, I'd be fine with aligning these buttons to the left in this instance. Eben PS a few notes on the design: 1. Is this screenshot showing the hover state of the toolbar button with the toolbar already locked in? If not, the small arrow beneath the activity icon should still be pointed downwards, to indicate that clicking on the button will lock it into place. It should appear pointing upward only when already locked in. 2. We should fix the style for the text entry so it appears correctly on black backgrounds. 3. I'll get you those scissors tonight, for real this time. Also, can we change the arrow to match those in the mockups? The one shown here competes with the icons themselves. 4. But these are nitpicks. Fantastic work!! > Thanks, > Simon > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
