# 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](/content/docs/customize/site-configuration/index.html)).

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

| Pattern | Structure | Typical use case |
| --- | --- | --- |
| **Pattern 1** | `Dropdown → Tabs → Dropdown` | Complex, category-first navigation with sub-sections |
| **Pattern 2** | `Dropdown → Dropdown` | Pure hierarchical sidebar without horizontal tabs |
| **Pattern 3** | `Tabs → Dropdown → Dropdown` | Tabbed sections each with their own nested categories |

## 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](/content/docs/components/collection-list/index.html) 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](/content/docs/components/collection-list/index.html).

---