Support more sublevel in chapters #90

Closed
opened 2026-02-04 16:39:29 +03:00 by OVERLORD · 65 comments
Owner

Originally created by @ducheneo on GitHub (Apr 6, 2016).

Originally assigned to: @ssddanbrown on GitHub.

It should be interesting if we could use at least one more level of sub-chapter in a book.
Collapsible sections are also interesting.

Originally created by @ducheneo on GitHub (Apr 6, 2016). Originally assigned to: @ssddanbrown on GitHub. It should be interesting if we could use at least one more level of sub-chapter in a book. Collapsible sections are also interesting.
OVERLORD added the 🛠️ Enhancement Open to discussion labels 2026-02-04 16:39:29 +03:00
Author
Owner

@ssddanbrown commented on GitHub (Apr 6, 2016):

Hi @ducheneo, I agree with collapsible sections, They're already open and requested on #78.

The extra level of grouping is an interesting topic. I would rather not add this feature and here's why:

Initially when building BookStack I allowed a system of highly nested pages. I was following the system that confluence used. From a development perspective this was tricky to support, Not impossible by any means but added extra complication whenever there was a listing or when working out relation trees.

From a user perspective things were fairly hard to navigate. Allowing a high level of nesting means you can only show part of a grouping, or tree structure, at a time which meant you only see a snapshot of a whole and it becomes easier for content to stay hidden. It also means there was no standard grouping system or clear separation of levels.

At that point I changed BookStack to a 2 tier grouping, Books & Chapters. I very much like this level of grouping as it can be related to the way we store content in books, It's familiar and simple while allowing a good level of organisation. It also forces you to keep the wider organisation of the content from going out of control. I feel that adding an extra layer of chapters would break this simple relation to books. On top of that there will always be someone that wants an extra layer, no matter how many layer are implemented.

I do understand the need for an extra dimension of organisation/categorisation through which will be added by the attribute-value system proposed in #48.

I'll keep this issue open and also I'm open to further discussion as the community may have a very different opinion to me but I do really like the core Book/Chapter/Page structure of BookStack.

@ssddanbrown commented on GitHub (Apr 6, 2016): Hi @ducheneo, I agree with collapsible sections, They're already open and requested on #78. The extra level of grouping is an interesting topic. I **would rather not** add this feature and here's why: Initially when building BookStack I allowed a system of highly nested pages. I was following the system that confluence used. From a development perspective this was tricky to support, Not impossible by any means but added extra complication whenever there was a listing or when working out relation trees. From a user perspective things were fairly hard to navigate. Allowing a high level of nesting means you can only show part of a grouping, or tree structure, at a time which meant you only see a snapshot of a whole and it becomes easier for content to stay hidden. It also means there was no standard grouping system or clear separation of levels. At that point I changed BookStack to a 2 tier grouping, Books & Chapters. I very much like this level of grouping as it can be related to the way we store content in books, It's familiar and simple while allowing a good level of organisation. It also forces you to keep the wider organisation of the content from going out of control. I feel that adding an extra layer of chapters would break this simple relation to books. On top of that there will always be someone that wants an extra layer, no matter how many layer are implemented. I do understand the need for an extra dimension of organisation/categorisation through which will be added by the attribute-value system proposed in #48. I'll keep this issue open and also I'm open to further discussion as the community may have a very different opinion to me but I do really like the core Book/Chapter/Page structure of BookStack.
Author
Owner

@nwalke commented on GitHub (Apr 7, 2016):

We definitely like the Book/Chapter/Page structure. This is why we're using BookStack.

@nwalke commented on GitHub (Apr 7, 2016): We definitely like the Book/Chapter/Page structure. This is why we're using BookStack.
Author
Owner

@ducheneo commented on GitHub (Apr 7, 2016):

Hi Dan, I can understand your point of view.
The point is that the nature of our documentation is deeply hierarchical, and 3 levels of grouping would be more appropriate. The display of the navigation tree could remain unchanged, by replacing the collapsible with "number of page" with the sub-chapter title. And if most people find the actual structure fine, adding the extra level as an option could satisfy everyone (but certainly tricky to implement).

@ducheneo commented on GitHub (Apr 7, 2016): Hi Dan, I can understand your point of view. The point is that the nature of our documentation is deeply hierarchical, and 3 levels of grouping would be more appropriate. The display of the navigation tree could remain unchanged, by replacing the collapsible with "number of page" with the sub-chapter title. And if most people find the actual structure fine, adding the extra level as an option could satisfy everyone (but certainly tricky to implement).
Author
Owner

@cpressland commented on GitHub (Apr 12, 2016):

Well, this is an awkward one. While I love the idea of being able to have chapters within chapters, I imagine it'll quickly become as overly complex as Sharepoint or a Filesystem. The current system forces the people and teams adding content to BookStack to be creative, rather than ending up with one page in a large number of chapters.

[book]Products > [chapter]SomeApp > [page]SomeContent
[book]Products > [chapter]SomeApp > [sub-chapter]Version 0.0.1 > [page]Changelog
[book]Products > [chapter]SomeApp > [sub-chapter]Version 0.0.2 > [page]Changelog

vs

[book]Products > [chapter]SomeApp > [page]SomeContent
[book]Products > [chapter]SomeApp > [page]v0.0.1 - Changelog
[book]Products > [chapter]SomeApp > [page]v0.0.2 - Changelog

Personally, I'm happy with the current design. Maybe a tagging system would be better for this? I'll ask a few people in the office for their opinions on this and report back.

@cpressland commented on GitHub (Apr 12, 2016): Well, this is an awkward one. While I love the idea of being able to have chapters within chapters, I imagine it'll quickly become as overly complex as Sharepoint or a Filesystem. The current system forces the people and teams adding content to BookStack to be creative, rather than ending up with one page in a large number of chapters. ``` [book]Products > [chapter]SomeApp > [page]SomeContent [book]Products > [chapter]SomeApp > [sub-chapter]Version 0.0.1 > [page]Changelog [book]Products > [chapter]SomeApp > [sub-chapter]Version 0.0.2 > [page]Changelog ``` vs ``` [book]Products > [chapter]SomeApp > [page]SomeContent [book]Products > [chapter]SomeApp > [page]v0.0.1 - Changelog [book]Products > [chapter]SomeApp > [page]v0.0.2 - Changelog ``` Personally, I'm happy with the current design. Maybe a tagging system would be better for this? I'll ask a few people in the office for their opinions on this and report back.
Author
Owner

@cpressland commented on GitHub (Apr 15, 2016):

Maybe we should be considering "sub-chapters" as "paragraphs".

So you have a Book for an Application Support Team, inside you have Chapters by product type such as "Financing", inside "Financing" you can have Paragraphs such as "QuickBooks" or "GnuCash" and then Pages inside said Paragraphs.

For what we're using Bookstack for at the moment, this'd probably fit quite well. I've sat down with a few people and the general consensus is this is what we want going forward.

@cpressland commented on GitHub (Apr 15, 2016): Maybe we should be considering "sub-chapters" as "paragraphs". So you have a Book for an Application Support Team, inside you have Chapters by product type such as "Financing", inside "Financing" you can have Paragraphs such as "QuickBooks" or "GnuCash" and then Pages inside said Paragraphs. For what we're using Bookstack for at the moment, this'd probably fit quite well. I've sat down with a few people and the general consensus is this is what we want going forward.
Author
Owner

@riorii commented on GitHub (May 13, 2016):

+1 with having 1 sublevel more. Like Subchapters. 1 sublevel more would be sufficient.

@riorii commented on GitHub (May 13, 2016): +1 with having 1 sublevel more. Like Subchapters. 1 sublevel more would be sufficient.
Author
Owner

@fredericmohr commented on GitHub (Jun 6, 2016):

I'm not sure if another sub level is such a good idea as, but what might be a good idea is to have the option of displaying only part of a page directly and have the other parts in different sections (sort of virtual pages inside a page).

[book 1] -> [chapter 1] -> [page 1]
If [page 1] get's really long, show everything just before the second [h1] headline and include a pagination. It would still be possible to load everything at once and handle only displaying the content via javascript. That would make it easier to structure content into sections using headlines without getting pages that are way too long.

This would also go great along with a table of contents feature (not a complete book toc but a per page toc). Just my 2 cents.

