Created attachment 196514 [details] Autofilter buttons vs UI buttons (LO 25.02 nightly) The down-arrow buttons we get when AutoFilter is in effect look "custom-drawn", and remind me of Windows 95 or even Windows 3.x down-arrow buttons. Be that as it may - they are certainly different than the buttons we see on combo-boxes, and the down-arrow is not even like the ones we see on toolbar menubuttons. It would be more visually pleasing if the buttons, and the down-arrows, looked like (or actually were) native widgets.
I'm not sure about the feasibility of using native widgets here, specially because of zoom levels. However I agree with you about the need to redesign this button... it feels old to me as well. I like the minimal design in Google Sheets.
Created attachment 198164 [details] screenshot Google Sheet dropdown mentioned by Rafael.
Created attachment 198194 [details] AutoFilter dropdown in Google Sheets (In reply to BogdanB from comment #2) > Google Sheet dropdown mentioned by Rafael. Actually your screehshot shows a data validation dropdown in Google Sheets. I've just attached an example from Google Sheets where you have the AutoFilter dropdown. TBH I like them because they're clean and light on the eyes.
A user on Reddit was complaining about the "UI sharpness" the other day: https://www.reddit.com/r/libreoffice/comments/1mw57v9/comment/n9y23m3/
Bogdan, Rafael - would you mind confirming?
Lets have more opinion here UX Team -- please take a look at this enhancement. Thanks! I marked this bug as new for the moment.
Another issue is that this triangle does not respond to zoom. And in fact it is drawn manually at ScDPFieldButton::drawPopupButton().
We discussed the topic in the design meeting. Native controls are desirable not least because of accessibility. The implementation is probably close to impossible (and should therefore be filed in an extra ticket) but drawing an icon or some other indicator could be a low hanging fruit. The aim is less anti-aliasing issues, adequate zooming, and more appealing design. We may try with horizontal lines similar to the GSheet example.
(In reply to Heiko Tietze from comment #8) Changed the bug title accordingly. The benefit of the "triangle of lines" approach is that it looks _very_ different from the arrows on native widgets, so that it doesn't feel like a crassly-reproduced native widget, but something intentionally different. We had also discussed the possibility of using the cached bitmaps used for rendering toolbars, and maybe even adding such caching for more zoom levels, so we would get more decent scaling. But - doers decide: Some alternative drawing which looks better is what we'll settle for right now. But anti-aliasing is important regardless. Lines drawn on exact pixel boundaries will feel very jagged and mispleasing.
Created attachment 202855 [details] Screencast Proposed solution
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2eb67678d93ede4c4031412b9d3b900ab2c34a71 Resolves tdf#163017 - More appealing design for AutoFilter button It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Poll whether the new design is an improvement at https://fosstodon.org/@libodesign/115230118309870832 reveals 74% acceptance. Unfortunately only 23 people participated.
The screencasts next to the poll are a mis-representation of what the existing situation looks like on screen. And the poll does not indicate what the faults with the current state of affairs are - biasing the results. Such a poll should have been coordinated either here or on the LO Design Telegram channel, and wasn't. Also, IIUC from Heiko's comments on Telegram, this is still a 16x16 pixel graphic. Therefore, it does not fix the bug, since we lack anti-aliasing. The bug re-titling was also incorrect, in that it set the requirement to _no_ anti-aliasing, while that is in fact the problem: we _want_ a proper anti-aliased graphic. So, I don't believe this bug can be marked as fixed.
(In reply to Eyal Rozenberg from comment #13) > Also, IIUC from Heiko's comments on Telegram, this is still a 16x16 pixel > graphic. Therefore, it does not fix the bug, since we lack anti-aliasing. > The bug re-titling was also incorrect, in that it set the requirement to > _no_ anti-aliasing, while that is in fact the problem: we _want_ a proper > anti-aliased graphic. I do notice the line width changing unexpectedly with zoom levels, like at 100% the button graphic looks balanced, but at 110% the lower bars shrink with the lowest becoming basically a dot. Not sure, if this is related to the anti-aliasing issue. Also, in case others test zooming and notice something strange: with commit 008c2354075e1b5b63000f6a2da802971a2902e6 the button size stays proportional, but the old behavior of the value moving closer to the button while zooming remained. So if you have a single digit in the autofilter cell, it will disappear when you zoom enough.