Managing Document Previews Comparisons and Quality Checks

Opening preview screens and understanding page status

If you already know the basics of public checks from Understanding Document Preview and Public Page Checks, this section focuses on the review flow inside Atloria while you are preparing a release.

From your project workspace, open the documentation page list and select the page you want to review. Writers usually enter preview in one of two ways: by opening a page-level preview from the page they are editing, or by switching into a release preview while reviewing a version. Use the preview option that matches your goal. A page preview helps you inspect one page quickly. A release preview helps you confirm how that page appears inside the selected version.

When the preview opens, check the header before you start reading. The header is your first confirmation that you are reviewing the correct content. Look for these details:

Tip: If the page content looks unfamiliar, check the version or release label first. Many review mistakes happen because the preview is showing versioned content instead of the latest draft.

Page status matters just as much as page content. In preview-related screens, look for signs that the page is still a draft, has changed since the last release, or is already published. Use those status cues to separate unreleased edits from content that readers can already see.

Stay inside preview while you move through the documentation set. Use the table of contents, sidebar links, and nearby page links to move between related pages. This makes it easier to review flow, structure, and page order without jumping back to the main page list each time.

Comparing page revisions before approving changes

Before you approve a page for release, open its comparison view and make sure you are comparing the right two versions. In Atloria, this usually means checking the current draft against the last published page, or comparing one saved revision with another. The comparison screen is only useful when the comparison targets match your review question.

Start by confirming the labels for both sides of the comparison. If one side is the draft and the other is the published version, you are checking what will change for readers. If both sides are saved revisions, you are checking how the page evolved during editing or review.

Reading change markers

Once the correct comparison is open, scan the change markers before reading line by line. Look for:

• added text
• removed text
• heading changes
• list changes
• code block changes
• moved or restructured sections

These markers help you spot edits that affect meaning, page structure, or readability. A heading change can alter navigation. A list change can affect instructions. A code block change can affect technical accuracy for readers.

Choosing the best comparison layout

If Atloria offers more than one comparison layout, use the one that fits the page:

1. Use side-by-side comparison when you want to review wording and layout together.
2. Use inline comparison when you want to read the page in a single flow.
3. Switch views if a long section is hard to follow in the current layout.

Do not stop with body text alone. Check whether links, screenshots, embedded media, or internal document links changed at the same time. A page may look almost identical in the text comparison while still containing updated assets or changed cross-references. Those non-text changes often affect release quality just as much as rewritten paragraphs.

Reviewing multi-page changes in preview mode

When a release includes more than one edited page, review the changed pages as a set instead of opening pages at random. In Atloria, use the preview page list or any changed-pages view available in the version workspace to narrow your review to pages modified since the last release candidate. This keeps your attention on content that actually needs approval.

Checking structure across several pages

As you move through the preview, verify that structural edits still make sense in the full documentation set. Focus on:

• navigation labels in the sidebar
• parent and child page relationships
• page order in the table of contents
• section names that appear in menus and links

A page can read well on its own but still create confusion if it sits in the wrong place or uses a label that no longer matches nearby pages.

Checking consistency between pages

After structure, review repeated content patterns. Compare similar pages and make sure they render consistently. Look closely at:

• heading levels
• callout boxes
• warning or note blocks
• reusable snippets
• screenshot placement
• spacing around lists and tables

Watch for this: Reusable content can appear correct on one page and look broken on another. If a note box, snippet, or repeated instruction appears in several places, open more than one page in preview before marking the release ready.

If your project uses more than one language or more than one release, test the selectors while you stay in preview. Switch the locale or version and confirm that the expected page variant appears. This is especially important when the same page title exists across multiple releases. You want to confirm that Atloria is showing the correct page, not just a page with a familiar name.

Running quality checks before content enters a release

Before content moves into a versioned release, review the quality check results in the release workflow. In Atloria, these checks help you catch issues that are easy to miss during visual review. Open the quality check panel or validation results and work through the flagged items one by one.

Common issues to watch for include:

• broken links
• missing page titles
• empty descriptions
• unresolved references
• pages that still need review

These checks tell you whether the content is complete enough to move forward, even if the page looks fine at first glance.

Checking visual rendering issues

After reviewing the issue list, return to preview and inspect the page itself. Some problems only appear when the page is rendered. Look carefully for:

• malformed tables
• code blocks that overflow the page
• missing images
• incorrect heading order
• content sections that look collapsed or misaligned

Confirming release readiness

Use the release readiness indicators in the version workspace to confirm whether the documentation set is ready for the next step. Reviewers and documentation managers typically look for all required checks to pass and for no pages to remain in an unreviewed state. If Atloria still shows unresolved issues, do not rely on visual review alone.