PS: Obviously this would have the downside of [ctrl]+[f] search not working as well, since only part of the content is shown. Maybe include a page search?

@fredericmohr commented on GitHub (Jun 6, 2016): I'm not sure if another sub level is such a good idea as, but what might be a good idea is to have the option of displaying only part of a page directly and have the other parts in different sections (sort of virtual pages inside a page). [book 1] -> [chapter 1] -> [page 1] If [page 1] get's really long, show everything just before the second [h1] headline and include a pagination. It would still be possible to load everything at once and handle only displaying the content via javascript. That would make it easier to structure content into sections using headlines without getting pages that are way too long. This would also go great along with a table of contents feature (not a complete book toc but a per page toc). Just my 2 cents. PS: Obviously this would have the downside of [ctrl]+[f] search not working as well, since only part of the content is shown. Maybe include a page search?
Author
Owner

@AkibaWolf commented on GitHub (Jun 30, 2016):

+1 for paragraphs.

@AkibaWolf commented on GitHub (Jun 30, 2016): +1 for paragraphs.
Author
Owner

@relu-xz commented on GitHub (Sep 8, 2016):

+1 for subchapters

My team is using Bookstack as wiki, I'm the admin and believe me, this feature will be useful because we have a lot of chapters and pages and it's becoming a nightmare...as @riorii said, one sublevel more will be sufficient.

@relu-xz commented on GitHub (Sep 8, 2016): +1 for subchapters My team is using Bookstack as wiki, I'm the admin and believe me, this feature will be useful because we have a lot of chapters and pages and it's becoming a nightmare...as @riorii said, one sublevel more will be sufficient.
Author
Owner

@haynes11 commented on GitHub (Dec 29, 2016):

+1 for subchapters. I agree with your reasoning, and the fact that people will always want an "extra layer" but I think one sub-level more would solve a lot of the problems I have with using this as a wiiki.

@haynes11 commented on GitHub (Dec 29, 2016): +1 for subchapters. I agree with your reasoning, and the fact that people will always want an "extra layer" but I think one sub-level more would solve a lot of the problems I have with using this as a wiiki.
Author
Owner

@DeviantEng commented on GitHub (Mar 2, 2017):

+1 for one more level here; not asking for full on nesting, but just 1 more level.

EDIT: Maybe instead of sub-chapters/sections/paragraphs, another level could be added above Books; such as collections? Could possibly do that as tags. I.E., a collection (or tag) of ClientA, with multiple Books underneath for that client. Those Books would have the same existing (optional) Chapters and Pages.

@DeviantEng commented on GitHub (Mar 2, 2017): +1 for one more level here; not asking for full on nesting, but just 1 more level. EDIT: Maybe instead of sub-chapters/sections/paragraphs, another level could be added above Books; such as collections? Could possibly do that as tags. I.E., a collection (or tag) of ClientA, with multiple Books underneath for that client. Those Books would have the same existing (optional) Chapters and Pages.
Author
Owner

@salmiery commented on GitHub (Mar 4, 2017):

+1 Yeah, it would be very cool to have more levels of nesting, maybe with the option to define what those levels are called per book.

+1 on DeviantEng on the level above for book collections. Would be cool to be able to group your books by category.

@salmiery commented on GitHub (Mar 4, 2017): +1 Yeah, it would be very cool to have more levels of nesting, maybe with the option to define what those levels are called per book. +1 on DeviantEng on the level above for book collections. Would be cool to be able to group your books by category.
Author
Owner

@ssddanbrown commented on GitHub (Mar 4, 2017):

Just as an update, Since it's almost been a year since my last comment, I am keeping this in mind as I'm refactoring any parts of BookStack and keeping entity references generic to help support more levels in the future. Then it'll be a case of just sitting down one weekend and finishing this off, Maybe once exports have been fleshed out and the search has been fixed (#271).

In terms of structure, A level above a book would be better to fit in with the understanding of the books/chapter/page structure but from an app/coding/architecture point a lot has been built around books being the top of the chain so it would require more effort.

@ssddanbrown commented on GitHub (Mar 4, 2017): Just as an update, Since it's almost been a year since my last comment, I am keeping this in mind as I'm refactoring any parts of BookStack and keeping entity references generic to help support more levels in the future. Then it'll be a case of just sitting down one weekend and finishing this off, Maybe once exports have been fleshed out and the search has been fixed (#271). In terms of structure, A level above a book would be better to fit in with the understanding of the books/chapter/page structure but from an app/coding/architecture point a lot has been built around books being the top of the chain so it would require more effort.
Author
Owner

@shelbyallenfranks commented on GitHub (May 10, 2017):

As mentioned in #337, I think that the concept of "book shelves" would be a really nice way of achieving this extra level of categorization without straying too far from the simplistic nature of BookStack. Having this extra level would be a great way of being able to link users to a specific set of books that are closely related.

However, if this is difficult to achieve from a coding point of view, perhaps an easier approach to this might be to allow applying tags to books in the same way that these can currently be applied to individual pages?

@shelbyallenfranks commented on GitHub (May 10, 2017): As mentioned in #337, I think that the concept of "book shelves" would be a really nice way of achieving this extra level of categorization without straying too far from the simplistic nature of BookStack. Having this extra level would be a great way of being able to link users to a specific set of books that are closely related. However, if this is difficult to achieve from a coding point of view, perhaps an easier approach to this might be to allow applying tags to books in the same way that these can currently be applied to individual pages?
Author
Owner

@mardeu commented on GitHub (Jul 27, 2017):

+1 for subchapters too

@mardeu commented on GitHub (Jul 27, 2017): +1 for subchapters too
Author
Owner

@VyBui commented on GitHub (Aug 17, 2017):

+1 for subchapters

@VyBui commented on GitHub (Aug 17, 2017): +1 for subchapters
Author
Owner

@Starow commented on GitHub (Sep 28, 2017):

+1 to be able to regroup books into bookshelves 👍

@Starow commented on GitHub (Sep 28, 2017): +1 to be able to regroup books into bookshelves :+1:
Author
Owner

@Ethanb00 commented on GitHub (Sep 28, 2017):

-1 for subchapters (I think it breaks the elegance of the existing structure)

+1 for bookshelves

@Ethanb00 commented on GitHub (Sep 28, 2017): -1 for subchapters (I think it breaks the elegance of the existing structure) +1 for bookshelves
Author
Owner

@genxlee commented on GitHub (Nov 9, 2017):

+1 for subchapters

@genxlee commented on GitHub (Nov 9, 2017): +1 for subchapters
Author
Owner

@CodeBrauer commented on GitHub (Nov 15, 2017):

What about ordering/sorting pages/chapters? Issue #257 may be closed but ordering pages is still an issue. I saw there is already field "priority" in the pages tables, but I think there is no option to set it?

Nevermind. It's just Books > "3 Dot menu" > Sort

@CodeBrauer commented on GitHub (Nov 15, 2017): ~~What about ordering/sorting pages/chapters? Issue #257 may be closed but ordering pages is still an issue. I saw there is already field "priority" in the pages tables, but I think there is no option to set it?~~ Nevermind. It's just Books > "3 Dot menu" > Sort
Author
Owner

@AbijeetP commented on GitHub (Dec 1, 2017):

Would prefer bookshelves myself.

@AbijeetP commented on GitHub (Dec 1, 2017): Would prefer bookshelves myself.
Author
Owner

@snics commented on GitHub (Jan 22, 2018):

+1 for subchapters

@snics commented on GitHub (Jan 22, 2018): +1 for subchapters
Author
Owner

@gojj-se commented on GitHub (Jan 25, 2018):

+1 for bookshelves (and permissions on those)
-1 for subchapters (if choosing is needed, otherwise both)

@gojj-se commented on GitHub (Jan 25, 2018): +1 for bookshelves (and permissions on those) -1 for subchapters (if choosing is needed, otherwise both)
Author
Owner

@pierre-le commented on GitHub (Mar 12, 2018):

+1 for either bookshelves or subchapter, this is merely a semantic issue.
This feature would be great, especially when Bookstack is used in company environments where you need to manage and categorize massive amounts of knowledge.

@pierre-le commented on GitHub (Mar 12, 2018): +1 for either bookshelves or subchapter, this is merely a semantic issue. This feature would be great, especially when Bookstack is used in company environments where you need to manage and categorize massive amounts of knowledge.
Author
Owner

