Navigation Pane

Intended Audience

The navigation component of the pages panel would be available to Core and commercial customers, while the more advanced operations through the pages panel would be a commercial component.

Additional information

Developing a new tree-based navigation has some limitations we must be aware of while developing this component:

• On the skin side, each skin makes very strong assumptions about the width available for navigation. The new navigation must account for the fact that most skins will only set aside at most 250px of width for navigation. Content overflow is a constant concern, as page titles can be freeform and take any amount of space. Due to the inherent inconsistent handling of overflows by different browsers and the horrible user experience around them, a simple overflow cannot be used to solve this use case. (Note that the scrollbar appears at the bottom of the element - only way we can ensure it shows up is by forcefully restraining the height of the section; but make it too short, and it's useless once a user scrolls.)
• On the performance side, retrieving a full list of subpages has been a consistent performance bottleneck. The pages panel must be able to elegantly handle the use case around retrieving 1,000 pages and displaying a reasonable data set to the end-user.

References

Use Cases

Non-goals

UI requirements

Here is a concept for what the "full tree" would look like, excluding any concept of how the tree actually fits in with the design:

The "Partial Tree" view would activated when a user lands directly on a page deep within the hierarchy. It is proposed as a possible solution to prevent full tree traversals and to optimize load times. Pages that are partially hidden in the partial tree view have swapped their collapsed icons for expand nodes.

API requirements