I broadly agree with what Mirek is proposing, but FWIW here are my responses:
mirek2 wrote > Ever since we've adopted the sidebar, we've had issues with duplicate > panels [1]. Worse yet, the sidebar brings yet another UI element to look > through for commands. This might not sound like a big problem, but this > makes our already hard to use UI even harder to use, and is bound to get > worse as the sidebar develops. Completely agree. mirek2 wrote > My proposed solution would be to split the sidebar into individual panels > (e.g. Properties, Formulas, Custom Animation, Slide Transition, etc.) and > add buttons for launching them to the relevant toolbars. This would not > only solve the problems of panel duplication [1], but it would also add > context to the individual panels. For example, the Slide Layout and Slide > Transition buttons would appear in the Slide toolbar. Can you expand on this to provide clearer examples? I am not clear about how this "split" would visually appear i.e., one above the other? How would it work in UX terms? I cannot determine if this describes launching the entire display side-pane, upon selection, to a separate toolbar, or providing a launch button on each toolbar to make visible the related panel in the sidebar? Either option seems somewhat cluncky. If "launching them to the relevant toolbars" is a reference to having a new toolbar appear, then this could cause UX problems. I currently find contextual toolbars to contribute to poor UX, especially if anchored above the viewable area (canvas) as they move the canvas as they dis/appear. Clicking in/out of a table is the classic example, which is why I anchor this particular toolbar at the bottom of the window. Toolbars and the sidebar should /never/ move the canvas. I realise this is a potentially separate issue (depending on the type of behaviour being suggested), but I would not like to see it become worse. A constant launching/retrieving type of behaviour based on toolbar clicks that expanded the sidebar and adjusted the canvas would be just as bad as the current contextual toolbar dis/appearance. I mention this for clarity. mirek2 wrote > In any case, it's imperative that we do something about the problem. We > can't afford to dig ourselves even further in terms of UX. Again, agreed. Rafael Rocha Daud wrote > Gimp's sidebar has been there for ages, and it's contextual and it has > tons of properties and settings you can control from there. I think Inkscape is a better example. If this is the type of behaviour Mirek is referring to then I am more enthusiastic. It would be nice if the key combinations to display a panel (e.g., SHIFT+CTRL+L to display the Layers panel in Inkscape) cycled through a launch/iconify/retrieve type of behaviour. This does not appear to be possible in Inkscape (it only launches). Mirek, is the iconfy button in Inkscape related to the behaviour you are suggesting? Best wishes, Owen. -- View this message in context: http://nabble.documentfoundation.org/The-Sidebar-Problem-tp4094331p4094869.html Sent from the Design mailing list archive at Nabble.com. -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
