I broadly agree with what Mirek is proposing, but FWIW here are my responses:
Ever since we've adopted the sidebar, we've had issues with duplicate
panels . 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.
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 , 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.
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.
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:
Sent from the Design mailing list archive at Nabble.com.
To unsubscribe e-mail to: firstname.lastname@example.org
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
- [libreoffice-design] Re: The Sidebar Problem (continued)
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy