Created attachment 112170 [details] Example file in order to illustrate the enhancement In order to improve the usability of the Navigator according expanding headings, I propose that headings are always expanded with a double-click and never collapse with a double-click. In order to illustrate the problem open the attached file and follow the instructions inside.
Comment on attachment 112170 [details] Example file in order to illustrate the enhancement fix mimetype
(In reply to Harald Koester from comment #0) > In order to improve the usability of the Navigator according expanding > headings, I propose that headings are always expanded with a double-click > and never collapse with a double-click. In order to illustrate the problem > open the attached file and follow the instructions inside. One for the UX Guild to tackle Status -> NEW Component -> ux-advise
I find the current behaviour fine as it is the same behaviour found in all tree type controls found in other applications (e.g. file manager). @Heiko, Stuart: What do you think?
Whether or not trees are expanded should be defined by the system (small screens might not have enough room for the full tree, for instance) or at least application wide as a general setting. However, 'expand all' would be a nice gimmick for the context menu. BTW: You can expand all nodes in any tree by pressing ctrl + plus (at least under Windows).
Sorry, I'm kind of missing why these widgets are even coded with double mouse click selection/action? Seems like a single mouse click to select, and a second single mouse click to perform the action would be more consistent with keyboard navigation and selection actions. Also, presently single mouse click on the plus icon widget expands/closes the listing. Keyboard navigation follows <F10>, <F6> and all cursor movments, and selection is with <Enter>. Expand/Close is with cursor <R> or <L> respectively. That aside, other than using the double mouse click for selection/action, as Harold reports the only thing that seems amiss is the double mouse click opening/closing the lists. We could fix that, of just replace the double mouse click selection/action with two discrete single mouse clicks. At least we do have the same behavior in <F5> dialog, or in the Sidebar implementation of Navigator.
Current handling of clicks and double clicks in the Navigator tree could be better. 1. Single clicking in the Navigator does nothing at all. Why? The obvious role of the Navigator is to permit navigating to selected elements, so why should single left clicking do nothing at all and I have to double click to get it to do anything at all? 2. Double clicking entries both navigates to them but also expands/collapses them. So after manually opening all the top level chapter nodes every time I navigate to a new chapter it closes again, forcing me to re-expand it every time. 3. The "Heading Levels Shown" feature doesn't seem to be as useful as an alternative "Heading Levels Expanded" feature. If I open a document with thirty odd chapters in it the entire navigation tree is inially fully collapsed and I have to manually expand every single chapter to get a basic overview of the document. In this situation "Heading Levels Shown" does nothing useful. A "Heading Levels Expanded" option which I could set to automatically expand the number of heading levels specified would be a Godsend. (Naturally it should remember its configuration on closing the Writer). --- Word in MS Office 2010 had the best navigator. Just copy how that works and you can't go wrong.
To clarify my position on the tree behaviour, i believe it should work like any other tree. 1) Single click to select 2) Double click expand/collapse and select
I fully agree we Jay (and any HIG except MacOS, AFAIK, but including Gnome which we use in LO) that single click is for selection and double click for execution. The reason is that selecting an item should show detailed information somewhere. However, I agree with the issue of collapsing items on double click. Solutions might be a) to expand/collapse only on click at the plus/minus (or whatever symbol is set by theme) or b) to have an explicit control for the action. At least a context menu with the options to jump to the item and to expand/collapse from here (issue #3). As a workaround there is (hidden) key access: plus and minus opens or close the chosen node but with ctrl it affects all siblings. So you may select Heading and press ctrl + plus to expand the tree completely.
See these discussions from 2011: https://bugs.documentfoundation.org/show_bug.cgi?id=36308 https://bugs.documentfoundation.org/show_bug.cgi?id=36309 No idea why the second one was closed, though.
Created attachment 116273 [details] List of functions accordings headings in the Navigator Your last comments induced me to examine the functions around clicking on and expanding and collapsing of headings in the Navigator a bit more. The result is quite a long list of functions. I add this list as an attachment to this bug report. In the list I also inserted some proposals for improvements. These proposal are marked with different colours. Perhaps some of you may take a bit of time to have a look at this list and comment my proposals.
Maybe it's useful to look at what other software do with this problem. For example, LyX(1) have a "navigator" with a tree view too, and single clicks move the cursor to the selected heading _and_ close/open the branch, *unless* you check a check box at the bottom called "keep": from that point on, you can only close/open the branch either by the arrows to the left of the entry or by double clicking the heading. (1) http://www.lyx.org/
(In reply to Harald Koester from comment #10) > Perhaps some of you may take a bit of > time to have a look at this list and comment my proposals. #2..#6 You suggest to automatically change the focus back to the document after selecting a control that can receive the focus (tree in the navigator). That would be counter intuitive and violates accessibility since keyboard navigation is not possible. #7 about context menu: Supposed there is nothing selected in the tree or list and you show a context sensitive menu, where do the function belongs to? Or you have an entry selected and right click another in order to run an action from the context menu for this item. Right click should select the item. #8..#12 with ctrl+click: Agreed :-) (except the focus change) #13 is unclear to me #14..#19: Disagreed. That's an 'irreversible' action which should started explicitly. So a double click is appropriate here. The use case is again keyboard access: navigate through the tree with cursors and activate by enter, just as the file browser behaves. And otherwise #21 ff wouldn't make sense. #22, #25: Agreed.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Patch has been submitted for bug 36308 https://gerrit.libreoffice.org/#/c/47241 (code review pending). Closing this ticket as duplicate. *** This bug has been marked as a duplicate of bug 36308 ***