@d-sko commented on GitHub (Apr 30, 2018):

bookshelves and subchapters are both very useful. But if I had to choose, bookshelfes would be more important to me. I also like @fredericmohr´s idea of adding a pagination for head tags (could be done similar to mediawiki, where a pagination is generated if there are more than n headings), which could be a replacement for subchapters. oops, just saw that this is already implemented

@d-sko commented on GitHub (Apr 30, 2018): bookshelves and subchapters are both very useful. But if I had to choose, bookshelfes would be more important to me. I also like @fredericmohr´s idea of adding a pagination for head tags ~~(could be done similar to mediawiki, where a pagination is generated if there are more than _n_ headings), which could be a replacement for subchapters.~~ oops, just saw that this is already implemented
Author
Owner

@mendiromania commented on GitHub (May 3, 2018):

+1 there's no reason not to gonna make my own clone with it

@mendiromania commented on GitHub (May 3, 2018): +1 there's no reason not to gonna make my own clone with it
Author
Owner

@CaptnBook4Git commented on GitHub (Jun 17, 2018):

I support this idea. But instead of an subchapter, i like the idea of bookshelves/collections. I use Bookstack for writing down stuff from university. And it is horrible to sort it like i need it. I would just need that one layer more to get out of the chaos. (I have a book for every main topic, then inside the book i use chapters for the main chapters in this topic, but one chapter has more than 50 pages with at least a minimum of 3 different subtopics. So this is chaos. I could do this all in different books, but then there is no red line anymore to learn them, i have to re-sort them, everytime i want to learn an old topic)

I would also like to know what going on now with this topic. It is now 2 years old, so many people want this, nobody is against this idea... so what is going on?

@CaptnBook4Git commented on GitHub (Jun 17, 2018): I support this idea. But instead of an subchapter, i like the idea of bookshelves/collections. I use Bookstack for writing down stuff from university. And it is horrible to sort it like i need it. I would just need that one layer more to get out of the chaos. (I have a book for every main topic, then inside the book i use chapters for the main chapters in this topic, but one chapter has more than 50 pages with at least a minimum of 3 different subtopics. So this is chaos. I could do this all in different books, but then there is no red line anymore to learn them, i have to re-sort them, everytime i want to learn an old topic) I would also like to know what going on now with this topic. It is now 2 years old, so many people want this, nobody is against this idea... so what is going on?
Author
Owner

@ssddanbrown commented on GitHub (Jun 22, 2018):

@iBooster This issue is not being ignored, I promise. It's just that this is no small task and will require a lot of fundamental re-working of BookStack to be done properly due to the core role that Books currently play.

Time is not free, All contributors are helping in their own time. As per the latest blog post (Next steps section) I am looking to plan out how to go about this as part of this release cycle.

@ssddanbrown commented on GitHub (Jun 22, 2018): @iBooster This issue is not being ignored, I promise. It's just that this is no small task and will require a lot of fundamental re-working of BookStack to be done properly due to the core role that Books currently play. Time is not free, All contributors are helping in their own time. As per the [latest blog post ](https://www.bookstackapp.com/blog/beta-release-v0-22-0/#next-steps) (Next steps section) I am looking to plan out how to go about this as part of this release cycle.
Author
Owner

@ssddanbrown commented on GitHub (Jun 24, 2018):

I've been thinking about this a little more, Thought it would be good to plan out a proposal. I've got some time off in a couple of weeks where I could crack on to get this done. Here's the proposal:


BookShelves

  • Sit above Books in the hierarchy.
  • Can only contain Books as direct children.
  • Many-to-many relationship with Books so a single Book can be part of multiple BookShelves.
  • Will have a name, description, tags & cover image like Books currently have.
  • Will have permissions but they won't dynamically cascade down (By maybe have an option to apply shelf permissions to all included Books).
  • Accessible as a header link as Books are now.
  • Will have homepage option of BookShelves listing.
  • Will be optional at a system level (Either through permissions or direct setting).

I thought the many-to-many relationship would give BookShelves a unique ability, rather than being a clone of the Book entity. It's like how, in the physical world, you could have copies of a Book on different BookShelves.

Any feedback on the above is appreciated.

@ssddanbrown commented on GitHub (Jun 24, 2018): I've been thinking about this a little more, Thought it would be good to plan out a proposal. I've got some time off in a couple of weeks where I could crack on to get this done. Here's the proposal: --- ## BookShelves - Sit above Books in the hierarchy. - Can only contain Books as direct children. - Many-to-many relationship with Books so a single Book can be part of multiple BookShelves. - Will have a name, description, tags & cover image like Books currently have. - Will have permissions but they won't dynamically cascade down (By maybe have an option to apply shelf permissions to all included Books). - Accessible as a header link as Books are now. - Will have homepage option of BookShelves listing. - Will be optional at a system level (Either through permissions or direct setting). --- I thought the many-to-many relationship would give BookShelves a unique ability, rather than being a clone of the Book entity. It's like how, in the physical world, you could have copies of a Book on different BookShelves. Any feedback on the above is appreciated.
Author
Owner

@CaptnBook4Git commented on GitHub (Jun 24, 2018):

That would be awesome!

@CaptnBook4Git commented on GitHub (Jun 24, 2018): That would be awesome!
Author
Owner

@Abijeet commented on GitHub (Jul 2, 2018):

@ssddanbrown - A few questions / notes,

  1. Bookshelves will not be mandatory. Books can exist without being on a Bookshelf? I see you mentioned - Will be optional at a system level but does that mean that even with that option turned on, I can have books outside a bookshelf?
  2. How about my existing book level permission? Assume that they'll remain as is?
  3. The existing books listing will mention the name of the parent bookshelf if applicable?
  4. Export a bookshelf?
@Abijeet commented on GitHub (Jul 2, 2018): @ssddanbrown - A few questions / notes, 1. Bookshelves will not be mandatory. Books can exist without being on a Bookshelf? I see you mentioned - *Will be optional at a system level* but does that mean that even with that option turned on, I can have books outside a bookshelf? 2. How about my existing book level permission? Assume that they'll remain as is? 3. The existing books listing will mention the name of the parent bookshelf if applicable? 4. Export a bookshelf?
Author
Owner

@ssddanbrown commented on GitHub (Jul 29, 2018):

Sorry for my late reply @Abijeet.

  1. Yeah, At least initially, Definitely by default to allow forwards compatibility of how things currently are. You thinking we should have an option to force Books to be within BookShelves? Is a good idea I suppose if you wanted people to stick to a structure.
  2. Yeah, Book permissions, and everything below, will remain as-is.
  3. That would be good although we'd need to limit it or have a nice way of displaying this since the relation will be many-to-many.
  4. Yes, although may omit this for the initial release just to get this feature out.
@ssddanbrown commented on GitHub (Jul 29, 2018): Sorry for my late reply @Abijeet. 1. Yeah, At least initially, Definitely by default to allow forwards compatibility of how things currently are. You thinking we should have an option to force Books to be within BookShelves? Is a good idea I suppose if you wanted people to stick to a structure. 2. Yeah, Book permissions, and everything below, will remain as-is. 3. That would be good although we'd need to limit it or have a nice way of displaying this since the relation will be many-to-many. 4. Yes, although may omit this for the initial release just to get this feature out.
Author
Owner

@aljawaid commented on GitHub (Jul 29, 2018):

@ssddanbrown

My input.... (using bookstack for a very small business how-to manual)

Bookshelves makes sense to be added as a feature. It should NOT be mandatory, as some books (supervisor/manager only) can be offshelf whilst staff books can be on a bookshelf. Hope that gives you an idea. Then again, some could argue that have a supervisor-only bookshelf. That could work too.

Having access to a bookshelf should be optionally password-protected.

Would be good to have the related books listed in a popup (if too many) but all related books should be mentioned.

Exporting of a bookshelve would be fantastic, with a exported list of books and then the option to print them in order into a single pdf (so bookshlelf + books = one pdf)

