Should there be one or more spaces in Confluence?

[Bob Do]

In my company (about 2000 employees), all employees can see and edit all spaces in Confluence. The question arose whether all pages should be managed in one space or in several spaces. What do you think?

[Bob Do · Accepted solution]

Thanks for the answers. One problem is, for example, the assignment of a page to a space. Individual pages could also be assigned to several spaces. The idea was therefore to use category pages (like this https://www.mediawiki.org/wiki/Category:Help). On the other hand, however, the clarity could be lost.

Our specific questions are:

1. What is the occasion to create a new space? (If the spaces are structured according to topics and authorizations are not considered)

2. How do we solve the problem of page assignment?

[Robert Reiner _smartics_]

Thank you for making the point clear! Now I think I understand your task.

As long as you think of team collaboration and products, creating new spaces comes quite natural. This is what I have been thinking of: Separate team spaces, workspaces, and topic spaces. But if you are working on something like a knowledge base, on a number of closely related topics, deciding what goes where is hard.

I would advise to keep pages with a strong (as relative as this word is) relation together in one space. I would only create a new space if I can remove that space without damage to the usability of any other space. For instance we have a space where we collect Confluence related information (for instance tips & tricks, or links to resources). Information on our add-on for Confluence is in a complete other space. Although both deal with with Confluence, their purpose does not overlap. So two separate spaces work fine for us.

We also have two spaces for our product: One for the concepts (version independent information) and one online manual (for the current version of the product). Again, the separation is easy, since the decision which page goes where is easy (although I have heard from users that they actually do not consider this separation to strengthen the usability).

We are also collecting information for topics that are relevant for our business. External resources (links to articles, books, etc.) are in one separate space we call 'attachment space '(more on this in a short article on our webpage: Using Spaces or in my answer on "How Granular are your Spaces?") . There everything is tagged and we provide category pages just as you have mentioned. These category pages are in separate spaces, but they could also be part of one large space. In contrast to your task we do not write original documentation in these areas. We simply collect, aggregate, evaluate. The result of our work is then project or product related and goes in that space.

We also use the concept of a delegate page that transcludes (similar to the Excerpt Macro) information from another page. The use case for this is to create a new view on existing information for a distinctive group of people on a limited number of pages. If you end up having several delegating pages for a large number of pages, this would probably be a waste of resources. If the audience for all your pages is the same, I would assume that all these pages are best kept in one space.

On the bottom line I think the task is creating an information architecture that is easy to use (see Finding without searching). I hope that my examples could show some aspects. Without knowing the details of your requirements I would start with one topic space and move the pages to a separate space as soon as you can tell that this information is not related to pages in the existing space (or addresses a different audience with different information needs).

So with no further ado ;) :

1. If you have information that is only distant related to information in existing spaces. If you need to refer to these pages as a unit (each space has a homepage and therefore a single access point), being able to assign access rights, archive them or (re)move them as a whole.

2. It should be no problem to assign a page since closely related pages are in the same space. The problem then will be "Where do I add the new page in this space?". And my answer would be that pages are placed by invariant information of that page (see Physical Location). Then you need to make sure that it is easy for your authors to understand and use the categorization scheme of your information architecture (and I think this is also hard to do).

But these are only rules of thumb ... we have collected a number of practices doing Agile Documentation (related to our product, but most of them should be tool agnostic) which may help to evaluate your information requirements.

Thank you again for your feedback! I totally misunderstood your question in first place.

[Bob Do]

Thank you. That was very revealing.

Do you have a measurement procedure to find out how granular a space should be?

[Robert Reiner _smartics_]

Unfortunately there are no hard rules on when to create a space and when to stick with a page tree. Brikit has a nice video on information architecture and also recommends flat hierarchies: Creating a sound Information Architecture in Confluence

I think for topic spaces (putting all other space types aside) it is dependent on the following factors:

1. who is working (producer) with the pages (includes 'ownership' as Stephen mentioned)?
2. who is the audience (consumer) of these pages?
3. do I need space features (archiving, searching, homepage/navigation, themes, access rights, ...) on these pages?
4. are pages within the space unrelated?

If (4) is true you may move these pages to their own space. If (3) is not true, you probably have no reason to do so. If (1) and (2) refers to the same team and audience (and (3) gives no reason to split), you probably would leave everything in one space. The key often is the navigation issue and spaces support navigation. They support handling pages since they can be semantically addressed as a unit.

So IMHO space granularity is about content: its cohesiveness and usage. If it does not naturally fall into pieces and (on the other side) users do not get confused by content they do not understand or are not interested in, you probably leave it as one topic in one larger space. If this large space causes headaches, then you can ask the question 'why' and tackle this.

Since cool URIs don't change, this may impose some additional pressure on getting it right the first time. But tools always evolve when used and so does the information architecture.

But again, these are rules of thumb and may neglect a number of information requirements your teams and users have. For your large user base you probably would need to sketch some information designs and test them with your teams and users.

[Bob Do]

Thank you for your help. Maybe it is the best way to some information design with the team. 

[Robert Reiner _smartics_]

I think this is not an easy task and therefore the more expert knowledge you get from your team (and maybe users), the clearer possible solutions will get. Everyone involved in creating the design will understand the pros and cons of the chosen approach. 

I would like to recommend (for those on the team that are new to the topic of information architecture) to have a look at Information Architecture, 4th Edition.

Good luck!

[Stephen Deutsch]

Confluence is designed around the use of Spaces, so if you don't use them, you lose a lot of functionality, especially easier navigation and grouping among pages, but also permissions and customizations. Spaces are often recommended to be used for a particular project, team, or theme, and that usually provides general enough granularity so that spaces are not too big or too small.

[Stephen Deutsch]

Also, if you have multiple spaces, then you can have different people/groups take on "ownership" of a space. If you have just one space, people often don't feel a sense of ownership (diffused responsibility) and the pages can often end up more disorganized in one big space than a few smaller spaces.

[Robert Reiner _smartics_]

Stephen listed a number of good reasons to favor multiple spaces.

Actually I can think of not one good argument to stick with only one space. For each argument I can think of, space blueprint (or a 'prototype space' to copy from if you must) would be a valid remedy. I can think of an organization of a wiki that does not meet the information requirements and is hard to navigate and use. But I can do this easily with and without spaces. :)

I have heard about the "number of spaces problem" quite some time. A number of Confluence users seem to really struggle with that. IMHO thinking about which spaces (and labels) may be useful for which users in what use cases would start the discussion on the organization of information in Confluence.

Can anyone provide some arguments to go with one space only? Or has anyone a success story with one large space where multiple spaces would probably have led to failure?