Publish to the Web

This article walks you through the available options to present your content authored in Scroll Versions as a documentation website or online help center, similar to the site you are reading right now.

The setups below are based on Scroll Versions' integration with Scroll Viewport and thus require you to have both apps.

Introduction to Scroll Viewport

Scroll Viewport for Confluence Server and Data Center is an app that enables you to create and run a website directly from Confluence. Scroll Viewport is optimized for documentation content and integrates seamlessly with Scroll Versions and Scroll Translations. There are several advantages to using Scroll Viewport as opposed to just anonymously accessible spaces:

• Completely custom branding and visual presentation

• Custom, SEO-friendly URLs without a dedicated web server

• Full adherence to Confluence permissions allowing for internal and external Viewport sites

• Quick and easy publishing of versions

To help you imagine what a Viewport Help Center might look like, here are a few examples:

• Atlassian Support

• K15t Help Center

• Teamlead Documentation

Choosing the Right Setup for Your Content

Depending on your particular space and version setup, as well as your target audience, the optimal approach for using Scroll Versions and Viewport together might differ. These are the setups we recommend:

Viewport in the authoring space

Using Viewport in the authoring space is the most powerful approach and we recommend using it if you can.

Score card

Unique to this approach:

• Version picker: Enable the reader to switch between multiple versions of any page

• Instant publish: Make versions available instantly by adding them to the viewport scope in the version management screen

Things to keep in mind:

• Audience access to Confluence: Your target audience needs to have permission to access Confluence. For example, if you plan to deliver your content to an anonymous audience online, you'll need to grant view permissions to anonymous users in that space.

• Changes are live immediately: Any changes made on a page which is part of a public version are reflected on the Viewport site as soon as you hit Update in the editor. This is useful when fixing typos, but generally bigger changes should be done in a version that isn't public.

• Understand inheritance: Content inheritance is a feature that can cause later versions to change when earlier versions are edited. Make sure you understand how content is inherited and keep an eye on the Page Byline.

Setup, authoring, and publishing flow

Before you create a viewport, we recommend to give Scroll Viewport's Get Started page a read. On it, you'll learn about the basic concepts in Scroll Viewport as well as how to setup your first viewport with the Help Center theme.  Once your viewport is created, make sure to first activate the Scroll Versions integration in the Scroll Viewport settings. With the integration active, click ••• > Show/Hide in Scroll Viewport to show or hide a version or variant in the viewport.

Permissions

For the most part, permissions can be set up the same way they are in any other space. Once you have the authors and readers configured, we recommend you test it within a private browsing session or a Confluence account that is configured to be a reader.

For an internal audience that logs into Confluence to view the content, check which versions are visible to them. If they have access to versions with the Author only label, try changing the value for the setting repository.property.version.fullaccess.reviewers in the Advanced Plugin Settings.

Viewport in a Space Published by Scroll Versions

Sometimes, for varying reasons, creating a viewport in the authoring space is not possible or just impractical for the goals at hand. In this case, you can publish a version into another Confluence space and create a viewport in the space.

Score card

Unique to this approach:

• Independent content: Changes to the authoring space don't affect public space content in any way, allowing for breaking changes to the content and space structure.

• Separate access: The authoring space and the public spaces are managed completely separately, allowing for more granular access control. When publishing remotely, authoring and public spaces can even be on separate Confluence instances.

• Change traceability: As public space content can only be changed by Scroll Versions' publishing functionality, it's easier to keep track of changes, which might be a requirement in some regulated industries.
  

Things to keep in mind:

• Publishing process is required: Scroll Versions publishing operates on a space version scope, meaning a publishing process has to be done for the entire space, even if only minor changes are published. In spaces with many pages and attachments (like images), this process might take a while.

• Public spaces contain one version: Due to the space version scope, a viewport in a public space can only contain one version and cannot contain a version picker to switch between versions. You can however publish each version into its own public space.

• Linking to other public spaces: Though all links within an authoring space are adjusted during publishing, links between several master spaces will break after publishing.

Setup, authoring, and publishing flow

As Scroll Versions produces typical spaces as the result of publishing, there isn't anything special to look out for when using Scroll Viewport in this case. Learn more about Scroll Viewport.

To learn about managing versions and publishing them in Confluence, Publish in Confluence is a good place to start.

Permissions

As mentioned above, permissions in the authoring and public spaces are completely independent. Learn about Scroll Versions' authoring space permissions in our documentation, and refer to the Atlassian documentation for permissions in the public space.