Bug 116298 - Hide/Show grips of Sidebar decks are too intrusive
Summary: Hide/Show grips of Sidebar decks are too intrusive
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Sidebar-UI-UX
  Show dependency treegraph
 
Reported: 2018-03-08 19:33 UTC by Rainer Fiebig
Modified: 2018-08-16 10:46 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
LO_545_screenshot (77.94 KB, image/jpeg)
2018-03-08 20:47 UTC, Rainer Fiebig
Details
LO_545-screenshot, xfce (73.67 KB, image/jpeg)
2018-03-09 09:02 UTC, Rainer Fiebig
Details
Screenshot with GTK VCL plugin for reference (68.82 KB, image/png)
2018-03-09 15:13 UTC, Aron Budea
Details
LO_5.3.7.2_sidebar_buttons (75.47 KB, image/jpeg)
2018-03-09 16:19 UTC, Rainer Fiebig
Details
LO 4.3 screenshot (107.69 KB, image/jpeg)
2018-03-10 09:30 UTC, Rainer Fiebig
Details
LO 5.4: cut-out of left side-bar (2.35 KB, image/jpeg)
2018-03-10 09:32 UTC, Rainer Fiebig
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Fiebig 2018-03-08 19:33:56 UTC
Description:
Hi!

Thanks for your work and the great progress LO has made over time in so many ways.

There's one thing however, that is really annoying and almost drives me mad each time I try a new version: it's the buttons/markers for opening/closing the side-panels (Navigator/formatting). 

While it was right to make them more visible than in the early versions, you unfortunately went to the other extreme. Now they are so intrusive, distracting and un-elegant - it's really a pain in the eye! They make LO virtually un-usable for me. Put another way: this seemingly little detail is a big obstacle for me to use and recommend LO. 

Please correct this visual-design-gaffe asap - in the interest of the whole project. And please let someone do it who's got a feeling for things like that. 

If you don't want to do it, please let me know where to look in the source - I'll do it myself then.

Thanks!

Rainer Fiebig

Actual Results:  
Obvious.

Expected Results:
Obvious.


Reproducible: Always


User Profile Reset: No



Additional Info:
Obvious.


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1
Comment 1 Aron Budea 2018-03-08 19:58:33 UTC
Hi! What exactly is the problem? The sidebar buttons for the different decks haven't changed. Can you attach a screenshot?
Comment 2 Rainer Fiebig 2018-03-08 20:47:14 UTC
Created attachment 140488 [details]
LO_545_screenshot

The sidebar-buttons (black rectangles on the left and right) are very distracting.
Comment 3 Rainer Fiebig 2018-03-08 20:56:18 UTC
I hope the screenshot speaks for itself.

The sidebar-buttons are not so important to give them this extreme visual weight. I find this very distracting and - in lack of a better description - un-pleasant.

And it really destroys the overall good visual appearance.
Comment 4 V Stuart Foote 2018-03-08 23:45:26 UTC
Those are the Hide / Show vertical grips to collapse or expose the Sidebar. They are sensitive to selection state (i.e. mouseover or clicked), but actually pull colors from your OS and Desktop Environment (DE) theme.

You look to have some odd DE in place, using Galaxy icons set--but to each their own.

Fix your DE theme, you control it. Otherwise close the Sidebar 

