Better support for content editors to create a structured document

[JoelH]

Can we better support content creators structure a rich document?

I’d like better support for content editors to create a structured document.

Particularly, can we do something to help content creators apply the (correct) heading level (1-6)?

When writing articles like wiki pages in Fibery, the structure is important, because:

• it helps with readability for users
• (headings) the only supported way to collapse content for users
• (headings) if you set the heading level wrong, collapse confuse users
• (headings) it’s important when exporting and printing
• (future) it’s the basis of Table of contents (TOC)
• (future) it becomes important when Fibery support a shortcut to collapse/expand all (like Notion)

When you write articles in markdown, the heading level is pretty clear (less so when heading level is 4-6, but still OK)

But when you work in rich text, it’s not obvious

In Fibery’s editor, we can use markdown shortcuts but we only see the rendered output.

Myself, I find it’s hard to see which heading level I’ve used in a document. I find myself constantly removing and reapplying heading level, to figure out which level it is, so it aligns with the rest of the document.

Demo of user experience

• as a reader, its hard to see where in the document structure you are
• as a content editor, it’s hard to see what level of heading to use when you want to new content next to sibling, child or parent

[JoelH]

I’m posting this in the community, because the solution is not obvious to me.

I think feature is related but not dependent on showing a full document outline/TOC. Some wiki editing software I’ve worked in supports TOC, but its still hard to see where in the document you are working, and that is not great.

To me, I like to first support content editors easily creating (correct) outline documents, then some outline visualization can build on that. Otherwise in my experience, it can be a pain to create a (good) outline (TOC), and then its just a feature that is not that helpful. Also, good structured documents are good for data portability.

Here are some ideas I think would help the content creator user to keep structure in a rich text document:

Break it down into several document
Often the best solution! But some pages should be one document, e.g. collaborative doc shared with others or where content is so closely related it makes sense to keep in a single larger document.

Make the heading level either directly visible or clearly distinguishable
For example, decorate H1, H2, H3 etc with subtle level indicator graphic (that is not be shown when printing, just in the UI).

E.g. something like this:

Breadcrumbs

If possible show grandparent as well so you can navigate the document that way, but also just showing the parent level would add value, I think

E.g something like this (grandparent + parent, and only parent):

[JoelH]

I’d love to hear ideas from others. I’m not sure if there is a clear best path here, I’ve worked with wiki software and haven’t yet found anything that I really like.

I think the best solution would be something that both helps content creators spot the current navigation context, and also helps users (readers and content creators) quickly navigate a longer document.

The current Fibery support with collapsed headings can be nice for some things like heading big JSON blocks or screenshots, at the same time, I’m not sure I necessarily need headings for that. To me, headings (to structure a document) and collapsing content are not always the same thing.

[Oshyan]

Hmm, I agree that it can be hard to be sure what Header level one is seeing/using (sometimes I quickly try applying a level to my current header to see if it changes as a form of diagnoses/identification ). I think the issue of navigability for readers is also important, but separate.

[DONE] Table of Contents block or other function

I was surprised to not find an existing feature request for this one, but I did search a bit and only found brief mentions in otherwise unrelated discussions. So the request is simple: some kind of Table of Contents feature, for docs, certainly, but perhaps even just overall for Rich Text. Maybe even as a kind of Block in the upcoming [IN DEV] Migrate Entity View to Blocks paradigm. Personally, though, I’d love to see it as something that can optionally “float” or exist outside/alongside the ma…

You have titled this Feature Request rather broadly, and within it I only really identify the one general request: make it more clear what Headers users are Applying, and which level their current text is at. If that is the extent of the feature request, can I suggest changing the Title to more clearly reflect that? If there is more that needs to be done for “creating a structured document”, let’s elaborate further.

As to the specific request to make Headers more clearly identified, both for authors and readers, I think your suggestion of putting the e.g. H1, H2, etc. next to the text is good, except I’d say it should only show on-hover/mouseover, just as Collapse and Anchor Link already do. To me this would completely solve the ambiguity issue in a very simple, clean way.

For readers (and, to some degree, editors) to better understand where they are within text as they read, e.g. say you’ve scrolled past the H2 that identifies the section you’re in, so you can’t easily mouseover it to know where you are in hierarchy, I think the best solution is a floating Table of Contents (which I describe in my feature request above). An alternative could be to have some “level” indicator in e.g. the left margin/gutter, outside of the text, which just shows a little number or maybe e.g. “H2”, but it starts to make things look busy I think. It could perhaps only show if you move your cursor outside the text, or maybe if you hold Alt as-in my more broad “Modal block vs. text editing” concept described here (which is to say only the concept of holding a modifier key to invoke additional info/context, so this is partly just an excuse to link my write-up ):

A proposal to enhance usability of block-based tools for writing and layout