@aljawaid commented on GitHub (Jul 29, 2018): @ssddanbrown My input.... (using bookstack for a very small business how-to manual) Bookshelves makes sense to be added as a feature. It should NOT be mandatory, as some books (supervisor/manager only) can be offshelf whilst staff books can be on a bookshelf. Hope that gives you an idea. Then again, some could argue that have a supervisor-only bookshelf. That could work too. Having access to a bookshelf should be optionally password-protected. Would be good to have the related books listed in a popup (if too many) but all related books should be mentioned. Exporting of a bookshelve would be fantastic, with a exported list of books and then the option to print them in order into a single pdf (so bookshlelf + books = one pdf)
Author
Owner

@msaus commented on GitHub (Aug 3, 2018):

nice :)

@msaus commented on GitHub (Aug 3, 2018): nice :)
Author
Owner

@MrKhalidJ commented on GitHub (Aug 4, 2018):

@ssddanbrown

Interesting idea. adding one more level of depth might help organization more.
one suggestion though: bookshelves should accept pages directly without requiring it to be part of a book first.

here's how I'm thinking of applying this in my department so you might get a better view of my idea:
we are a small IT department. I'm trying to centralize our documentation papers using bookstack.
so I'm thinking of having one shelf for the networking team, one for sysadmin team, one for helpdesk team and so on.
a number of subjects don't need more than one paper, and not all subjects are related to be grouped into one book or chapter. so having pages alongside books on bookshelves might make it better for not having to use books for every little subject just so you can add it to a shelf.

that's my feedback. hope it helps shape the idea further. 😃

@MrKhalidJ commented on GitHub (Aug 4, 2018): @ssddanbrown Interesting idea. adding one more level of depth might help organization more. **one suggestion though:** bookshelves should accept pages directly without requiring it to be part of a book first. **here's how I'm thinking of applying this in my department** so you might get a better view of my idea: we are a small IT department. I'm trying to centralize our documentation papers using bookstack. so I'm thinking of having one shelf for the networking team, one for sysadmin team, one for helpdesk team and so on. a number of subjects don't need more than one paper, and not all subjects are related to be grouped into one book or chapter. so having pages alongside books on bookshelves might make it better for not having to use books for every little subject just so you can add it to a shelf. that's my feedback. hope it helps shape the idea further. 😃
Author
Owner

@nvnvnvnvn commented on GitHub (Aug 8, 2018):

Any reason not to add another layer at the same time?...Could have Bookcase, then bookshelf, then book, chapter, pages.

@nvnvnvnvn commented on GitHub (Aug 8, 2018): Any reason not to add another layer at the same time?...Could have Bookcase, then bookshelf, then book, chapter, pages.
Author
Owner

@ssddanbrown commented on GitHub (Aug 8, 2018):

@nvnvnvnvn Yeah, Extra build effort, extra systems to maintain, additional system and UX complexities, Extra testing needed.

I've given my thoughts on extra levels in general here:
https://github.com/BookStackApp/BookStack/issues/95#issuecomment-206509825
For BookStack, I do think there should be a limit. Someone will always want 'one more level'.

@ssddanbrown commented on GitHub (Aug 8, 2018): @nvnvnvnvn Yeah, Extra build effort, extra systems to maintain, additional system and UX complexities, Extra testing needed. I've given my thoughts on extra levels in general here: https://github.com/BookStackApp/BookStack/issues/95#issuecomment-206509825 For BookStack, I do think there should be a limit. Someone will always want 'one more level'.
Author
Owner

@carlospauluk commented on GitHub (Aug 17, 2018):

Ok, but what about an index for page sections?

@carlospauluk commented on GitHub (Aug 17, 2018): Ok, but what about an index for page sections?
Author
Owner

@mendiromania commented on GitHub (Sep 9, 2018):

working demo for those who can't wait
https://github.com/mendiromania/BrainStack

run this sql
https://gist.github.com/mendiromania/e323f6532531d9cf125e8f9b33c6067e

and in books manually update the bookshelf_id with the id of the bookshelf

edit:
added a migration for the sql and a bookshelf option in the book editor
Demo

@mendiromania commented on GitHub (Sep 9, 2018): working demo for those who can't wait https://github.com/mendiromania/BrainStack run this sql https://gist.github.com/mendiromania/e323f6532531d9cf125e8f9b33c6067e and in books manually update the bookshelf_id with the id of the bookshelf edit: added a migration for the sql and a bookshelf option in the book editor ![Demo](https://i.imgur.com/ggoULvk.png)
Author
Owner

@guyinpv commented on GitHub (Sep 11, 2018):

I was just editing my books and thinking, it would be cool to have bookshelves once you start to get a lot of books. Then boom I see this on the roadmap, excellent!

To me, the shelves are little more than a folder system. I have a lot of books, so now I just want to organize some books in this folder and some in that folder etc. But keeping with the theme of Bookstack, I though, bookcases. It's a logical thing to do.

Like others have said, a bookcase in my home can hold anything, so maybe it can hold books, but it could also hold directly, just pages.

For permissions, it's obvious things like, access to the entire book case or not. But then this could get tricky if you allow a book to exist in multiple bookcases. Existing in multiple places sounds more like tags and categories, not necessarily bookshelves. Maybe bookshelves themselves can have a reference system.

In real life bookshelves could categorize books alphabetically or topically. For BookStack, you could have a structure like this, it could even be auto-generated based on alpha, or based on tags.

I think most use cases would have shelves relating to departments in a company. The IT dept, the media dept, etc. But automatic shelves would be a neat concept. A bookshelf for all books and pages created per-user. This is Zack's shelf, for example. Or shelves based on tags or alpha as mentioned.

The bottom line is, after only about 9 or 12 books, it's already a bit much to look at. At the very least I think after about 12 books, the grid view should get smaller. Instead of 3 blocks wide it could adjust to 4 blocks wide with smaller thumbnails. Maybe even 5 blocks wide if you have over 30 books.

OR, do the shelves, but it must be visually pleasing to do shelves. The whole idea is to reduce visual clutter and make it a little easier to browse books. We should still have a "view all books" view, just to avoid clicking in and out of shelves, kind of like looking at my Amazon Kindle, you can view the entire list of books, that should always be available. But shelves could simply be an alternative to grid and list view for those of us who want to organize our books into "folders".

@guyinpv commented on GitHub (Sep 11, 2018): I was just editing my books and thinking, it would be cool to have bookshelves once you start to get a lot of books. Then boom I see this on the roadmap, excellent! To me, the shelves are little more than a folder system. I have a lot of books, so now I just want to organize some books in this folder and some in that folder etc. But keeping with the theme of Bookstack, I though, bookcases. It's a logical thing to do. Like others have said, a bookcase in my home can hold anything, so maybe it can hold books, but it could also hold directly, just pages. For permissions, it's obvious things like, access to the entire book case or not. But then this could get tricky if you allow a book to exist in multiple bookcases. Existing in multiple places sounds more like tags and categories, not necessarily bookshelves. Maybe bookshelves themselves can have a reference system. In real life bookshelves could categorize books alphabetically or topically. For BookStack, you could have a structure like this, it could even be auto-generated based on alpha, or based on tags. I think most use cases would have shelves relating to departments in a company. The IT dept, the media dept, etc. But automatic shelves would be a neat concept. A bookshelf for all books and pages created per-user. This is Zack's shelf, for example. Or shelves based on tags or alpha as mentioned. The bottom line is, after only about 9 or 12 books, it's already a bit much to look at. At the very least I think after about 12 books, the grid view should get smaller. Instead of 3 blocks wide it could adjust to 4 blocks wide with smaller thumbnails. Maybe even 5 blocks wide if you have over 30 books. OR, do the shelves, but it must be visually pleasing to do shelves. The whole idea is to reduce visual clutter and make it a little easier to browse books. We should still have a "view all books" view, just to avoid clicking in and out of shelves, kind of like looking at my Amazon Kindle, you can view the entire list of books, that should always be available. But shelves could simply be an alternative to grid and list view for those of us who want to organize our books into "folders".
Author
Owner

@ssddanbrown commented on GitHub (Sep 20, 2018):

Just to provide an update, I'm coming to the final steps of the build of this in #947, Just have to implement some testing. I'm hoping I can get this done and then wrap up the next release by the end of this weekend.

Please note the initial release with bookshelves will be focused on the core functionality as in my proposal above, Most of the design and UI is simply copied from the 'Book' UI.

