Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded When the user right-clicks on a heading in the Navigator tree, s/he gets a submenu which says "Expand all / Send item to clipboard / Outline tracking / Outline level / Drag mode / Display". AFAICS, this needs documenting in the helpfiles.
I agree. I could only find informations about the "Navigator for Document Overview" [1] but not about expand and collaps levels [1] https://help.libreoffice.org/7.0/en-GB/text/shared/guide/navigator.html?&DbPAR=WRITER&System=WIN
This is not an issue of documentation, this is an issue of behavior. It is standard behavior on macos that option-clicking a disclosure triangle should fully expand or collapse the item and everything beneath it. Having to do something in a nonstandard way adds friction and frustration to the experience of using the application.
Also, this is not just about Navigator, it is about disclosure triangles in outline/hierarchical list views, wherever they may be.
(In reply to R. Green from comment #0) > When the user right-clicks on a heading in the Navigator tree, s/he gets a > submenu which says "Expand all / Send item to clipboard / Outline tracking > / Outline level / Drag mode / Display". AFAICS, this needs documenting in > the helpfiles. Some things (e.g., Outline Level, Drag Mode) are already documented, see: https://help.libreoffice.org/7.0/en-GB/text/swriter/01/02110000.html Additional help at: https://help.libreoffice.org/7.1/en-GB/text/swriter/guide/arrange_chapters.html Outline Tracking is new. While you are waiting for help pages see: https://wiki.documentfoundation.org/ReleaseNotes/7.0#Navigator ==> NEW There are two different context menus here. 1. "Headings" label itself. 2. Individual heading objects ("children" of "Headings"). For "Headings" itself and its children New: Collapse/Expand All (easy enough to figure out that "all" is relative) "Outline Tracking" (mentioned in release notes) For "Headings" itself: Not well-documented (in Navigator help): "Send Outline to Clipboard" (but has also existed since at least 6.3 - and seems a little wobbly). @Jim -- do I have this right: 1. "outline tracking" is the only "new" (undocumented) command/feature in the context menu for "Headings" (and its children)? 2. while all other items in the context menus (for both Headings and for its children) (including newly added or rearranged "old" ones) are already documented on the Navigator help page (except for "Send Outline to Clipboard)? 3. And if I have read the source code correctly (uibase/utlui/content.cxx), then Send Outline to Clipboard is using: .uno:SendOutlineToClipboard (which I guess you have not worked on -- so I won't file a bug report. (-: )
> @Jim -- do I have this right: > > 1. "outline tracking" is the only "new" (undocumented) command/feature in > the context menu for "Headings" (and its children)? I think so, other than the mentioned Collapse/Expand All. Outline tracking settings: Default - do not collapse already expanded outline entries Focus - collapse all outline entries other than the one being tracked Off - do not track https://bugs.documentfoundation.org/show_bug.cgi?id=108766#c14 > 2. while all other items in the context menus (for both Headings and for its > children) (including newly added or rearranged "old" ones) are already > documented on the Navigator help page (except for "Send Outline to > Clipboard)? Reading the help, it looks that way. > 3. And if I have read the source code correctly (uibase/utlui/content.cxx), > then Send Outline to Clipboard is using: .uno:SendOutlineToClipboard (which > I guess you have not worked on -- so I won't file a bug report. (-: ) Yep, Send Outline to Clipboard is inherited from OOo. It boils down to: https://opengrok.libreoffice.org/xref/core/sw/source/filter/ww8/rtfexport.cxx?r=7c70a59c#1023
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/efae5941210d1801523ae2a7a6ef3e3d5521bd46 tdf#135668 general cleanup of help page for Navigator
(In reply to Jim Raykowski from comment #5) >-- do I have this right: Many thanks for quick confirmation and elaboration of "Online tracking settings". Have updated Navigator help page to correspond to the order of controls on Navigator (and removed obsolete controls)... ...which generates one additional question. @Jim: the spin button in upper right corner. Is it "Go to Page" (and has nothing to do with "Navigate By")? (experiments and source code examination lead to this speculation). If that is correct, then I can add a "tooltip" (swriter/ui/navigatorpanel.ui), which should help matters. (Meanwhile, I still think "List Box" is redundant (-: ) > Yep, Send Outline to Clipboard is inherited from OOo. Thanks. Very helpful. Motivated bug 137591.
(In reply to Commit Notification from comment #6) > tdf#135668 general cleanup of help page for Navigator This bug is not resolved yet. "Outline Tracking", "Expand/Collapse" and "Send Outline to Clipboard" are only in the context menus, not the Navigator UI. Need to design a solution about how to present the information. Meanwhile, it takes a few days before the online help is updated from master to see the changes in the Navigator help page: https://help.libreoffice.org/7.1/en-US/text/swriter/01/02110000.html
(In reply to sdc.blanco from comment #7) > @Jim: the spin button in upper right corner. Is it "Go to Page" (and has > nothing to do with "Navigate By")? > (experiments and source code examination lead to this speculation). > If that is correct, then I can add a "tooltip" > (swriter/ui/navigatorpanel.ui), which should help matters. Correct, it has nothing to do with "Navigate By". I agree that a tool tip would help matters. > > (Meanwhile, I still think "List Box" is redundant (-: ) > I'm not following how it is redundant? Seems to have unexpected behavior for Promote/Demote Chaper/Level when List Box is off. @Seth, Thank you for doing the help page updates!
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/09bcd753036bb6f8abeeb5a523f7dfbcf770aca0 tdf#135668 add "tooltip" about "Go to Page" in Navigator It will be available in 7.1.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.
(In reply to Jim Raykowski from comment #9) > Correct, it has nothing to do with "Navigate By". I agree that a tool tip > would help matters. See patch in comment 10. > > (Meanwhile, I still think "List Box" is redundant (-: ) > I'm not following how it is redundant? I retract my statement (which was based on experience from Feb. 2020). Nothing redundant in its present behavior. Thanks for your help. No more questions. The Navigator help page should now match the current Navigator (including a note that context menus are different for each category). From there, it should be easier to see how/where to introduce this information about the Heading context menu, as requested (i.e., comment 8 is still valid).
*** Bug 136435 has been marked as a duplicate of this bug. ***
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/211ba118b3f99e2c785309403b81319bae7b1213 tdf#135668 - remove quotes around keyname in tooltip It will be available in 7.1.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 166678 [details] Possible solution about how to provide help about Navigator context menus Attached is a picture that shows an approach providing help about the context menus in Navigator. 1. It is complete in the sense of showing all the essential characteristics. 2. But incomplete in the sense that it addresses only the first 6 categories in Navigator, but the last 6 do not have any features not already shown here. 3. The "line-spacing" is a consequence of the tool used, but in .html pages, it would appear like other tables that you might know (e.g., for fields, numbering styles). I mention this because the query here is to get feedback about the way of giving an understandable overview of the available information (trying to be complete, but avoid unnecessary redundancy). 4. I will not explain the picture -- beyond mentioning that the items in "blue" are links to further information, either provided on the Navigator page or other pages with the information -- and that all the items for Headings that start with "Promote", "Demote", or "Outline" would get links.
Created attachment 166684 [details] proposal for Outline Content Visibility help in Navigator @Jim, etc. - will be grateful for your assessment of this attached proposal. A question: Am I wrong to believe that it is exhaustive (in relation to functionality)? A comment: Not all variations are listed within a heading - in the belief that less is more. That is, also adding "Hide All" for Headings seems to obscure the point. Similarly for giving "Show all" for the "level". The idea is that in explaining one, it will be easy to understand the other in context (and confusing to have to understand two variations, when learning for the first time). -- opinions? Comments about UI -- no need to answer here. 1. Given that you use "fold" to describe the operation, perhaps "Fold All" is better than "Hide All" ("fold" gives a better conceptual image from user POV). 2. For individual items, probably you have "state" information. So instead of "Toggle", why not give a state-dependent: "Fold" or "Open" ?
(In reply to sdc.blanco from comment #15) > Created attachment 166684 [details] > proposal for Outline Content Visibility help in Navigator > > @Jim, etc. - will be grateful for your assessment of this attached proposal. > > A question: > > Am I wrong to believe that it is exhaustive (in relation to functionality)? > Toggle, Show (Unfold), and Hide (Fold) are exhaustive in functionality. Concerning the word 'text' in 'Show or fold text for ...' in the proposal. Outline content includes not only text. Shapes, frames, tables, etc. get hid or shown when outline content visibility is changed. > A comment: > > Not all variations are listed within a heading - in the belief that less is > more. That is, also adding "Hide All" for Headings seems to obscure the > point. > Similarly for giving "Show all" for the "level". The idea is that in > explaining one, it will be easy to understand the other in context (and > confusing to have to understand two variations, when learning for the first > time). -- opinions? Maybe a short explanation of when both are available would help. Something like: 'Hide All' and 'Show All' are both available for headings that have sub headings with a mix of outline content visibility. > > > Comments about UI -- no need to answer here. > > 1. Given that you use "fold" to describe the operation, perhaps "Fold All" > is better than "Hide All" ("fold" gives a better conceptual image from user > POV). > > 2. For individual items, probably you have "state" information. So instead > of "Toggle", why not give a state-dependent: "Fold" or "Open" ? IIRC 'Show' and 'Hide' were deemed more favorable terms for the UI than 'Unfold' and 'Fold'. I have no opinion which is better. Changing menu item labels for toggling (Show or Hide) seemed awkward when tested by myself.
(In reply to Jim Raykowski from comment #16) Many thanks for replies. > Concerning the word 'text' in 'Show or fold text for ...' in the proposal. > Outline content includes not only text. Shapes, frames, tables, etc. get hid > or shown when outline content visibility is changed. That was also the intention. So the problem is how to say it clearly and compactly. Will think further about it -- but happy for suggestions. > Maybe a short explanation of when both ("Show All" and "Hide All") are available > would help. Something like: > > 'Hide All' and 'Show All' are both available for headings that have sub > headings with a mix of outline content visibility. The general point here is that sometimes only one and sometimes both "Hide All" and "Show All" appear, and that some indication should be given about the meaning or significance when both appear. Do I have that right? If so, no problem, in principle, to add this information. But I am not sure I understand your explanation here. And in my experiments in Navigator with "Hide All" and "Show All", I was not able to get a reliable a pattern that I could explain (e.g., some headings started with both Hide All and Show All (and toggle), but then I could not get them back to that state). Either I will need more help about how to describe the intended behavior -- -- or I will have to make more experiments, to see if I can understand the behavior to be able to summarize it clearly. > IIRC 'Show' and 'Hide' were deemed more favorable terms for the UI than > 'Unfold' and 'Fold'. I have no opinion which is better. Changing menu item > labels for toggling (Show or Hide) seemed awkward when tested by myself. Interesting to know the background....
(In reply to sdc.blanco from comment #17) > (In reply to Jim Raykowski from comment #16) > > Many thanks for replies. > Thank you for taking on documenting the feature. > > Concerning the word 'text' in 'Show or fold text for ...' in the proposal. > > Outline content includes not only text. Shapes, frames, tables, etc. get hid > > or shown when outline content visibility is changed. > That was also the intention. > So the problem is how to say it clearly and compactly. > Will think further about it -- but happy for suggestions. Something content wise I suppose. > > Maybe a short explanation of when both ("Show All" and "Hide All") are available > > would help. Something like: > > > > 'Hide All' and 'Show All' are both available for headings that have sub > > headings with a mix of outline content visibility. > The general point here is that sometimes only one and sometimes both "Hide > All" and "Show All" appear, and that some indication should be given about > the meaning or significance when both appear. Do I have that right? > If so, no problem, in principle, to add this information. > > But I am not sure I understand your explanation here. > And in my experiments in Navigator with "Hide All" and "Show All", > I was not able to get a reliable a pattern that I could explain > (e.g., some headings started with both Hide All and Show All (and toggle), > but then I could not get them back to that state). > > Either I will need more help about how to describe the intended behavior -- > -- or I will have to make more experiments, to see if I can understand the > behavior to be able to summarize it clearly. > I hope these screen shots help understanding. HideAllExample.png ShowAllExample.png HideAllShowAllExample.png > > IIRC 'Show' and 'Hide' were deemed more favorable terms for the UI than > > 'Unfold' and 'Fold'. I have no opinion which is better. Changing menu item > > labels for toggling (Show or Hide) seemed awkward when tested by myself. > Interesting to know the background.... I believe discussion of this is somewhere in the Bug 38093 jungle.
Created attachment 166712 [details] Hide All example
Created attachment 166713 [details] Show All example
Created attachment 166714 [details] Hide All Show All example
Yeah, "content-wise" -- that is good. I see now how to go forward. Thanks for visual examples, will work further with them. Have also been able to "stumble" into creating a few situations, I am starting to get a handle on it. 2 additional clarification questions. 1. As best I can tell, only possible to toggle "Outline Content Visibility" in Options dialog (or toolbar, if button is added) -- not possible to toggle in Navigator. If that is correct, then I will probably add a note about that in the Navigator help page -- for those who wonder why "Outline Content Visibility" does not appear in their context menu in Navigator. 2. In your examples, it looks like the Mac interface shows all possible options, greying out what is not applicable. In contrast, the Windows version only shows what is possible (i.e., adding or removing controls as applicable). I assume this difference does not make a difference, but just want to be sure. Thanks.
(In reply to sdc.blanco from comment #22) > 1. As best I can tell, only possible to toggle "Outline Content Visibility" > in Options dialog (or toolbar, if button is added) -- not possible to > toggle in Navigator. If that is correct, then I will probably add a note > about that in the Navigator help page -- for those who wonder why "Outline > Content Visibility" does not appear in their context menu in Navigator. > Correct, the Options dialog and user command .uno:ShowOutlineContentVisibilityButton that can be added to menus, toolbars, and assigned shortcut keys, are the only current ways to turn the feature on and off. > 2. In your examples, it looks like the Mac interface shows all possible > options, greying out what is not applicable. In contrast, the Windows > version only shows what is possible (i.e., adding or removing controls as > applicable). I assume this difference does not make a difference, but just > want to be sure. > The vcl backend used in the examples is actually gtk3 on a Linux box. I think all other backends only show what is possible instead of greying out.
Created attachment 166751 [details] Two alternative ways to introduce enabling instructions Attached are two different ways to explain the instructions about how to enable Outline Content Visibility. As explained in the attached, one is more "dramatic" than the other. I would suggest a more dramatic version if you think users should made aware that it could be "dangerous" (in this case, such things as data loss, anchors lost, frame positioning changed). Or if you assess that people are not likely to "break" things, then let's use the less dramatic. I must trust your assessment here.
Created attachment 166752 [details] Instructions for enabling, accessing, and controlling the command Attachment shows current version of "top" of the help page. (have assumed the "less" dramatic introduction here) (And thanks for explanation about vcl/unix -- as you will see, this attachment was made with Mac in mind.) Here are the questions posed in the attachment. 1. Is it ”exhaustive”? 2. Is it accurate? I understand now (from comment 23) that the "additional control" note should also mention shortcut keys. (will add in next version), so read those questions now as though "shortcut key" was also mentioned.
Created attachment 166754 [details] Updated (expanded) instructions about how to customize Attachment now shows how to customize both with toolbars and keyboard shortcuts. Also forgot to mention question 2.5 in comment 25 2.5 How to refer to Headings category in Navigator?
(In reply to sdc.blanco from comment #24) > Created attachment 166751 [details] > Two alternative ways to introduce enabling instructions > > Attached are two different ways to explain the instructions about how to > enable Outline Content Visibility. As explained in the attached, one is > more "dramatic" than the other. > > I would suggest a more dramatic version if you think users should made aware > that it could be "dangerous" (in this case, such things as data loss, > anchors lost, frame positioning changed). > > Or if you assess that people are not likely to "break" things, then let's > use the less dramatic. I must trust your assessment here. I think the less dramatic version is fine with an addition of (may be unstable) which then would match the 'Enable experimental features (may be unstable)' checkbox label.
@Seth, answers to questions asked in instruction attachments with some additional comments. definitions: "outline heading paragraph" is a paragraph with a style that has outline level set to a numeric value 1-10 "outline content paragraph" is a paragraph with a style that has outline level set to 'text' and has an outline heading paragraph somewhere previous to it. > 1. Is it ”exhaustive”? There is an other way to toggle outline content visibility other than the user control, canvas buttons or Navigator context menu. Pressing ctrl key with the mouse pointer positioned on an outline heading paragraph changes the pointer image to a hand pointer that when left mouse clicked will toggle outline content visibility of following outline content paragraphs until the next outline heading paragraph. If there are sub outline level paragraphs (paragraphs with outline level greater than the paragraph outline level clicked on), right click will also toggle content visibility of sub levels. On canvas outline content toggle buttons that appear in the left margin next to outline heading paragraphs have ctrl+left and right mouse button actions that toggle content visibility of sub outline levels. Tooltips are displayed to aid what can be done. > 2. Is it accurate? If there is already a help page about how to customize, maybe a link to it with mention of the user commands that can be added to control this feature. 'Show outline content visibility button' user command enables and disables display of outline content visibility control button on the document canvas. ' 'Toggle Outline Content Visibility' user command toggles outline content visibility relative to cursor position. > 2.5 How to refer to Headings category in Navigator? A paragraph outline level is set by the applied paragraph style either by default or explicitly. To examine the paragraph outline level, right click on a document paragraph to access the Paragraph context menu, select Paragraph -> Paragraph... or Paragraph -> Edit Style... then Outline and Number tab in the dialog that appears. Knowing Headings category entries are simply paragraphs having an outline level set to 1-10 may be helpful to understand how the 'Headings' category in the Navigator is populated and how to refer to the Headings category in Navigator. Additional comments: The steps to enable experimental features seem different on Linux than mac. NB, have shown ”Mac” version here, but ”help” is sys-dependent, so for Win or Unix, command sequence starts with ”Tools – Options” to open Options dialog.) I didn't know about help being sys-dependent and was going to comment that the sequence to follow in the image was different than what I see. Hide followed by open seems awkward to me. Hide followed by show seems to flow better together. Optionally fold and unfold, collapse and expand, close and open would work.
@Seth, I just read your comment at https://bugs.documentfoundation.org/show_bug.cgi?id=137236#c11 I see you already have the concept of what makes a paragraph an outline heading or possibly an outline content paragraph :)
(In reply to Jim Raykowski from comment #29) > I see you already have the concept of what makes a paragraph an outline > heading or possibly an outline content paragraph :) (-: But your detailed discussion has made it apparent that it would be good to present the page in a way that also takes account of the fact that some who read the page will know know about outline levels. I will add some links in the "Related Topics" section at the bottom. Meanwhile -- the intention in my question 2.5 about "Headings" was much more banal. Let me try again. As you know, the "To access" currently says: In Navigator (F5) (for Headings) And as you also know, there are different "parts" of Navigator (I do not know what they are called -- so I make up some terms here: the navigation panel across the top, and the "Content Window" with the different icons (Heading, Images, Bookmarks, etc.). So -- I considered an alternative like: In Navigator (F5) (for Headings in Content View) (but I was uncertain if "Content View" was a "technical" term, or if that Window should be called something else) -- which motivated question 2.5. Actually, the alternative looks better to me -- but maybe it creates confusion if "Content View" could not be understood or guessed. "Content Window"? (nothing critical here -- but while the paint is still wet, now is the time for small adjustments.)
(In reply to Jim Raykowski from comment #28) > @Seth, answers to questions asked in instruction attachments with some > additional comments. Many thanks for answers. So it starts to appear that the boundaries are marked off (i.e., all relevant topics have been mentioned), and reasonably accurate (just need to tighten the screws and remove sharp edges). > If there is already a help page about how to customize, maybe a link to it > with mention of the user commands that can be added to control this feature. Ok. Will add in "Related Topics" > 'Show outline content visibility button' user command enables and disables > display of outline content visibility control button on the document canvas.' > > 'Toggle Outline Content Visibility' user command toggles outline content > visibility relative to cursor position. Was a little uncertain here. Did you see attachment 166754 [details]? I can see your descriptions are a little different than mine -- so I will adopt yours. (The attachment shows this as a "note"- but I am planning to take it out of "note", which will give more room for explaining.) > The steps to enable experimental features seem different on Linux than mac. They are. > I didn't know about help being sys-dependent It is only when (a) a human is aware of and knows the differences and (b) adds a switch in the code. The web browser does the rest. > Hide followed by open seems awkward to me. Hide followed by show seems to > flow better together. Optionally fold and unfold, collapse and expand, close > and open would work. Just to be sure: This is referring to the very first line at the top, after the "Title". "Hide and show" seems like the best choice -- consistent with command names in context menu. (BTW, this first sentence risks being used (embedded) in other help pages (because then it does not have to retranslated), so it is worth getting it right.
Created attachment 166791 [details] Using mouse with Outline Content Visibility Attached .png shows help text for using mouse. (It was prepared before your latest, extensive discussion about mouse, so the point about "Ctrl" is missing. I will add for the next version.) I was going to ask as before: Exhaustive? Accurate? But now I will assume that you have given me the "exhaustive" answer. But it is still relevant to check that my descriptions are accurate Additional comments: 1. "right-click" instructions are based on what you wrote in the Release notes, but rewritten some what - so please give extra attention to that formulation. I think you have given additional information in your latest reply, so that must be worked in. (also, you should look at the last sentence about Outline Content Visibility in the Release notes. Looks like some words were supposed to be deleted, but weren't.) 2. I also discovered that I probably got the idea of folding "text" from the Release notes. You might want to change it to "content" (-:
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/79d9996623c1896170aec53c788f9623df7731e0 Mostly resolved: tdf#135668 - Help for Navigator context menus in Content View
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/5ff0399475618e2991e2544c3b685085f8ea7111 tdf#135668 fix a couple of links in Navigator help page
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/f803f33413ed171305013ecdc65084eda8f58d11 Resolves: tdf#135668 + relevant to: tdf#136435 Outline Content Visibility context help in Navigator
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/dacdc705fa872112af67b9c38eb56d3656bf20e8 tdf#135668 - repair links in outline content visibility help page
The Navigator help page is updated to include information about all the context menus, not only for Headings, plus added information about Outline Tracking, and there is also a place for Outline Content Visibility. Some patches with corrections were also submitted last week, but the online help has not been updated from master. Will close this as FIXED.
I can see the new informations in https://help.libreoffice.org/7.2/en-US/text/swriter/01/02110000.html?&DbPAR=WRITER&System=WIN As far as I can see there is nothing to add => VERIFIED FIXED