In Start Center, some document may be the "selected" one; that selection is highlighted ("silver" in my theme / OS), and may be moved using arrow keys / opened using Enter key. Also, there is a highlight shown when mouse is hovered over the thumbnails. The problems are: 1. The color of the hover highlight is (in most cases) almost identically "silver" (on my Windows system). The two different things shown identically doesn't make sense. 2. In *one* case, specifically when I hover over the currently selected item, the hover highlight becomes blue. This also doesn't make sense: what information does a user get by that color change? In the context of the Start Center, there is absolutely no practical value in knowing that this item is simultaneously selected and hovered. User seeing this blue color will almost definitely not know what does it mean. The proposal is: make hover highlight color (a) different from selection color, and (b) same for any element - be it selected or not. And it would be nice to use the blue for hover vs. silver for selection; or the other way round (with hover color being used when mouse is over the selected item).
Created attachment 190675 [details] A screencast
Reproducible with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 026be6f62f183f14b9c0bf2e50cde9ac69856f53 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Clicking on other thumbnail without open it, make the first having the same color as others.
Besides the color that is not based on any element of the system's theme, the contrast with the text is infimum (an a11y issue).
The status of being selected needs a different appearance. We have * normal (any list item, no highlight) * hovered (the item which becomes pre-selected, typically some greyish color) * selected (per click or keyboard and executed/loaded via enter, typically some lighter grey) * selected and hovered => makes no sense to have a special background here So we should _change the selected color_ to make it distinct from hover and ignore the combination meaning drop the blue highlight. Whether we go with grey/lightgrey or blue/lightblue is not so important. Windows Explorer uses grey, KDE file browser blue. Most colors in the start center are variable per Tools > Options > Advanced (search for startcenterthumbnails). (Switching back to unconfirmed to keep the ticket in the UX loop for a while)
Patch at https://gerrit.libreoffice.org/c/core/+/159286
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/285a3e8d8b77b44da3dcc767877f878fe0e0493e Resolves tdf#158084 - Use system colors in start center It will be available in 24.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.
On macOS in the past weeks I saw two unintended states. For a while it seemed accent color was used to highlight document on mouse over. Then a light grey was used. And with todays build Highlight colour is used, which is the expected color on macOS to be used. I see two remaining issues and from my understanding this bug here is not resolved yet. 1. when opening StartCenter the first document is highlighted. That highlight can be moved with arrow keys. But I can also mouse over and those documents get highlighted. I find it very confusing two have two documents highlighted at the same time in order to make a selection. Should that even be possible? Wouldn't it be better to remove the default selected document as soon as the mouse pointer hovers over one of the start center documents? That would ensure to remove confusion as to why two documents would be selected at the same time. 2. This bug here was about using different colors for selected vs mouse over. I understand the idea, but following the suggestion from 1. this would be obsolete and no longer needed. And I tend to find using two different colors in the same selection for two different selection methods even more confusing. 3. There is one funny behavior: when a document is selected and I mouse over that document, no longer is the macOS highlight colour used but it seems Accent colour is used instead. That should imo not happen. Do these suggestions that make sense?
No editing... 🙄 Three remaining issues and here is the build I tested with: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c60a9db1f2a8e2a088c6b89bcdff4901b28f2864 CPU threads: 8; OS: macOS 13.6.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded
(In reply to steve from comment #7) > I find it very confusing two have two documents highlighted at the same time... See comment 4 why this is needed. > Accent colour is used instead... The function is used in the start center for recent documents and templates as well as the template manager. Each of the three instances has its own initialization - and I just changed it for the recent documents to look like the other three. In fact it is not the accent color but active. maHighlightColor = rSettings.GetHighlightColor(); maHighlightTextColor = rSettings.GetHighlightTextColor(); maSelectHighlightColor = rSettings.GetActiveColor(); maSelectHighlightTextColor = rSettings.GetActiveTextColor(); We probably don't need to distinguish between selected and hovered. Let me check how it feels...
https://gerrit.libreoffice.org/c/core/+/159407 (I also increased the transparency so that hovering is more clearly to distinguish from selection)
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/adfb0a34af196befc46527418f6e870d1f8f1889 Resolves tdf#158084 - Start Center hover color It will be available in 24.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.
Created attachment 190834 [details] Screenshot 2023-11-15 left keyboard, right mouse over About 1. from comment 7: > Heiko: See comment 4 why this is needed. I read comment 4 a few times. It elaborates on the different states. It does not explain why having two documents highlighted at the same time is needed. I would propose to use identical color for both highlight events: keyboard + mouse. As soon as the mouse moves into start center and highlights a document, the document that was highlighted when using the keyboard before or the default (highlight top left document) is no longer highlighted. It should still be possible to continue navigating with keyboard, but that should be done from the last highlighted document which then would be the the document last touched with mouse over. About 2. from comment 7: I stick to that argument. Mouse over uses a very light accent colour which is barely visible against the undefined (nor light nor dark) grey background of start center document area. This is problematic UX. (see Screenshot 2023-11-15 left keyboard, right mouse over) 3. from comment 7: is resolved in that the keyboard highlight color is not changed when keyboard highlight and mouse over highlight meet on the same document.
(In reply to steve from comment #12) > It does not explain why having two documents highlighted at the same time is needed. The state _selected_ needs to be distinguished from _hovered_. > I would propose to use identical color for both <highlight> events... The latest patch uses only the highlight color, but with much stronger transparency than previously. > Mouse over uses a very light accent colour which is barely visible... It's the highlight color with 75% transparency, done intentionally to clearly understand that hovered items are not selected. Regarding visibility, keep in mind that you move the cursor. Feel free to change it to any other value, eg. 50% by setting mfHighlightTransparence = 0.5 in sfx2/source/control/recentdocsview.cxx and sfx2/source/control/templatedefaultview.cxx.
(In reply to Heiko Tietze from comment #13) > (In reply to steve from comment #12) > > It does not explain why having two documents highlighted at the same time is needed. > The state _selected_ needs to be distinguished from _hovered_. Steve's proposal is to change the selected state upon hover. Please give arguments why this would be bad. So far in the design chat, the argument was basically that one could accidentally change the selection when hovering. If someone was using both the keyboard and the mouse for navigation, the theory is that implementing Steve's proposal might cause confusion. However, as there is no multi-selection involved and no potential for harmful actions based on selection, I think the argument is weak.
(In reply to Buovjaga from comment #14) > Steve's proposal is to change the selected state upon hover. |(In reply to steve from comment #7) | 2. This bug here was about using different colors for selected vs mouse | over. I understand the idea, but following the suggestion from 1. this would | be obsolete and no longer needed. > Please give arguments why this would be bad. We need the information of selected and hovered. And it is implemented respectively.
(In reply to Heiko Tietze from comment #15) > We need the information of selected and hovered. And it is implemented > respectively. I am afraid, it is not clear who is "we" and why "we" need that - give that the idea discussed after your changes is to *join* the "selected" and "hovered" (I didn't propose it initially, but I concur). Why can't movement of mouse over the list be considered the same action as using keyboard? Then, there will be *no* separate hovered items vs. keyboard-selected. Which use case is broken then?
(In reply to Heiko Tietze from comment #15) > And it is implemented respectively. Selected vs. hovered is now distinguished by transparency.
Extra, extra, read all about it: I have just discovered we support selecting multiple items in the Recent docs thumbnail view by using Shift+arrow keys. The catch is that any action (Enter to open, mouse click to pin or remove) will only operate on the last selected item or the one you click. So the question becomes: do we embrace this (accidentally inherited?) multiselection functionality and make it work or do we quietly remove it while simplifying the highlighting/selection logic?
(In reply to Buovjaga from comment #18) > we support selecting multiple items in the Recent docs thumbnail view Weird. The only reasonable action is to move/export items in the template manager. > quietly remove it while simplifying the highlighting/selection logic? ^ this IMO (with a new ticket)