It is not necessary to distinguish between hovered and selected state in the Start Center Recent Documents view. We should also remove multiselection behaviour from Recent Documents view. This is probably better as a separate patch. I am working on the code right now and should be able provide some kind of a barbaric proof of concept.
(In reply to Buovjaga from comment #0) > I am working on the code right now and should be able provide some kind of a > barbaric proof of concept. 👍 - assigning to you then.
Wait, current hover <==> mouseover, triggers display of file path info. Seems a rather useful facet of SC UI not resulting in selection. Why eliminate?
(In reply to V Stuart Foote from comment #2) > Wait, current hover <==> mouseover, triggers display of file path info. > Seems a rather useful facet of SC UI not resulting in selection. > > Why eliminate? No useful thing will be eliminated. Selection as a separate state is only useful in the Template view.
Not getting it. With a recent document selected, mouse over hover currently will highlight the thumbnail view and show the path of other recent docs--but not select it without a l-mouse click. The current selection remains as set. An <enter> launches the selection, not the mouse over/hover document. Releasing the mouse over by pointing away returns to the original selection. The mouse over/hover allows visual scan of the MRU listing's thumbnails exposing their path. That is reasonable behavior, what reason to change?
(In reply to V Stuart Foote from comment #4) > Not getting it. With a recent document selected, mouse over hover currently > will highlight the thumbnail view and show the path of other recent > docs--but not select it without a l-mouse click. The current selection > remains as set. > > An <enter> launches the selection, not the mouse over/hover document. > Releasing the mouse over by pointing away returns to the original selection. > The mouse over/hover allows visual scan of the MRU listing's thumbnails > exposing their path. > > That is reasonable behavior, what reason to change? Left-click doesn't select, left-click opens the file. To get a better idea of the selection functionality, use the arrow keys while focused into the thumbnail view. Then, use Shift+arrow keys. In the Templates view this makes sense as you can operate on multiple selected items. In Recent Documents view you can only operate directly on an item by clicking its pin or close icon, selection has no meaning there.
Issue is the behavior of what is selected? <F6> rotation into the Thumbnail views listing of MRU will result in the most recent being selected. Cursor <R,L,U,D> will move selection. Mouse pointer movement does not make a selection, nor should it! Mouse click can Pin, Delete, or Open the document. Mouse over <==> hover displays the file path. Only time there is NO selection is on return to SC from the last open document. Selection should not change with mouse over <==> hover over the MRU thumbnail view (or document Icon when thumbnails are suppressed).
(In reply to V Stuart Foote from comment #6) > Mouse pointer movement does not make a selection, nor should it! > > ... > > Selection should not change with mouse over <==> hover over the MRU > thumbnail view (or document Icon when thumbnails are suppressed). We discussed this some days ago in the design chat and also in bug 158084, but there was no strong argument and I tried my best to think of problems. Please explain the reasoning behind your opinion and the problems you see, if I change the behaviour.
Sorry, don't see that there was *agreement* in bug 158084 to eliminate mouseover highlight and make the mouseover/hover change into a selection. Only saw Heiko's action to adjust for color distinction between Selected vs. Mouseover/Hover over state. "Selected vs. hovered is now distinguished by transparency" It remains a useful function and kind of core to the *visual* rendering of the MRU listing as thumbnails on the SC backing plane. There is one "selected" object, but any of the thumbnail views of the MRU can be hovered over to reveal its full path and file type. -1 that any change to SC selection behavior is needed.
(In reply to V Stuart Foote from comment #8) > It remains a useful function and kind of core to the *visual* rendering of > the MRU listing as thumbnails on the SC backing plane. There is one > "selected" object, but any of the thumbnail views of the MRU can be hovered > over to reveal its full path and file type. You still did not give any concrete argument for its usefulness or mention any problems that would arise from the proposed change.
As you've mentioned many times the tooltips revealing the paths, those won't be going anywhere with the change.
Because there is *no* reason to actually change and make selection by mouseover/hovering! The cursor controls work for keyboard users (and a11y) the mouseover behavior was intended and offers simple visual feedback of the MRU item via its Thumbnail view. Mouseover (and its corresponding highlight that Heiko has tweaked) to display the URI for the document object--that alone is enough. A l-mouse click to open, or pin, or delete without out the mouseover making selection has worked just fine. Again, why would it need to be changed? You are now proposing to drastically change the SC behavior by merging mouseover behavior with cursor movement selection. It is not needed (nor I imagine desired) and is at odds with the way the SC was implemented and released at 4.2
(In reply to V Stuart Foote from comment #11) > Because there is *no* reason to actually change and make selection by > mouseover/hovering! > > The cursor controls work for keyboard users (and a11y) the mouseover > behavior was intended and offers simple visual feedback of the MRU item via > its Thumbnail view. > > Mouseover (and its corresponding highlight that Heiko has tweaked) to > display the URI for the document object--that alone is enough. > > A l-mouse click to open, or pin, or delete without out the mouseover making > selection has worked just fine. Again, why would it need to be changed? > > You are now proposing to drastically change the SC behavior by merging > mouseover behavior with cursor movement selection. It is not needed (nor I > imagine desired) and is at odds with the way the SC was implemented and > released at 4.2 It should be changed because the two different highlights provide no value in the Recent Documents view and instead cause a jarring visual effect, when the selection confusingly stays put while the highlight follows the mouse. The change is in no way drastic as it makes the mouse behaviour coherent and does not remove any functionality. If you want to argue it is drastic, please provide concrete scenarios where things get worse due to the change. In the Templates view we should probably make the multiselection more useful by allowing Shift/Ctrl-clicking to expand the selection. Now it is difficult to discover for mouse users as it only works via keyboard.
(In reply to Buovjaga from comment #12) > It should be changed because the two different highlights provide no value > in the Recent Documents view and instead cause a jarring visual effect, when > the selection confusingly stays put while the highlight follows the mouse. > No, the MRU selection and mouseover highlight are now clearly different visual events on the StartCenter with Heiko's tweak for bug 158084 -- sorry but I don't see it as as "jarring visual effect" in any sense. > The change is in no way drastic as it makes the mouse behaviour coherent and > does not remove any functionality. If you want to argue it is drastic, > please provide concrete scenarios where things get worse due to the change. > It is drastic as attempts to change the mouseover into a selection action serves no purpose in the UI. It does not consolidate anything--mouseover on SC sidebar, on Menu submenu items, and on Toolbar widgets behaves the same as the SC thumbnail views--with focus/selection remaining while mouseover highlights and triggers tooltips. Selections are not changed there either. In fact the mouseover changes to the SC would cause more user annoyance than any visual improvement to the UI. > In the Templates view we should probably make the multiselection more useful > by allowing Shift/Ctrl-clicking to expand the selection. Now it is difficult > to discover for mouse users as it only works via keyboard. Not clear there should be a multi-select for the Templates as now via keyboard--to me that is an implementation error. You can only open one template at a time to create a new document--and the last selected in a multi-select has the focus and is used for the new document.
(In reply to V Stuart Foote from comment #13) > Not clear there should be a multi-select for the Templates as now via > keyboard--to me that is an implementation error. You can only open one > template at a time to create a new document--and the last selected in a > multi-select has the focus and is used for the new document. Hmm, good point: for some reason I had only tested with the Template Manager and thought it behaved the same way as the Templates view. Sorry for the noise. So multiselection should also be removed from the SC Templates view.
As a somewhat on-topic note, we could enrich the Template Manager dialog per Mike Kaganski's comment in the dev chat: "as to multiselection: mobile/web UIs have a paradigm to show checkboxes when user explicitly tells to multi-select for some feature (e.g., to remove multiple)" I should create a new report for that.
I will focus on the multiselection for now and not change the hover behaviour.
(In reply to Buovjaga from comment #16) > I will focus on the multiselection for now and not change the hover > behaviour. I'm somewhat surprised by hover = selection idea. Wasn't it only about multiselection, as sufficiently explained in comment 12, for example. To summarize: Issue + Multi-selection has no meaning in the start center (and minor in the template manager) + Hovering over selected items is not visible anymore (neither needed) Expected result + Selection remains possible for a11y (primarily via tab/F6 + arrow keys; no _need_ to block it via mouse - and mouse click selects anyway) + Selected items are opened via enter or single click (we would have to switch to double click if multi-selection was possible) + Hovered items give feedback so users get what clicking means in advance Still need for UX input?
(In reply to Heiko Tietze from comment #17) > (In reply to Buovjaga from comment #16) > > I will focus on the multiselection for now and not change the hover > > behaviour. > I'm somewhat surprised by hover = selection idea. Wasn't it only about > multiselection, as sufficiently explained in comment 12, for example. To > summarize: > > Issue > + Multi-selection has no meaning in the start center (and minor in the > template manager) > + Hovering over selected items is not visible anymore (neither needed) > > Expected result > + Selection remains possible for a11y (primarily via tab/F6 + arrow keys; no > _need_ to block it via mouse - and mouse click selects anyway) > + Selected items are opened via enter or single click (we would have to > switch to double click if multi-selection was possible) > + Hovered items give feedback so users get what clicking means in advance > > Still need for UX input? Steve's idea was never about removing any feedback upon hover, but indeed to make hover equal to selection. It made sense to me looking only at Start Center, but as Stuart pointed out we have pre-selection highlighting all over the place (including the buttons in Start Center).
Patch: https://gerrit.libreoffice.org/c/core/+/160003
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?
Ilmari Lauhakangas committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5584980493fd599054cc5bbdb9911ae2c70cd60f tdf#158404 Start Center: remove ability to do multiselections 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.