Currently, the navigation tree for the library is split into two parts: Library and Private
Library: shows only the published pages
Private: shows draft, unlisted and in-review pages
The problem here is that, being a tree structure, nodes can be created at any position in the tree but the default visibility for a node is always "draft" meaning that it won't immediately show in the tree.
This is only ever not the case for top-level (root) nodes, which when created will always show immediately under "Private".
Which poses a UX problem around the design of how the user's content and the public content is shown.
We want to allow users to create any node anywhere and submit it for review so library managers can accept new nodes easily. However, we also don't render the full tree by default. A better design is needed, or rather a better user experience as the overall design is fine.
Solution
Render the full tree, so if an authenticated user views the page, all their own content is also shown, but with a new colour accent indicating a differentiation between published nodes (default, what there is now) and draft nodes (outlined in some way, similar to breadcrumbs)
Merge both trees into one, so that the heading is simply a top-level tree leaf, this solves some of the complexity around dragging (#217) so that items can more easily be dragged between private and published (given the user has the permission)
When rendering, split top-level private pages to the lower "Private" area and anything else not top-level, render it in-line in the tree using the aforementioned styling to highlight non-published nodes.
Currently, when creating a child node, because it's draft by default, it simply does not appear in the tree as it 1. cannot render in the Private section, as it's not a top-level node and 2. cannot render in the Library section as it's not published.
Assuming the API is set up (which I think it is) this should be quite easy.
Another consideration is that users with manage-library permissions may need to be able to see "In review" items in the tree. They will also show in /queue (moderation queue) but it could make sense (if not too complex query-wise) to show them in the main tree too.
Currently, the navigation tree for the library is split into two parts: Library and Private
The problem here is that, being a tree structure, nodes can be created at any position in the tree but the default visibility for a node is always "draft" meaning that it won't immediately show in the tree.
This is only ever not the case for top-level (root) nodes, which when created will always show immediately under "Private".
Which poses a UX problem around the design of how the user's content and the public content is shown.
We want to allow users to create any node anywhere and submit it for review so library managers can accept new nodes easily. However, we also don't render the full tree by default. A better design is needed, or rather a better user experience as the overall design is fine.
Solution
Merge both trees into one, so that the heading is simply a top-level tree leaf, this solves some of the complexity around dragging (#217) so that items can more easily be dragged between private and published (given the user has the permission)
When rendering, split top-level private pages to the lower "Private" area and anything else not top-level, render it in-line in the tree using the aforementioned styling to highlight non-published nodes.
Currently, when creating a child node, because it's draft by default, it simply does not appear in the tree as it 1. cannot render in the Private section, as it's not a top-level node and 2. cannot render in the Library section as it's not published.
Assuming the API is set up (which I think it is) this should be quite easy.
Another consideration is that users with manage-library permissions may need to be able to see "In review" items in the tree. They will also show in /queue (moderation queue) but it could make sense (if not too complex query-wise) to show them in the main tree too.