Content reuse on a wiki – a case study

Recently I finished developing the documentation for a new user directory management framework that’s incorporated into two of our products. When designing the documentation, one of the primary goals was efficient and effective content reuse. Since we do all our documentation on a wiki, this was an interesting and rewarding exercise. So I thought you may like to read about it. 🙂

The reusable chunks of documentation are in the User Management (USERMAN) space on our documentation wiki. The chunks are used in the Confluence administration guide and the JIRA administration guide.

What the documentation is about

The documentation describes a software framework for managing user directories. A user directory is a place where you store information about users and groups. Using the software, administrators can connect various types of user directory to their application, and manage the directory connections. A directory can be an internal directory, with data stored on the product database, or an external LDAP directory like Active Directory, or even another application that manages the user information and directory connections.

Why content reuse makes sense for this documentation

The user directory management framework itself consists of a set of back-end libraries and a user interface plugin. The libraries and UI plugin are currently used in two separate products, Confluence and JIRA. The business rules followed by the back-end process and the UI experience are therefore the same in both Confluence and JIRA. In future, other products may join the party.

It makes sense to share the documentation too. This will ensure a consistent experience for our customers across the products, and improve our efficiency when maintaining the documentation.

Introducing the USERMAN space

The User Management (USERMAN) space contains the reusable chunks of documentation. Its home page looks a little different from our standard documentation home pages. A standard home page introduces readers to the documentation and gives them links to the user’s guide, administrator’s guide, and so on.

Instead, the USERMAN home page:

  • Lets readers know that “This documentation is not intended to be read independently of the JIRA and Confluence documentation” and gives them links to those documentation spaces. This is necessary because many people come to our documentation via Google searches. If they land on this home page, we want them to find their way to the relevant documentation quickly.
  • Tells authors where they can find the reusable chunks within the space.
Content reuse on a wiki - a case study

Home page of the USERMAN space

A simple example of content reuse

Let’s start with a simple topic, configuring the LDAP connection pool. The reusable chunk is in the USERMAN space: _LDAP Connection Pool Settings. Here’s a screenshot of the content of that page:

Content reuse on a wiki - a case study

A chunk of reusable content

The above page consists entirely of reference information. There is no orientation at the top, nor any other context apart from the standard message telling readers where to go for the “real” documentation.

The content of the page is reused in both the JIRA documentation (Configuring the LDAP Connection Pool) and the Confluence documentation (Configuring the LDAP Connection Pool). Here’s what it looks like on the JIRA page:

Content reuse on a wiki - a case study

LDAP connection pool in the JIRA documentation

On the JIRA page shown above, there’s:

  • Contextual information at the top of the page.
  • JIRA-specific “how to” instructions.
  • Reused content: The chunk of reference information, dynamically copied in from the USERMAN space when the page loads into the browser.
  • More contextual information, in the form of “related topics”, at the bottom of the page. (Not shown on the screenshot.)

How do you include content from one page into another?

Confluence wiki provides the {include} macro. To use the macro, you edit your page and enter the macro name in curly brackets, specifying the space key and the page title of the page that you want to include into your page.

For example, the above JIRA page contains this macro code:

{include:USERMAN:_LDAP Connection Pool Settings}

When Confluence renders the page, it will replace the macro code with the content of the “_LDAP Connection Pool Settings” page from the “USERMAN” space.

If you like, you can find out more in the documentation for the {include} macro.

The design of the reusable content

Here’s a summary of various design considerations and decisions:

  • Reusable content in a separate space. I decided to house the reusable chunks in their own space, rather than in one of the product documentation spaces. This is because the information is independent of any specific product.
  • Reusable chunks hidden from the reader. Well, as much as possible. The topics in the USERMAN space are not visible in left-hand navigation bar, but people will find them if they search for them. We need to make it clear to readers that the USERMAN space is not intended for reading independently of the product documentation. We also give readers links pointing to the relevant JIRA and Confluence documentation.
  • Inclusions library. Put the topics in an “inclusions library” and start each page name with an underscore. This will alert both readers and authors to the fact that there’s something different about the page, and will help prevent people from changing the page name (which breaks the auto-inclusion). A while ago, I wrote a post about inclusions libraries. One thing to note is that an “inclusions library” is not a feature of the wiki. It’s just a convention we have adopted. The page called “_InclusionsLibrary” is just a page with a funny name. 🙂
  • Spaces as a mechanism for version control. When we release a significant new version of the user management framework (either the back-end libraries or the front-end user interface) we will need to publish a new version of the documentation too. Then, as each product incorporates the new version of the user management framework, we will adjust the product documentation to include the relevant version of the user management documentation. To make this work, we will create a new USERMANxxx space for each version of the documentation. The “xxx” represents the version number.
  • Size of the reusable chunks. How do we decide how big the reusable chunks should be? Well, this is a biggie, so I decided to devote a whole section to it. See the next section, after the screenshot.

