10 Replies Latest reply on Aug 16, 2016 8:49 AM by scottwdennis

    Is there a wild card for tags?

    benfowler

      We have software release notes tagged by software version, e.g. 1.7, 1.7.1, 1.7.2, 1.7.3, etc.

       

      If we wanted to use one tag to be inclusive of all of the above, is that possible? So if a document is relevant to all sub-versions, instead of having to list out each version and sub-version tag, we could enter just one, e.g. 1.7.*

        • Re: Is there a wild card for tags?
          mpetrosky

          In ours, we did a tag like 1.7.x and that sort of became our standard for any document that applied to any version in the 1.7 family.

            • Re: Is there a wild card for tags?
              benfowler

              Thanks, we've tried that, but we still need the more granular tags as well in order for our tagged content to surface correctly throughout the site. I'm trying to minimize the # of tags we end up associating to a doc.

               

              I was wondering if there was something Jive has embedded into their tagging code to allow a user to input some sort of wild card character when filtering content by tags, such as an asterisk (*), which many search systems use as a wild card character.

                • Re: Is there a wild card for tags?
                  Billy Volpone

                  As far as I know Ben, there isn't an option for that currently. Might make for a good idea in our Ideas for Jive space though. To clarify, are you mainly asking in related to pure metadata/search or for users to manually filter for specific releases, etc?

                    • Re: Is there a wild card for tags?
                      benfowler

                      Thanks Billy Volpone. It would be for users.  So instead of a user needing to put in a bunch of tags in a content page tag filter to see a suite of related product docs (e.g. tags: 1.7.1, 1.7.2, 1.7.3), let the user just enter tag: 1.7*. Such as:

                        • Re: Is there a wild card for tags?
                          Billy Volpone

                          If this is related to filtering, I think search alone should get them to what they need, since our system is looking at way more than just tags for metadata. However, just looking at tags, we also have lots of documents on this very community with patch release numbers (ie: 8.0.2.2, etc). In most cases that I can find on this site along with many of our developer communities is that either those numbers aren't being used in tags (but instead in the title or body of the content) or they are simply putting the full number in the tag.

                           

                          I might also want to ask Scott Dennis about what his document team prefers, since I know there are a large amount of knowledge base content in their Canvas community. I took a look at a few area, but didn't see version numbers in the tags of the ones I opened.

                            • Re: Is there a wild card for tags?
                              benfowler

                              The primary use is case is so we can send our users to a specific URL in our community that's pre-filtered to show only content related to that set of tags. We'll have a release notes document and within it says, "click here to see all docs relevant to this release." I'm trying to minimize the chance for error when we create those URL's by requiring fewer tags. We like the "forced refinement" that tags provide (versus search results that could contain extraneous content), but want to ease the effort for our knowledge and product teams so they don't have to remember all the tags and enter them one by one when creating the pre-filtered content results URL.

                              • Re: Is there a wild card for tags?
                                scottwdennis

                                Hey Billy,

                                You are indeed correct, we don't use document version tags on our documentation.  We have over 1000 technical articles that we keep up to date on a three week cycle using a 3rd party documentation product that pushes updates into Jive that then create new versions of the Jive docs.  But we don't really want to encourage people to refer back to previous versions as the product being documented is a cloud based SAS model product w/o versions.

                                1 person found this helpful