Please, add screenshots of OmniOutliner on the Mac and Ecco Pro on Windows if available.
And enumerate needed functionality

Created attachment 56266 [details]
Ecco Pro Outliner Screenshot

Created attachment 56267 [details]
Omnioutliner Screenshot

Created attachment 56268 [details]
Outliner showing text style options

I've attached the desired screenshots. About the request for functionality: there's a good introduction to the features of typical outliners on this web page: http://www.atpm.com/9.10/atpo.shtml

The vital features (listed on that page) are:

1. Nesting. Any item in the outline can have sub-items, which can themselves have sub-items. (The Outline View in Impress can show only one level of sub-items, but multiple levels are really needed if it is to be used as an outlining tool. Outlines in Writer are already fine in this respect).

2. Promoting/Demoting. This is the vital missing part. Each item should have an associated icon that allows it to be grabbed and moved either up and down to change the order of items in the outline hierarchy or left or right, to change its level in the hierarchy. Sub-items are automatically shifted along with their head item.(Whether the Outline view in Impress or the outline function in Writer is taken as the basis for developing the LibreOffice outliner, then this functionality is entirely missing). The icon is generally a triangle. The triangle points at the associated item if sub-items are hidden ("collapsed") or down, if they are not. A click on the icon changes the direction in which it points and whether the sub-items are visible.

3. Each item should be able to hold one or more paragraphs of text, so the outliner could be used to write long, well-structured documents.

4. Where paragraphs are used, they should be able to be "folded," so only the first line is visible. This helps to concentrate on the structure, rather than the content of the document. Unfolding allows the content to be worked on.

5. Styles. Each level in the outline hierarchy should have an associated style.

Comment on attachment 56267 [details]
Omnioutliner Screenshot

This screenshot shows how whole paragraphs of information can be integrated in an outline.

Comment on attachment 56266 [details]
Ecco Pro Outliner Screenshot

This shows the interface of a typical single-pane outliner. The blue dots are handles which can be grabbed and moved within the hierarchy, either up/down or left/right. Clicking them shows or hides sub-items associated with the head item. In this case the "Bills" item has hidden sub-items (as indicated with a small black triangle by the blue dot). The "Stuff" item has its sub-items visible.

(In reply to comment #9)
> Thanks for good explanation. It is interesting idea. 

It's a critical idea. 
Single pane outliners with the ability to organize visually and move large blocks of text are critical to writing and publishing. 
I know many writers and most use Macs just to get OmniOutliner, which is the gold standard for writers and academics right now. I teach and belong to a professional writers' group and every serious published member seems to have a Mac running OmniOutliner except me. 
There are also several other good single-pane outliners for Macs. 
On Windows the best is the discontinued EccoPro. MSOffice has an okay one that my students have to use to learn to outline. 
Linux has nothing at all. 
Currently I draft using Scite and the CSS stylesheet function to get a good nesting outline. It's far from ideal and I have {{{ brackets and strange colors all over the place. I also run Notepad2 with code folding, which runs well in wine. N2 has keystrokes to move blocks of text up and down. Coupled with the outline function, that makes this tiny program very useful for drafting. 
LO's Navigator is good when you have a finished document, but nearly useless for brainstorming and organizing. Moving back and forth is a time-consuming. I would work entirely from the navigator panel if I could, but of course you can't edit the navigator panel. 
Dave Winer's OPML editor might provide some interesting open-sourced code.
This is more than an interesting idea. This is a critical function. My only quesstion is whether it should be a view in LO's writer or be made a special outlining program. I could do without formatting, fonts, publication views and so on to really be able to organize lots of text.

Noticed this request/forum after already posting this: http://ask.libreoffice.org/question/2596/text-folding-pretty-please

Please add folding text functionality to the next release of Writer or give advice on how to make add-on.

Additional Comments:
For brain storming, outlining, studying, code writing, drafting documents, or helping the reader brief documents quickly, Folding text/collapsible outlining is a must! It makes the tasks listed not only possible but a breeze. 

The programs which already offer this feature are EXTREMELY poor word processors. They DO NOT compare to MS Word or Libre Writer.  Writer needs this capability as it will give them a huge advantage over OpenOffice and MicrSoft.

Additional Suggestions for Functionality.  Yes, the General FoldingText/Outlining available capability in MS Office and omin outliner is good, but if Libre Office is developing this, while add it these features should be considered:

- Yes, the paragraph summary displaying "only the first sentence", but also...

- Additional Summary/Folding Options: the option to customize what is displayed in place of the full text (ie, customize the summary item that is displayed in place of the full text).
        Txt summary item may be either:    
         i.   PreDefined text (ex, "+", "note", "...", "Summary", a bullet)
         ii.  Auto Enumerated text- (ex "exhibit", "exhibit2", "par1", "par2")
         iii. Auto text Summary of:
                only the First Paragraph.
                only the First Sentence.
                only the First line.
                until page full, but not more than 2 lines, & at least 1 line.
         iv.  Any Custom Text/Field. examples
                "(click to see examples)"  
                "Class Notes [Date]."
          v.  Any picture or other item.
 
        ***In all instances***: 
            1. ability to format summary item (be it text or pic) like any other text or pic in the doc.
            2. ability to not allow or to allow the editing of the summary item.
            3. method indicating inlinetext is summarized (ex, highlight on mouse over)
       

NOTE: The following feature MIGHT not be able to be added with a single script project, but probably need to be separate scripts, but still should be packaged as one add-on with previous features.

- Inline Summary of ANY string of words/symbols/or inline pictures (not limited to a whole paragraph).  
DESCRIPTION: Highlight any inline item (words, pictures, etc), click a "summarize" button, user is given option to condense (hide) highlighted text and display only the summary item (which could be any text specified by user, a bullet like "+", a picture, or text box).  The summary item is formatable and inline with the text around it, editable just like any item in the doc. But, being a summary item, right clicking it will give the additional option to show hidden text, and vice versa.  And right clicking on hideable text will give the additional option to display only the summary (the summarized item).  

- In-Line Text Preview for embeded or linked documents.  
DESCRIPTION: The embeded/linked document would be represented by a summary item.  The summary item can be any user defined item (ex "{...}", a long or brief description, a bullet, or image). But Writer should also give an additional option in the case of embedding or linking a document: the option to make any portion of the embeded/linked document the summary item, NOT allow any change to that summary item (except formatting), BUT updating the summary item when the linked document/embedded document changes.  Finally, right clicking the summary item will give the additional option to open the document.

Added related Apache OO issue to See Also list. Version set to Inherited From OOo. Bug 38262 would appear to be a duplicate.

(In reply to Susan Cragin from comment #10)
> (In reply to comment #9)
> > Thanks for good explanation. It is interesting idea. 
> 
> It's a critical idea. 

Use jedit; see: https://bz.apache.org/ooo/show_bug.cgi?id=3959#c245

With 325 comments, this ticket's sibling on the OO side is by far the most commented there: https://bz.apache.org/ooo/show_bug.cgi?id=3959#c325

Writer's keyboard shortcuts to 'Promote/Demote One Level' and 'Move Up/Down with Subpoints' work well with bullet lists but disappointingly not with title levels... Extending their use to titles would be a nice way to start alleviating the outlining pains in Writer without having to incur the high cost of implementing a new view.

Also, those who wish some perspective on the state of the art might want to look at those few examples...

A non-WYSIWYG example in the deceptively spartan Vim, The Vim Outliner:
http://bike-nomad.com/vim/vimoutliner.html - it does everything a classic
outliner does, as its documentation explains:
http://bike-nomad.com/vim/README.otl.txt

A cross-Apple example - Apple only, but the UI scales across the whole product
range from phone to desktop: https://www.omnigroup.com/omnioutliner/#Write -
autistic software, but functionally very nice.

A web-based example: https://www.theoutlinerofgiants.com - utterly removed from
the desktop world, but perfect for those newfangled youths who were born in a
browser... And it has an example structured document that happens to be a
great dissertation about the outliner nature:
https://www.theoutlinerofgiants.com/outliners

From that one, for some nice historical examples I recommend the sections
covering Wordperfect and FullWrite Pro at http://www.atpm.com/10.03/atpo.shtml

I've been following the OO bug almost since its beginning.  Unfortunately, the discussion there has been somewhat polluted by rancor between commenters.  Consider this a heartfelt plea to avoid this happening here!  Please, folks, keep your comments relevant to the desired feature.  If you have a taste for flame wars, please take them elsewhere.

As a small contribution to this bug, I offer a description I gave several years back of the outlining capability of Ecco Pro, a Windows PIM: http://www.compusol.org/ecco/outlining.html.

To be clear, Ecco is not a candidate for an outlining component of a word processing application or suite.  However, I've been using it for well over a decade as a project/task organizer and tracking tool.  The main reason for posting it here is the ease of managing outlines, including easy restructuring as needed.  It might be useful to review Ecco's outlining functions when designing the outliner for LO.

In the migration from one system to another, my comments have been lost, but I have been very vocal about this need. I want to echo the previous commenter: The outliner in Word is so superior to anything similar in LibreOffice that I will never use LibreOffice until something as good is present here. 

In the 1980s, prior to the wide acceptance of Word, I wrote all of my magazine articles for eight years using a primitive outliner named PCOutline. The outliner functions were so absolutely important to me that I was not tempted by anything else until I was convinced that Word's outliner was actually an improvement--for instance, because I could use a mouse for editing.

I'm always concerned about what I would do if I no longer could use Word's outliner, so I've made a study of everything I can find. WPS Office from China is an okay outliner, and if I were forced to choose between LibreOffice and WPS Office, I would choose the latter because of the outliner.

The functions of an outliner that I love:
1) I can brainstorm in text points and then drag and drop these brainstorms into headings that I generate on the fly.
2) When a heading gets too bloated for convenient dragging and dropping, I can collapse it and continue dragging and dropping until the job is done.
3) Within each heading, I can create subheads and organize the points in that heading into the subheads through dragging and dropping.
4) I can create subheadings to nine levels, collapse all of the text points, and organize the entire document by dragging and dropping. When I move a heading with collapsed text, all the text goes with the heading, as well as all of the children subheadings.
5) I can easily switch back and forth between outline view and draft or print view. When doing so, formats of headings and text are preserved, but all collapsed text and subheadings are visible in the draft or print view. 
6) Word outliner view allows all text to be collapsed to a "Show First Line" view. In this view, I see only one line for every paragraph in the document. This enables extremely efficient reorganization of paragraphs.

