## Defining a Shared Screenshot Library Structure In Atloria, a shared screenshot library works best when your team organizes images the same way every time. Start by separating screenshots at the highest level by the categories your writers actually search for most often: product, release or version, language, and interface theme. For example, teams usually look for a screenshot based on the feature area and release first, then narrow it down by language or light and dark theme. If your library includes folders or collections, keep those top-level groupings broad and predictable so writers do not have to guess where a reusable image belongs. A consistent naming pattern makes the library easier to search, especially when the same screen appears in several guides. A practical format is **product-area-screen-state-version-language**. That pattern helps writers recognize whether an image shows a dashboard, settings page, dialog box, or completed workflow state before they open it. Naming is most useful when it reflects what a person sees on the screen, such as a navigation panel, setup page, or confirmation dialog. Keep different image types in separate library locations so writers can choose the right file quickly: - **Source captures** for original, unedited screenshots - **Edited versions** for screenshots with callouts, highlights, or masking - **Web-ready exports** for optimized images used in published documentation Metadata matters just as much as folders. When Atloria shows fields for asset details, use them consistently. The most useful fields for reusable screenshots are: | Field | What to record | Why it helps | |---|---|---| | Owner | The person responsible for the image | Helps writers know who to ask before reusing or replacing it | | Capture date | When the screenshot was taken | Makes outdated images easier to spot | | Product release | The release shown in the image | Prevents reuse in the wrong version | | Approval status | Draft, approved, superseded, or archived | Shows whether the image is safe to publish | [SCREENSHOT: Shared screenshot library showing folders by product, version, language, and theme] If your team already uses project-based screenshot workflows, keep that process aligned with the shared library rather than replacing it. For project and version coordination, refer to [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). ## Setting Up Roles, Permissions, and Contribution Rules A shared library only stays useful when everyone follows the same contribution rules. In Atloria, your team should decide who can upload screenshots, who can edit metadata, who can approve assets for reuse, and who can archive outdated images. These responsibilities usually follow documentation team roles rather than project ownership. A common setup looks like this: | Role | Typical access in the library | |---|---| | Documentation Manager | Approve, replace, archive, and manage folder structure | | Technical Writer | Upload, edit details, and submit assets for review | | Reviewer | Check accuracy, metadata, and approval status | | Designer | Upload edited variants and maintain annotation consistency | Before anyone uploads a screenshot, require a contribution check so the library does not fill up with inconsistent images. Your checklist should cover the visible quality of the image and the information entered with it. Useful checks include: - Approved image resolution - Browser or device label - Redaction review for hidden or masked fields - Alt text entry - Correct version or release label - Correct language and theme - Clear title and searchable tags Use restricted folders or approval-only collections for screenshots that are still under review. This prevents unreviewed images from being reused in published pages just because they appear in search results. If Atloria shows approval status in the asset details, make sure only approved items are treated as reusable team assets. Set one rule for replacements and one for new versions. A Documentation Manager may replace an existing approved asset when the screenshot is clearly the same screen in the same context and only needs a current refresh. Writers should create a new version instead when the workflow, layout, menu labels, or release context has changed enough that teams may still need the older image for another guide. That approach preserves image history and avoids breaking documentation that still depends on an earlier release. [SCREENSHOT: Screenshot asset details showing approval status, tags, owner, and restricted collection placement] ## Capturing and Uploading Screenshots for Reuse When you capture a screenshot for the enterprise library in Atloria, focus on whether another writer could reuse it without asking follow-up questions. The image should match the intended documentation scenario exactly, including the correct product version, the right user role, and sample data that looks realistic but safe to share. If the screen changes based on permissions, make sure the visible menus, buttons, and page content match the audience for the guide you are supporting. 1. Open the target page in the correct version and confirm the screen shows the right workflow state, such as an empty form, completed setup, confirmation message, or selected menu. 2. Capture the image with the expected browser or device view your team has agreed to use. 3. Edit the image before upload if needed. Crop away browser chrome if your team does not document it, mask sensitive values, and only add callouts when the guide truly needs them. 4. Upload the screenshot to the shared library in Atloria. 5. Complete the required asset details so other writers can find and trust the image later. When Atloria prompts for image details, fill in every field your team relies on for search and reuse. The most helpful fields usually include: - **Title** - **Tags** - **Product area** - **Release number** - **Usage notes** - **Language** - **Theme** - **Owner** - **Approval status** Place the image in the collection or folder that matches the feature area, not just the project where you captured it. For example, if the screenshot shows a settings page used across several documentation sets, store it with other settings-related assets instead of burying it under one project name. That makes the library useful across teams, not just for the original author. Use usage notes to explain anything another writer cannot see directly in the image, such as “captured with admin-level navigation visible” or “shows onboarding after final confirmation step.” [SCREENSHOT: Upload screen for a screenshot asset with title, tags, product area, release number, and usage notes fields] ## Finding Approved Images Across Multiple Documentation Projects In Atloria, the fastest way to reuse screenshots across projects is to search with a combination of folder location, tags, and metadata filters instead of browsing one project at a time. Start with the feature area or screen type, then narrow the results by version, language, and theme. If your team documents both light and dark interface styles, always check the theme filter before selecting an image. The same is true for localized content—an approved English screenshot may not be suitable for a guide in another language. When you open a screenshot record, compare the available variants before adding it to a page or knowledge base article. Many teams keep three related versions of the same image: - The original source capture - An annotated version with callouts or highlights - The latest approved reusable version Look at the asset details and confirm that the approved version matches your guide’s release and audience. If the image includes notes about user role, setup state, or hidden fields, read those before reusing it. This is especially important when a screen looks similar across several workflows but the visible buttons or menu labels differ slightly. To avoid duplicate captures, search the library before taking a new screenshot. Check for matching navigation screens, dialogs, setup pages, and completed workflow states. Writers often create duplicates because they search by project name instead of by feature area or screen purpose. A shared library works better when teams search for the screen itself, not the document it originally supported. Usage notes and linked project references are your final check. If an asset record shows where the screenshot has already been used, you can judge whether it is safe to reuse in another publication. A screenshot already used in multiple approved guides is often a better choice than a newly uploaded image with no review history. [SCREENSHOT: Library search results filtered by version, language, theme, and approval status] ## Keeping Screenshot Libraries Current as Products Change A screenshot library becomes unreliable quickly if nobody reviews it after product updates. In Atloria, treat screenshots as versioned documentation assets, not one-time image files. Each time your team prepares content for a new release, compare existing screenshots against the current interface. Pay close attention to renamed menu items, updated icons, changed button labels, new page layouts, and revised forms. Even small visual changes can make a guide feel outdated. Use version labels and replacement workflows to keep the library current without losing history. When a screenshot is no longer the best choice for current documentation, do not simply overwrite it without review. Instead, update its status and connect the replacement image clearly so writers can see which asset is current. Archive folders are useful for older screenshots that still need to remain available for previous releases or older published versions. High-change areas need a regular review cadence. Teams usually review these areas more often: - Dashboards - Settings pages - Onboarding flows - Navigation menus - Multi-step setup screens A simple status model helps everyone understand what to use: | Status | Meaning | |---|---| | Draft | Uploaded but not ready for reuse | | Approved | Cleared for use in current documentation | | Superseded | Replaced by a newer approved image | | Archived | Retained for history, not for current content | When Atloria shows status in the asset record, use it consistently. Writers should only insert screenshots marked **Approved** for the correct release. Reviewers and managers should move older assets to **Superseded** or **Archived** as soon as a newer image becomes the standard. This prevents outdated screenshots from continuing to appear in search results as if they were current. [SCREENSHOT: Screenshot library asset history showing approved, superseded, and archived statuses] ## Fixing Common Library Management Problems Most screenshot library problems in Atloria come from inconsistent naming, incomplete metadata, or unclear approval status. When duplicate assets appear, compare the file names, tags, capture dates, and release labels first. If several images show the same screen and one is already approved, treat that approved item as the master image. Update usage so writers reuse the approved record instead of continuing to upload near-identical copies. Inconsistent screenshots are another common issue. A guide may look uneven when one image uses a dark theme, another uses a light theme, and a third was captured at a different zoom level or with different sample data. Fix this by enforcing capture presets and checking those details during review. If a screenshot does not match the team standard, return it for correction before approval rather than letting the inconsistency spread across more pages. Writers also struggle when they cannot find assets that already exist. In most cases, the problem is not the image itself but the library details attached to it. Review these fields when search results seem incomplete: - Folder or collection placement - Tags - Product area - Version or release field - Language - Theme - Approval status If those details were entered incorrectly, update the asset record so the screenshot appears in the right searches and filters. This is often faster than creating a replacement image. For outdated screenshots already used in published documentation, trace where the superseded asset is still referenced and replace it with the current approved version. Linked usage references are especially helpful here because they show which pages, projects, or documentation sets still depend on an older image. Once those references are updated, move the old screenshot to **Archived** if it is no longer needed for past releases. If your team is dealing with missing or mismatched screenshots across versions, the troubleshooting steps in [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions) are the best companion reference. ## Overview This guide focuses on how documentation teams use a shared screenshot library in Atloria to support multiple projects, versions, and publications without recreating the same images repeatedly. The goal is not just to store screenshots, but to make them easy to find, safe to reuse, and clearly marked so writers know which image belongs in current documentation. You will work with a few core practices throughout this guide: - Organizing screenshots by product, version, language, and theme - Applying consistent titles, tags, and usage notes - Separating source captures from edited and web-ready images - Using approval status to control what can be reused - Replacing or archiving outdated screenshots as the interface changes This guide assumes your team is already working with screenshot processes at the project and version level. If you need help with that foundation first, read [Managing Screenshot Workflows Across Projects and Versions](doc:managing-screenshot-workflows-across-projects-and-versions). That guide explains how screenshot work fits into release-based documentation workflows. Here, the focus is broader: building a reusable enterprise library that supports many writers and many doc sets at once. In Atloria, this work usually involves the screenshot library views, asset detail screens, upload forms, folder or collection organization, and approval status tracking. You do not need to set up every rule at once, but your team should agree on naming, metadata, and review rules before the library grows too large. A well-managed library saves time, reduces duplicate captures, and helps teams keep screenshots visually consistent across documentation. ## Prerequisites Before using a shared screenshot library in Atloria, make sure your team has a few basics in place. This guide assumes you already have access to the areas where screenshots are uploaded, reviewed, and reused. It also assumes your team has agreed on at least a simple documentation workflow for how screenshots move from capture to approved reuse. You should have: - Access to Atloria with permission to view the screenshot library - The ability to upload screenshots or edit screenshot details, if that is part of your role - A team standard for image naming, version labels, and approval status - Agreed rules for themes, languages, browser or device views, and annotation style - Sample data that is appropriate for screenshots and safe to share in documentation - A clear understanding of which screenshots are source captures and which are edited or web-ready variants It also helps if your team already knows how screenshots are used inside documentation pages and release workflows. If you need that background, start with [Managing Screenshots for Documentation](doc:managing-screenshots-for-documentation) and [Organizing Screenshots for Documentation and Releases](doc:organizing-screenshots-for-documentation-and-releases). For teams working across many projects, you may also want to confirm who is responsible for approvals, replacements, and archiving before you begin. Without that ownership, libraries tend to fill up with duplicate or outdated images. If your organization manages permissions centrally, the related admin guidance in [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions) may help you align screenshot contribution rules with team responsibilities. The next step in this screenshot series is [Managing Screenshot Workflows Across Documentation](doc:managing-screenshot-workflows-across-documentation), which expands this library-focused approach into broader documentation operations.