I plan on doing a UI update soon after which should provide bookshelves a slightly more unique & focused design & user-experience. This will also aim to improve the efficiency of the UI in many areas so may align it closer to what you are thinking about @guyinpv.

I'll have a think about having pages within a BookShelf. If this is something you want please create a new issue for it for more focused discussion.

@ssddanbrown commented on GitHub (Sep 20, 2018): Just to provide an update, I'm coming to the final steps of the build of this in #947, Just have to implement some testing. I'm hoping I can get this done and then wrap up the next release by the end of this weekend. Please note the initial release with bookshelves will be focused on the core functionality as in my proposal above, Most of the design and UI is simply copied from the 'Book' UI. I plan on doing a UI update soon after which should provide bookshelves a slightly more unique & focused design & user-experience. This will also aim to improve the efficiency of the UI in many areas so may align it closer to what you are thinking about @guyinpv. I'll have a think about having pages within a BookShelf. If this is something you want please create a new issue for it for more focused discussion.
Author
Owner

@ssddanbrown commented on GitHub (Sep 21, 2018):

#947 has now been merged into master so I will now close this pull request. As my message above, Expect a new release soon with Bookshelves included.

@ssddanbrown commented on GitHub (Sep 21, 2018): #947 has now been merged into master so I will now close this pull request. As my message above, Expect a new release soon with Bookshelves included.
Author
Owner

@willc commented on GitHub (Dec 2, 2018):

It looks like Shelves were implemented since this thread was closed, and that puts BookStack on par with OneNote as far as levels of categorization/organization go (not that we need to compare this to OneNote, necessarily).

But after using this app for a few days and starting to port over years of content from OneNote, I am thinking that just one more level of depth (sub chapters) would make a huge positive impact on being able to organize everything just so.

I don't think it needs to become a slippery slope towards supporting/coding infinite levels of content. But based on all the comments and support for just one more level above, I think it would be a really good feature to have.

@willc commented on GitHub (Dec 2, 2018): It looks like Shelves were implemented since this thread was closed, and that puts BookStack on par with OneNote as far as levels of categorization/organization go (not that we need to compare this to OneNote, necessarily). But after using this app for a few days and starting to port over years of content from OneNote, I am thinking that just one more level of depth (sub chapters) would make a huge positive impact on being able to organize everything just so. I don't think it needs to become a slippery slope towards supporting/coding infinite levels of content. But based on all the comments and support for just one more level above, I think it would be a really good feature to have.
Author
Owner

@phylogram commented on GitHub (Apr 13, 2020):

When I go to my library, there are so many books with nested chapters (not only subchapters), and many of them are great books. I was looking for writing software, which does not dictate organizational logic.

@phylogram commented on GitHub (Apr 13, 2020): When I go to my library, there are so many books with nested chapters (not only subchapters), and many of them are great books. I was looking for writing software, which does not dictate organizational logic.
Author
Owner

@ssddanbrown commented on GitHub (Apr 13, 2020):

I was looking for writing software, which does not dictate organizational logic.

@phylogram Then, to be bluntly honestly, BookStack is probably not the platform you're looking for. An opinionated structure is at the core of the platform.

@ssddanbrown commented on GitHub (Apr 13, 2020): > I was looking for writing software, which does not dictate organizational logic. @phylogram Then, to be bluntly honestly, BookStack is probably not the platform you're looking for. An opinionated structure is at the core of the platform.
Author
Owner

@JoeIzzard commented on GitHub (Jan 14, 2022):

Just to throw my hat in on the issue. I think Subchapters would provide added benefit to Bookstack for the reason of Permissions management.

I am currently documenting our systems using Bookstack. Each department is given a Shelf, with each App or Topic existing as a Book. If multiple departments use an app we can share it in multiple shelfs. Using JumpCloud as an example (We use it for account management), we have the book set to be viewable by everyone. It includes information on resetting passwords and how to access the user portal.

I then have a chapter explaining LDAP, and how to enable a user in the LDAP directory. This chapter can be viewed by Managers. In the same chapter it would be good to then go one more level for system configuration. This information should only be viewable by Admins. The additional level would give us the flexibility of documenting very large interconnected systems with complex permission structures easily and from everything I have documented so far, one additional level would solve a lot of the issues.

Another example is License Servers for an app. I could break it out into another book, but ideally I would be able to document the License Server for app A, in the app A book. The additional level would give more control of that very large topic.

I've seen some talk of Sections in these discussions and think that could work well as a way to maintain the link to books and this additional level. Some very long or varied books include sections of chapters. This could provide the same function as a sub-chapter, but instead placed above a chapter giving you:

  • Shelf
    • Book
      • Section
        • Chapter
          • Page

