## Recognizing What Public Page You Are Viewing When you open a public documentation page in **Atloria**, start by checking the context around the page content before you focus on the article itself. The **document title** tells you which page you are reading, but it does not tell you whether you are in the right **project**, **version**, or **audience view**. Those details usually appear in the surrounding page header, navigation area, or version controls. Look for these cues first: - The **project name** shown in the public documentation header or navigation - Any **project-specific branding**, such as a distinct site name or visual identity - The **version selector** or visible version label in the page header - Any **audience indicator** that shows whether you are viewing a general public page or an audience-specific variation These details matter because the same page title can appear in more than one place. For example, a page called **Getting Started** may exist in multiple projects, or it may exist in several releases of the same project. If you only look at the title, it is easy to assume you are on the correct page when you are actually reading a different release or a different documentation set. A good habit is to read the page in this order: - **Project context**: Which documentation set am I in? - **Version context**: Which release am I viewing? - **Audience context**: Is this the public view or a targeted view? - **Document title**: Is this the page I meant to open? [SCREENSHOT: Public documentation page showing the project name, document title, and version selector in the header] If you need help finding the page itself, use the navigation techniques from [Finding and Reading Content in Published Documentation](doc:finding-and-reading-content-in-published-documentation). This guide focuses on understanding the context around the page once you have already opened it. ## Understanding How Project, Version, and Audience Shape the Page A public page in **Atloria** is shaped by three layers of context working together: - **Project** - **Version** - **Audience** The **project** decides which documentation set you are reading. If your team manages more than one published project, each one can have its own public pages, structure, and branding. Even when two projects contain similarly named pages, they are still separate public documentation experiences. The **version** decides which release of that documentation is shown. When a public page includes a **version selector**, changing it can keep you on the same page name or path while swapping the visible content to another release. That means the page title may stay familiar, but the instructions, screenshots, or wording can change because you are now reading a different published revision. The **audience** decides whether the page shows the general public content or an audience-targeted variation. If your team uses audience-specific publishing, some sections may appear only for certain readers, while other sections may be hidden or replaced. This is why one reader may report seeing a warning, note, or setup instruction that another reader cannot find. Keep these effects in mind: - **Same project + different version** can show older or newer instructions - **Same project + same version + different audience** can show different sections or wording - **Different project + same page title** can show a completely different documentation page This combination explains why two people can open what seems like the “same” page and still see different results. Before comparing content, confirm that both people are looking at the same **project name**, the same **version label**, and the same **audience context**. [SCREENSHOT: Version selector open on a public page, with the same page shown across different release labels] ## Checking Why a Public Page Looks Different Than Expected If a public page in **Atloria** looks outdated, incomplete, or unfamiliar, check the visible context before assuming the content is wrong. In most cases, the difference comes from the selected **version**, the active **audience view**, or the fact that the page belongs to a different **project** than expected. Start with the **version label** in the page header or version selector. If the page text does not match the release you expected, you may be reading an earlier or later version of the document. This is especially common when a page title stays the same across releases, but the instructions inside the page have changed. Next, review any **audience indicator** shown on the page. Audience-targeted documentation can hide sections, swap content blocks, or present alternate wording. If a reader says a section is missing, the page may still be correct for the current audience context. Then confirm the **project context**. If your organization publishes multiple documentation sets, a link or search result may have opened a similarly named page in the wrong project. The page title alone will not always reveal that mistake, so compare the header, branding, and navigation area. Use this quick comparison: - **Outdated wording**: check the active **version** - **Missing section**: check the active **audience** - **Unexpected navigation or branding**: check the **project** - **Correct title but wrong content**: compare all three together When reviewing a confusing page, rely on the combination of: - **Page title** - **Project name** - **Version selector** - **Audience context** [SCREENSHOT: Public page header with title, project indicator, and version label highlighted] These cues usually explain why a page looks different without needing to inspect anything behind the scenes. ## Managing Public Context as a Documentation Team For documentation teams, public context is something to review actively, not something to assume is correct. In **Atloria**, a page can look perfectly polished while still being published from the wrong **project**, shown under the wrong **version label**, or displayed with the wrong **audience-targeted content**. When reviewing a public documentation set, first confirm that the correct **project** is the one being presented to readers. Check the public header, project naming, and navigation structure to make sure the published docs set matches the team’s intended project. This is especially important when teams manage multiple projects with similar page names. Then review the **version labels** visible to readers. The labels shown on public pages should match the release naming your team uses internally and in customer communication. If a release is known by one name internally but appears differently in the public selector, readers may choose the wrong version without realizing it. Audience targeting also needs a public review. Check that the current **audience configuration** is exposing the correct content to public readers and not showing a variant meant for a different audience. When audience rules change, revisit affected pages and confirm that the visible sections still match the intended reader experience. A practical review workflow usually includes: - Opening key public pages after each **version update** - Checking the **version selector** on those pages - Reviewing audience-targeted pages in the expected **audience view** - Confirming the **project name** and public navigation are still correct - Comparing important pages side by side when teams report mismatches [SCREENSHOT: Public documentation review session with version selector and page navigation visible] If your team also manages release readiness, pair this review with the checks described in [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Controlling Version Visibility and Export Options](doc:controlling-version-visibility-and-export-options). ## Using Public Context Cues to Answer Reader Questions When readers report a problem with public documentation in **Atloria**, the fastest way to resolve it is to ask about the visible context on the page. Most support questions become much clearer once you know the **project**, **version**, and **audience view** the reader is using. If a reader says the instructions are outdated, ask them to check the **version shown in the page header** or the current selection in the **version selector**. Often, they are reading an older release while expecting the latest one. If the reader says a section is missing or the page feels incomplete, ask whether the page shows any **audience-specific context**. Audience-targeted content may hide blocks that are visible in another audience view. This is one of the most common reasons two readers describe the same page differently. If a link opens an unexpected page, compare the **project name** and surrounding navigation. A shared link, search result, or bookmarked page may lead to a document with the same title in a different public documentation set. When collecting details from a reader, ask for a screenshot that includes: - The **page title** - The **project name** or public header - The **version selector** or version label - Any visible **audience indicator** [SCREENSHOT: Example support screenshot showing title, project header, version selector, and audience context] Those four items usually provide enough information to identify the mismatch quickly. If the reader only shares the article text, you may miss the real cause of the issue. Encourage teams to compare context first, then content. That keeps support conversations focused and avoids unnecessary back-and-forth about wording that may actually be correct for a different release or audience. ## Fixing Common Public View Confusion Most public-view confusion in **Atloria** comes down to one of four mismatches: wrong **version**, wrong **audience**, wrong **project**, or a comparison between two pages that only look similar. The fix is usually simple once you identify which context is different. If the **wrong content is showing**, start with the **version selector**. Switch to the intended release before comparing any page text. A page can keep the same title while showing a different revision underneath, so always confirm the active version first. If **a section seems missing**, review the current **audience context**. Audience-targeted pages may exclude certain blocks from the public view or replace them with alternate content. This does not always mean the page is incomplete; it may simply be filtered for the current audience. If the **page looks correct but belongs to the wrong docs set**, check the **project name** and any project-specific navigation elements in the header. This often happens when multiple projects publish similar documentation structures. If **two people see different content on the same page**, compare these items side by side: - **Project name** - **Version label** - **Audience context** - **Page title** A useful troubleshooting pattern is: - Match the **project** first - Match the **version** second - Match the **audience** third - Compare the page content only after those three align [SCREENSHOT: Side-by-side comparison of two public pages showing different version labels or project headers] This approach helps you explain missing sections, unexpected wording, and inconsistent screenshots without guessing. In most cases, the page is behaving as published; the confusion comes from readers opening the page in different public contexts. ## Overview Public document views in **Atloria** are easier to understand when you treat every page as a combination of visible context, not just a standalone article. The page body matters, but the surrounding controls and labels tell you **why** that specific content is being shown. The main context cues to watch are: - **Project name** in the public header or navigation - **Version label** or **version selector** - **Audience context** when audience-targeted content is used - **Document title** for the page itself These cues work together. The **project** tells you which documentation set you are in. The **version** tells you which release of that documentation you are reading. The **audience** tells you whether the page is showing general public content or a targeted variation. The **document title** tells you which article is open inside that context. This is why public pages can feel inconsistent if you only compare titles. Two pages with the same name may belong to different projects. One page may be from an older release. Another may be showing content for a different audience. Once you check the visible context, those differences usually make sense. Keep these points in mind while reading or reviewing public docs: - Do not rely on the **page title** alone - Check the **version selector** before judging whether content is outdated - Review **audience context** when sections appear missing - Confirm the **project header** when a page seems to belong to the wrong docs set For browsing help, refer back to [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) and [Browsing Published Documentation and Finding the Right Page](doc:browsing-published-documentation-and-finding-the-right-page). The next topic is [Reading Versioned Documentation in Public Views](doc:reading-versioned-documentation-in-public-views). ## Prerequisites Before this topic is useful, you should already be comfortable opening published documentation pages and moving through public navigation in **Atloria**. This guide assumes you can already reach a public page and identify the main reading area, navigation links, and page header. You will get the most value from this guide if you can already do the following: - Open a published documentation page in **Atloria** - Recognize the **page title** and the surrounding public navigation - Use public navigation to move between pages - Understand that one documentation set may contain multiple releases - Know that some published content may be audience-specific If you have not covered those basics yet, read these first: - [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) - [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content) - [Finding and Reading Content in Published Documentation](doc:finding-and-reading-content-in-published-documentation) This guide does **not** require access to Atloria’s editing screens, project setup screens, or admin areas. It focuses on what readers and documentation reviewers can understand directly from the **public documentation view**. You only need access to a published page where the header, navigation, and version controls are visible. It also helps if you are reviewing a page that belongs to a project with more than one published version or with audience-targeted content, because those are the situations where context differences are easiest to spot. [SCREENSHOT: Public documentation page ready for review, with navigation and version controls visible] If you are ready to focus specifically on how release labels affect reading across published docs, continue with [Reading Versioned Documentation in Public Views](doc:reading-versioned-documentation-in-public-views).