Deselect View -> Sidbar, or use the Sidebar's Close Sidebar button action.
Comment 5 Rainer Fiebig 2018-03-09 09:00:13 UTC
(In reply to V Stuart Foote from comment #4)
> Those are the Hide / Show vertical grips to collapse or expose the Sidebar.
> They are sensitive to selection state (i.e. mouseover or clicked), but
> actually pull colors from your OS and Desktop Environment (DE) theme.
> 
> You look to have some odd DE in place, using Galaxy icons set--but to each
> their own.
> 
The DEs are not "odd" but pretty fine: KDE and xfce. LO is used *with* KDE-integration.
> Fix your DE theme, you control it. Otherwise close the Sidebar 
> 
It's not the DE theme(s) that need to be fixed. All other apps look fine - whether run under KDE or xfce. This is an LO-only problem.

I've added a second screenshot - this one taken under xfce with a different color-theme and different icon-set (to please you). Venture a look. And if you still think this is OK, your'e either blind or don't you know how to fix it.

> Deselect View -> Sidbar, or use the Sidebar's Close Sidebar button action.
Yeah - the easy way out. But to me that's not an option. I know a better one.

Final tips for you: 
1) Customers/users always have choices.
2) Those who complain (better: give feedback) are only the tip of the iceberg. And those who take the time to file a bug-report are probably the tip of the tip of the iceberg.
3) Word of mouth is a powerful marketing-tool.
Comment 6 Rainer Fiebig 2018-03-09 09:02:54 UTC
Created attachment 140496 [details]
LO_545-screenshot, xfce
Comment 7 Aron Budea 2018-03-09 15:13:26 UTC
Created attachment 140507 [details]
Screenshot with GTK VCL plugin for reference

To be clear about the expectations, would you find a less intrusive color suitable, ie. as in the screenshot?

I think the problem could be that the handle uses inverse colors for when the mouse is over it compared to when it isn't, and the basic colors with "gen" VCL plugin has black for the arrowhead, maybe it's the same issue with KDE VCL plugin.

Note that LO can be started with different VCL plugins by setting the environment variable like this: SAL_USE_VCLPLUGIN=gen
The different options are: gen, kde4, gtk, gtk3
Possibly not all will work in an installation, but gen is always there as basis.

The current logic was implemented in the following commit for 5.0:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=b951771244d511c140a7c84181a1e160d9ef97c1
Comment 8 Rainer Fiebig 2018-03-09 16:18:01 UTC
(In reply to Aron Budea from comment #7)
> Created attachment 140507 [details]
> Screenshot with GTK VCL plugin for reference
> 
> To be clear about the expectations, would you find a less intrusive color
> suitable, ie. as in the screenshot?
Thanks for your constructive answer!

Surely a less intense color would be better. I have added another screenshot with LO 5.3.7.2 where the problem is not so big as the color of the grips better matches the theme and the contrast is not that stark.

But I also think that an even better balance can be found between visibility (one knows where the grips are) and usability (they don't distract/irritate). 
> 
> I think the problem could be that the handle uses inverse colors for when
> the mouse is over it compared to when it isn't, and the basic colors with
> "gen" VCL plugin has black for the arrowhead, maybe it's the same issue with
> KDE VCL plugin.
> 
> Note that LO can be started with different VCL plugins by setting the
> environment variable like this: SAL_USE_VCLPLUGIN=gen
> The different options are: gen, kde4, gtk, gtk3
> Possibly not all will work in an installation, but gen is always there as
> basis.
> 
> The current logic was implemented in the following commit for 5.0:
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=b951771244d511c140a7c84181a1e160d9ef97c1

Thanks for the info. I'll try your suggestions when I find time and report back.

So long!
Comment 9 Rainer Fiebig 2018-03-09 16:19:39 UTC
Created attachment 140513 [details]
LO_5.3.7.2_sidebar_buttons
Comment 10 Rainer Fiebig 2018-03-10 09:30:41 UTC
Created attachment 140537 [details]
LO 4.3 screenshot


OK, found an older version in a VM and added a screenshot of LO 4.3. While admittedly not optimal, the handles there are 10 times better than the current solution - with respect to aesthetics *and* usability.

And just as an aside: the black rectangle of the current left handle is wider than the border of the side-bar (see other screenshot). Any graphics-designer worth his money would agree that this is completely unacceptable and amateurish. Nothing like that would have survived even the early stages of a professional review-process.

So, my recommendation is: 
1) revert commit b951771244d511c140a7c84181a1e160d9ef97c1 asap - that would be an instant and very relevant improvement for LO

2) if you are absolutely sure (preferably from user-feedback) that you *really* have to enhance the visibility of the handles, involve a graphics-designer and take time to find a good solution - another blunder would be devastating