I have opened another issue (#3167) As a potential work around for not having another layer but still getting the same permission control of content, although that would also be a nice feature on its own.

@JoeIzzard commented on GitHub (Jan 14, 2022): Just to throw my hat in on the issue. I think Subchapters would provide added benefit to Bookstack for the reason of Permissions management. I am currently documenting our systems using Bookstack. Each department is given a Shelf, with each App or Topic existing as a Book. If multiple departments use an app we can share it in multiple shelfs. Using JumpCloud as an example (We use it for account management), we have the book set to be viewable by everyone. It includes information on resetting passwords and how to access the user portal. I then have a chapter explaining LDAP, and how to enable a user in the LDAP directory. This chapter can be viewed by Managers. In the same chapter it would be good to then go one more level for system configuration. This information should only be viewable by Admins. The additional level would give us the flexibility of documenting very large interconnected systems with complex permission structures easily and from everything I have documented so far, one additional level would solve a lot of the issues. Another example is License Servers for an app. I could break it out into another book, but ideally I would be able to document the License Server for app A, in the app A book. The additional level would give more control of that very large topic. I've seen some talk of Sections in these discussions and think that could work well as a way to maintain the link to books and this additional level. Some very long or varied books include sections of chapters. This could provide the same function as a sub-chapter, but instead placed above a chapter giving you: - Shelf - - Book - - - Section - - - - Chapter - - - - - Page I have opened another issue (#3167) As a potential work around for not having another layer but still getting the same permission control of content, although that would also be a nice feature on its own.
Author
Owner

@tvogt commented on GitHub (May 4, 2022):

I'd also like one additional level, as outlined above by JoeIzzard. This structure can actually be found in many paper books.

@tvogt commented on GitHub (May 4, 2022): I'd also like one additional level, as outlined above by JoeIzzard. This structure can actually be found in many paper books.
Author
Owner

@KnightNine commented on GitHub (Mar 28, 2023):

has anyone suggested "non-collapsable chapter separators which can be nested?" simply being a grouping mechanism for chapters that is seen on the Book level without needing a whole page dedicated to displaying chapters within this sublevel.
I mean the Book>Chapter>Page makes sense for novels but for manuals it would help to be able to group chapters by subject.

Right now I'm running into an issue where I have a "Lore Encyclopedia" Book for and I want a chapter for "Items" and within it would be categories of items like "Weapons & Tools", "Miscellaneous", and "Equipment", though ideally these would also be chapters unless I want a single bloated page containing every "Weapon And Tool" across my entire project, which I don't.


As the outermost level of categorization I'd rather dedicate shelves to specific projects I'm working on:

  • Project i'm working on (Shelf):
    • Documentation specific to each profession in the project (Art, Writing, Programming, Marketing) (Books)
      • Broad categorization (Coding Languages) (chapter seperators.)
        • Specific categorization (PHP, C++, HTML, etc...) (Chapters)
          • information in regards to that specific categorization that is in a digestible step by step format across several pages (Pages)

It would be annoying to have books for specific parts of the encyclopedia.

The only way around this that I can see is to add a prefix to define the chapter category like "Items- Weapons & Tools" and "Items- Miscellaneous". Though it would probably be better to split up my encyclopedia into different books since I wouldn't need to add this ugly prefix as much for my 3 broad categories.

@KnightNine commented on GitHub (Mar 28, 2023): has anyone suggested "non-collapsable chapter separators which can be nested?" simply being a grouping mechanism for chapters that is seen on the Book level without needing a whole page dedicated to displaying chapters within this sublevel. I mean the Book>Chapter>Page makes sense for novels but for manuals it would help to be able to group chapters by subject. Right now I'm running into an issue where I have a "Lore Encyclopedia" Book for and I want a chapter for "Items" and within it would be categories of items like "Weapons & Tools", "Miscellaneous", and "Equipment", though ideally these would also be chapters unless I want a single bloated page containing every "Weapon And Tool" across my entire project, which I don't. --- As the outermost level of categorization I'd rather dedicate shelves to specific projects I'm working on: - Project i'm working on (Shelf): - Documentation specific to each profession in the project (Art, Writing, Programming, Marketing) (Books) - Broad categorization (Coding Languages) (chapter seperators.) - Specific categorization (PHP, C++, HTML, etc...) (Chapters) - information in regards to that specific categorization that is in a digestible step by step format across several pages (Pages) It would be annoying to have books for specific parts of the encyclopedia. The only way around this that I can see is to add a prefix to define the chapter category like "Items- Weapons & Tools" and "Items- Miscellaneous". Though it would probably be better to split up my encyclopedia into different books since I wouldn't need to add this ugly prefix as much for my 3 broad categories.
Author
Owner

@baevga commented on GitHub (Apr 16, 2023):

Yes, i'm sure that having one more level will play a very good role in wiki organization

@baevga commented on GitHub (Apr 16, 2023): Yes, i'm sure that having one more level will play a very good role in wiki organization
Author
Owner

@eskapdk commented on GitHub (Jun 15, 2023):

i'd also like if bookstack have one additional level like sub-chapters / section / other.

i'm using bookstack for my project in applications government wiki, it's used by two user there is public (like user of my apps for access on apps user guides) and private user (techincal user like technical witers, PM and others for acces on technical documents).

it will be great if have one level like sub chapters / section / other, because in my old user guides and tech docs (it's using PDFs) its have leves like book -> chapter -> sub chapter -> pages, and current bookstack book -> chapter -> pages, i would be greatly appreciate if the current bookstack hace more at least one sub-chapters

Or if it's cannot be done because all reasons above, can you suggest bookstack hack if i will add some chaptes, please?

thank you

@eskapdk commented on GitHub (Jun 15, 2023): i'd also like if bookstack have one additional level like sub-chapters / section / other. i'm using bookstack for my project in applications government wiki, it's used by two user there is public (like user of my apps for access on apps user guides) and private user (techincal user like technical witers, PM and others for acces on technical documents). it will be great if have one level like sub chapters / section / other, because in my old user guides and tech docs (it's using PDFs) its have leves like book -> chapter -> sub chapter -> pages, and current bookstack book -> chapter -> pages, i would be greatly appreciate if the current bookstack hace more at least one sub-chapters Or if it's cannot be done because all reasons above, can you suggest bookstack hack if i will add some chaptes, please? thank you
Author
Owner

@komoricodrutz commented on GitHub (Jun 20, 2023):

7 years after this topic was opened (and almost 3 years after I switched to Linux), I stumbled upon BookStack in my until now endless search for a FOSS alternative to OneNote.
It is wonderful, it ticks almost all my checkboxes, however, the possibility of adding more nesting levels is something that I also consider extremely useful.
My current workaround is to add a chapter without pages as a "section title" to be able to more easily follow the structure, but the multiple nesting function would make it a lot easier to sort your articles.

Thank you!

@komoricodrutz commented on GitHub (Jun 20, 2023): 7 years after this topic was opened (and almost 3 years after I switched to Linux), I stumbled upon BookStack in my until now endless search for a FOSS alternative to OneNote. It is wonderful, it ticks **almost** all my checkboxes, however, the possibility of adding more nesting levels is something that I also consider extremely useful. My current workaround is to add a chapter without pages as a "section title" to be able to more easily follow the structure, but the multiple nesting function would make it a lot easier to sort your articles. Thank you!
Author
Owner

@MKHIII commented on GitHub (Sep 25, 2023):

It would be so helpful to have an additional layer of organization. I am migrating an entire Confluence Space to BookStack and am having extreme difficulties. I cannot create links in the chapter descriptions (as you can link to headings, other pages, etc on pages themselves) and simply being able to create a chapter index would be helpful. Honestly, it should automatically do this as you add pages to a chapter. A section or a sub-chapter would be really helpful as well. Also...a link list that can be sorted containing all books on a shelf, or chapters in a book, or pages within a chapter that occurs automatically and can be sorted OR at least the ability to put links in the description section of these. As well as having just one more level of organization...

@MKHIII commented on GitHub (Sep 25, 2023): It would be so helpful to have an additional layer of organization. I am migrating an entire Confluence Space to BookStack and am having extreme difficulties. I cannot create links in the chapter descriptions (as you can link to headings, other pages, etc on pages themselves) and simply being able to create a chapter index would be helpful. Honestly, it should automatically do this as you add pages to a chapter. A section or a sub-chapter would be really helpful as well. Also...a link list that can be sorted containing all books on a shelf, or chapters in a book, or pages within a chapter that occurs automatically and can be sorted OR at least the ability to put links in the description section of these. As well as having just one more level of organization...
Author
Owner

@jinjaghost commented on GitHub (Oct 19, 2023):

+1 for one more level.

The Shelf > Book > Section > Chapter > Page would be a perfect fit for many users.

@jinjaghost commented on GitHub (Oct 19, 2023): +1 for one more level. The Shelf > Book > Section > Chapter > Page would be a perfect fit for many users.
Author
Owner

@yblis commented on GitHub (Nov 7, 2023):

Hello :)

Given that we are in the context of a 'book', why not simply add:

Library => Shelf => Book => Chapter => Pages

This sequence outlines the hierarchical organization of books within a library, starting from the broadest category (the library itself) and narrowing down to the individual pages within a book.

@yblis commented on GitHub (Nov 7, 2023): Hello :) Given that we are in the context of a 'book', why not simply add: > **Library** => Shelf => Book => Chapter => Pages This sequence outlines the hierarchical organization of books within a library, starting from the broadest category (the library itself) and narrowing down to the individual pages within a book.
Author
Owner

@canklamassono commented on GitHub (Dec 20, 2023):

As this Topic has been discussed a lot already - why not give an option to Enable another Layer (Like Sections/Subchapters) etc. This has to be done and isn't enabled by default, therefore it wouldn't contradict the general mindset of keeping it simple except for when the User has the special need to make it more complicated.

I really don't get why even after Shelves have been introduced, this optional setting for more Layers isn't available yet. Obviously people will continue to ask for it.

@canklamassono commented on GitHub (Dec 20, 2023): As this Topic has been discussed a lot already - why not give an option to **Enable** another Layer (Like Sections/Subchapters) etc. This has to be done and isn't enabled by default, therefore it wouldn't contradict the general mindset of keeping it simple except for when the User has the special need to make it more complicated. I really don't get why even after Shelves have been introduced, this optional setting for more Layers isn't available yet. Obviously people will continue to ask for it.
Author
Owner

@ssddanbrown commented on GitHub (Dec 20, 2023):

I wouldn't want to add an option that changes the core structure and focus of BookStack, especially just for only when users have a "special need" for it. I generally avoid making things options in that manner due to the eventual complexity they introduce.

Generally my view on extra layers remains much unchanged from my original comment in this thread. I specifically built to a fixed level system for the usability/UX/design goals of BookStack, and each layer impacts those goals while adding complexity. Therefore I don't really have any intent to expand on this within the official project.
That's not to say there's not a desire or need in some use-cases, it's just that I don't want to alter/maintain BookStack with this specific change to meet those desires/use-cases and, as demonstrated above, adding another layer will likely still result in a request here for just one extra level.

@ssddanbrown commented on GitHub (Dec 20, 2023): I wouldn't want to add an option that changes the core structure and focus of BookStack, especially just for only when users have a "special need" for it. I generally avoid making things options in that manner due to the eventual complexity they introduce. Generally my view on extra layers remains much unchanged from my original comment in this thread. I specifically built to a fixed level system for the usability/UX/design goals of BookStack, and each layer impacts those goals while adding complexity. Therefore I don't really have any intent to expand on this within the official project. That's not to say there's not a desire or need in some use-cases, it's just that I don't want to alter/maintain BookStack with this specific change to meet those desires/use-cases and, as demonstrated above, adding another layer will likely still result in a request here for just one extra level.
Author
Owner

@canklamassono commented on GitHub (Dec 21, 2023):