When you find a problem, record the follow-up directly from the review flow if that option is available. Assigning or noting the fix while the issue is visible reduces the chance of missing it later. This is especially useful when the problem affects several pages, such as a repeated broken link or a missing description pattern across a section.

Confirming what will appear in the versioned release

The final review step is confirming the exact content that will appear in the upcoming release. This means switching from draft preview to release preview and checking the versioned view, not just the latest working draft. In Atloria, that distinction matters because a writer may still have unpublished edits that are not meant to ship.

Start in the selected version or release workspace, then open the release preview. Read the page as a reader would see it in that release. Confirm the page body, sidebar placement, and page metadata together so you are not approving text without checking where and how it appears.

Verifying version-specific details

Pay close attention to version-related details in the preview header and navigation. Check:

Separating release content from work in progress

If you suspect a mismatch, compare the release snapshot against the current unpublished draft. This helps you separate work in progress from content intended for versioning. It is a useful check when a page has recent edits but only part of that work should appear in the release.

Final review note: Sign off only after you confirm that required pages, screenshots, embedded assets, and internal links are present in the release preview. A clean draft page is not enough if the release preview is missing supporting content.

Use this step to make a final yes-or-no decision. Once the release preview matches your expectations, you can move into the broader release process described in Preparing Versions for Final Approval.

Fixing common preview and comparison issues

When preview or comparison results look wrong, start by checking the review context before assuming the page content is broken. In Atloria, many apparent issues come from opening the wrong preview type, comparing against the wrong revision, or reviewing a release snapshot instead of the latest draft.

When preview does not match the editor

If the preview does not match what you just edited, check whether you are looking at:

• the latest draft
• an older saved state
• a release preview
• a versioned snapshot

A mismatch often happens when you switch from editing into a release view without noticing the release label in the header.

When comparison results seem unexpected

If the comparison screen shows changes you did not expect, verify the selected base revision first. You may be comparing the current draft to an older published page instead of the most recent saved revision. Also consider whether shared content changed. Reusable snippets, shared text blocks, or linked content can create differences on several pages at once.

When images or assets are missing

If screenshots, images, or embedded items do not appear in preview, confirm that the asset is available in the release or locale you are reviewing. Then check whether the page is pointing to the correct file and whether the selected preview context includes that asset.

When quality checks fail but the page looks fine

Some issues are not obvious in the visible page body. Review the flagged details for hidden problems such as:

• broken anchor links
• duplicate headings
• blank metadata fields
• unresolved internal references

For broader release comparison work, continue with Comparing Documentation Versions for Release Decisions.

Overview

This guide covers the review work that happens between editing and release approval in Atloria. It focuses on four connected tasks: opening the correct preview, comparing page revisions, checking multi-page changes, and confirming quality results before a version is finalized.

Use this guide when you need to answer questions such as:

• Am I reviewing the latest draft or the release snapshot?
• What changed on this page since the last published version?
• Did structural edits affect navigation or page order?
• Are there unresolved issues that block release readiness?
• Will the selected version include the correct pages and assets?

This guide assumes you are already comfortable editing pages and using standard preview checks. If you need a refresher on basic preview behavior and public-facing checks, return to Understanding Document Preview and Public Page Checks. If you need help with page editing before review, see Creating and Editing Documentation Pages.

Table of contents

• Opening preview screens and understanding page status
• Comparing page revisions before approving changes
• Reviewing multi-page changes in preview mode
• Running quality checks before content enters a release
• Confirming what will appear in the versioned release
• Fixing common preview and comparison issues

The goal is not just to read pages one by one. It is to confirm that the right content, structure, and supporting assets will appear in the right release, with no hidden issues left behind.

Prerequisites

Before you use the workflows in this guide, make sure you can already access the parts of Atloria involved in document review and release preparation.

You should have:

• access to the project workspace that contains the documentation pages
• permission to open document previews and version-related review screens
• at least one page draft, saved revision, or release candidate to review
• familiarity with the documentation page list and project navigation
• a basic understanding of version review from earlier guides

Helpful background reading includes:

• Organizing and Reviewing Document Content
• Managing Document Comparisons During Content Updates
• Managing Version Lists Statuses and Comparisons
• Understanding Version Lifecycle and Release Readiness

If your review also includes screenshots or other visual assets, it may help to keep these guides nearby:

• Managing Screenshots for Documentation
• Checking Screenshot Readiness Before Version Release

For teams working across multiple releases, languages, or approval stages, it is also useful to understand the wider release process in Preparing a Version for Final Release Review.