Looking at a tree view of the pages in the USERMAN space, you’ll notice that the space home page (marked with the house icon, and at bottom of the screenshot) has no child pages. In a “normal” documentation space, you’d expect most of the pages to be children of the home page. Instead, in USERMAN all the pages are children of the “_InclusionsLibrary” page.

Content reuse on a wiki - a case study

Tree view showing the pages in the USERMAN space

Deciding the size of the reusable chunks

On the one hand, the smaller the chunks the better. Small pieces of content give us much more flexibility. We can use them in different sequential orders and in different contexts. We can add product-specific and contextual information between the chunks. We can leave out bits in one product and include them in another. We are less affected by changes in the user interface, for example when the order of the input fields changes or entire sections move to different screens.

On the other hand, smaller chunks are more difficult to manage. Every time we need to update the page inclusions, such as when we need to move to a new version, there are a large number of {include} macros to update. This reduces the benefit of efficient maintenance. Too much flexibility may lead to confusion in the final output that the reader sees, reducing the benefit of cross-product consistency.

You could go to one extreme and have a reusable chunk per input field or concept (“setting the optimal size for your LDAP connection pool”). Or you could go to the other extreme and define one large reusable chunk per user task (“connecting an LDAP directory”).

After discussion with the product manager and development team, I decided to go for a middle-of-the-road approach.

  • Most of the reusable content is reference material and conceptual material, rather than “how to” steps.
  • We divided the content into logical blocks, corresponding to a logically-related set of input fields or to a concept.

The result is:

  • For the simpler task-based topics, there are two page inclusions: one for the concept and one for the reference material. Example. (To see the wiki markup source of a page, click “Tools” and select “View Wiki Markup” from the dropdown menu.)
  • For the more complex topics, the number of inclusions ranges from five to ten: one or two conceptual chunks,  a number of reference chunks and one or two illustrative chunks. Example 1. Example 2.

What about the procedures and context that are specific to the product?

In the documentation pages for Confluence and JIRA, there are sections that are specific to the product and sections that are common to both products.

These bits are specific to the product, and therefore not reusable:

  • Procedures: The primary user interface is different for each product, and so the path that the user takes (click here, select this, click that) to get to the directory connection screens is specific to the product. Once the user has reached the directory connection screens, the user interface is the same for both products.
  • Context: It’s a good idea to start each page with a mention of the product (Confluence or JIRA) and other orienting information, so that the reader knows what the page is about. After that, it’s safe to dive into the reused content which, of course, is free of contextual information.
  • More context: The path within the documentation itself differs. For example, we need to give people links to related topics and parent pages.

Each documentation page therefore has a section or sections of reused content, with a wrapping of product-specific content.

Diving into a more complex example of content reuse

Let’s take a look at a complex topic, connecting to an LDAP directory.

The topic has a number of sections:

  • A short introduction to the page.
  • An overview of the LDAP connections provided and why you’d use them.
  • A “how to” procedure.
  • Seven sections containing details of specific settings.
  • Diagrams of possible configurations.
  • Related topics

Only three of the above sections contain content specific to the product:

  • The short introduction.
  • The “how to” procedure.
  • The related topics.

All the other sections are drawn from reusable chunks:

  • An overview of the LDAP connections provided and why you’d use them.
  • Seven sections containing details of specific settings.
  • Diagrams of possible configurations.

To see this at work, go to the page (for example, in the Confluence documentation, Connecting to an LDAP Directory), hover over the “Tools” button and select “View Wiki Markup” from the dropdown menu. You’ll see that most of the page consists of headings and {include} macros like this:

h2. Server Settings
{include:USERMAN:_LDAP Server Settings}
h2. Schema Settings
{include:USERMAN:_LDAP Schema Settings}
h2. Permission Settings
{include:USERMAN:_LDAP Permission Settings}

