Is there a way to ignore certain labels when using labels for an index?
The feature to generate an index from labels sounds great on the surface; however, there are many reasons to use labels in Confluence that don't align with the purpose of a typical index. For example: Even the K15t products have a feature that uses labels to include pages into a publication. We're using that feature but it doesn't make sense to have that label show up in the index - it would obviously point to every page! It would be great if there was a way to list labels we do not want to include in the index as part of the export scheme. I realize that probably has to be added as an enhancement, but I thought I'd check to see if it was possible now by some other means I'm unaware of. I also think there is probably a way I can ignore specific labels in a custom template by changing some Velocity code somewhere. If so, please give me some guidance on how to do that. Thanks!
-
Hi Roy,
that's currently not possible.
You could try to use Scroll Versions and its variant functionality to make specific pages available for different publications. See http://www.k15t.com/display/VSN/Variant+Management+and+Conditional+Content.
Another possibility would be to use the indexterm macro to define indexterms, but unless https://k15t.jira.com/browse/EXP-315 is implemented there's no way to create an index page including the defined indexterms.
I hope that helps.
Cheers,Nils
-
Hi Nils,
As you say, the whole thing is pointless until we can actually generate an index page. But I'll give you a little feedback anyway so you'll know were we're coming from.
I did do a pretty detailed review of Scroll Versions a while back and had to eliminate it as a possible solution for us for one very fundamental reason: That product uses the Confluence parent-child relationship of pages for managing versions and we already use the parent-child relationship of pages extensively for other purposes. For example, we have a very detailed process model which uses "process decomposition" to explode higher-level processes into more detailed-processes, and then explode those processes further until we reach a granular level that makes sense. That technique works great with the Confluence parent-child relationship of pages where each page represents one node in the overall process model. But it can't work with Scroll Versions. There are several other places where our use of the parent-child relationship of pages has meaning that is incompatible with the basic architecture of Scroll Versions. Too bad, the feature list of Scroll Versions looks pretty good, but that architectural design choice eliminated us as a potential user.
Back to the issue of having an index: If we assume EXP-315 will be implemented (and if it doesn't, K15t should remove all reference to indexing as a feature in your documentation), then I think you are on the right path with both support of labels and having an indexterm macro. However, neither one alone is a great solution. Including all labels is not a great solution because there are so many other reasons plug-in vendors or customers use labels that there are bound to be a handful of labels that make no sense to be listed in an index. Unfortunately, a bad index is worse than no index at all, so even though most labels are good, the labels that don't work as being part of an index destroy the entire value of having an index. The fact that Confluence builds an internal page-index on labels is probably why so many plug-in vendors offer a feature or two that leverages labels. You guys do it - you allow us to pick what pages to include in a publication by the means of a label. Great feature, but it is illogical to then have that label show up as an item in the index because it isn't helpful to the reader and would list every page in the publication! That said, most of the labels would be perfect for an index and can be added to pages fairly easily because you don't have to edit the page. So the basic concept is great, but only if there is a way to pick labels to ignore. BTW - most "Tag Cloud" widgets have this ability to ignore selected tags for the exact same reason. Now, the indexterm macro is also nice because you can index to a more specific point in a page. So if a page has a lot of content and a label would not be all that helpful because a reader would have to scan through a lot of content to find the related content, the indexterm could help out. But the weakness of an indexterm macro is that someone has to go and edit all the pages to put these things in which is very time consuming and affects the content so is subject to workflow standards. It is also very likely that the work of doing this is redundant with the labels the page already has; therefore, it is not cost-effective. So... the best solution (in my opinion) is to allow both at the same time: Support labels but provide a means to ignore certain ones (use of wildcards would be great - ignore all labels starting with "pub-*" for example) and at the same time include any indexterm macros that have been added to pages. This way, we could base the index on labels, but eliminate the labels that aren't helpful in an index, and extend the index to include other items that benefit from having a more definitive target in the page.
BTW - if you guys like this approach and decide to go with it, the issue will come up with what to do when the label and the indexterm are the same and both point to the same page. Easy - the indexterm wins out because it is more definitive.
Anyway, I'm not your product manager, but that seems like the most useful approach to creating an index to me!
Cheers!
-
Hi Roy,
thanks for the great input - very valuable!
With regards to your comment of Scroll Versions: If I got you right, your use-case should be possible to implement with Scroll Versions. At least I can tell from customers who use Scroll Versions to manage complex process documentation for the business processes implemented in SAP. The parent-child relationship is hidden to users by the Scroll Versions Theme and by the page restrictions on the page versions.
That said, I have to mention that technically Scroll Versions does not depend on the parent-child-relationship. So eventually, we hope to store the page versions at a separate location, because it should also give us a performance improvement.
I'd be happy to discuss this on a separate topic on the Scroll Versions forum: https://k15t.zendesk.com/forums/20857468-Scroll-Versions
Thanks again for your comments,
-Stefan -
Hi Roy,
I just wanted to let you know that I've created an improvement in our JIRA system regarding the mentioned functionality: https://k15t.jira.com/browse/EXP-427
Cheers,
Nils
Please sign in to leave a comment.
Comments
5 comments