Thank you for the quick reply and reasonable answer. Even though you're not going to add this to the core, is there a possibility for you to disclose how this could be achieved (if there actually is a straightforward way) if someone wanted to implement this by themselves?

@canklamassono commented on GitHub (Dec 21, 2023): Thank you for the quick reply and reasonable answer. Even though you're not going to add this to the core, is there a possibility for you to disclose how this could be achieved (if there actually is a straightforward way) if someone wanted to implement this by themselves?
Author
Owner

@KnightNine commented on GitHub (Dec 23, 2023):

@ssddanbrown I don't understand how it could be seen as a "special need", it is quite natural that you'd want an extra layer of categorization to pages mirroring how many categories and sub-categories of information (how much depth) the subject you're trying to document has.

the solution you provided for this extended categorization functionality doesn't seem to be relevant to organizing the branches of a subject which I believe this is on the topic of. Tags are more for labeling the relationships between pages/chapters/shelves.

I still suggest infinite categorization at the Chapter level but in a simplified way that is title only and non-collapsible, so that there isn't any folder bloat and it's all visible at once. People will always be asking for another layer of categorization, so the only solution I see is to give them infinite categorization in a way that isn't overly complex. On the back end it can simply function the same way as tags but only relevant to the layer the page exists on, where you add the category as a label of the page without actually nesting the data and then displaying it as if it were nested.

@KnightNine commented on GitHub (Dec 23, 2023): @ssddanbrown I don't understand how it could be seen as a "special need", it is quite natural that you'd want an extra layer of categorization to pages mirroring how many categories and sub-categories of information (how much depth) the subject you're trying to document has. the [solution you provided](https://github.com/BookStackApp/BookStack/pull/110) for this extended categorization functionality doesn't seem to be relevant to organizing the branches of a subject which I believe this is on the topic of. Tags are more for labeling the relationships between pages/chapters/shelves. I still suggest infinite categorization at the Chapter level but in a simplified way that is title only and non-collapsible, so that there isn't any folder bloat and it's all visible at once. People will always be asking for another layer of categorization, so the only solution I see is to give them infinite categorization in a way that isn't overly complex. On the back end it can simply function the same way as tags but only relevant to the layer the page exists on, where you add the category as a label of the page without actually nesting the data and then displaying it as if it were nested.
Author
Owner

@Lbsl commented on GitHub (Jan 10, 2024):

I'm trying to move team's knowledge share docs from other system (showdoc) to BookStack, but the old system has much deeper structures so it's very hard to do the migration, it will be much more helpful if BookStack can support recursive nested chapters

@Lbsl commented on GitHub (Jan 10, 2024): I'm trying to move team's knowledge share docs from other system (showdoc) to BookStack, but the old system has much deeper structures so it's very hard to do the migration, it will be much more helpful if BookStack can support recursive nested chapters
Author
Owner

@UAnton commented on GitHub (Jan 18, 2024):

+1

@UAnton commented on GitHub (Jan 18, 2024): +1
Author
Owner

@JohnShield commented on GitHub (Mar 6, 2024):

Thanks Dan for creating bookstack,

It's a great tool and I'm impressed by how well it runs and been thought out.

Background

I've been trialing Bookstack for use as the wiki for my company, specifically in scope for the engineering department. The main shortfall I'm seeing is the hierarchy depth feels like a bad fit for my use case.

  1. Company level data department/project/function organisation takes up 3 layers of hierarchy by itself.
  2. Larger engineering designs lends themself to creating hierarchy that matches the system breakdown, which can go 3 deep before getting to the main content pages.
  3. Then another 2 layers of hierarchy to organize the various documents.

The regular hierarchy is:
Department->Projects->Discipline Teams->Major System Components->Sub-components->Sub-Sub-Components->Document Category->Documents

Attempt at mapping Hierarchy to Bookstack

In an attempt to organize the data, I've been adding the additional hierarchy levels into the name of books, chapters and pages. It's been okay at the book level, as the first 3 layers of hierarchy are organisational and not useful for everyday work. However, it's a rather messy outcome at the chapter and page level. It's difficult to find the information you want within the large number of chapters and pages and their long names.

This is our current layout, when trying to map it to Bookstack:
Shelves -> Department: (IT department, Engineering Department, Company Policies, etc)
Books -> Projects: (Various paid customer projects)
Books (Artificial naming) -> Discipline Teams: (Artificial naming of books to avoid chapters for this) (Software, Hardware, Firmware, etc)
Chapters -> Major components: (Interfaces, Digitial Signal Processing, Peripheral Chips, Formal Verification Testing)
Chapters (Artificial naming) -> Sub-components: (Ethernet Interface, Chip Configurations, User Interface)
Pages -> Sub-component (Overview, Design Descriptions, Sub-component interfaces, Sub-Sub-Components)
Pages (Artificial naming) -> Sub-Sub-Components (Overview, Design Descriptions, Sub-Sub-component interfaces)
Pages (Artificial naming) -> Document Category (legacy pages, test data, design exploration, test setup)
Pages (Artificial naming) -> Documents (Individual instances of the categories)

Discussion

My observations while trying to flatten the hierarchy. The organizational/company hierarchy isn't useful day to day. However, it needs to be there to avoid different teams and departments from tripping over each other. I think it could be replaced by a simple top level jump page, to different groupings of shelves or to specific books.

However, the organizational/company separation also needs to be kept separate otherwise the listing of shelves and books would end up very cluttered.

The 3 levels of hierarchy for system components I think is critical for documentation of my engineering work. The problem is the short page names often are misleading about what the contents contain. Often times there's a page named "Decoder .... ....", which is a correct description of what it is, but there's actually 3 different parts of the system that also match that description. The most important bit of information is what is the major component or function the decoder is part of, which is part of the heirarchy. Similarly staff will often make a page called "verification test results" or something with similar naming, which can be around 20 A4 pages of content. The length of the content requires it's separated into its own page, and the naming of the page requires some hierarchical information about what it relates to.

This common problem of similar names being used for different parts of the system also degrades search capability, making hierarchy more important. Tagging pages sounds like an alternative solution, but our systems are large and complex enough that it's difficult to know what tag to look for. Stepping down through the hierarchy from the high system level down to the detail of components is more intuitive. Furthermore, the hierarchy sometimes needs to change names, to help differentiate between components that were originally similarly named. Hierarchy changes makes that quick, updating all the tags on every page would be very slow.

Reading your prior thoughts on hierarchy, I feel the different perspectives are related to use-case:

  1. Larger organisations require large parts of the hierarchy dedicated to purely staff organisational separation.
  2. Larger project scope creates more content, and more content drives the need for more hierarchy. The last project I worked on in Confluence, it ran for only 1.5 years (a short time frame and smaller project), and my team produced +200 confluence pages, which if printed out in non-verbose proper print formatting would be around +1000 A4 pages.
  3. Finally, I think wikis when they reach a certain data density need curating. Someone needs to act as the Librarian. As the lead of my team, part of my role was acting as the Librarian to organise the pages, so that it is easy to find information. It didn't take that long, 10hrs total for the whole 1.5 years, but made a big difference in how easy it was to use our knowledge base.

Seeking and Advice

Do you have any advice on how to better organise our pages on bookstack? Trying to add artificial extra levels of hierarchy as part of the naming convention has been very awkward.

Suggestion

Two potential suggestions.

I think if the staff organisational separation could be done as a separate hierarchy system. That would leave the engineering teams to start at the shelves level. Using Bookstack's 3 levels purely for the system design, would be doable. The engineering team requirement is around 4 levels, so only minor inconvenience would be experienced bringing that down to 3 levels.

The other suggestion is to allow for around 4 depth hierarchy between pages. I agree there are many situations, where having the deep hierarchy is just letting people shoot themselves in the foot. This is especially the case where the wiki is being used at the small scale. However, it is limiting the scale that Bookstack can be used in, for the reasons I explained above.

Best Regards,

John Shield

