Managing Technical Documentation Browsing and API Reading

Opening technical documentation from project and public views

In Atloria, generated technical documentation can appear in two different reading contexts: inside a project workspace and in the public documentation site. The content may cover the same API reference pages and technical sections, but the surrounding navigation is different depending on where you open it.

Inside a project, you usually enter the technical documentation flow from the project’s documentation area, where you can browse page lists and move through generated reference content alongside the rest of the project’s documentation structure. This project-scoped view keeps you inside the workspace, so you are reading documentation with the project context around you. That makes it easier to compare technical pages with other project materials and move between documentation sections without leaving the project.

In the public documentation site, readers access the same published reference content through the public navigation experience. This view is focused on reading rather than managing. Public readers see the documentation structure, page titles, and section navigation, but they do not see project workspace controls. The page is presented as published documentation rather than as part of an internal project area.

Use these differences to orient yourself while browsing:

• Project view usually keeps you inside the project workspace and project navigation.
• Public view presents the documentation as a reader-facing site.
• Both views can include the same technical guides and API reference pages if that content has been published.

When you are unsure which view you are in, look at the surrounding navigation and page framing rather than only the page content. The API page itself may look similar, but the project view includes project context while the public view is designed for external reading.

For a broader explanation of where these pages appear, see Using API Reference Pages in Published and Project Views and Browsing Technical Documentation and Entity Reference Pages.

Moving between technical guides and API reference pages

When you browse technical documentation in Atloria, you often need to move back and forth between explanatory guide pages and generated API reference pages. The fastest way to do that is to follow the documentation navigation rather than opening pages one by one from scratch.

1. Open the documentation area from your project workspace or from the public documentation site.
2. Use the left sidebar to find the section you want to read. Look for technical guide pages in the broader documentation structure and API reference entries grouped under their own reference section.
3. Click a guide page when you want explanation, workflow context, or narrative documentation.
4. Click an API reference page when you need request details, field definitions, or response information.
5. Use in-page links when a guide points you directly to a related API page. These links help you jump from explanation to reference without losing your place in the documentation set.
6. To return to a broader section, use the breadcrumb trail, the left navigation, or the parent section link if it is shown on the page.
7. Repeat this pattern as you verify that guide content and generated reference content match each other.

This movement is especially useful for technical writers and reviewers. A guide page may explain when to use a feature, while the API reference page shows the exact request and response structure. By switching between the two, you can confirm that the written guidance still lines up with the generated reference details.

Watch for grouped API sections in the navigation. These groups help you move from high-level technical content into more detailed reference pages without losing the overall documentation structure. If you need a refresher on how technical sections are arranged inside a project, see Managing Technical Documentation Browsing Inside Projects.

Reading generated API reference pages

A generated API reference page in Atloria is built for close reading. The page usually starts with a clear title for the operation, resource, or reference item, followed by identifying information such as a path, name, or other label that distinguishes that page from nearby entries. Near the top, you will also see summary text that explains what the page covers.

As you scroll, the page typically breaks information into predictable sections. Request details are shown in a structured way so you can quickly see what must be sent and what is optional. Response details appear in separate blocks so you can understand what comes back after a request is processed.

Use the page layout like this:

1. Start with the page heading to confirm that you opened the correct reference item.
2. Read the summary text under the heading to understand the purpose of the page before reviewing the details.
3. Look for request sections that list inputs such as parameters, request body fields, and named fields.
4. Check whether fields are marked as required or optional before comparing them with your guide content or implementation notes.
5. Move to the response section to review status codes, response body details, and any linked schema information.
6. Open linked schema or model references when you need more detail about a field structure that is only summarized on the current page.
7. Review example payloads and field tables to understand how the request and response are expected to look in practice.

The table below shows the main page elements you will usually rely on while reading:

Understanding how reference pages are organized

Atloria groups generated reference pages so readers can move through large documentation sets without guessing where each page belongs. In most cases, API reference entries are collected under a dedicated reference area in the documentation navigation, while narrative technical pages stay in broader guide sections. This separation helps you tell whether you are reading explanation or generated reference content before you even open a page.

You will usually notice a few common organization patterns:

• Pages grouped by API area so related topics stay together
• Pages grouped by resource so similar operations appear in one place
• Pages grouped by version when the documentation set separates reference content by release
• Nested pages for schemas or models under a related reference section

These patterns matter because they shape how you browse. If several pages share a resource or topic, they are often listed together in the sidebar. If a page describes a data structure rather than an operation, it may appear under a schema or models section instead of beside guide pages.

Page titles and navigation labels are your best clues. Technical guide pages usually read like instructional content, while generated reference entries are more likely to use concise labels tied to a specific API item. The title style, placement in the sidebar, and nearby pages help you understand what kind of content you are reading.

Project and public views can show the same hierarchy with different surrounding controls. In a project workspace, the reference tree appears within the project context. In the public site, the same hierarchy is presented for reading, without project management controls around it. The page order and grouping should still feel familiar across both views, which makes it easier to review published output against the project source.

Finding the right page faster while browsing large documentation sets

