Description: The current UI is overly complex while adding little value but adding confusion. This is a proposal to simplify the start-center document selection UI. Screenshot 2023-11-15 left keyboard, right mouse over.png shows current UI. There was discussion about how to change this in - https://bugs.documentfoundation.org/show_bug.cgi?id=158084 - https://bugs.documentfoundation.org/show_bug.cgi?id=158404 Steps to Reproduce: Look at current start center behavior Actual Results: Hightlight one: dark blue: keyboard selection (enter press does open document) Highlight two: light blue: mouse over (enter press still opens document with highlight one, probably because it is assumed that that is the document used for keyboard interaction) Expected Results: 1. when opening start-center the first document is highlighted. That highlight can be moved with arrow keys. Hovering the mouse would take over document highlight. It is confusing to have two documents highlighted at the same time in order to make a selection. This proposal ensures to remove confusion as to why two documents would be highlighted at the same time. 2. #158084 here was about using different highlight colors for selected vs mouse over. I understand the idea, but following the suggestion from 1. this would be obsolete. And I tend to find using two different colors in the same selection for two different selection methods even more confusing. 3. selection can be done via keyboard or mouse at any point in time. When mouse selection took over, keyboard selection continues from the last selected document. 4. another benefit is, that enter press could open document even from mouse hover, since a differentiation between mouse and keyboard selection no longer is needed. 5. what did I forget to cover? Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1a74a87b442857567d20da5dc97bbbc278745afd 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
Created attachment 191245 [details] Screenshot 2023-11-15 left keyboard, right mouse over
No, when the Start Center is opened focus is onto the Main menu--not into the backing window for either Template or Recent Documents thumbnail views. Likewise on return from closeout of the last open document. "On mouse over" behavior is a distinct UI action from "Selection" cross platform and is correct on the UI of the Start Center. For keyboard navigation, on open or following an <F10>, <F6> will cycle into the thumbnail view backing window and then cursor movements will make selections--the same behavior on UI Menus and TBs. Making an "on mouse over" document selection from the SC thumbnail views would then be at odds with UI behavior on Menus and Toolbars and anywhere else we have preselection highlights. If alternative representation(s) of the thumbnail views, bug 95739 and dupes, ever happen the current on mouse over would be expected. The UI representation of the Most Recently Used (MRU) menu list with thumbnail views on the SC backing window was a GSOC 2013 project modeled on LibreOffice work for the Template manager UI both implemented with behavior of TB and menus, The SC thumbnail views went in for 4.2.0 release.
Here we go (again). I understand Stuart is not fond of this proposal, because the start-center would behave different from how toolbars behave. So far this is the only argument brought up against this proposal. I don't understand how that even is a valid comparison. The start-center is NOT a toolbar. If you think that, you are mistaken. Thus there is no reason it should behave identical to toolbars. Adding a screencast of how pages template picker behaves: it is simplified even further: there is no mouse over whatsoever. And guess what - it makes for great UI + UX. It is very simplistic speaks a clean design language and causes no confusion on the user side. Want to open a document, either navigate there with your arrow keys or mouse, select it and press enter Why is it so hard to make the most basic operations (selecting a template or document from start center) user friendly? It really is beyond me. Sorry, I am not sure I'll engage much further in this debate.
Created attachment 191253 [details] Pages template picker 2023-12-05
I've said my piece on bug 158404 (while bug 158084 was fully resolved by shifting to 75% transparency) and have now passed this over for UX consideration. I'm a -1 to any merging of mouse over to become a selection action. It is up to others...
(In reply to V Stuart Foote from comment #2) > Making an "on mouse over" document selection from the SC thumbnail views > would then be at odds with UI behavior on Menus and Toolbars and anywhere > else we have preselection highlights. Selected state for buttons usually indicates some feature has been activated and this can be true for multiple ones (Bold, Italic, Underline...). So the interaction with buttons is quite different from the Start Center thumbnails. Buttons are almost ten times smaller than the thumbnails, so the dual highlight effect in Start Center might appear as jarring to some users in comparison. Similarly, menus have a unique behaviour: if you click to open a menu and then hover over other menu items of the same level, the opened state will immediately switch to the hovered one. So compared to buttons, menus behave more like how steve envisions Start Center thumbnails should behave. In bug 158404 comment 20 I asked: (In reply to Buovjaga from comment #20) > Created attachment 191112 [details] > Screen recording of Start Center behaviour with patch making hover equal to > selection > > As we still only have the argument of uniformity, I would be interested in > hearing what is the problem with the behaviour shown in this video. > > Stuart: can you explain what is bad/annoying based on the video? I'm still interested in hearing about the badness. I made a Reddit poll that ran for 5 days and the result was 4 votes for the current behaviour and 7 votes for steve's proposal: https://www.reddit.com/r/libreoffice/comments/187p7l3/which_hover_interaction_in_libreoffice_start/
Pages selects on click and opens/executes on double-click (not a bad choice). We open on single click - some users might want this (KDE, and probably other OS too, has an option whether single click selects or executes). As long as we open on single click / enter, we need to show what clicking means. If we go with Ilmari's alternative (auto-select on hover) we run into the danger of unintended mouse movements. The hover design is of course open for discussion, but the only alternative is to open on double click.
(In reply to Heiko Tietze from comment #7) > Pages selects on click and opens/executes on double-click (not a bad > choice). We open on single click - some users might want this (KDE, and > probably other OS too, has an option whether single click selects or > executes). The pages screencast was not an optimal comparison as it is a template manager, so compares to LibreOffice's manager which likewise does not open upon single click. > As long as we open on single click / enter, we need to show what clicking > means. If we go with Ilmari's alternative (auto-select on hover) we run into > the danger of unintended mouse movements. > > The hover design is of course open for discussion, but the only alternative > is to open on double click. Can you explain this danger, I don't understand it?
(In reply to Buovjaga from comment #8) > Can you explain this danger, I don't understand it? You may select one item with the plan to open per enter. Accidentally moving the mouse selects a different item, happening potentially close to enter.
While I am not sure I see the danger of mouse interaction while intending to use arrow keys and open with enter as a scenario that should prevent the change from happen, it could be considered an argument for the document selection as shown in the screencast of Pages. Mouse over may show file path but not highlight the document at all. Highlight ever only happens after the document is either selected via arrow keys or mouse click. Enter or another mouse click opens the document in question. Btw I consider both variants a win over the current implementation.
More precisely: select per click (or arrow keys), open with double-click (or enter). And hover just shows the usual tooltip if the cursor rests over the control. And shows the pin icons to give a hint on the possibility. Any argument against this solution?
(In reply to Heiko Tietze from comment #11) > More precisely: select per click (or arrow keys), open with double-click (or > enter). And hover just shows the usual tooltip if the cursor rests over the > control. And shows the pin icons to give a hint on the possibility. > > Any argument against this solution? I'm against this solution as it complicates the workflow. It's fine for template manager, but for the Start Center views it is irrelevant as there is no multiselection.
(In reply to Buovjaga from comment #12) This workflow would become much more relevant, if (when) we add options to the thumbnails: e.g., allow to use the same filter as last time (or redo the type detection, as it happens now). Double-click is not the "workflow complication" problem needing much attention - double-clicking is used ~universally. +1 from me.
(In reply to Mike Kaganski from comment #13) > (In reply to Buovjaga from comment #12) > > This workflow would become much more relevant, if (when) we add options to > the thumbnails: e.g., allow to use the same filter as last time (or redo the > type detection, as it happens now). Double-click is not the "workflow > complication" problem needing much attention - double-clicking is used > ~universally. > > +1 from me. Very well. Onward to a new and glorious Start Center!
(In reply to Heiko Tietze from comment #11) > More precisely: select per click (or arrow keys), open with double-click (or > enter). And hover just shows the usual tooltip if the cursor rests over the > control. And shows the pin icons to give a hint on the possibility. > > Any argument against this solution? (In reply to Mike Kaganski from comment #13) > (In reply to Buovjaga from comment #12) > > This workflow would become much more relevant, if (when) we add options to > the thumbnails: e.g., allow to use the same filter as last time (or redo the > type detection, as it happens now). Double-click is not the "workflow > complication" problem needing much attention - double-clicking is used > ~universally. > > +1 from me. OK so meaning, we move SC to single-click selection and double-click open? On mouse over still only exposes the tooltip, but does it continue to show the 75% transparent selection color? If so, +1 for implementing a on-mouse-over / single click / double click selection sequence cross platform for SC.
(In reply to V Stuart Foote from comment #15) > On mouse over still only exposes the tooltip, but does it continue to show > the 75% transparent selection color? No, that's not needed anymore and was challenged in first place here. > If so, +1 for implementing a on-mouse-over / single click / double click > selection sequence cross platform for SC. Still in agreement, or do you have arguments why hovering needs feedback?
(In reply to Heiko Tietze from comment #16) > (In reply to V Stuart Foote from comment #15) > > On mouse over still only exposes the tooltip, but does it continue to show > > the 75% transparent selection color? > No, that's not needed anymore and was challenged in first place here. > > > If so, +1 for implementing a on-mouse-over / single click / double click > > selection sequence cross platform for SC. > Still in agreement, or do you have arguments why hovering needs feedback? Yes, for the SC changing cross platform to a single-click to select, and double click/enter to actually open, having just tool tip on-mouse-over is sufficient UI feedback (i.e. the 75% transparency "highlight" could be dropped). End result just needs to be consistent cross platform and documented, even if at odds with os/DE norms.