On 30 Jun 2009, at 00:32, Michael Stone wrote: -- big snip from old thread ---
>> - Better Anything toolbar filter palette (use a grid layout to >> minimise scrolling) > > How do you think > > http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars > > would work out here? An 'Anything' filter button opening a palette with a grid layout of filter options could work as is right now. It could be a relatively small and contained code change, for a relatively large improvement in usability. I guess (in Ebens toolbar mock-ups) a pop-up row could be filled with the same filter options, but it would need to cope with multi row layouts as the number of filter options grows over time (i.e. as more Activities are installed). More generally regarding the toolbar mock-ups, some points needing clarification: - Stop button must be visible at ALL times, none of these mock-ups show a stop - Activity collaboration control has disappeared, assume this should be a primary icon - No solution yet for textual names/labels (inventing unique and clear icons is going to get real tough, real fast, and many Activity authors already struggle creating decent activity icons). - Activity title has disappeared from toolbar is that intentional to rely on the naming dialogue every-time? Being Mr ActivityTeam at the moment, I do really worry about the amount of work this is going to be to get Activities updated and complying to a large toolbar redesign. Supporting both toolbar API styles will help, but I think we'll end up with multiple toolbar styles in different Activities for perhaps 6 months to a year or more. That's a bad backward step for usability. Just look at the amount of time/effort it is taking to migrate Activities over to SL infrastructure, let alone making anything but minor maintenance code changes to them. >> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) > > What do you think of Scott's journal2 design here? Technically? A massive redesign requiring a rock-star lead developer and a long-term commitment to refine, debug, and stabilise over several Sugar platform release cycles. There are nice ideas in there, I particularly like the idea of turning directory paths into tags as a way to access the file system. But, a much simpler option would be to let a user type something like "/usr/local/..." in the existing Journal search and have the Journal display a basic folders/files view, typing just "/" would show the root level and a user could navigate old school style from there. Copy/paste could be extended to move content between Journal/file-system views, and external devices could show the file-system view by default so a USB key or SD card could be more easily managed. Regards, --Gary _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel