[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[libreoffice-design] Re: The Sidebar Problem
- Subject: [libreoffice-design] Re: The Sidebar Problem
- From: Owen Genat <firstname.lastname@example.org>
- Date: Fri, 31 Jan 2014 04:57:07 -0800 (PST)
- To: email@example.com
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: http://nabble.documentfoundation.org/The-Sidebar-Problem-tp4094331p4094869.html
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] The Sidebar Problem||"Mirek M." <email@example.com>|
- Prev by Date: [libreoffice-design] Re: [libreoffice-marketing] Urgent need for a design before Tuesday
- Next by Date: Re: [libreoffice-design] Re: Website Redesign - Beta
- Previous by thread: [libreoffice-design] Re: The Sidebar Problem
- Next by thread: Re: [libreoffice-design] The Sidebar Problem