Manage versions at the article level
complete
Bianca Ragsdale
Currently, my company has 2 versions of our product (let's say "Release" and "Beta"), and we have a separate support site version for each in Document360. However, we’d prefer to have 1 support site, and allow readers to select their product version for each article. A lot of content is the same for both versions, so right now we’re copying/pasting, which takes up time and could lead to errors.
Here are more details for my request:
- Add ability for reader to toggle between article versions
- Add ability for author to toggle between article versions
- This is a stretch, but it would be great to add conditional text directly to an article, and have the content the user sees change based on the version they select. That way you only need to manage 1 article.
- Changing the article version should change the last part of the URL. This will help with tracking page visits.
For example, the same article in 2 versions looks like this:
- domain/docs/widget
- domain/beta/docs/widget
Instead, it should look like this:
- domain/widget
- domain/widget/beta
Log In
Shakeer Hussain S
complete
Shakeer Hussain S
Hi All - This has been rolled out as part of August release. Please find the below details on what is covered on this release.
When readers switch between workspaces on your knowledge base site, they’ll now stay on the same article, as long as it exists in the selected workspace. This provides a smoother experience for users navigating across different product versions or documentation branches. If the article isn’t available in the selected workspace, they’ll be redirected to the workspace’s main article with a clear message explaining why.
You can also customize the Workspace label in the portal to better match your site’s terminology.
This enhancement helps users compare content and view changes made across versions.
V
Viswanathan
Hi Bianca Ragsdale,
Greetings of the day!
Thank you for your continued patience.
After evaluating this use case, we have found that supporting multiple versions within a single workspace would require a complete architectural overhaul.
To balance feasibility with your needs, we have decided to minimize the scope of this requirement for now. As an interim solution, we propose introducing versioning as an option aligned with the current workspace behavior — effectively, this will be a label/name change rather than a structural change.
Please let us know if this approach is acceptable, so we can proceed accordingly.
Riffat Wyne
Viswanathan Thank you for suggesting a workaround for this. Is it possible to see the output of this workaround as an example, how will it look as versioning on KB site for readers?
K
Kristina Ejstes-Svensson
Hi Viswanathan ,
As I can not visualize the suggested solution to be applicable to our situation, where one workspace has several products and several versions per product, I am also looking forward to an example.
V
Viswanathan
Riffat Wyne Same as workspace we have now in the KB site.
V
Viswanathan
Kristina Ejstes-Svensson Versioning as an option aligned with the current workspace behavior. It will be a label/name change rather than a structural change.
Riffat Wyne
Viswanathan Thank you for your quick reply. But I agree with Kristina Ejstes-Svensson, how will it work based on our requirements?
We have multiple products in different workspaces. And within each workspace we have sub-components or modules for those products as categories.
Will the drop-down menu specify each category then since we have v10.2.1, v10.3.1, v11 for those components or modules.
We clone these categories and create new versions of the category to match the product's version number. After that we create articles referring to those product's version numbers.
We would like to have a drop-down for versions on article level for readers as well as contributors on KB site and portal - so instead of cloning categories all the time - we should be able to create a new version of article referring to new product's version release.
Is that what you are also looking for Kristina Ejstes-Svensson and Bianca Ragsdale?
K
Kristina Ejstes-Svensson
Yes, Riffat. Your idea sounds good. Using one workspace in the otherwise very nifty Doc360 web for a dozen products, sub products, with various development cycles and a growing amount of versions calls for challenges. Allowing the reader to select a version on category or article level will do wonders for the user experience.
Cloning must be seen as the common but old way to make a new version of a book. Even if only 10 pages are updated in the 600 page book, 100% is duplicated for every new version, filling servers with copied data. Aside from unnecessary storage, the duplicates does not do wonders for the search mechanisms on a web, offering to many similar options which is confusing for both the readers and Eddy AI.
Bianca Ragsdale
Viswanathan This is no longer a requirement for us, but it sounds like this would be helpful for other people on this thread!
V
Viswanathan
Riffat Wyne and @ Kristina Ejstes-Svensson
To better manage multiple product releases (like Alpha, Beta, GA, or version numbers such as V10.1, V11.1), we propose using the "Workspace" as the "Version".
Each workspace will represent a specific version (e.g., Alpha Version, Beta Version, Release Version), and inside each workspace, you can organize Products and Categories accordingly.
Example:
Workspace = Version (Alpha, Beta, GA, V10.1, V11.1)
Product = Category inside the workspace
Module = Subcategory
Articles = Linked to modules
This structure ensures that:
You select the version first (Workspace).
Then choose the product (Category) under that version.
Then drill down into modules and articles.
Please refer to the below diagrams for clarity. Workaround Solution Diagram (how it will work after applying this structure)
Please let us know if this approach works for you.
Riffat Wyne
Viswanathan Thank you for your detailed reply on this workaround. But creating a new version of workspace (workspace= version) will not require buying/adding a new workspace to project?
Will we still be able to keep (product = category) as separate sites, and not add all of the products as categories in one e.g. in our case we have 7 different products as 7 workspaces - and they have different sets of customers/readers? we cant add them as categories all on one workspace?
Is it possible to set up a small meeting with all the stakeholders, to just clarify and understand this workaround solution that you are offering, to ensure that it will fulfil everyone's requirements?
K
Kristina Ejstes-Svensson
Hi Viswanathan! Thanks for reaching out. The suggested solution may suite other types of businesses but unfortunately not for my client.
In my perspective your solution would need 10 workspaces. And, this would still not work as the 10 products on various versions are interlinked, meaning product 1, 6 and 7 can be used together to achieve a certain feature, depending on the versions of the product 1, 6 and 7. Which means splitting the instructions for the 10 products into workspaces is not an option.
Looking forward to other solution suggestions.
Best regards
Kristina Ejstes-Svensson
Technical writer and content creation consultant
V
Viswanathan
Riffat Wyne Greetings for the day! Thanks for the reply, our CSM team will reach you for scheduling the call.
K
Kristina Ejstes-Svensson
Representing a company in the same situation:
With several products documented in the same knowledge base, and with end customers using different versions of each product, there is a need for an enhanced forking solution, also visible on the readers' side. Where an article can be forked and have more than one published version at a time, labeled in an intuitive way in both the editors' mode and the readers' view.
I assume the easiest way today is to copy the massive x7.1 content to a new folder/category named x7.2 and continue updating there. However, this will no longer be a "one source web solution easy to maintain" and it will definitely cause an unwanted strain on the Document360 storage environments.
Thiru
under review
Thiru
Bianca Ragsdale thank you very much for such a detailed request. We will evaluate this scenario and keep you posted for updates.
Abby Dong
This would be a huge improvement to our current content management processes. We're also copy-pasting between versions. I'd like to add to this the ability to label versions. We use this for releases, so we have a current-state version, and a release version (v2.1 and v2.1.1, etc) for things we know are upcoming and want to get ahead of on documenting. This is something the current forking ability sort of supports, but lacks some functionality for more advanced content processes.