Hiding page elements based on viewer?s actions?
Asked by Andy Phillips:

Hello all,

First post and I'm guessing like a lot of members here I joined after my company introduced me to their Confluence Server project (I already worked out we're on Server, not Cloud). So far it's been great. I'm loving being able to capture thoughts, full blown processes and track projects on Confluence. Inevitably though, I have a question...

I'm hoping this is as easy a question to answer as it is to ask - can you hide or reveal elements of a Confluence page based upon a user's actions? In this case I'm thinking of a radio button or checkbox selection.

The general idea is that with a single page I can create an upgrade guide for multiple versions of our software. The various steps in the upgrade might be relevant to one or more versions of the software. If we created a set of radio buttons at the top of the page (one for each version of the software) then the reader could make a selection to indicate which version they are interested in upgrading. The tagged upgrade steps on the rest of the page could then be rendered visible or invisible based on their tags.

There seems to be the ability to hide and reveal page contents based on user ID or priority (as discussed here and elsewhere community.atlassian.com/t5/Confluence-questions/hide-content-on-a-page/qaq-p/172703) but that's not quite what I'm after.

Obviously if my search-fu is weak then simply point me to the correct answer rather than repeating it. Failing that, any advice would be most welcome!

Thanks in advance,

Andy


Answers:
author: Sven Schatter _Lively Apps_
body: Hi [@Andy Phillips](/t5/user/viewprofilepage/user-id/4257552),

I'm one of the developers of [HideElements for Confluence](https://marketplace.atlassian.com/apps/1211757/hideelements-for-confluence?hosting=server&tab=overview), so I can say with confidence that I know a thing or two about hiding things in Confluence. I'd love to suggest to you our app for that, but I'm afraid what you're going for here is better solved with a different approach.

As far as I understand, it sounds like you want to do something [like Atlassian does in their documentation](https://confluence.atlassian.com/doc/add-assign-and-view-tasks-590260030.html) where users will be shown different content / instructions given on a version of your software they have selected. Correct?

![versions.png](https://community.atlassian.com/t5/image/serverpage/image-id/130507i59DAD42A21D17BE2/image-size/large?v=v2&px=999 "versions.png")

If yes, Atlassian themselves is using [Scroll Viewport](https://marketplace.atlassian.com/apps/1211636/scroll-viewport-for-confluence?hosting=server&tab=overview) for this, which might be exactly what you need. We use it ourselves (but without the versions feature) and really love it. If you have any questions about it, I'm sure someone from the K15t team like [@Matt Reiner \[K15t\]](/t5/user/viewprofilepage/user-id/2246048) will be happy to chime in and answer those! :)

Cheers,  
Sven

comments: author: Matt Reiner [K15t]
body: Thanks for mentioning me [@Sven Schatter _Lively Apps_](/t5/user/viewprofilepage/user-id/1169931)

Hey [@Andy Phillips](/t5/user/viewprofilepage/user-id/4257552), I'm glad you're enjoying Confluence. ? This really does sound like a good fit for our apps [Scroll Versions](https://marketplace.atlassian.com/apps/1210818/scroll-versions-for-confluence?hosting=server&tab=overview) and [Scroll Viewport](https://marketplace.atlassian.com/apps/1211636/scroll-viewport-for-confluence?hosting=server&tab=overview).

We're using these two apps to create our [help center](https://help.k15t.com/). Users can pick whatever documentation version relates to the version of the app their using.

Here's a bit more about how [Scroll Versions](https://www.k15t.com/rock-the-docs/versioning/manage-versions-of-confluence-documentation-with-scroll-versions) and [Scroll Viewport](https://www.k15t.com/rock-the-docs/publishing/publish-your-content-as-a-help-center-with-scroll-viewport) work. Let me know if you'd like to see them in action. I'd be happy to give you a tour.


author: Andy Phillips
body: Hello,

Thanks to you both for the suggestions. Sorry for the delayed reply but I've had a chance to review the two pages provided. After a brief inspection it looks like one would essentially create individual pages and present the relevant page as the user makes a selection. Is that correct?

Thanks,

Andy


author: Matt Reiner [K15t]
body: Hey [@Andy Phillips](/t5/user/viewprofilepage/user-id/4257552)

That's how Scroll Versions handles multiple versions of the content, yes. But this is all handled in the background automatically. So you could just create a new version, update/add/remove pages in the page, and then users can easily switch to the version they'd like to see.


author: Andy Phillips
body: Thanks for the clarification Matt. It seems like this is a superset of the functionality we need at this time, plus I'm really after streamlining the maintenance process. The audience experience (in this specific case) is a secondary benefit. The audience is already savvy enough to navigate the existing pages but if I could have merged those pages into a single reactive one for the benefit of the authors, that would have really helped them. I guess it is a slightly unusual case in that a lot of our pages are very similar, hence the emphasis on maintenance simplification. Thanks again for the suggestion though,

Andy


Tags: confluence-server

server