Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

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:
Sent from the Design mailing list archive at

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.