How Workspace Sites Separate Site Settings, Public Pages, and Analytics

A workspace can hold private drafts, research, files, and team decisions. A public site has a different job: present selected material for people who should not need access to the workspace itself. In ReadyTools Workspace, the codebase identifies four components for this area: a sites modal, a site settings modal, a public site renderer, and an analytics dashboard.

Together, those names point to three distinct concerns: managing a site, presenting public content, and reviewing site analytics. They do not, by themselves, prove which settings or metrics are available, or whether Workspace Sites is available to every account. Understanding the roles helps make sense of the structure without assuming details the code listing does not establish.

The three responsibilities behind a workspace site

It helps to think about a published site as a small system rather than a single page. Someone needs a place to manage site-related work, a public-facing view needs to display content, and analytics may provide a separate view of site activity. Keeping those concerns distinct makes the purpose of each component easier to understand.

• Site management: a place to work with site-level items or options.
• Site settings: a dedicated area for configuration.
• Public rendering: the presentation of content intended for public viewing.
• Analytics: a dashboard-oriented view related to site activity.

This is a way to read the component structure, not a claim about every action or data point each screen supports.

What the four components indicate

WorkspaceSitesModal.js: a site management surface

The repository includes WorkspaceSitesModal.js. Its name indicates a modal associated with Workspace Sites, which is consistent with a site management surface. A modal is a type of interface; the filename alone does not reveal the available controls, the data shown, or the steps a user can complete there.

WorkspaceSiteSettingsModal.js: a separate configuration area

WorkspaceSiteSettingsModal.js identifies a second modal specifically associated with site settings. This separation suggests configuration is treated as its own concern rather than being synonymous with the public page itself. The supplied component information does not specify which settings exist, so details such as custom domains, themes, search visibility, or access controls should not be assumed.

PublicWorkspaceSite.js: the public-facing view

PublicWorkspaceSite.js is the component associated with public rendering. The distinction matters: the private workspace is where work is created and organized, while a public renderer is responsible for presenting material as a page for visitors. ReadyTools describes Workspace Sites as a way to turn selected notes into clean public reading pages without exposing the private workspace. The specific rendering options and publishing controls are not established by the component name alone.

WorkspaceSiteAnalyticsDashboard.js: an analytics view

WorkspaceSiteAnalyticsDashboard.js points to a dashboard associated with site analytics. That confirms an analytics component exists in the relevant code area, but it does not tell us which metrics are displayed, how activity is measured, or how frequently information updates. Avoid relying on a particular metric until it is confirmed in the product interface.

How the pieces fit into a publishing workflow

A useful mental model is a sequence of responsibilities, not a guaranteed click-by-click procedure:

1. Prepare material in the workspace. Draft and organize the content privately, with the context and collaboration it needs.
2. Choose what is ready to share. Treat public selection as a deliberate boundary. A finished page and a private workspace are not the same audience.
3. Manage the site and its configuration. The site management and settings components represent separate areas for these concerns. Their exact controls are not specified by the available component information.
4. Present the public page. The public rendering component is the part associated with displaying content to visitors.
5. Review analytics if available. The code includes an analytics dashboard component, but the supported details do not identify its metrics or reporting behavior.

For example, a project team might keep a working brief and discussion inside a private workspace, then prepare a selected note as a reading page for an external audience. The useful distinction is between the material needed to do the work and the material intended for readers. The example describes the publishing model, not a promise about particular sharing controls.

What the component list does not confirm

Source code presence is evidence of implementation scope, not a complete product or access guide. The repository identifies four relevant files: WorkspaceSitesModal.js, WorkspaceSiteSettingsModal.js, PublicWorkspaceSite.js, and WorkspaceSiteAnalyticsDashboard.js. That supports describing management, settings, public rendering, and analytics as represented areas.

It does not establish whether these components are currently available to all users, which plans include them, or which options each screen contains. It also does not confirm specific analytics metrics, publishing permissions, custom branding, domain support, or how search engines handle public pages. Those details require confirmation from the current product interface or documentation.

This caveat is practical, not merely technical. A filename can show that a component exists without showing whether it is enabled in a particular account, what data it receives, or what a visitor can see. Before relying on a setting or metric, verify it in the product rather than inferring it from the component list.

When this structure is useful

Separating configuration, public presentation, and analytics makes it easier to ask the right question. If the issue is what readers see, focus on the public page. If it concerns site options, look for the settings area. If it concerns site activity, the analytics dashboard is the relevant component. This avoids treating “the website” as one undifferentiated screen.

For a closer look at the broader workspace context, visit ReadyTools Workspace. If the next task is preparing a note for public reading, the guide to publish notes as a website is the relevant next step. Check current product access and available options directly, since the component list alone cannot confirm either.