The first {include} macro draws in a reusable chunk from this page in the USERMAN space: _LDAP Server Settings.

The corresponding page in the JIRA documentation (Connecting to an LDAP Directory) looks very similar to the Confluence page.

Reusing Gliffy diagrams

This is something pretty cool that I discovered when creating this set of documentation. You can use the {include} macro to pull in a page that contains a Gliffy diagram. Let’s say you have a Gliffy macro on Page A. Then on Page B, you insert an {include} macro that pulls in Page A. Confluence will faithfully reproduce the diagram on Page B, as well as Page A.

That’s awesome!

Here’s an example. This page in the USERMAN space contains just a Gliffy diagram and its caption: _Diagram Confluence JIRA Crowd.

Here’s a screenshot of the above page:

Content reuse on a wiki - a case study

A reusable Gliffy diagram

Reusing the diagram:

Developing the design

The exercise of designing the reusable content was interesting in a couple of aspects.

  • First, the end result would be a set of reusable chunks, only loosely resembling the “documentation” that most subject matter experts are used to seeing. How could I prototype the design and the content with them?
  • Secondly, the content would be used in two different sets of documentation, for two different products: Confluence and JIRA. Only the Confluence documentation is “mine”, in terms of technical writing responsibilities. Two other technical writers manage the JIRA documentation. I needed to make sure they had input into the design and were happy with the end result.

The usual process of consulting and collaborating with subject matter experts when designing a new documentation suite goes something like this: Draft the table of contents, review it with product managers and developers, apply changes, add detail, and refine it until we’re all happy.

The difference was that there were two tables of contents:

  • The list of topics and their hierarchical structure as they would appear to readers. Let’s call this the compiled documentation
  • The list of reusable chunks that we would plug together to form the above readable material. Let’s call these the reusable chunks.

My strategy was to discuss and review the planned table of contents for the compiled documentation in great detail, making sure that I covered all topics and was consistent in the amount of attention given to each subject. Then I designed the reusable chunks to best satisfy the requirements so discovered. When designing the reusable chunks, I relied more on my technical writing and information design skills.

As soon as we had a basic design, I created the draft content in the reusable chunks and hooked them together to create the compiled documentation for one of the products.

Then I walked the technical writing team, product managers and developers through that first draft. I showed them the reusable chunks and discussed the design strategy (size of the chunks, use of wiki spaces, setting of permissions, consistency, removal of context, and so on). But most of our attention focused on the human-readable documentation. The review session, as always, gave me much valuable feedback that I applied to the draft.

After that initial review, I focused on each individual topic and went through the usual iterative procedure of drafting, reviewing and updating the content.

The tools

A summary of the tools I’m using for this case study:

  • Confluence wiki.
  • The {include} macro, supplied as part of Confluence.
  • Spaces, the primary way of organising content into logical collections, or libraries, in Confluence.
  • The Documentation theme, supplied as part of Confluence. In fact, you do not need the Documentation theme for content reuse. All of the techniques mentioned in this post will work in the default Confluence theme and most other themes too. But I’ve mentioned the Documentation theme here because the screenshots show it in action, in particular the left-hand table of contents supplied by the theme.
  • Gliffy online diagramming tool. Again, this tool is not needed for content reuse. I’m including it in the list because it’s an interesting part of the case study.

That’s it for now