Large documentation sets can feel crowded if you scan every page title from top to bottom. In Atloria, the quickest approach is to narrow your view using the documentation structure first, then confirm the page type from the content on the page itself.

1. Start in the left sidebar and choose the top-level technical section that matches what you are looking for.
2. Expand only the relevant API group or technical section instead of scrolling through the full documentation tree.
3. Open a likely page and check the page heading immediately. A guide page usually reads like instructional content, while a generated API reference page usually opens with a more specific reference title.
4. Scan the body of the page for clues:
   • Parameter tables
   • Request body sections
   • Response blocks
   • Schema references These signs usually mean you are on a generated API reference page.
5. Use breadcrumbs or parent links to confirm where the page sits in the documentation hierarchy.
6. If you are reviewing documentation quality, compare the page title in the sidebar with the page heading on the page. Consistent naming makes it easier for readers to move between guide pages and API pages without confusion.
7. If the page is not the one you need, return to the sidebar and move sideways within the same group before jumping to a completely different section.

This approach is especially helpful when you are reviewing generated documentation after updates. Instead of treating the documentation as one long list, use the structure Atloria already provides: top-level section, grouped reference area, then page-level confirmation. That keeps browsing predictable for both internal reviewers and public readers.

For more page-reading patterns, see Reading API and Technical Reference Pages.

Common issues when browsing documentation and how to fix them

When technical documentation and API reference content are spread across project and public views, a few browsing problems come up repeatedly. Most of them can be solved by checking the page’s location in the documentation structure and confirming how the content is being presented.

1. An API reference page appears in the project view but not in the public view.
   First, confirm that you are looking at the published documentation site rather than the project workspace. If the page exists inside the project but not publicly, review the publication or visibility setup for that generated documentation. A page can be available for internal review before it is visible to public readers.

2. Readers cannot tell whether they are on a guide page or an API reference page.
   Check the page title, breadcrumb trail, and left navigation label. A clear naming pattern helps readers understand whether they are reading explanatory content or generated reference content. If nearby pages use inconsistent labels, update the surrounding documentation structure so the distinction is easier to spot.

3. Links between technical content and API pages feel incomplete.
   Open the guide page and look for in-page links to the related API reference entries. Then check the API navigation group to make sure the target page is easy to find from the sidebar as well. Readers should be able to move both ways: from guide to reference and from reference back to the broader section.

4. Reference pages seem to be in the wrong group or out of order.
   Review the navigation hierarchy and compare page placement across project and public views. If a resource, version, or schema page appears under the wrong section, the documentation structure likely needs adjustment so grouped reference pages stay together.

If you are troubleshooting visibility or review context, the admin-facing areas in Atloria may also help you confirm what is available for readers. Related background is covered in Using the Admin Workspace, Reviewing Security and Audit Controls, and Monitoring Administrative Analytics and Activity.

Overview

This guide focuses on the reading experience for generated technical documentation in Atloria. The main goal is to help you move confidently between technical guide pages and generated API reference pages, whether you are working inside a project workspace or reviewing the published documentation site.

The key ideas are straightforward:

• Generated technical documentation can be read in both project and public views.
• The same reference content may appear in both places, but the surrounding navigation and controls are different.
• Technical guide pages and API reference pages usually sit next to each other in the documentation structure, so readers can move from explanation to detailed reference without leaving the documentation flow.
• Page titles, breadcrumbs, sidebar groups, parameter sections, and response blocks help you quickly identify what kind of page you are viewing.

This guide does not repeat the deeper page anatomy already covered in Browsing Technical Documentation and Entity Reference Pages. Instead, it concentrates on navigation: how to enter the documentation from different views, how to switch between page types, and how to find the right page faster when the documentation set grows.

You will also find practical fixes for common browsing problems, such as a page showing up in a project but not in the public site, unclear page labeling, missing cross-links, or reference groups that feel out of order. These are common review tasks when teams are checking generated documentation before or after publication.

If your job involves reviewing technical docs for clarity, this guide is especially useful because it shows how readers actually move through Atloria’s documentation structure rather than only describing what each page contains.

Prerequisites

Before using the steps and browsing patterns in this guide, make sure the following basics are already in place:

• You can sign in to Atloria and open the relevant workspace. If needed, use Accessing and Registering Your Atloria Account or Signing In to Atloria and Solving Access Problems.
• You have access to a project that already contains generated technical documentation or API reference content.
• If you plan to compare project and public views, the documentation has already been published so the public documentation site is available to read.
• You are familiar with the basic project navigation and documentation areas in Atloria. If not, review Exploring Technical Documentation Inside a Project.
• You understand the difference between a guide page and a generated reference page at a basic level. For that foundation, see Reading API Reference Sections in Technical Documentation and Understanding Entity Detail Pages in Technical Documentation.

It also helps if you already know why you are browsing the documentation. For example, you might be:

• Checking whether published API pages match the project version
• Verifying that guide pages link to the correct reference pages
• Reviewing page organization before sharing documentation with readers
• Comparing how the same content appears internally and publicly

The next document in this sequence is Browsing Entity Reference Pages and Related Details, which goes deeper into reading linked reference details once you have reached the right page.