From bug 38093 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 support making these features available in a specific view, accessed through the View menu. It should be called Outline View, not Web View. There is no connection between outlining and the World Wide Web, either technically or in use.
Outlining should be in a specific view for two reasons. Firstly, so that users do not accidentally collapse a section by misclicking and think that LibreOffice has lost their work. It's frightening (especially to less computer-savvy users) to see their words suddenly disappear. Secondly, so that users can switch between the viewing the final printed version of the document and the outline view where they edit the document, without losing the state of the outline view. For example, I am editing a hypothetical section 4.3 with reference to section 6.2, so all other paragraphs are collapsed. But I need to add a table in section 4.3 and I want to make sure it's at the bottom of a page. So I should be able to switch to Normal View, add and edit the table in WYSIWYG mode, then switch back to Outline View and find that everything except sections 4.3 and 6.2 are still collapsed. I'm not sure whether the second workflow is currently possible or not, but an Outline View makes it possible to add it at a later data. (Apologies for double-posting, I though Bugzilla comments would be editable)
I support this idea. Mike gave also some important arguments in comment 10 and comment 11 of bug 135373. cc: Design-Team for decision
I'm against the special view mode. Use case of the feature is primarily to hide distracting passages while sorting is secondary. Word processing without WYSIWYG, as suggested per switching between outline and normal mode, is pointless. Questions like header/footer, accidentally collapsed sections, print mode preview should be addressed, of course. However, I doubt many of these arguments count for the user. Could imagine a two-pronged approach with a limited feature set for the normal mode and the outline view mode.
(In reply to Heiko Tietze from comment #4) > I'm against the special view mode. Use case of the feature is primarily to > hide distracting passages while sorting is secondary. Word processing > without WYSIWYG, as suggested per switching between outline and normal mode, > is pointless. > >... No, have to disagree here. The main use of an outline mode is to outline--not to hide passages or content as effect, but to facilitate adjusting the sequence and flow of the manuscript. Trying to maintain WYSIWYG layout while performing the outlining causes a lot of compromise on things that could be better structured if the objects of the document were cast onto a different VCL canvas. Flows-from/to, anchoring, outline level, cross-referencing/URL, etc. attributes would be primary--while applied styles secondary. Functional ability to outline over maintaining WYSIWYG layout. New or modified controls to move and rearrange document objects could then be specific to this use. Believe that all is facilitated by *not* attempting to maintain the print page normal view. No different than current Writer Web with its non-paged 'Web' preview mode and its 'HTML Source' markup mode in addition to its 'Normal' page like view. Perceive a new mode within MUFFIN efforts (though not GladeBuilder XML alone). A UI / Canvase mode more aligned with work needed for a Tabbed UI by document section (bug 33173). Or related framework needed for a Tabbed Multi-Document Interface (bug 37134).
(In reply to Heiko Tietze from comment #4) Note also that this simplistic PoV to the outlining downgrades a powerful feature to something cosmetic, not *helping* users much. Any professional knows that any task may be approached from orthogonal directions. Providing a plain text editor, you don't allow users to create rich documents. Not providing styles, you don't allow users to create *structure* in formatting. LibreOffice being built around styles is its real advantage over competition when it comes to having well-formed structured electronic documents (albeit it has its learning curve). Likewise, outline mode is another powerful tool in managing *content* structure of your document. And it's not useful to always insist on displaying every feature of a work you are doing. Trying to fit all different models of working with document into one view will both make that view over-crowded with features (creating confusion, UX problems like accidentally activating things with shortcuts, etc.), and *distract* one's attention from the aspect of work that is important at the moment, decreasing the efficiency of own work. E.g., in any engineering development (building, software, infrastructure, anything), you create different cross-sections of displayed data. They all serve own purpose; show details from different directions; provide time vs resource diagrams; show low level of details for planned piping on papers for bedding, etc. If you try to create one view for all the building process, you will not succeed. So please do not oversimplify the very important structuring aspect of this mode dedicated to efficient structured management of *document content*, which is orthogonal to formatting.
No further input, removing UX keyword. Happy to support the further development of this outline mode.