I hope you find the examples and design tips useful!

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 3 April 2011, in Confluence, technical writing, wiki and tagged , , , , , , , . Bookmark the permalink. 34 Comments.

  1. Sarah, this is excellent how-to information from someone who really knows “how to” do it. Thank you for sharing it!

  2. Hi,
    I’ve been wrestling with this exact thing for a couple of months now (in between other projects) and came to a similar solution. But if you could just hide the third space and keep the contents from being searchable, that would be ideal. Having this extra third space is very confusing to readers. I am hoping to get around the rogue space in the dashboard by using an alternate home page instead of the dashboard with links to the relevant spaces, but the searching thing is still a problem.

    If Confluence wants to function well as a knowledge base solution, I really recommend adding the above options as well as allowing chunking a page and including parts across spaces instead of just within a space. Single-sourcing across spaces seems to me to be a pretty key feature, as indicated by our identical problems.

    • Hallo Emily

      That’s a very interesting point.

      It’s tempting to say we should be able to hide the space from viewers and from the search. There are points for and against this suggestion.

      Looking at the points against the idea: In a wiki, the aim is to allow the community to edit as well as view the content. If they can’t find the content, then it will be difficult for them to edit it. Also, one of the big points in favour of Confluence is its simplicity. Adding complexities around permissions structures may lead to confusion in settings and usage.

      As you said, one way is to use an alternative home page for your wiki. The administrator can instruct Confluence to display a home page other than the dashboard. Here’s the documentation on how to do that:

      We’ve defined our own documentation home page, although we haven’t set it as the default home page for our wiki site. Instead, we’ve added a link at the top of the dashboard, pointing to our documentation home page. Here’s the page:

      Here’s another thing to consider: how about using the Space Directory as your home page? In Confluence 3.5, you can categorise your spaces and then view them in the Space Directory. For example, you could add space categories (like labels) to only the spaces you want people to read, and then only those spaces will appear in the Space Directory. Here’s the documentation:

      Still, I think it would be great to explore the idea of improving content reuse on Confluence. I see Confluence as a continually-evolving platform, with many uses and many communities using it. The development team are very open to suggestions on how to improve its usability for a particular community group — in our case, technical writers. 🙂

      One way would be to add more config options to the Documentation theme, perhaps, since that theme is targeted at our usage scenarios. That may be a way of confining the complexity to a group of users to understand its purpose and workings. We could suggest a checkbox that marks a space as intended for content reuse. The results of selecting that checkbox could be:
      * Space does not appear on the dashboard.
      * Space contents only appear in the search if the search term includes a specific key word.
      * Search engines are discouraged from indexing the space.
      * Space gets a special colour scheme, alerting authors that its content is reused elsewhere.

      What does everyone think?


  3. Hi again, I just saw this secure-include macro from Customware. Might it be possible to make the third “shared content” space inaccessible to your users and then use this macro to do your including and so solve the problems of having “extra” pages floating around? Looks like its not supported for the most recent Confluence versions though?

    • Hallo Emily

      That does look like an interesting macro. I haven’t tried it myself, and I’m not sure exactly what it does. At first glance, it does seem to let you include content from a page where the space has restrictive permissions, into a page in a space with more open permissions. But the description also says that if the author loses permission to view the restricted space, then the page inclusion will no longer display the content.

      The macro is supplied by the Perimeter plugin:

      As you remarked, it isn’t yet supported in Confluence 3.5.

      I’ve emailed the Customware guys, asking if they can help us out. 🙂

      Cheers, Sarah

      • Hi there,

        The secure-include macro basically lets the first user that uses it to include a page in any other location that that user has access to. As you say, if the original user that did the ‘secure-include’ loses permission to see the included page, it will stop including.

        With regards to compatibility, it is something we aim to get working in 3.5, but we haven’t had time to test it yet. It is possible that it will work as-is, but it does depend on a couple of built-in features that have been known to change in the past. Also, given that the permissions/user authentication system was changed significantly in 3.5, there are good odds that would have broken something also.

        Short answer is, we will get it going again as soon as we can fit it in. If you would like to accelerate the process, shoot us an email at and we can get a quote for you and bump it up to the top of the list.

        Hope that helps!


  4. OK so I’m testing out the Perimeter plugin in our dev instance, and it seems to work fine, and hopefully will be the solution! The description of the macro was completely confusing though, and the author thing is indeed pretty odd—i.e. if I am the author and I leave the company, I guess things get messed up? However at my company we just leave users in place at the moment, so at least for now it should not be a problem.

    As to your hesitation on hiding the parent space, you can grant access to any authors, but not read-only users. In my example, I’m authoring a customer-facing knowledge base that customers cant edit, but all employees can edit. I think your case is the same—for example, you don’t need me to be able to see the shared content space, but you want your coworkers to see it.

    I’ll keep you updated on my progress with the Perimeter plugin.

    • Hi there,

      Just to let you know, the reason we check the original author’s permissions is that we have to pick someone to check. If you can just nominate another user then anyone could access content they don’t have access to, just by using the username of someone else with more access. Basically, the intent was that a user can ‘include’ any content that they have access to, no more, no less. If their access changes in the future, they can no longer share that content.

      To work around the problem of a user leaving the company etc, you could create a more permanent ‘virtual’ user, and log in as that user to create the secure includes.

      If you have any suggestions of a better way to have it work, please let us know – easiest way is via

  5. Update: The Perimeter Plugin works fine, but I ran into another snag. Included material doesn’t turn up in a search, so if you hide the source material, you eliminate the ability to search the material. But you have the same problem with non-hidden source material—you will simply be directed to the shared content space in a search, which brings us back to the problem of confusion.

    Sarah, do you have any solution to this? You could use labels, but that’s only going to cover key words of course.

    • Hallo Emily

      I agree completely, that the search results should include pages where the matching content arrives on the page at render time via the {include} and {excerpt-include} macros.

      We have a feature request here:

      It would be great if you could add a comment to that issue, to bump it up in our product management team’s queue. 🙂 You can also vote for the issue, and “watch” the issue to keep informed about progress. To get access to comment, watch and/or vote, sign up for a username if you don’t have one yet.

      Thanks so much for sharing your experiments!


      • Comment added, Sarah. Thanks for the heads up on that feature request. I’m having our developers look into a back-end work around, but it would be great for Confluence to add this feature, as it would be useful to many of your customers, I’m sure.

  6. Hi – was wondering what everyone uses for generating PDF output from Wiki content?
    I’d be happy with dropping PDF output completely, but it does serve a purpose still (and prod mgmt wants it… :)).

  7. Hurrah! Thanks to David Petersen who pointed out the cache macro, I’ve now got a complete solution.

    The key is the CustomWare secure-include and the Confluence cache plugins (s and, so I sure do hope they are supported in perpetuity! Here’s how it works: I create my single-source content in a third space, which is accessible to my company’s employees but not to customers. Then I use the secure-include macro to grab the content I want and include it into the 1st and 2nd spaces, where it is visible to anyone who has permission to view those spaces. Then (and you have to do this after you have done the include and saved the page) you wrap the secure-include macro with the cache macro. This makes the “included” pages in spaces 1&2 show up in a search.

    The only real drawback is that someone editing these pages cant edit in situ; they have to go find the original page, which is a little annoying. And the syntax of the secure-include macro doesn’t tell you what the original page is called. But I’ve set a standard that the included pages have the same page title as the original page, so that’s not too much of a pain.

  8. We are also introducing something along these lines, and seem to have a structure set up.
    My question is: How you do you know where (on what pages) the reusable chunks are being used?

    • Hallo Jo
      Alas, there isn’t any cross-referencing system in Confluence. I usually just do a search. It works well enough if you use double quotation marks.

      For example, to find a reference to a page called “_MyReusedPage”, search for “_MyReusedPage” (including the quotes).

      You can even add the word “include” to your search term, to refine it. For example, let’s say you have a reusable chunk called “My Reusable Chunk”. Then you can search for “include:My” (including the quotes).

  9. Søren Mønsted

    Very interesting post 🙂

    We are just fighting the same problems as Emily writes about. One thing we are still trying to figure out: if you have a third space with shared content that is included in other spaces, how do you handle versioning? Ideally we want to version the shared content space so it corresponds to versions of the spaces facing our customers. But I cannot see a way of doing that without updating all the include macros to point to a specific version of the space whenever we make a new version.

    Does anyone have a solution to this?

    • Hallo Søren

      You’re right, you will need to update all the include macros when you make a new version of the space that contains all the reusable content.

      That’s what we do with the USERMAN space. When the developers create a new version of the User Management tool, we create a new space for the version. Then when one of the products releases a new version that uses the new version of the shared User Management libraries, we update the include macros.

      Luckily, in our case the shared code libraries haven’t undergone much change since development. There have only been 3 or 4 versions.

      Cheers, Sarah

      • Søren Mønsted

        Hi Sarah,
        In our situation this happens quite frequently and there will be +100 macros to update. But It seems we can work around this when we export the space to xml and import it again. A simply replace operation on the xml file solves the problem.

  10. Søren Mønsted

    Another question: If I’m writing a piece of shared content, and I wish to reference another page also part of shared content, it seems like I have big problems… Or did I miss something?

    I would hate linking into the general shared content – that would be really confusing for our readers.

    • Hallo Søren
      Ah, there you’ve hit one of the quandaries of content reuse. This problem is inherent to content reuse, whether you’re using Confluence or any other platform. The reusable chunks need to be independent of context, and in most cases it’s not possible to add useful links inside the shared chunk. Instead, people usually put all references in a “related topics” section on the page that is using the shared content.

      • Søren Mønsted

        Hi Sarah,

        I have realized over the weekend that I am in a fundamentally different situation compared to the situation you describe in this post.

        We have three different editions of our software package, and they share a lot of common features and I would then like to build a user manual for each version with 90% of content based on re-usable content.

        But this is clearly not the right way to go. What I would need is something like conditional content (as known from traditional technical writing software).

        I think we will end up using Confluence for authoring one manual for all three versions, using tags to mark content for the different revisions, and then we will find a way of “publishing” this when we make a new release. Maybe by scripting the xml export of a space and import it back again.

        But thanks anyway for getting back!


      • Hallo Søren

        Ah, what you describe is just what we’re looking for, for another of our requirements. In fact, we’re working with K15t Software to build a plugin that will provide conditional publishing in conjunction with content reuse and version control. 🙂 The conditional publishing will be at page level, and also for chunks of content within the page.

        The plugin is called Scroll Versions. It’s currently in beta release, about to come out with its version 1.0. That version will contain the version control and content reuse, but not the conditional publishing. We’re working with them on version 1.1, which will have the conditional publishing too. Exciting!

        If you’re interested, feel free to get in touch with Tobias Anstett and Stefan Kleineikenscheidt at K15t, and let them know I sent you. They’re very interested in any feedback tech writers can give them. 🙂

        Cheers, Sarah

      • Søren Mønsted

        Brilliant 🙂
        I will do that.

  11. Hi,
    I’ve noticed that you put in the docu configuration details. Like connection pool settings for example. Do you have a way to make sure these settings are always up to date in the documentation?
    We resigned from writing properties in docu, as after some time when they are being changed, in 99% of cases developers forget to let us know about the change and documents become outdated.


    • Hallo Lukasz
      Good discussion point! We haven’t found a completely reliable way of ensuring that the details are kept up to date. We have a few strategies in place.

      The most effective is that we allow the developers and support staff to update our documentation, and we educate them to know that when they make a change, they should look for the affected page and fix it.

      We also allow comments on the documentation pages. Customers, partners and other experts often add a comment letting us know something needs updating.

      And lastly, we watch the fixes in our issue tracker to see what the developers are doing for each release. When we see something that may affect the documentation, we investigate.


  12. Hi Sarah,

    Thank you for a helpful article!

    As almost two years have elapsed since the original post, I wonder if you have any updates to share regarding the best approach(es) to reusing content in Confluence?

    It seems from visiting the example pages that you may be doing things differently at this point — as one would indeed expect!

    An attractive aspect of the original method you described is that it was workable with older versions of Confluence — we are using v 3.5 — and did not entail acquiring plugins. (I sigh in vain for the features of Scroll Versions…)

    Hope you will have a chance to bring us up to date on this topic!

    • Hallo Daniel

      I’m so glad to hear you’re finding this post useful. Actually, very little has changed since I wrote it. We still use exactly the same methodology and technology. There are two points to note.

      One of the pages referenced in the post no longer exists in the latest JIRA documentation, because the feature was removed from JIRA. It’s the page about configuring the LDAP connection pool. Here’s the link to the page in the JIRA 4.3 documentation:

      The other point is that, in Confluence 4.0 and later, wiki markup is no longer the storage format used by Confluence. You can still use wiki markup to enter the content into the page. So, the example code in the above post will still work. But when you view a page, you’ll see the new storage format instead of wiki markup.

      The examples in the post come from our own documentation wiki, which is running on Confluence 5.1 at the moment. So, where the post says this:
      “To see the wiki markup source of a page, click “Tools” and select “View Wiki Markup” from the dropdown menu.”
      It should now say this:
      “To see the source of a page, click “Tools” and select “View Source” from the dropdown menu.”
      You’ll then see the macro placeholders, which look like rounded grey rectangles.

      There’s no need for any additional plugins. The method described in the post works in Confluence out of the box, for 3.5 all the way up to 5.1. 🙂

      Good luck with your content re-use. It’s paid off many times for us, in reducing maintenance effort and improving consistency.

      Thanks so much for your feedback. It’s great to know people are finding this post useful!


  1. Pingback: Making the include macro’s content appear the Confluence search results « ffeathers — a technical writer’s blog

  2. Pingback: The “One Thing, in One Place, Once” Rule using Confluence «

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: