Views

Understand views (tabs and dropdowns), how they relate to dimensions and content, and how to choose and manage navigation patterns in the Web Editor.

Overview

Views control how content is organized and navigated within a Dimension context in Documentation.AI.

• Dimensions decide which content is in scope (for example, product, audience, or version).
• Views decide how that scoped content appears in the UI (Tabs, Sidebar Dropdowns, and how they nest).
• Content items (Groups, Pages, Page Groups, OpenAPI References) live inside Views to form your navigation tree.

You work with views in two places:

• In the Web Editor, when you organize navigation for a project.
• In site configuration, when you define views and patterns programmatically (see Site configuration).

This page focuses on:

• The conceptual model and reference rules for views.
• A Web Editor–focused workflow for adding and organizing tabs and dropdowns.

Think of a dimension as a filter on content, and a view as the layout for navigating that filtered content.

Supported view types

Documentation.AI supports two view types at the layout layer:

• Tabs: horizontal, top-level navigation areas.
• Dropdowns: collapsible sidebar categories.

Both types act as containers for content or other containers.

Tabs

Tabs are top-level navigation sections such as Guides, API Reference, or Changelog.

Use Tabs when:

• You have 2–5 major sections readers switch between often.
• Each section needs its own navigation branch.
• You want clear separation between content types (Guides vs API) or audiences (Developers vs Admins).

What Tabs do: Switching Tabs changes the active navigation branch and typically changes what appears in the sidebar.

You will often see tabs used in patterns like:

• Guides | API Reference | Changelog
• Developers | Admins

Dropdowns

Dropdowns are collapsible sidebar categories such as Getting Started, Integrations, or SDKs.

Use Dropdowns when:

• The sidebar is long and needs clear categories.
• You need hierarchy inside a section.
• You want readers to drill down through categories.

What Dropdowns do:

• A Dropdown is a container: it reveals child items when expanded.
• Dropdowns can nest, but keep nesting shallow in most docs.

In practice, your main sidebar will often be composed of dropdowns with groups and pages inside.

Two starting states: with Dimensions vs without Dimensions

Your project can be organized in either of these ways:

• With Dimensions: you first select a Dimension value (for example, Version: v1.0), then build Views inside it.
• Without Dimensions: there is only one global navigation tree, and you build Views directly at the root.

The Editor supports both. The steps for adding Views change slightly depending on which starting state you’re in.

Working with Views in the Web Editor

How layering works (Parent vs Child)

• Add Parent layer (top “ + ”): wraps the current level in a new container and moves existing items under it. Use when you want to restructure everything at that level.
• Add Child layer (bottom/inline “ + ”): adds a new container only inside the selected item. Use when you want to restructure only that section.
• Layers can wrap Views or Content, but Views can’t be added above Dimensions.

Adding Views inside existing Views (nested Views)

Once a View exists, you can add another View underneath it, as long as the one-child rule is respected.

Common examples:

• Add Dropdowns under a Tab to create sidebar categories.
• Nest Dropdowns inside a Dropdown for sub-categories.
• Add Tabs inside a Dropdown only if your intended pattern supports it (Dropdown → Tabs → Dropdown).

How Views connect to Groups and Pages in the sidebar

After you select a branch (for example: Version: v1.0 → Tab: Guides → Dropdown: Integrations), the sidebar will show the content level for that branch:

• If that branch uses Groups, you’ll see a Groups section and add pages inside a group.
• If that branch is flat, you’ll see a Pages section and add pages at the top level.

Views determine where you are in the navigation tree. Groups/Pages determine what content exists inside that branch.

Core rules for Views

These rules explain how Views work and why the Web Editor shows (or hides) certain actions.

1) Views never contain Dimensions

Dimensions (when used) are always the outermost layer of the navigation tree.

• You can add a View as a parent for another View or for Content.
• You cannot add a View as a parent for Dimensions.

2) The one-child rule

Every container can contain exactly one child type.

• A Tab can contain only one of: Pages, Groups, or Dropdowns.
• A Dropdown can contain only one of: Pages, Groups, Tabs, or Dropdowns.

3) Common supported nesting patterns

How views relate to dimensions, groups, and pages

To design navigation that scales, it helps to keep the layering clear:

• Dimension
  • Defines a scope such as Product, Version, or Audience.
• Views (tabs, dropdowns)
  • Control layout and interaction patterns inside that dimension.
• Groups and pages
  • Represent actual documentation content and sections.

Content pages on views

By default, tabs and dropdowns are purely structural: they organize content but do not have pages of their own. Clicking a tab switches the navigation branch; clicking a dropdown expands it.

When to attach a content page to a view

• Tab landing pages – Give each tab an overview page that introduces its section.
• Dropdown hub pages – A dropdown for "Integrations" could have a content page listing supported integrations with a CollectionList component.
• Breadcrumb navigation – When a view has a content page, it appears as a clickable link in the breadcrumb trail, helping readers orient themselves in deep navigation hierarchies.

Add a content page in the Web Editor

1. In the editor sidebar, click the menu icon next to the tab or dropdown name.
2. Select Attach Content Page.
3. Enter a path (slug) for the page, or browse unpublished pages to reuse an existing MDX file.
4. The view now opens its content page when clicked. Write your content or add Collection components.