Many spaces to one single knowledge base for JSD
Hello there,
I have to understand whether Scroll Versions suite our needs or not.
I have tried it out and just took a quick glance at its docs, so probably I can be wrong. But if I get it right with Scroll Versions I get a version management with variants for each Confluence Space. Private and public areas are also very useful.
The working template becomes something like "one-space-per-manual" (or docs), which in general is a good approach for me.
However, since Jira Service Desk integration with Confluence handles only one linked space of knowledge base, is there a workaround to make it work with all the info from all the versioned spaces on Confluence, i.e. all the info from all the manual? May I merge all the public spaces to one single space which becomes my knowledge base for JSD?
If this is not possible I think that all this beauty becomes useless for us...
Many thanks for your assistance.
Best regards,
Alessandro Tondo
-
Hi Alessandro,
thanks for your interest in Scroll Versions.
Unfortunately, the one-space limitation in JSD cannot be overcome. Also there is currently no integration between Versions and Jira Service Desk. JSD is not aware that the connected as a KB space is versioned. Therefore, there is no ability to specify a certain (or latest) version to be searchable.
As a workaround I would suggest using Scroll Viewport, which integrates with Scroll Versions. You could publish your latest version to a single space, which has Viewport enabled. That way users would only get search results from the latest version.
You would then publish other (older) versions to separate spaces, and "combine" them all in a version picker in Viewport. Atlassian is using this approach with their docs. We also have an article on how to do it: https://help.k15t.com/scroll-viewport/latest/switching-between-spaces-published-by-scroll-versions-140550282.html.Does this help?
Cheers,
Roman. -
Thank you very much Roman.
I'm going to read the article and I'll let you know if I need any further help.
Anyway, with both the extension I should be able to have several versioned manual spaces and a single last-version-available-manuals knowledge base linked to JSD, right?
Best regards,
Alessandro Tondo -
Hello again Roman,
I think that I'm close to what we need, but I may miss something.
With the linked tutorial, I have properly set up a couple of private manual spaces, let's say DEV1 and DEV2, and configured Viewport properly to navigate through their versions and variants.
First question: in the tutorial it is written that you should use the private master space configuration and uses several public spaces for each version, each with a viewport configuration. Should I use the public master space paradigm and set up only one viewport for the unique space or is different for some reason?
Apart from the above question, I have been able to set up another space with a "global viewport" configuration which handles all the linked viewports previously created. This is completely fine for exploring the whole documentation of our products (e.g. in a way similar to this if I understand it correctly: https://help.k15t.com.
Anyway, Jira Service Desk handles only the information inside the space (and not accessible through the viewport). And as said above JSD can be set only with a single Confluence Space.
I can publish the last version of DEV1 and DEV2 even to the common public space, but I'm not sure what could be the proper publishing configuration. For example to avoid orphan pages since I publish each time a different space root...
Do you know how to get around this situation?
Thanks for your assistance!
-
Hi Alessandro,
Should I use the public master space paradigm and set up only one viewport for the unique space or is different for some reason?
If you use Public Master approach, the content will be searchable from the JSD. However, since it doesn’t know about the Versions concept, users will get multiple details for the same search term (each for the versioned page). This might be confusing.If you use multiple spaces you the ability to link to a "hub" space that would display links to other spaces with Viewport. Users won’t be able to search for the content this way, though.
This is completely fine for exploring the whole documentation of our products (e.g. in a way similar to this if I understand it correctly: https://help.k15t.com.
We use Public Master approach where we select through the Viewport which versions we share to the public. Other companies might have additional requirements where end-users are not allowed to access, therefore, each version is published to a separate space.
I can publish the last version of DEV1 and DEV2 even to the common public space, but I'm not sure what could be the proper publishing configuration.
Do these spaces have different content or they are two versions of the same documentation?
Roman.
-
Hi Roman,
In the above example DEV1 and DEV2 refer to "device 1 manual" and "device 2 manual" which are two completely different device manuals. Therefore they contain different contents (not just versions).
Is this a problem?
Anyway, I understand the Public Master approach issue for a JSD project. So in that case it is better to have several viewports configurated, as shown in your example tutorial.
Do you have any other suggestions?
-
Alessandro,
this is not a problem. In case you want to provide users access to both documentations, I would recommend having another "hub" space with Viewport. Users access the portal where they either access documentation for DEV1 or DEV2 or search for the answer in both products (this won’t be possible in JSD search, unfortunately).
I don’t have other suggestions. I recommend getting trial licenses and try out the solution with JSD, Confluence, Versions and Viewport.
Roman.
-
Yeah, I was already trying some workaround with your evaluation licenses.
I think that we could be fine with a hybrid solution like the following:
- Each distinct device type manual lays in its private space;
- For each space I have set up a Viewport which handles all its version and variants;
- I've created another "knowledge base" common space for JSD with a Viewport configured in a way similar to the above tutorial (redirecting to all the other Viewports);
- Additionally, I publish all the lastest versions of each manual to the common space with each root page as an orphan page of that space;
- If I do not change the root page structure of each manual, it should not alter the "orphan state" of the root pages in the public space (when publishing a new release).
In such a way I should be able to spot results from my JSD configuration (without duplicate pages issue), and have all the documentation properly organized when redirecting the user to the Viewport configuration.
Can you tell me if you find some weakness that I haven't spot yet?
Another idea could be to try to embed the JSD portal website inside the overall Viewport, but I'm not very sure about how to deal with it.
Thanks for you assistance Roman.
-
Alessandro,
your approach sounds good to me. Don’t see any weaknesses.
If you want to add something like a support button in Viewport, this should be doable. On our help portal we have a floating Zendesk support button where a user can submit a question: https://help.k15t.com (bottom right corner). You would probably need to know how to implement this through JSD API.
Roman.
Please sign in to leave a comment.
Comments
11 comments