The benefits of an outliner which I will never abandon for a straight word processing program:
1) Brainstorms can be quickly organized to a very granular level without any loss of time.
2) Documents can be totally reorganized in seconds or minutes. 
3) Outliners replace project management software by enabling whole project planning, detailed subproject planning, and efficient integration of all levels.
4) To-do lists do not become obsolete, but just get reorganized into the new plan.

(In reply to Cougar Brenneman from comment #27)

So everything you wrote sums up to only this? "LibreOffice cannot do #6 from the list; everything else is easily done using Navigator".

Mike Kaganski(In reply to Mike Kaganski from comment #28)
> (In reply to Cougar Brenneman from comment #27)
> 
> So everything you wrote sums up to only this? "LibreOffice cannot do #6 from
> the list; everything else is easily done using Navigator".

No, LibreOffice cannot do everything up to this point. When I can't use MS Word, I use WPS Office because it has the features I'm describing. I have the latest LibreOffice on my computer, and it does NOT.

Let's try again. 
1) In Outliner View, Word puts a little button in front of every paragraph or heading that you can use to drag and drop. This is a key feature which is not at all available in OO.
2) In Outliner View, all text below any heading can be hidden. This creates a headings only view.
3) In Outliner View, all headings which are children of a selected heading can be hidden. This can, for instance, create an "h2 and above view" or an "h3 and above view."
4) Text paragraphs can be viewed with only the first line showing.
5) In Outliner View, when you drag and drop that little button icon in front of the paragraph or heading, all of the hidden text and headings go along with the heading that you're dragging. BY DRAGGING AND DROPPING THAT SINGLE BUTTON, you can drag 10,000 hidden words from below 10,000 other hidden words, and drop them in the new location. Then you can collapse those 20,000 words under a different heading, and drag them invisibly to another new location. Then you uncollapse all of the sections, hide all but the first lines of the entire page, and drag paragraphs into new positions before displaying the whole paragraphs that you've dragged around.

I HATE the fact that when I can't use Word, I have to put the security of my system in the hands of the Chinese (with WPS Office), when the Chinese have a history of malicious hacking. 

With both Word and WPS Offices, I can perform this magic.
With OO,  I canNOT perform this magic. This makes OO a VASTLY inferior product.

(In reply to Cougar Brenneman from comment #29)
> Let's try again. 

Ok.

> 1) In Outliner View, Word puts a little button in front of every paragraph
> or heading that you can use to drag and drop. This is a key feature which is
> not at all available in OO.

Ok; agreed - I missed that those "text points" you were mentioning are normal paragraphs; yes, this is missing.

> 2) In Outliner View, all text below any heading can be hidden. This creates
> a headings only view.

The Navigator's headings provide you just that: a heading only view.

> 3) In Outliner View, all headings which are children of a selected heading
> can be hidden. This can, for instance, create an "h2 and above view" or an
> "h3 and above view."

The Navigator allows you to collapse any heading's children. Also, it allows you to limit view to only N levels, hiding all levels below L (say, only level 1 and 2 would be visible).

> 4) Text paragraphs can be viewed with only the first line showing.

This one was the one I agreed to in comment 28. No need to reiterate.

> 5) In Outliner View, when you drag and drop that little button icon in front
> of the paragraph or heading, all of the hidden text and headings go along
> with the heading that you're dragging. BY DRAGGING AND DROPPING THAT SINGLE
> BUTTON, you can drag 10,000 hidden words from below 10,000 other hidden
> words, and drop them in the new location. Then you can collapse those 20,000
> words under a different heading, and drag them invisibly to another new
> location. Then you uncollapse all of the sections, hide all but the first
> lines of the entire page, and drag paragraphs into new positions before
> displaying the whole paragraphs that you've dragged around.

Dragging isn't working in Navigator (for some unclear reason); still, there are "Promote/Demote Chapter" and "Promote/Demote Level" buttons on the Navigator's toolbar, which do just that: move chapters with everything inside them (all those thousands paragraphs and included sublevels).

> I HATE the fact ...

This is totally irrelevant. The discussion here isn't about anyone's personality and feelings; it's about figuring out what needs addressing (and that's why I jumped in and try to clarify what is really missing, and what is already present - and thus not needed in this discussion, because it only clutters it and makes the issue unmanageable).

@Heiko, * -- can we add this to the Design/UX pile...

Need to scope functional requirements (for a document viewshell and also enhancing Navigator) for implementing an Outline View layout and editing mode for Writer, with an eye toward a GSOC project (or two). And/or preparing same for a crowd funded dev effort.  

Getting the UI requirements hammered out has not occurred in any fashion in the OOo era, nor with AOO, nor in any of the LO Bugzilla dupes. Jean-Marc Liotier started requirements [1] on Wiki in 2014, but they have languished.

And, guess that if any additions to ODF are needed to hold a document in an Outline View, that has to started as well.

=-ref-=
[1] https://wiki.documentfoundation.org/Outline_view

*** Bug 58105 has been marked as a duplicate of this bug. ***

Video & documentation which might be of interest for the LibreOffice Design Team at https://bugs.documentfoundation.org/show_bug.cgi?id=47746#c31

8 duplicates, 33 people in CC - so let's do it. 

We need a command to collapse all paragraphs below a certain heading. Headings show an icon on hoover that allow to collapse on click, and always show another icon to expand. The same command should be available at the Navigator.

Jim, is this kind of easyhack for you or rather worth a GSoC project next year?

Heiko, this would be great!
But it is not enough.
What we need is a drag and drop of headings from one level to the next.

If you see in your navigator these headings:

H1

h1 
h2
h3



H1a

h1a 
h2a
h3a

======================
let me take h2a in the navigator with the mouse and drop it somewhere else
and have as result this:

H1

h1 
h2a
h2
h3


H1a

h1a 
h3a

and one more feature that is needed:

you also need to be able to easily promote or demote a paragraph in the hierarchy.

