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 main contents. Not so much as a traditional book-style ToC, as-in a Word doc, but rather as a navigation aid. That said, depending on how flexible Blocks can be, an option in a ToC block to simply “dock and float right/left on scroll” would satisfy that need very well.
If I were to outline my perfect ToC functions, it would look something like the following, though I realize some of these may be a big ask, or too much work to do for the context in Fibery (which is not intended to be a sophisticated doc editor, I think; more about getting work done).
Block-based, can be instantiated anywhere in a Doc or Rich Text
Ability to configure what header levels it shows
Optional collapsible headers, possibly with a “Collapsed by default” and/or “Only one header expanded at a time” options
Click to navigate to headers with a click
Option to display alongside doc contents somehow
Ideally the ability to “float” and scroll with the user’s view as a navigation aide
Using the ToC for navigation and having clickable header links suggests that this would rely on/require implementation of Anchor Links. Or at the least that adding Anchor Link functions would follow well from having clickable nav from a ToC.
Anyone else want something in a ToC feature that I missed? I made this post a Wiki, so feel free to edit and add your own bullets for additional desired ToC-specific features.
Love to see that as well, very needed for larger docs.
What surprised me when dealing with larger doc is that the collapsible state of headings are not stored. If i write a large doc with many details, i may want to hide stuff from it to make it more readable, one section at a time or let user “explore” it and expand only the sections/headings that applies to himself, to his role, etc…
However, seems that Fibery doesn’t store those states… if I collapse some headings, when I share it to a user or externally, the entire document is fully expanded. That’s not desired outcome and defeats the biggest purpose of collapsible headings.
Love the existing collapsing of contents that are inside the heading. But, as we write a long-form document inside Fibery, it feels like an outline/table of content feature would be more beneficial.
I love how Coda does it. Not a big fan of Notion/Clickup way of doing it.
Yeah, is you plan to replace rather than integrate with some sort of docs, I.e. Google Docs, then navigating a slightly bigger Document with numerous of heading is important. Otherwise we end up with just a giant Rich Text Field. I’m personally would really love to integrate/import some existing docs and make navigating them somehow possible. I’m not sure this should be in the sidebar are as “Smart Folders” or inside the content area. But the tendency goes to side bar for me.
Want to add my vote here as well. If Fibery wants to be one place for all workspace related applications, it needs to have the ability to handle long structured text more efficiently. For example, on Fibery’s own User Guide, it’s quite tedious to scroll to a specific section when the page gets longer. A ToC on the right hand side would solve this problem.
Now that I think about it, it’d be nice to be able to put a ToC block anywhere, but if that’s harder than a floating ToC, or the choice of dev resources comes down to either a ToC block or a floating ToC, but not both (for now at least), then I’d be in favor of a really good floating ToC design, collapsible, showing indentation for header levels, etc. It should show up in the “gutter” on the right or maybe left side of doc contents. Since it would be always available, it would largely address the desire to have ToC in a block, I think, and it could then be designed into the page settings, etc. This would also solve part of this recent FR:
The Clover note-taking app has kind of a cool implementation of a subtle, persistent, collapsed, open-on-hover ToC. I’d prefer it to have the ability to “pin” it open though:
Note how even in the collapsed state you can tell the header levels (H1-H3 are all that is supported) by the size of the dot. Subtle but clever.
It’s getting more and more painful as I write longer content in Fibery. Wondering if this will be implemented anytime soon. Otherwise, I have to move to other places for writing, although it would be great if I can put all things together in one app.
I have already voted for this but thought I could add a more detailed comment as well.
We are considering moving our entire organization to Fibery. The database/relations functionality is really good.
We are also planning to move all of our documentation to one place (and that would be Fibery). I personally think some small enhancements to the document editing would have very big improvements to the look and feel of Fibery as a whole.
It would be very nice to have an automatic Table of Contents block based on headings (or similar) as some documents can have a lot of information.
A workaround right now is to break up a document into smaller documents and link to them instead but it doesn’t always make sense to do so.
I honestly wouldn’t mind creating manual Table of Content lists but there does not seem to be a way to do internal links yet (as mentioned here). It takes away from the look and feel when a new tab is opened instead of jumping within the same page.
It’s a nice step forward, for sure! I personally would want to be able to pin it open, at the least. And for Rich Text Fields, I would prefer it to pop-out to the Left and not overlap contents (and also be pin-able), at least where width/screen space allow (I’m on a 4k monitor, plenty of room).
I also wonder if there is a way to better hint at what it is, make it more discoverable to whose who are less exploratory and don’t tend to just click on something that isn’t clearly identified. The on-hover pop-up text is helpful, and may be enough. Probably needs some time to see how people’s experience is with it.
Finally, for some reason I find the line length identifier for header size/level to be a less obvious/intuitive one than dot size. Is the longer line “bigger” (larger/higher level header, e.g. H1), or smaller (further indented, smaller/lower header, e.g. H3)? Turns out it is the former, but I wasn’t sure until I started clicking on them to see, and that’s not ideal. I think it should be immediately legible from the start, and the current design has some conflation with indentation as a representation of hierarchy IMO. I also feel that, even though it stays in the margin, it “feels” as though it is intruding a bit more on the text (and also reminds me of a ruler). If you prefer to keep the line length indicator, maybe combine it with a line weight/thickness.
Overall it’s pretty good as-is though, and it addresses the most important aspects of my feature request I think: it’s unobtrusive, floating/sticky, jump-click, collapsible, etc.