Don't treat this issue lightly. From a marketing point of view things like that can make or break a product. And if I were in charge of LO, reverting that commit and call a graphics-designer would be the first thing I would do in the first hour of the first day in the office. ;)

So long and good luck!
Comment 11 Rainer Fiebig 2018-03-10 09:32:19 UTC
Created attachment 140538 [details]
LO 5.4: cut-out of left side-bar
Comment 12 Aron Budea 2018-03-10 10:22:48 UTC
(In reply to Rainer Fiebig from comment #10)
> OK, found an older version in a VM and added a screenshot of LO 4.3. While
> admittedly not optimal, the handles there are 10 times better than the
> current solution - with respect to aesthetics *and* usability.

Try to see how noticeable the handles are in the old version when the sidebar is completely closed (bug 83527 was about that, and that's why it's been changed). 

But let's not argue about that, the point here is the difference in the handle's background color between attachment 140513 [details] (5.3.7) and attachment 140488 [details] (5.4.5).
Comment 13 Rainer Fiebig 2018-03-10 12:11:40 UTC
(In reply to Aron Budea from comment #12)
> (In reply to Rainer Fiebig from comment #10)
> > OK, found an older version in a VM and added a screenshot of LO 4.3. While
> > admittedly not optimal, the handles there are 10 times better than the
> > current solution - with respect to aesthetics *and* usability.
> 
> Try to see how noticeable the handles are in the old version when the
> sidebar is completely closed (bug 83527 was about that, and that's why it's
> been changed). 
I said they are not optimal. But once you know where they are, you find them if needed. And in the meantime you don't notice them. Good!

They don't need to be and must not be "in your face" all the time: an indicator is enough. The handles are in the middle of the window, not at the edge. Which means: exactly where you look when you work on a document. And this makes them so distracting in their current form. Put another way: you've got *eye-catchers* where you don't want them.
> 
> But let's not argue about that,
I disagree. That bug-report is obviously at the heart of the matter. The headline sets people on the wrong track. It focuses them on "color" instead of "visibility". Imagine this headline: 

"Enhance visibility of sidebar buttons"

This opens a whole world of other possibilities than just "color".

> the point here is the difference in the
> handle's background color between attachment 140513 [details] (5.3.7) and
> attachment 140488 [details] (5.4.5).
Sorry, that's *not* the point. The point is that it's bad and ugly. And whether it's bad and ugly or somewhat *less* bad and ugly is irrelevant. Reminds me of line in a Huey Lewis song: "... sometimes bad is bad".

But I think we have reached a point where further discussion is a waste of time. You now either see what's obvious or not. In the latter case, I can't help it.

Thanks for your time and kind regards!
Comment 14 V Stuart Foote 2018-03-10 16:49:16 UTC
Of course, always some potential to change the visuals of the grips as implemented by Tomaž in solving bug 83527.  Use of a single full width triangle pointer in 7px x 72px size and using the "DarkShadowColor" for fill of the grip  (as extracted from DE theme in use) remains IMHO the correct choice cross platform and especially for our HiDPI scaling needs. Not sure an alternative shading/color drawn from DE theme is possible.

But, OPs use case of a Navigator (F5) docked left with its width extended, places its "Hide/Show" grip into center of view. And I do think we can do something to remove that visual noise. Near term we should remove the grips from the "temporary [1]" 2nd Navigator deck (linked to its F5 toggle).

Longer term  do we even need include the "Hide/Show" grips when implementing detached Sidebar decks (bug 85905)? Probably not. 

Samuel, Tomaž?

=-ref-=
[1] as worked out in bug 73151, F5 will continue to control a 2nd detached Navigator (using the Sidebar deck/content panels structure) to support having Navigator and Style decks visible at the same time.
Comment 15 Rainer Fiebig 2018-03-11 11:16:18 UTC
(In reply to V Stuart Foote from comment #14)
> Of course, always some potential to change the visuals of the grips as
> implemented by Tomaž in solving bug 83527.  Use of a single full width
> triangle pointer in 7px x 72px size and using the "DarkShadowColor" for fill
> of the grip  (as extracted from DE theme in use) remains IMHO the correct
> choice cross platform and especially for our HiDPI scaling needs. Not sure
> an alternative shading/color drawn from DE theme is possible.
> 
> But, OPs use case of a Navigator (F5) docked left with its width extended,
> places its "Hide/Show" grip into center of view. And I do think we can do
> something to remove that visual noise. Near term we should remove the grips
> from the "temporary [1]" 2nd Navigator deck (linked to its F5 toggle).
> 
> Longer term  do we even need include the "Hide/Show" grips when implementing
> detached Sidebar decks (bug 85905)? Probably not. 
> 
> Samuel, Tomaž?
> 
> =-ref-=
> [1] as worked out in bug 73151, F5 will continue to control a 2nd detached
> Navigator (using the Sidebar deck/content panels structure) to support
> having Navigator and Style decks visible at the same time.

Thanks, sounds promising.

For me, keeping the triangle as an indicator and giving up the dark-colored rectangle would be a major improvement.
Comment 16 Heiko Tietze 2018-03-19 16:15:45 UTC
Not a fan of these controls too we should keep in mind that it's an interactive control actually a button. But we should definitely go with a better theme color than DarkShadowColor.
Comment 17 Rainer Fiebig 2018-08-13 17:55:10 UTC
After de-installing libobasis5.4-kde-integration, the background-color of the handles changed from black to the one you can see in attachement https://bugs.documentfoundation.org/attachment.cgi?id=140513. 

That's an improvement. The other colors didn't change and still match the color-theme. 

Doing the same for LO-5.3 didn't have any negative effect, everything looks like before.

So it seems that on my system (KDE-4) "libobasis5.x-kde-integration" is not necessary for LO-5.3 and actually impairs KDE-integration for LO-5.4.

Making the handles less intrusive or even obsolete should still be an urgent design-goal, imo.
Comment 18 V Stuart Foote 2018-08-13 19:15:53 UTC
(In reply to Rainer Fiebig from comment #17)
> Making the handles less intrusive or even obsolete should still be an urgent
> design-goal, imo.

Reality is that Tomaž spent a fair bit of time on these widgets to ensure they function well for our lowres users on legacy hardware in addition to our growing community of HiDPI. The draw their colors from theme of the DE.

As noted comment 14, we probably should remove the show/hide grip button from the second "detached" Navigator deck.

Not clear the design can really be improved without additional control logic for the widget--an effort simply not justified. And certainly not "urgent" in any sense.

But, patches always welcome... 

IMHO => WF

@Tomaž, any thoughts on a solution? And, how hard to remove the grip from sidebar decks when detached (or the F5 instance Navigator)?
Comment 19 Rainer Fiebig 2018-08-13 20:16:27 UTC
(In reply to V Stuart Foote from comment #18)
> (In reply to Rainer Fiebig from comment #17)
> > Making the handles less intrusive or even obsolete should still be an urgent
> > design-goal, imo.
> 
> Reality is that Tomaž spent a fair bit of time on these widgets to ensure
> they function well for our lowres users on legacy hardware in addition to
> our growing community of HiDPI. The draw their colors from theme of the DE.
> 
> As noted comment 14, we probably should remove the show/hide grip button
> from the second "detached" Navigator deck.
> 
> Not clear the design can really be improved without additional control logic
> for the widget--an effort simply not justified. And certainly not "urgent"
> in any sense.
> 

OK, obviously we're not tuned to the same wavelength. So let's cut our losses in time now and move on.
AFAIC, you may close this thing.
Thanks for your time and effort.


> But, patches always welcome... 
> 
> IMHO => WF
> 
> @Tomaž, any thoughts on a solution? And, how hard to remove the grip from
> sidebar decks when detached (or the F5 instance Navigator)?
Comment 20 Heiko Tietze 2018-08-16 10:46:06 UTC
(In reply to V Stuart Foote from comment #18)
> IMHO => WF


(In reply to Rainer Fiebig from comment #19)
> AFAIC, you may close this thing.
> Thanks for your time and effort.

Thank you for reporting and discussing the issue.