(In reply to Heiko Tietze from comment #42)
> 8 duplicates, 33 people in CC - so let's do it. 

Just a note to avoid false expectations like in comment 44.
That design tram sees it useful (based on user demand) and sees no problems for the design team if that is implemented (which is expressed by those "so let's do it" words) does not mean that someone decided to work on that. It needs some interested developer ... so don't hold your breath, I wouldn't be surprised that it stays another decade this way.

*** Bug 47746 has been marked as a duplicate of this bug. ***

OK, since bug 47746 (and its dupes) have been dropped here--are we considering now that scope of work on an "Outline view" would include the document shell work to "collapse / expand" and reposition paragraphs and other objects on document canvas?

Yes the features go together--but should bug 47746 "Collapse-expand" run as its own feature enhancement?

(In reply to V Stuart Foote from comment #49)
> ...should bug 47746 "Collapse-expand" run as its own feature enhancement?

Made one a duplicate of the other. We do have an outline view with the Navigator, the examples show collapsed headings as "outline view". My take: Solve one and get the other for free.

(In reply to Heiko Tietze from comment #50)
> (In reply to V Stuart Foote from comment #49)
> > ...should bug 47746 "Collapse-expand" run as its own feature enhancement?
> 
> Made one a duplicate of the other. We do have an outline view with the
> Navigator, the examples show collapsed headings as "outline view". My take:
> Solve one and get the other for free.

OK, I've no real concern with merging--but I think the requirements work will confirm that support 'only' from the Navigator will not suffice. 

And that the document shell will need work done to support collapsing objects (not hiding content, just suppress it in blocks for the on screen layout) and expanding (fully exposing to page layout on screen).

In this mode the pagination would no longer be shown as calculated--just the line starts, headings, object captions, etc. representing the objects.

Plan/design for that and the enhancement can be merged.

(In reply to V Stuart Foote from comment #51)
> And that the document shell will need work done to support collapsing...

See my comment 42

> In this mode the pagination would no longer be shown as calculated

Yes, that needs consideration.

(In reply to Heiko Tietze from comment #52)
> (In reply to V Stuart Foote from comment #51)
> > And that the document shell will need work done to support collapsing...
> 
> See my comment 42
> 
> > In this mode the pagination would no longer be shown as calculated
> 
> Yes, that needs consideration.

Sorry, yes I just read that again and noticed you'd suggested support of collapse when document is organized with heading levels. And that certainly tracks with some of Jim's recent work on Navigator's heading objects.

+1, and gets this underway although rigidly linked to templated headings.

But what of other documents, e.g. a 4 or 5 page manuscript with Default or Text Body style paragraphs with some mix of images, tables, charts. Documents more representative of the vast majority of documents being prepared in Writer by our Benjamin users.

Seems they could be supported equally well for the Benjamin users without imposing rigor of working with Headings--as suggested here and in multiple dupes--by collapsing paragraphs down to their first line, and allowing writer docshell movements in that mode. 

Could the Headings mode in Navigator be made aware of Paragraph objects outside Heading objects, i.e. having a "no-heading" attribute?

Created attachment 160171 [details]
video of outline folding from Writer Navigator

Hi all, 

Here is effort that implements outline folding in the document from the Navigator. 

https://gerrit.libreoffice.org/c/core/+/93241

(In reply to Jim Raykowski from comment #54)
> Created attachment 160171 [details]
> video of outline folding from Writer Navigator
>...

@Jim, cool!  Shows it is feasible, but likewise that it probably needs a more 'visual' control/indicator (on the Sidebar deck, and on document canvas) as the Navigator deck's context menu 'Fold in document' / 'Unfold in document' alone is going to be too cumbersome. It makes the UI for the feature feel heavy...

Likewise don't forget needs of keyboard drivers, so lay down accelerators early.

But it is a great start!

Thanks Jim for both your contribution and for the video in comment 54 above :) This is fantastic. And videos are useful for users who are not software engineers. But interested to contribute to LO.

- - - - - - - - - - - - - - - - - - 


Strengths

• A first benefit of using the Navigator like you did in your video is that many users are familiar with this Navigator. As it's being around for a long time. So it's likely that end-users would have an easier learning curve about the collapse and expand new features.

• A second benefit of using the Navigator is that in very large document, it's sometime much easier to use the Navigator than the Document canvas. The Navigator shows a summary of the whole document Headings. Compare to the Document canvas with with very large documents the users would have to do lots of scrolling up and down.

• In the Navigator, the wordings "Fold in Document" and "Unfold in Document" are concise. Which looks & feels clean and uncluttered.

• The collapse and expand are very fast & responsive :)

- - - - - - - - - - - - - - - - - - 


Challenges


Here are three challenge below. With suggested resolution. Feel free to choose any other resolutions or design to your liking. The following are just suggestions for your consideration.


Challenge 1

• Within the Navigator, the wording "Fold in Document" & "Unfold in Document" might be cryptic & not clear for some users using the English version of LO. 
This is a suggested resolution. How about using terms most users are more familiar with? Such as "Expand Heading" or "Collapse Heading"
One benefit with those wordings is that they make it clear that there is a relationship between the Document Headings and the Collapse or Expand features.

The number 3 in this mockup I made today show this suggested wordings resolution at https://i.postimg.cc/Pxc45tX9/Mockup-Navigator-Expend-or-Collapse-Expand-All-Headings-and-Collapse-All-Headings-v2.jpg


Challenge 2

• The "Fold in Document" & "Unfold in Document" would likely meet the need of users with small LO Documents. But for very large Documents it would likely not. I mean if a small Document has 10 headings, it's realistic for the user to click up to 10 times to collapse or expand heading to her/his liking. But if a large document has 10,000+ headings, it's not realistic for the user to click up to 10,000 times. 
This is a suggested resolution. How about this, within the Navigator, add a new top menu titled "Expend/Collapse", then add those two additional sub-menu. I mean this workflow: 
1. "Expend/Collapse" ---> "Expand Heading"
2. "Expend/Collapse" ---> "Collapse Heading"
3. "Expend/Collapse" ---> "Expand All Headings"
4. "Expend/Collapse" ---> "Collapse All Headings". 

What those options do is self explain. For example, with a large Document the user could start by clicking on "Collapse All Headings". Then use the other "Expand Heading" option with only a few headings which are presently of interest.

The numbers 1, 2, 3 in this mockup show this suggested resolution at https://i.postimg.cc/Pxc45tX9/Mockup-Navigator-Expend-or-Collapse-Expand-All-Headings-and-Collapse-All-Headings-v2.jpg

Created attachment 160201 [details]
Mockup Navigator Expand Collapse---v3

I fixed my typos in this mockup version 3. I'm new to this "Attachments" form. Learning it.

@Francewhoa, Thanks for contributing the mock up and ideas. I didn't put a lot of thought into the UI. The main focus of this first patch set is proof of concept.

For the Navigator UI there needs to be a way to distinguish between the Navigator tree and the in document collapse/expand operations.

As of yet, I haven't a clue how to do an in document UI for this. Perhaps something similar to what code editors do for code block folding by using a symbol in the margin. There is also the hover over idea. 

Lots of interesting and fun challenges ahead.

Good morning Jim Raykowski, V Stuart Foote, and all contributors :) I agree with both Jim and V Stuart about a more 'visual' indicator on the document canvas. In addition to the handy Navigator.

The challenge is that the Navigator is very useful for advanced LO users. But many newcomers or beginners are not yet familiar with this advanced-blackbelt-ninja-Navigator.

Feel free to choose any design to your liking. The following are just suggestions for your consideration.

In summary, how about adding small tapable/clickable triangles inside the document canvas left side margin?

- - - - - - - - - - - - - - - - - - 


Below is the same suggestion as above. But with details. Including suggested mockups and workflow I made to facilitate communications.

How about adding small gray triangles (gray carets) to the LibreOffice Document canvas left side margin? Those triangles would allow those beginner users to easily & quickly use the collapse and expand feature within the document canvas? WIth folding symbols & hover over. Which Jim mentioned in his comment 60 above. 

- - - - - - - - - - - - - - - - - - 


Mockups Triangle Five Suggested States

State 1: Hidden
https://bugs.documentfoundation.org/attachment.cgi?id=160240

State 2: Expanded gray triangle
https://bugs.documentfoundation.org/attachment.cgi?id=160241

State 3: Expanded blue triangle
https://bugs.documentfoundation.org/attachment.cgi?id=160242

State 4: Collapse blue triangle & collapse heading content
https://bugs.documentfoundation.org/attachment.cgi?id=160243

State 5: Collapse gray triangle
https://bugs.documentfoundation.org/attachment.cgi?id=160244

- - - - - - - - - - - - - - - - - - 


Suggested Workflow

1. User opens a LO Writer .odt document. The number 1 in this mockup shows this at https://bugs.documentfoundation.org/attachment.cgi?id=160240
Assumptions:
• Assumes the triangle is hidden by default. So that the canvas feels and looks clean and uncluttered.

2. User moves the mouse over the Heading. In other words, a mouse over. In this example a mouse over the heading titled "Uberschrift 62". A gray triangle is display within the left side margin of the canvas. The number 1 in this mockup shows this at https://bugs.documentfoundation.org/attachment.cgi?id=160241
Assumptions:
• Assumes the triangle is a light gray. HTML #d9d9d9. So that the triangle is less visible than the heading and most other items within the canvas area.
• Assumes the triangle is pointing down. Which visually means expanded. Users are familiar with this visual meaning. Which is the same as the meaning inside the Navigator. So easier learning curve for users. Which means a more pleasant user experience.
• Assumes if the user moves the mouse away from the heading "Uberschrift 62", the triangle is automatically hidden. So that the canvas area looks and feel uncluttered. 

3. User moves the mouse over the triangle, the triangle shift color from gray to blue HTML #3daeea. The number 3 in this mockup shows this at https://bugs.documentfoundation.org/attachment.cgi?id=160242
Assumptions:
• Assumes this blue color is the same blue as a selected heading row within the Navigator window
• Assumes the blue color visually communicate to the user that this item is clickable
• Assumes if the user moves the mouse away from the triangle, the triangle color shift from blue to gray

4. User left clicks on the blue triangle. The triangle shift from pointing down to pointing right. The number 4 in this mockup shows this at https://bugs.documentfoundation.org/attachment.cgi?id=160243
At the same time, the heading collapse. In other words the heading content is hidden. The number 5 in this mockup shows this at https://https://bugs.documentfoundation.org/attachment.cgi?id=160243
Assumptions:
• Assumes the triangle is pointing right. Which visually means collapsed. Same meaning as the other triangles in the Navigator.
• Assumes within the Navigator, the associated heading and its sub-heading(s), if any, would automatically collapse. In other words, to collapse an heading, the user could either left click on the blue triangle inside the canvas, or right click on the heading inside the Navigator. Then navigate the menu to "Expand/Collapse ---> Collapse Heading".
• Assumes if the heading has sub-heading(s), and the user clicks on the top heading, then all associated sub-heading(s) are automatically collapsed. So that it's easy and quick to collapse or expand multiple headings within a large Writer document. In other words, this collapse & expand feature is able to scale up. For example, if the user collapses this "Heading 1" below, then the associated sub-headings ranging from "Sub-heading 1.1" to "Sub-heading 1.200" are automatically both collapsed and hidden. Only the "Heading 1" remain display with a permanently display gray arrow. Which is pointing right.

Example
  Heading 1
     Sub-heading 1.1
     Sub-heading 1.2
     Sub-heading 1.3
     [etc]
     Sub-heading 1.200
   Heading 2
     Sub-heading 2.1
   Heading 3

Where "[etc]" above means that to facilitate communications, all other sub-headings ranging from "Sub-heading 1.4" to Sub-heading 1.199" where not include in this example

5. User move mouse away from the blue triangle. The triangle shift from blue to gray. The number 6 in this mockup shows this at https://bugs.documentfoundation.org/attachment.cgi?id=160244
Assumptions:
• Assumes that after the user move the mouse away from the gray triangle, the triangle is permanently display
• Assumes the state of the triangles are persistent. Meaning if the user do use any triangle(s) to collapsed heading(s), then after closing the Writer document, then re-opening it, all triangle states remains. They are not lost.
• Assumes the gray triangle permanently display visually communicate to the user the this heading is presently collapsed. This reminder is increasingly useful and needed as time passes. For example, if the user does not use this Writer document for more than one year. Then after that period re-open it. The permanently display gray triangle visually reminds the user that this heading is collapse. Without this gray triangle permanently display, there is a risk that the user might misinterpret the hidden heading content as somehow deleted content, or a bug with the content.


6. In the future, when the user needs to expand this heading "Uberschrift 62". First the user moves the mouse over the gray triangle. The triangle shift from gray to blue. The number 4 in this mockup show this at https://bugs.documentfoundation.org/attachment.cgi?id=160243 
Then the user simply click on the blue arrow. Next the triangle shift from pointing right to pointing down. At the same time the heading content is display. The number 3 in this mockup show this at https://bugs.documentfoundation.org/attachment.cgi?id=160242
Assumptions:
• Assumes after this step 6, optionally and if the user needs to do additional operations, the user would go through the same workflow as above. For example, starting with step 1 above to collapse a new heading.

- - - - - - - - - - - - - - - - - - 


Notes

• This 3 minutes video might be of interest for inspiration and improving on. It shows the collapse and expand in MS Word 2016 at https://youtu.be/aft_4mcaxHU?t=31
This video includes audio with more information.
This is the same full video with an introduction at https://youtu.be/aft_4mcaxHU

Attribution to Professor Adam Morgan for this video above. This video shows the relationships between the MS Word 2016 Navigation/Navigator operations and the Canvas operations. I like most of the workflow in MS Word 2016 except one thing. My vote goes for not using the 45 degree triangle state. Because this is risky to be confusing for end-users. I mean there is little or no value for this state. Or maybe I missed something about its value. By "45 degree triangle state" I mean this weird looking triangle. Which in using an additional triangle states with a triangle rotated at 45 degree. Or maybe I'm missing somethign about the usefulness of this "45 degree triangle". The numbers 1 and 2 in this screenshot show this "45 degree triangle state" at https://bugs.documentfoundation.org/attachment.cgi?id=160245

To resolve this challenge above I suggest to use the simplified & cleaner LO "Suggested Workflow" above. Where the gray triangle is expanded & pointing down. The number 2 in this mockup show this at https://bugs.documentfoundation.org/attachment.cgi?id=160241

• About the Navigator and the naming of the menu items, this related documentation from WS Word might be useful for inspiration at https://archive.md/5R8UO#selection-1307.0-1329.61

Created attachment 160269 [details]
video of uno command use for outline folding

Francewhoa, nice job explaining in detail that part of the UI. I have found that the line number and change tracking features use the margin areas similar to as described. Most likely this will take some time for me to accomplish.

One question. Would a user ever want to only fold a parent and not it's children? This doesn't seem to be possible in the details given.

I have made additional effort that adds a menu item to the document context menu for folding and unfolding. This is done by creating an uno command, .uno:FoldOrUnfoldOutline, that can be added to toolbars and menus. A keyboard shortcut can be assigned to fold and unfold headings without mouse use. For code details please see patch set 2 at the gerrit link given in comment 54. For usage example please see attached demo.

(In reply to Francewhoa from comment #56)

> 
> Challenge 2
> 
> • The "Fold in Document" & "Unfold in Document" would likely meet the need
> of users with small LO Documents. But for very large Documents it would
> likely not. I mean if a small Document has 10 headings, it's realistic for
> the user to click up to 10 times to collapse or expand heading to her/his
> liking. But if a large document has 10,000+ headings, it's not realistic for
> the user to click up to 10,000 times. 
> This is a suggested resolution. How about this, within the Navigator, add a
> new top menu titled "Expend/Collapse", then add those two additional
> sub-menu. I mean this workflow: 
> 1. "Expend/Collapse" ---> "Expand Heading"
> 2. "Expend/Collapse" ---> "Collapse Heading"
> 3. "Expend/Collapse" ---> "Expand All Headings"
> 4. "Expend/Collapse" ---> "Collapse All Headings". 
> 
> What those options do is self explain. For example, with a large Document
> the user could start by clicking on "Collapse All Headings". Then use the
> other "Expand Heading" option with only a few headings which are presently
> of interest.
> 
> The numbers 1, 2, 3 in this mockup show this suggested resolution at
> https://i.postimg.cc/Pxc45tX9/Mockup-Navigator-Expend-or-Collapse-Expand-All-
> Headings-and-Collapse-All-Headings-v2.jpg

I would like to address another use case: Say s/he has 200 headings

1. In the first state all Headings are expanded
2. User collapse Heading 3 then Heading 5, Heading 15, Heading 17, Heading 22, Heading 24, Heading 25, Heading 27, Heading 45, Heading 64, Heading 72, Heading 97, Heading 114)
3. User click Expand All Headings
4. User want to back to previous state, that some Headings collapsed again (Heading 3, 5, 15, 17, 22, 24, 25, 27, 45, 64, 72, 97, 114)

How to reach fourth step automatically? Yes of course s/he can do it manually one by one collapse them but how if the selected collapsed Heading counts hundreds?

(In reply to Rizal Muttaqin from comment #70)
> How to reach fourth step automatically?

I disagree for this reason with the Expand/Collapse All idea. There are plenty of use cases that might be considered like Collapse All Other, just to add one more. It makes the simple function complex - by now you need a submenu for all options.

And I would also not store the last collapse state for this reason. However, the use case is clear and deserves a solution. And that's a macro (shouldn't be too difficult to iterate all headings and run Jim's UNO command).

So in a nutshell: keep it simple but allow extensions.

I agree with Heiko to keep it simple. 

Let's begin with an UNO to fold and unfold outline content that can be added, by the user, to toolbars and menus, and can be assigned keyboard shortcuts.

In Patch Set 4, at the gerrit link given in comment 54, all Navigator use of the UNO command has been removed. IMHO, Navigator use of the command is best done in a separate patch.

Code review and testing is much appreciated.

Created attachment 160837 [details]
Outline content folding featuring Navigator UI

Hi all,

The attached video shows effort that adds sub menu 'Outline Content Visibility' with three menu items, 'Toggle', 'Hide All', and 'Show All', to the Navigator Headings context menu. 'Toggle', toggles the visibility of outline content. It is available for all Headings content in the content navigation view. 'Hide All' and 'Show All' are available for headings with sub headings, depending on the visibility of content. If all content is folded/hidden then 'Show All' is available. 'Hide All' is available when all content is unfolded/visible. If there is a mix of these, both 'Hide All' and 'Show All' are available. For the headings content type entry, Headings, 'Toggle' is never available, only 'Hide All' and 'Show All'.

I struggled with the layout not always being as expected after hiding and showing outline content. The solution is to not have the text flow attribute 'Keep with next paragraph' set for Headings. Similar unexpected layout results occur when outline node content is deleted for Headings with 'Keep with next paragraph'. Zoom factor somehow figures into this behavior also.

Here is the link to the patch that does what is shown in the video:
https://gerrit.libreoffice.org/c/core/+/93908

(In reply to Jim Raykowski from comment #73)
> Created attachment 160837 [details]
> Outline content folding featuring Navigator UI

@Jim, that is looking really nice! And, *very* happy to see you're also thinking about non-Navigator based usage and have already made the UNO command(s) available for use from Context menu and Toolbar!  If we can't get the controls onto document canvas--the context menu would be a good supplement to the Navigator.

Created attachment 160918 [details]
Toggle outline content visibility ctrl+mouse click demo

Perhaps using ctrl + mouse-click on headings in the document could be enough for the canvas interface?

The attached demo shows a pointing hand when the mouse pointer is over a heading and the ctrl key is pressed. Clicking the left mouse button toggles the visibility of the outline content. If there are sub headings, the right mouse button toggles the visibility of the outline content of the clicked on heading and all sub headings to that of the clicked visibility.

(In reply to V Stuart Foote from comment #74)
> If we can't get the controls onto document canvas

Think about the popup controls for page breaks and headers/footers (that appear when you hover over relevant parts of document); a toggle to enable/disable popup of similar controls for outline operations could be useful (because people could want to not have them always popping up).

And collapsed state of a part should have a sticky indication...

Here is the gerrit link that does the mouse click outline folding discussed in comment 75
https://gerrit.libreoffice.org/c/core/+/94377

Thanks Jim!

As implemented thus far, would have no visual indicator added to canvas, meaning the Navigator would have to remain expanded, or be undocked. 

And of course it forces the use of mouse+keyboard--which is not too much of an issue since keyboard only navigation get more difficult/less efficient with larger Writer documents.

Are we going to bump into other os/DE use of the <Ctrl>+lmouse, <Ctrl>+rmouse? Of course os/DE focus would explicitly be into the LibreOffice module--so maybe a non-issue. Bounce it off the dev list?

(In reply to Mike Kaganski from comment #76)
> 
> Think about the popup controls for page breaks and headers/footers (that
> appear when you hover over relevant parts of document); a toggle to
> enable/disable popup of similar controls for outline operations could be
> useful (because people could want to not have them always popping up).

So what thoughts for toggling visibility/enabling on-canvas outline markings as done with the <Ctrl>+F8 Field shadings, or the <Ctrl>+F10 Non-printing Characters formatting?

> 
> And collapsed state of a part should have a sticky indication...

Yes, for sure.

(In reply to V Stuart Foote from comment #78)
> So what thoughts for toggling visibility/enabling on-canvas outline markings
> as done with the <Ctrl>+F8 Field shadings, or the <Ctrl>+F10 Non-printing
> Characters formatting?

I meant that we might not need the controls on canvas - a blue toolbar with controls may popup on hovering over the headings. That makes the functionality easier for use than just key+mouse button.

Created attachment 161108 [details]
hover over outline heading in document demo

Great tip to look at how the frame controls work, thanks Mike. Attached is a demo of a first stab at doing this from the canvas.

(In reply to Jim Raykowski from comment #80)
> Great tip to look at how the frame controls work, thanks Mike. Attached is a
> demo of a first stab at doing this from the canvas.

Afraid this will be annoying in the average workflow. It's a large dialog always in the way like MSO's mini toolbars for formatting (see bug 87040). Either the indicator is out of sight (left margin of the outline) or we just go with the simple ctrl+click solution plus context menu.

(In reply to Heiko Tietze from comment #81)
> Afraid this will be annoying in the average workflow. It's a large dialog
> always in the way like MSO's mini toolbars for formatting (see bug 87040).
> Either the indicator is out of sight (left margin of the outline) or we just
> go with the simple ctrl+click solution plus context menu.

Using ctrl+click solution plus context menu would be very awkward. I suppose that having an "outline mode" - some button toggling a *dedicated toolbar with the functions*, and in the same time *activating the popups for the time of the mode*, would possibly be a better option for discoverability and usability.

Additionally, popping up in a different place could be an option: e.g., to the left of the paragraph; using only small icons like "+"/"-" and a drop-down for more options would make the toolbar small enough to fit to left?

What is "left margin of the outline"? any mockup?

(In reply to Mike Kaganski from comment #82)
> Using ctrl+click solution plus context menu would be very awkward. I suppose
> that having an "outline mode" - some button toggling a *dedicated toolbar
> with the functions*, and in the same time *activating the popups for the
> time of the mode*, would possibly be a better option for discoverability and
> usability.

I agree. Outline mode option within the view-menu is something, I would expect.

Created attachment 161178 [details]
Toggle button in the margin way out of the way

Here is an out of the way button that may be too out of the way.

Created attachment 161179 [details]
Toggle button in the margin less out of the way

demo of button in margin less out of the way.

Here is a gerrit link to the code that does the menu button shown in the demo videos in the previous two comments:

https://gerrit.libreoffice.org/c/core/+/94745

I saw the videos from the comments 84 and 85. From user point of view, it would be painful if I have to wait for the control to appear after pointing the mouse over the title. What about implementing a button which is always displayed besides the title (when using a specific mode) ?

(In reply to Jim Raykowski)
> Here is an out of the way button that may be too out of the way.

A bit but not too much, IMHO (better than other solutions, worse than a symbol left-attached to the outline).

As Jérôme commented, the two clicks (plus time to wait for the popup) are bad. It's acceptable as indicator for shift/ctrl+click but not really usable. So either you respond on click at the blue button itself, dropping the "only this level" option, or keep it as it is with the idea of a clue for the supposed interaction. Shorter labels would be good, perhaps "Hide", "Hide all" and Show if hidden. MSO has no tooltip and toggle always all nodes.

We definitely need an option to suppress the popup (see also bug 118621).

Created attachment 161446 [details]
Plus Minus button single click demo

Here is another go at the button appearing when mouse is held over heading approach. This version shows a '+' or '-' button which only requires one click to toggle outline content visibility. As the code stands now, content visibility for sub headings is not toggled when upper level heading content visibility is toggled. Perhaps right mouse click on the button or left mouse click with held mod key could be used to toggle including subs.

An option to suppress the popup noted but not yet implemented.

Link to code for plus minus button single click approach with right mouse click to toggle including subs:
https://gerrit.libreoffice.org/c/core/+/94745/5

(In reply to Jim Raykowski from comment #90)

That's brilliant! I suppose that having a tooltip mentioning the changed opeartion with right-click (like format paintbrush has) could make that discoverable.

Personally I would prefer (a) the button cliser to the text (as in comment 85), and (b) usung key like ctrl or shift or alt to change the operation to include subs. The common meaning of ctrl+something (likewise alt+something, etc) is to modify the action; the common meaning of right button is to bring context menu.

Created attachment 161556 [details]
Tooltip and supress option additions

Thanks Mike, a tooltip has been added. Also an option to enable/disable the button has been accomplished by following Heiko's patch tdf#118621. Perhaps there is a better description for this than what I have come up with 'Show outline content visibility button' 

https://gerrit.libreoffice.org/c/core/+/94745/7

Providing UNO commands for customization is always a good idea. However, this entry does not fit under Tools (neither I would place it anywhere else by default). My first idea regarding an option was to have a checkbox at Tools > Options. 

If we want to bring this patch as a last minute feature into 7.0 we should hurry up. Sorry for the additional work, if you agree.

(In reply to Heiko Tietze from comment #93)
> Providing UNO commands for customization is always a good idea. However,
> this entry does not fit under Tools (neither I would place it anywhere else
> by default). My first idea regarding an option was to have a checkbox at
> Tools > Options.

I would expect that option in view menu. That's logical for me and you have an easier access to that command than in Tools = Option => ...

> > If we want to bring this patch as a last minute feature into 7.0 we should
> hurry up. Sorry for the additional work, if you agree.

Would be great!

When looking at the demo provided by comment #92, the option "show outline content visibility" is great.

Why the +/- toggle button isn't always visible when this option is enabled ?

If it would be always visible when this option is enabled then it would immediately inform the user that there is a hidden content in case of "+" label.

In case it isn't show by default without hovering, how the user knows there is a hidden content when reading the document at a glance ?

Created attachment 161602 [details]
Options dialog option to show button

Removed option to show button from Menu > Tools and added to Options dialog.

(In reply to Jim Raykowski from comment #96)
> Removed option to show button from Menu > Tools and added to Options dialog.

So users can expand/collapse outlines per context menu at the headings (where also the shortcut is shown), the Navigator, and via shortcut. If the option is switched on, we also show a button to click on. And last but not least all is customizable. Sounds like a perfect solution to me.

(In reply to Jim Raykowski from comment #96)
> Created attachment 161602 [details]
> Options dialog option to show button
> 
> Removed option to show button from Menu > Tools and added to Options dialog.

That's fine there.

About the +/- symbol can it be an icon from the icon theme? cause than the icon designers can modify them depend on the icon theme. would be great. you can also choose an icon name if you don't find an well fitting icon and we will do the icon's for the different icon themes.

Created attachment 161788 [details]
right click menu in the navigator.

I'm new at that feature request and didn't read all the 99 commands.

Would it be possible to have an right click menu. I for example use the navigator often for select an specific header section like it's possible in the sidbar navigator. You can use the context menu from the Navigator so you only have to offer the right click menu.

(In reply to andreas_k from comment #98)
> About the +/- symbol can it be an icon from the icon theme? cause than the
> icon designers can modify them depend on the icon theme. would be great. you
> can also choose an icon name if you don't find an well fitting icon and we
> will do the icon's for the different icon themes.

This is completely unrelated. This might be reasonable, but should be handled independently, so that all cases of such pop-ups (e.g., in header/footer popups) are made using some themed images etc.

Created attachment 161972 [details]
demo using icon themes for button image

Here is a demo using andreas_k's idea to use the icon themes. Plus and Minus icons are used in this demo. 

I switched the defines for the demo. Seems all the icon-themes links.txt files have these reversed.

sw/inc/bitmaps.hlst
#define RID_BMP_COLLAPSE                        "res/sx18002.png"
#define RID_BMP_EXPAND                          "res/sx18003.png"

Forgot to mention the video also shows that Space and Enter keys can be used to toggle. Space toggles content not including sub levels. Enter toggles content including sub levels.

Is there a way to make the +/- always visible when using this feature , without the need of hovering ?

(In reply to Jérôme from comment #103)
> Is there a way to make the +/- always visible when using this feature ,
> without the need of hovering ?

Why? It's intentionally designed in this way to be an unobtrusive feature. We shouldn't make it brew coffee on top :-).

My take: Push it, and make the 7 shine.

(I don't like the plus/minus icons and would prefer special carets ">" and "v").

yes push it. tiny improvements can be added afterwards. Look good to me.

In reply to comment #104 :
> (In reply to Jérôme from comment #103)
> > Is there a way to make the +/- always visible when using this feature ,
> > without the need of hovering ?
> 
> Why?

Because the user doesn't know that there is a hidden content if the "+" doesn't appears while reading the document. He/she could type again what he/she already wrote. It could provide a bad user experience.

(In reply to Jérôme from comment #106)
> Because the user doesn't know that there is a hidden content...

Got it. And you are right, in case of collapsed outlines the icon must be permanently visible. Only for expanded/normal outlines it shows up on hoover (and that's what I had in mind).

Created attachment 161999 [details]
buttons always shown approach

Here is an approach change from mouse hover over to show button to buttons always shown.

Created attachment 162002 [details]
arrow icons

(In reply to Heiko Tietze from comment #104)

> (I don't like the plus/minus icons and would prefer special carets ">" and
> "v").

Sukapura theme uses these kind of icons.

(In reply to Jim Raykowski from comment #108)
> Created attachment 161999 [details]
> buttons always shown approach
> 
> Here is an approach change from mouse hover over to show button to buttons
> always shown.

https://gerrit.libreoffice.org/c/core/+/96310

(In reply to Jim Raykowski from comment #108)
> Here is an approach change from mouse hover over to show button to buttons
> always shown.

How about showing only the minus always but the plus on hover?

(In reply to Heiko Tietze from comment #111)
> 
> How about showing only the minus always but the plus on hover?

good idea.

(In reply to Jim Raykowski from comment #101)
> Created attachment 161972 [details]
> demo using icon themes for button image

In general from visual design I would prefer to show only the icons and not the button. Than it's visual not that disturbing but with the icon easy to select. Like you know the + from text editors like notepadd++, sublime, kate, ...

(In reply to andreas_k from comment #113)
> I would prefer to show only the icons and not the button...

Sure, but I'm talking about button+icon and to have a plain, conventional layout even when the option is on. You get this by not showing the collapse button+icon unless you hover over the outline. In case of collapsed section we have to always show the plus button+icon to give a feedback of hidden content.

I agree that it is reasonable to always show the Expand icon/button for collapsed parts. But then what means "always"? I suppose that in that case, either that button must be shown even when the "Show outline content visibility button" is disabled in Options, or the said setting should not only control the button visibility, but also turn off the collapsed state (so should be more like "enable/disable outline function", with effect on other means to expand/collapse, like using Navigator and keyboard shortcuts). Without that, we still have situation that there's a collapsed section without a visual clue.

Created attachment 162071 [details]
demo of only folded buttons always show approach

Demo of "Only show unfold/expand buttons always".

@Jim comment #116
Wunderbar. Great job.

how can I test it? Great work.

(In reply to andreas_k from comment #118)
> how can I test it? Great work.

https://gerrit.libreoffice.org/c/core/+/96486

(In reply to Jim Raykowski from comment #119)
> (In reply to andreas_k from comment #118)
> > how can I test it? Great work.
> 
> https://gerrit.libreoffice.org/c/core/+/96486

Works like a charm. 

Nitpicking: the icon is not placed at the center of the heading. Depending on the font size it is below or above the text which looks a bit unpolished.
Objects such as images are hidden in the Navigator when the outline is collapsed. Makes sense to not let the user double click on it but it's not perfectly consistent as disabled means no content. But would keep this.

And we have to discuss whether the new option should be on by default (currently it's off, +1 from my side).

This option should be off by default IMO. However, maybe it could be available into the "View" menu, beside the "normal" and "web" modes.

(In reply to Jérôme from comment #121)
> This option should be off by default IMO. However, maybe it could be
> available into the "View" menu, beside the "normal" and "web" modes.

I agree

https://gerrit.libreoffice.org/c/core/+/96672 is a patch that combines the UNO command, Navigator interface, and on canvas patches. It includes effort to resolve the icon is not placed at the center of the heading plus a some other improvements concerning the canvas buttons portion of the patch which are detailed in my patch set 2 comment here https://gerrit.libreoffice.org/c/core/+/96486

Tested https://gerrit.libreoffice.org/c/core/+/96672 and found a few more "issues".

First, if a chapter has no content folding is not possible. But I guess something like "1.<Heading> 1.1<Subheading> <some text>" is common and users would like to fold the complete chapter. Please check what happens when you delete the single paragraph after the folded chapter. For example 1.Foo /n Test /n 1.1.Bar /n Lorem ipsum. When I delete the paragraph break after Foo in folded state the application crashes.

That brings me to the second point: I miss key handling or some key+mouse interaction (not least since the delay is a bit long for my taste). How about toggle all on ctrl+click at the heading text and not only at the button? Alternatively an interaction at the Navigator might be also good.

And less of a taste thing, if you disable the "Show outline visibility" option while a chapter is folded there is no way to get it back. The unfold icon/button must not be hidden by the function.

(In reply to Heiko Tietze from comment #124)
> Tested https://gerrit.libreoffice.org/c/core/+/96672 and found a few more
> "issues".
> 
> First, if a chapter has no content folding is not possible. But I guess
> something like "1.<Heading> 1.1<Subheading> <some text>" is common and users
> would like to fold the complete chapter. 

Nothing coming to me right off the top of my head for handling this case using the canvas buttons interface, but sub menu items in the Navigator headings context menu 'Outline Content Visibility' can be used to do this.


>Please check what happens when you
> delete the single paragraph after the folded chapter. For example 1.Foo /n
> Test /n 1.1.Bar /n Lorem ipsum. When I delete the paragraph break after Foo
> in folded state the application crashes.
> 

Assuming you are using the delete key to delete the paragraph, an assert is failing.
 
core/sw/source/core/text/txtfrm.cxx:1249: TextFrameIndex SwTextFrame::MapModelToView(const SwTextNode*, sal_Int32) const: Assertion `static_cast<SwTextNode*>(const_cast<SwModify*>(SwFrame::GetDep())) == pNode' failed.

This also happens when left or right arrows are used to move past folded content. Initially I removed the assert as I could see no ill affects by doing so but have been advised to not remove it. I think with a non debug build this does not happen. This is something that requires higher knowledge of what badness may occur.

> That brings me to the second point: I miss key handling or some key+mouse
> interaction (not least since the delay is a bit long for my taste). How
> about toggle all on ctrl+click at the heading text and not only at the
> button? Alternatively an interaction at the Navigator might be also good.
>

How about making the delay half of what it is now before collapse button is shown? Collapse button grabs focus on display so you should be able to use the Space key to fold content or the Enter key to fold content including and sub levels initially after it is shown. So the code from the ctrl+click patch to do visibility toggle when mouse pointer is clicked on outline heading should be added?
 
> And less of a taste thing, if you disable the "Show outline visibility"
> option while a chapter is folded there is no way to get it back. The unfold
> icon/button must not be hidden by the function.

Navigator heading context menu for outlines with folded content can be used to show the content. Also the UNO .uno:togglecontentvisiblity can be used. Perhaps if the 'Show outline visibility button' option is switched off all currently folded outline content should be shown?

(In reply to Jim Raykowski from comment #125)
 
> Assuming you are using the delete key to delete the paragraph, an assert is
> failing.
>  

I meant Backspace key

(In reply to Jim Raykowski from comment #125)
> > First, if a chapter has no content folding is not possible. But I guess
> > something like "1.<Heading> 1.1<Subheading> <some text>" is common and users
> > would like to fold the complete chapter. 
> 
> Nothing coming to me right off the top of my head for handling this case...
> ...
> Navigator heading context menu for outlines with folded content can be used
> to show the content. Also the UNO .uno:togglecontentvisiblity can be used.

That's okay, and I wouldn't play with the delay. Point is, we do not have a quick way of folding as known from XML editors or IDEs. It always takes half a second or some clicks. But let's wait for user input about this.

> Assuming you are using the delete key to delete the paragraph, an assert is
> failing.

Going into the folded chapter via key or deleting the content with delete/backspace throws the assertion, yes. Looking forward to review the final patch (have seen also the improvements regarding positioning, icon, behavior - great work!).

(In reply to Heiko Tietze from comment #127)
> (In reply to Jim Raykowski from comment #125)
> > > First, if a chapter has no content folding is not possible. But I guess
> > > something like "1.<Heading> 1.1<Subheading> <some text>" is common and users
> > > would like to fold the complete chapter. 
> > 
> > Nothing coming to me right off the top of my head for handling this case...
> > ...
> > Navigator heading context menu for outlines with folded content can be used
> > to show the content.

Provision for this case is added in Patchset 5 which can be found here:
https://gerrit.libreoffice.org/c/core/+/96672/5

Created attachment 163341 [details]
outline mode read-only mode approach

Hello All,

It has been interesting exploring the document model/view code and many other UI code areas involved in this enhancement. I ran into problems with promoting/demoting folded chapters, and cases that add content to folded outline content. Making outline mode a read-only feature avoids these problems.

Shown in the demo is use of the .uno:OutlineMode command function in toolbar button form. It can be added to any toolbar or menu and can be assigned a keyboard shortcut. Folded outline content is shown when either edit mode is activated or outline mode is toggled off. Returning to outline mode will fold the outline content previously folded.

I have only had success on how to export/save the attribute used to indicate folded outline content state. WIP on importing. This means no persistence of outlines folded when document is closed and reopened.

(In reply to Jim Raykowski from comment #129)
> Making outline mode a read-only feature avoids these problems.

Doesn't this solution cripples the functionality too much? Use case is to temporarily hide (meaning collapse) distracting chapters and continue writing. Read-only makes it a just browse-through-document thing. I would rather accept the shortcomings and file a ticket so it can be solved later. For example by making just the collapsed section read-only (probably not so easy). 

So my take: Commit Early, Push Often. And involve the users in the iterations (38 people on CC of that many never build from source but might try the nightlies).

(In reply to Heiko Tietze from comment #130)
> So my take: Commit Early, Push Often. And involve the users in the
> iterations (38 people on CC of that many never build from source but might
> try the nightlies).

I agree. Perhaps it is useful to make it an experimental feature first?

(In reply to Heiko Tietze from comment #130)
> 
> So my take: Commit Early, Push Often. And involve the users in the
> iterations (38 people on CC of that many never build from source but might
> try the nightlies).

Yes!

There's a lot of editing that I like to do in outline view in Word and in WPS Office, when I was using that. However, during the process of demoting or promoting content, you should be able to lock the content at the moment you try to demote or promote by  making it temporarily read-only during the process. 

In both Word and WPS Office, it appeared to me as a user that this was how it worked, whether using keyboard commands or when you click the button to drag and drop the content at a new level. If selecting a heading for demotion/promotion automatically also selects the entire tree below that heading, read-only during drag, and releasing it to be edited after it is dropped at its new level (or at its new location), those would prevent the content from being corrupted while it was being moved.
(In reply to Heiko Tietze from comment #130)


> (In reply to Jim Raykowski from comment #129)
> > Making outline mode a read-only feature avoids these problems.
> 
> Doesn't this solution cripples the functionality too much? Use case is to
> temporarily hide (meaning collapse) distracting chapters and continue
> writing. Read-only makes it a just browse-through-document thing. I would
> rather accept the shortcomings and file a ticket so it can be solved later.
> For example by making just the collapsed section read-only (probably not so
> easy). 
> 
> So my take: Commit Early, Push Often. And involve the users in the
> iterations (38 people on CC of that many never build from source but might
> try the nightlies).

*** Bug 70862 has been marked as a duplicate of this bug. ***

*** Bug 63352 has been marked as a duplicate of this bug. ***

*** Bug 96229 has been marked as a duplicate of this bug. ***

*** Bug 131878 has been marked as a duplicate of this bug. ***

Created attachment 163434 [details]
outline content folding

Back on track after read-only mode derail. Hacked around promote/demote issue and certain key inputs that cause bad things to happen.

https://gerrit.libreoffice.org/c/core/+/96672

I'm fairly confident of this version not falling completely on it's face so may be a good one to start user testing involvement.

I could probably figure out how to make this an experimental feature as Dieter has suggested if it needs to be moved to that.

(In reply to Jim Raykowski from comment #138)
> I could probably figure out how to make this an experimental feature as
> Dieter has suggested if it needs to be moved to that.

E.g. see https://gerrit.libreoffice.org/c/core/+/96033 (a search for "experimental" on gerrit gives many other matches).

(In reply to Mike Kaganski from comment #139)
> E.g. see https://gerrit.libreoffice.org/c/core/+/96033 (a search for
> "experimental" on gerrit gives many other matches).

Thanks Mike, I've added code to make the feature experimental mode only.

Created attachment 163540 [details]
outline folding with persistence

Persistence seems to be working. This is my first time poking around xmloff export and import. It would be super great to have this looked over by a kind dev with experience in this area. Persistence addition was the only changes in patchset 21. loext:outline-content-visible is the tag used to indicate outline content was folded. Below is a cut out of a content.xml office:body tag that shows Heading 2 and Heading 4 outline content was folded when the document was saved.   

<office:body>
<office:text>
<text:sequence-decls>
...
</text:sequence-decls>
<text:h text:style-name="P1" text:outline-level="1">Heading 1</text:h>
<text:p text:style-name="P5">A paragraph under Heading 1</text:p>
<text:h text:style-name="P2" text:outline-level="2" loext:outline-content-visible="false">Heading 2</text:h>
<text:p text:style-name="P5">A paragraph under Heading 2</text:p>
<text:h text:style-name="P3" text:outline-level="2">Heading 3</text:h>
<text:p text:style-name="P5">A paragraph under Heading 3</text:p>
<text:h text:style-name="P4" text:outline-level="3" loext:outline-content-visible="false">Heading 4</text:h>
<text:p text:style-name="P5">A paragraph under Heading 4</text:p>
</office:text>
</office:body>

I still believe that making the outline mode in normal view is a wrong thing to do. Having things like headers/footers with possible page numbers and/or chapter names would interfere with the mode; having the pages indicator in to status line ... It would result in much confusion. The page numbering problem was already raised in comment 51 and comment 52.

E.g. Word shows its outline in something like our "web" view.

(In reply to Mike Kaganski from comment #142)
> I still believe that making the outline mode in normal view is a wrong thing
> to do. Having things like headers/footers with possible page numbers and/or
> chapter names would interfere with the mode; having the pages indicator in
> to status line ... It would result in much confusion. The page numbering
> problem was already raised in comment 51 and comment 52.
> 
> E.g. Word shows its outline in something like our "web" view.

I fully agree

(In reply to Mike Kaganski from comment #142)
> I still believe that making the outline mode in normal view is a wrong thing...

Worth to discuss in a follow-up ticket, in my opinion. There are pros and cons, as always.

Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b2686de46250d0c8d14365a2af8428387baa0c24

tdf#38093 Writer outline folding - feature sensitivity

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.

Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/835cd06a047717dfe5e0f117959f3c042e13b21b

tdf#38093 Writer outline folding - outline visibility and on canvas ui

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.

Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5ab17ad2696aeb8acfc21cd2442908b785a53e86

tdf#38093 Writer outline folding - ctrl + click toggle visibility

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.

Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/12ff89af74cd12375436b67b85674a4a2064ef8d

tdf#38093 Writer outline folding - .uno:ToggleOutlineContentVisibility

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.

Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/dce97e84f2bb748e4403841593bb7b0b92ea44c4

tdf#38093 Writer outline folding - Navigator UI

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.

Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1c080b887c1ef28cb2e98173d0121bcae3167075

tdf#38093 Writer outline folding - persistence

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 Commit Notification from comment #150)
> Affected users are encouraged to test the fix and report feedback.

Jim, thanks for your great work! Shall we report feedback (I assume, Feedback could be very different) under this bug or would it be better to open separate reports and collect them in a meta bug?

(In reply to Dieter from comment #151)
> or would it be better to
> open separate reports and collect them in a meta bug?

This. Thank you for review and constructive feedback!

Awesome work, Jim! Let's resolve this ticket and close the honeypot. All follow-up go ideally into single tickets.

Created Meta bug 135310.

(In reply to Cougar Brenneman from comment #156)

Cougar, all: please *don't* post to this CLOSED issue. Any follow-up issue concerning ouline must be filed as a *new* separate issue, and when you file that new issue, put "Writer-Outline-View" into "Blocks:" field in the filed bug. Thank you!

(In reply to Mike Kaganski from comment #157)
> (In reply to Cougar Brenneman from comment #156)
> 
> Cougar, all: please *don't* post to this CLOSED issue. Any follow-up issue
> concerning ouline must be filed as a *new* separate issue, and when you file
> that new issue, put "Writer-Outline-View" into "Blocks:" field in the filed
> bug. Thank you!

I've been talking about this issue with LibreOffice for ten years, and when Jim Raykowski committed  7.1.0, he specifically asked for user comments. Almost twenty years ago, I posted about why I could never use OpenOffice,  and now, for the first time in ten years, LibreOffice has finally made progress towards making an open-source word processor useful to me.

But LibreOffice is still not useful to me, except as a last resort. As far as I know, this is the only place to go to ask for what I, as a writer and user, need. I'm right now studying Github on Pluralsight, but really, I'm not a developer, I'm an end user. 

I was responding to a direct request for user feedback from Jim Raykowski in comment #150, because this is the first progress that I've seen in ten years toward what I've needed as a writer to use the product. My feedback is important as a user, and because I don't understand all of the intricacies of using Git systems. 

I don't like to be in a position of always complaining, so when I say this FIRST progress towards since I began watching the OpenOffice/LibreOffice development process in 2001, I wanted to try it out immediately and give immediate feedback. 

When working as a technical writer for Fujitsu Software in San Jose in the 1990s, I would writer everything in MS Word before importing it all into Framemaker for publication, and the only reason for doing so was the outliner. So I can tell you that what I need is what I need.

Do you want feedback from users? Then don't criticize me if I don't understand where to post and why.

Now, finally, the open source community has gotten a little closer to what I need than has been in 20 years. Where do I post that?

(In reply to Cougar Brenneman from comment #158)
> I was responding to a direct request for user feedback from Jim Raykowski in
> comment #150

Comment 150 was just an automatically generated notification about a commit. Then immediately, in comments 151 and 152, we discussed where to continue all feedback. Please respect the rules of the resource you use.

> Do you want feedback from users? Then don't criticize me if I don't
> understand where to post and why.

I not "criticized", I pointed to how to do that properly. Or do you mean "Do you want feedback from users? Then don't expect them following any advises, even if you give them for the benefit of their feedback become heard"?

> Now, finally, the open source community has gotten a little closer to what I
> need than has been in 20 years. Where do I post that?

In a new bug report just here, pressing the link "New" at the top of the page. Then write your feedback there in the new report, and then put "Writer-Outline-View" into "Blocks:" field in the filed bug, as described in comment 157.

Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c405bae468d887ec77dd3830b7678fcedc2debfd

tdf#138136 tdf#38093 add option to treat sub outline levels as content

It will be available in 7.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.

*** Bug 54772 has been marked as a duplicate of this bug. ***

*** Bug 47746 has been marked as a duplicate of this bug. ***

# me-too
As I write this, on the right hand side there is an option to 'Collapse All Comments' & to 'Expand All Comments' 
That alone demonstrates the value of Outlining/code folding: if it's so useful here, how is it not useful in our personal docs? 

I am using LO to write technical notes, migrating from the great but limited Kate. Several of Kate's scripting templates (eg 'python') have code folding. It is of inestimable value. 

The points about using Navigator are cogent, but it is just not the same. Outlining hugely improves navigation /within/ the doc. That works the way our minds do, providing memory cues as to the information within. It reduces the redundancy of swapping from keyboard to mouse. It keeps focus where it belongs: on the document. It reduces the partitioning of screen space. 

The amount of people requesting this, for well over a decade, the fact that it just refuses to go away, should be motivation enough.

It is a large & valuable leap in utility.

Addendum to Comment 163
I am using version 6.4.7.2 . I jsut noticed the note re version 7.2. If code folding has been added there then please ignore this.
Cheers!

CLOSED - RESOLVED at 7.2 release -- DO NOT REOPEN

Please see META bug 135310 for continued issue tracking and RFE