@JohnShield commented on GitHub (Mar 6, 2024): Thanks Dan for creating bookstack, It's a great tool and I'm impressed by how well it runs and been thought out. ### Background I've been trialing Bookstack for use as the wiki for my company, specifically in scope for the engineering department. The main shortfall I'm seeing is the hierarchy depth feels like a bad fit for my use case. 1) Company level data department/project/function organisation takes up 3 layers of hierarchy by itself. 2) Larger engineering designs lends themself to creating hierarchy that matches the system breakdown, which can go 3 deep before getting to the main content pages. 3) Then another 2 layers of hierarchy to organize the various documents. The regular hierarchy is: Department->Projects->Discipline Teams->Major System Components->Sub-components->Sub-Sub-Components->Document Category->Documents ### Attempt at mapping Hierarchy to Bookstack In an attempt to organize the data, I've been adding the additional hierarchy levels into the name of books, chapters and pages. It's been okay at the book level, as the first 3 layers of hierarchy are organisational and not useful for everyday work. However, it's a rather messy outcome at the chapter and page level. It's difficult to find the information you want within the large number of chapters and pages and their long names. This is our current layout, when trying to map it to Bookstack: Shelves -> Department: (IT department, Engineering Department, Company Policies, etc) Books -> Projects: (Various paid customer projects) Books (Artificial naming) -> Discipline Teams: (Artificial naming of books to avoid chapters for this) (Software, Hardware, Firmware, etc) Chapters -> Major components: (Interfaces, Digitial Signal Processing, Peripheral Chips, Formal Verification Testing) Chapters (Artificial naming) -> Sub-components: (Ethernet Interface, Chip Configurations, User Interface) Pages -> Sub-component (Overview, Design Descriptions, Sub-component interfaces, Sub-Sub-Components) Pages (Artificial naming) -> Sub-Sub-Components (Overview, Design Descriptions, Sub-Sub-component interfaces) Pages (Artificial naming) -> Document Category (legacy pages, test data, design exploration, test setup) Pages (Artificial naming) -> Documents (Individual instances of the categories) ### Discussion My observations while trying to flatten the hierarchy. The organizational/company hierarchy isn't useful day to day. However, it needs to be there to avoid different teams and departments from tripping over each other. I think it could be replaced by a simple top level jump page, to different groupings of shelves or to specific books. However, the organizational/company separation also needs to be kept separate otherwise the listing of shelves and books would end up very cluttered. The 3 levels of hierarchy for system components I think is critical for documentation of my engineering work. The problem is the short page names often are misleading about what the contents contain. Often times there's a page named "Decoder .... ....", which is a correct description of what it is, but there's actually 3 different parts of the system that also match that description. The most important bit of information is what is the major component or function the decoder is part of, which is part of the heirarchy. Similarly staff will often make a page called "verification test results" or something with similar naming, which can be around 20 A4 pages of content. The length of the content requires it's separated into its own page, and the naming of the page requires some hierarchical information about what it relates to. This common problem of similar names being used for different parts of the system also degrades search capability, making hierarchy more important. Tagging pages sounds like an alternative solution, but our systems are large and complex enough that it's difficult to know what tag to look for. Stepping down through the hierarchy from the high system level down to the detail of components is more intuitive. Furthermore, the hierarchy sometimes needs to change names, to help differentiate between components that were originally similarly named. Hierarchy changes makes that quick, updating all the tags on every page would be very slow. Reading your prior thoughts on hierarchy, I feel the different perspectives are related to use-case: 1. Larger organisations require large parts of the hierarchy dedicated to purely staff organisational separation. 2. Larger project scope creates more content, and more content drives the need for more hierarchy. The last project I worked on in Confluence, it ran for only 1.5 years (a short time frame and smaller project), and my team produced +200 confluence pages, which if printed out in non-verbose proper print formatting would be around +1000 A4 pages. 3. Finally, I think wikis when they reach a certain data density need curating. Someone needs to act as the Librarian. As the lead of my team, part of my role was acting as the Librarian to organise the pages, so that it is easy to find information. It didn't take that long, 10hrs total for the whole 1.5 years, but made a big difference in how easy it was to use our knowledge base. ### Seeking and Advice Do you have any advice on how to better organise our pages on bookstack? Trying to add artificial extra levels of hierarchy as part of the naming convention has been very awkward. ### Suggestion Two potential suggestions. I think if the staff organisational separation could be done as a separate hierarchy system. That would leave the engineering teams to start at the shelves level. Using Bookstack's 3 levels purely for the system design, would be doable. The engineering team requirement is around 4 levels, so only minor inconvenience would be experienced bringing that down to 3 levels. The other suggestion is to allow for around 4 depth hierarchy between pages. I agree there are many situations, where having the deep hierarchy is just letting people shoot themselves in the foot. This is especially the case where the wiki is being used at the small scale. However, it is limiting the scale that Bookstack can be used in, for the reasons I explained above. Best Regards, John Shield
Author
Owner

@JohnShield commented on GitHub (Mar 6, 2024):

Hi Dan,

Another suggestion. In theory, you could get some artificial "Visual Hierarchy" simply with how you display the pages and chapters, by adding a simple option to indent the chapter/page colored bar. See the image below.

Visually it can provide the understanding of a level or two of extra hierarchy to the reader.

This has the drawback that if you move the parent page it doesn't move the subpages, so the content producers need to be conscious of page relationships when they move pages. It also can become confusing when there are 2 or more levels of visual hierarchy with 7 or more pages involved, as you can't minimize the visual hierarchy to reduce the page clutter.

image

Best Regards,

John

@JohnShield commented on GitHub (Mar 6, 2024): Hi Dan, Another suggestion. In theory, you could get some artificial "Visual Hierarchy" simply with how you display the pages and chapters, by adding a simple option to indent the chapter/page colored bar. See the image below. Visually it can provide the understanding of a level or two of extra hierarchy to the reader. This has the drawback that if you move the parent page it doesn't move the subpages, so the content producers need to be conscious of page relationships when they move pages. It also can become confusing when there are 2 or more levels of visual hierarchy with 7 or more pages involved, as you can't minimize the visual hierarchy to reduce the page clutter. ![image](https://github.com/BookStackApp/BookStack/assets/11167392/375c1fce-d399-4368-a62e-61b5880f5a3c) Best Regards, John
Author
Owner

@WirtsLegs commented on GitHub (Mar 13, 2025):

This is definitely something I would love to see and is really the only thing holding me back from migrating to bookstack, otherwise the app looks and feels great and I would love to adopt it.

Regardless of what the levels are called the classic hierarchical approach to storing knowledge works extremely well, confluence is popular for a reason, some people get a little page-nest-happy but I've also seen a lot of spaces with 10+ layers that are all appropriate.

In one of my current use-cases I'm looking at documenting a large set of SOPs for which the current nesting limits simply won't work, really in every usecase I have in mind I'd likely need to go have more layers than bookstack supports.

@WirtsLegs commented on GitHub (Mar 13, 2025): This is definitely something I would love to see and is really the only thing holding me back from migrating to bookstack, otherwise the app looks and feels great and I would love to adopt it. Regardless of what the levels are called the classic hierarchical approach to storing knowledge works extremely well, confluence is popular for a reason, some people get a little page-nest-happy but I've also seen a lot of spaces with 10+ layers that are all appropriate. In one of my current use-cases I'm looking at documenting a large set of SOPs for which the current nesting limits simply won't work, really in every usecase I have in mind I'd likely need to go have more layers than bookstack supports.
Author
Owner

@hakancunier commented on GitHub (Apr 10, 2025):

Come on! You should enable multiple levels this is really a must, then unwilling people don't have to use it. This is not a developers or system designers issue, it's content editors issue.

@hakancunier commented on GitHub (Apr 10, 2025): Come on! You should enable multiple levels this is really a must, then unwilling people don't have to use it. This is not a developers or system designers issue, it's content editors issue.
Author
Owner

@zib-ctrl commented on GitHub (May 21, 2025):

At least one or more level would really be necessary.
The presentation of the navigation is a design problem that can be solved.

Without wanting to diminish the valuable / great work of the developer of this tool, the current basic layout of the navigation still has potential for improvement (e.g. why does the number of subpages have to be displayed as a separate menu item)?

@zib-ctrl commented on GitHub (May 21, 2025): At **least one or more level would really be necessary**. The presentation of the navigation is a design problem that can be solved. Without wanting to diminish the valuable / great work of the developer of this tool, the current basic layout of the navigation still has potential for improvement (e.g. why does the number of subpages have to be displayed as a separate menu item)?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#90