What Do You Want? Charles Miller
One of the most asked-for features in Confluence is nested spaces, and we want to give our customers (or potential customers) what they want. Personally, though, I'm having problems wrapping my mind around just what a nested space is. The problem, I think, is that nested spaces are a solution, not a problem. Nobody really needs 'nested spaces' per se, nested spaces are a means towards a set of practical benefits: problems that Confluence does not currently solve.
Speaking personally again, I find it very hard to implement a feature without knowing clearly what problems that feature is trying to solve, because if I don't know that, how do I know if I've done it right? And how do I know that there's not some better solution to those problems that I'm missing because I'm heading straight for the solution?
So, I'd really like to know what specific needs nested spaces would address? If you're interested in this feature, please add to the list below, or add comments to this page if you want to explain your requirement in more detail.
- Users need a way to see what spaces are 'related' to each other, and group them accordingly
- Users need a way to limit search results to a group of spaces
- Users want to track recent changes (via the dashboard or RSS) that encompass "families" of spaces
- Administrators want to share permission schemes (and other space preferences?) between spaces
- Users need an easier and more organized way to browse large lists of spaces (imagine looking for a specific project in a flat dashboard list of 80 project spaces to which you have comment access)
The Mechanics of Nesting
The other thing that's causing me to be unable to wrap my mind around nested spacing is just how it would work practically:
- Exactly where in a space would the nested spaces be? Would you go to a page in space Foo called "Bar", and that page would be the homepage of the Bar space? Or would the nested spaces be separate from the pages?
- Could you have a page called Bar and a space called Bar in the same space?
- Would you need some kind of 'inheritance' of page namespaces?
- Would you want parent-child page relationships that span spaces?
Comments (41)
Jun 18, 2004
Dan Hardiker says:
Space Grouping / Hierarchy There are several cases where multiple groupings of ...Space Grouping / Hierarchy
There are several cases where multiple groupings of spaces would take place in some form of hierarchy - but ideally for our uses, spaces would be able to reside in multiple parent spaces - for example (where title is a content space and title is a group space, if in fact you want to make that distinction):
This is pre-empting the addition of a user space but you could also add the following formation:
Where the staff at the end of the lists would each have their own space, but be organisable. I guess this could all be done through one default / home / base space, where everything is nested inside. i.e. where there is a confluence base space which all other spaces are nested inside of.
This could mean shifting the home page (which lists all the spaces and reciently modified files) into a macro on a page which can then be edited in the confluence base space (by those with the correct permissions).
Space Settings altered for a subtree of pages - possibly by making the root page of that subtree a space
As another thought, reasons for nested spaces is that you might want to manage a set of pages (macros, permissions, templates and other space-wide settings) differently to the rest of the space. For example - we have an IT Support space, we want anyone to be able to add questions to the FAQ tree inside of ITSUP, but only want IT Admins to add pages inside of the IT Support space. We currently cannot accomodate that flexability, where as nested spaces would allow it.
A Radical Option
Instead of having nested spaces - why not expand what a space "is" to encompase all pages. I'm probably missing somethings out of the following list, but it should be enough to give you the direction of my train of thought. This is what I think differenciate pages from spaces:
Permissions
The ability to say who can do what to this space (add pages, remove pages, edit pages, lock pages etc). What about expanding this so pages themselves can have this? So I could say the following:
Macros, Templates, Decorators and such like
These could all be tackled in a similar way to the permissions and all held in an administration area for each page (setup only when used and this should be able to be deactivatable for subpages, as a permission). The biggest problem I can see is handling the admin of several pages and also detecting modifications (eg: which subpages modify my settings) ... but thats a problem which would exist with nesting too.
Duplicate Page Names and Interspace Linking
This could cause issues, for example if I have a glossary page in two spaces [SPC1:Glossary] and [SPC2:Glossary], I can't currently work out how to get around this. Perhaps by having tree names? As in labling a page (which would be the base of a subtree inside the whole page tree) as having a root label of SPC1, and then the link would search that subtree for the page. This would make duplicate catching hard, if not impossible.
So whats the need for spaces?
Well, there isn't one in this scenario. There is just the base confluence page and everything is hung off it and pages are re-permissioned (etc) where needed. Bear in mind that I have no idea of the impact, either conceptually or programatically on confluence if this was to be an accepted idea - I just like radical thoughts!
I would love to hear people's thoughts and suggestions over this idea (he says, preparing to be shot down in flames) ... it's just a pitty we can't nest comments and be able to contain the conversation! (*wink* *wink*, *nudge* *nudge*)
Jun 18, 2004
Charles Miller says:
Dan: Programmatically, everything is possible. It's all just bits. :) The big p...Dan: Programmatically, everything is possible. It's all just bits.
The big problem here is maintaining useability and administrative simplicity. Conceptually, a single-rooted tree is a very clean way to organise stuff, but practically it can be quite evil. "This is a space. It's a bucket you can put stuff in. If you want to know anything about the space, just look at the summary page" is a lot easier for people to grok than "You bless this page in a certain way, and every page under it is now blessed. To find out how it works, you look at the aggregate effect of all the blessed pages above it."
This is similar to what's wrong with the filesystem metaphor: A real filing system consists of cabinets, containing drawers, containing files, containing papers. The hierarchy is very limited, and each level of the hierarchy is specialised for the sole purpose of being at that level. When the filing system metaphor was moved to the computer, you ended up with infinitely nested, indistinguishable files and folders, and the practical upshot is that most users just shove every file they own in "My Documents".
Personally, I think we could solve 90% of the requirement for nested spaces by implementing permissions schemes that can be shared between spaces, and allowing the definition of "space groups" by users and administrators that could be used to group and filter spaces on the dashboard, RSS feeds, searches and other summaries. That way, the hierarchy is kept shallow with the purpose of each level clearly defined, and it's easy to make the UI distinguish what level the user is looking at.
I think, perhaps, what I really wanted from this page was for somebody to point out some important practical value in the remaining 10% that makes the complexity of nested spaces worthwhile to our customers.
Jun 25, 2004
Andrew Denysenko says:
We have just started to use confluence. Our need is perhaps a little simpler tha...We have just started to use confluence. Our need is perhaps a little simpler than the above stated scenarios. In our "Application Development" space we have different kinds of articles (e.g. How Tos, Knowledge Base, Procedures, Announcements). What we would like to do is put all documents of a given type in a folder (or more approriately a category). I know that you can create hiearchies of pages but frankly when you potentially have hundreds of documents you really don't want them all children of some other document. The parent document may go away altogether - and now you have lost your grouping. So I guess what I would like to have is a way to group related pages within a space - either by category or folder. If you could grant permissions to that category or folder that would be nice but certainly not a must have. If you had a "folder" or "category" concept you could then provide some sort of macro to easily render links to items in that category or folder - perhaps even with some of the options that the "blog-posts" macro provides. So, perhaps we would have something like this:
1. For each Space, the admin can define 'categories' or 'folders'. Let's just say category for the rest of this example:
2. When a page is authored the user can pick the category.
3. The page looks like every other page except that it has an adornment (meta-data) on it that specifies a category (or categories).
4. From the Space Summary, end users can browse by category.
5. A custom macro would be provided that would allow embed links and/or extracts to the documents.
If you went with a hierarchical folder scheme you could even provide some sort of portlet that navigates all of the folders - ala Plone - see www.plone.org
Aug 05, 2004
Alexander Kiel says:
Wy don't use a label system like in SnipsnapWy don't use a label system like in Snipsnap. With help of this we can add any kind of meta-data to a page.
I don't like nested spaces because this would route Confluence away from a wiki towards a filesystem. With categorys we can group pages in a heterogeneous way.
Aug 06, 2004
Alexander Kiel says:
Link to Metadata Ideas.Link to Metadata Ideas.
Aug 20, 2004
Andy Ciordia says:
Regardless of Nested spaces, the nested auth idea is needed. I don't like having...Regardless of Nested spaces, the nested auth idea is needed. I don't like having to make a new space up whenever I need to restrict viewership to a few pages. I'd rather have a more granular auth setup.
Jan 07, 2005
Steven Richards says:
In our environment we will tend to have a lot of smaller teamlevel spaces rather...In our environment we will tend to have a lot of smaller team-level spaces rather than a small number of large spaces. There are many reason behind this, including security granularity, however probably the key one is to minimise page name conflicts. This is fairly easy to control in a smaller space however can become an issue in very large spaces and tends to mean you have to have longer and longer page names.
(Of course this may also be solved by using the internal unique Page ID instead of the name for linking thus allowing pages with the same name however ultimately this is bound to become confusing for mere mortals.)
Therefore the requirement becomes one of manging a large number of spaces in a single Confluence instance as efficiently as possible.
Nested or grouped spaces (or a similar concept) would provide for the possibility of a range of functionality to help this requirement. eg.
Also I think spaces should be able to exist in multiple groups/hierarchies.
Actually this is sounding more and more like "space" categorisation which is simple one level higher than "page" categorisation which is also not a bad idea. I think the key thing is to get some tangible benefits from putting the effort into defining and maintaining the categorisation - which would be the case in space group/categorisation as defined above.
Feb 28, 2005
Paul Russell says:
In my environment, I think what I need isn't so much 'nested spaces' as 'space n...In my environment, I think what I need isn't so much 'nested spaces' as 'space namespaces'. We have 34,000 employees in this country alone. While we're not in a place where we're likely to roll Confluence out to that many people, we might (eventually) want to roll it out to enough people that having a flat 'space namespace' might be a problem.
It would be good for us to split spaces down a bit, perhaps a hierachy like:
Department +- Intranet space +- Project 1 | +- Space 1 | +- Space 2 +- Project 2 +- Space 3Only the 'leaf' spaces would actually contain content, but at least someone in a completely separate department doesn't have to delve through all these spaces to find the one relevant to them.
It'd be nice to be able to define permissions at each level etc, but it'd still be useful without. I guess what I'm saying is that personally, I could wait for the more advanced features.
Just my 0.10 euros, though.
Nov 04, 2005
John M. Black says:
One real example of this is the Confluence Test SpaceOne real example of this is the Confluence Test Space itself. Try viewing this in a hierarchy and you will not only sit for a minute or more, you also won't know where to begin. One thing we are trying to do in our evaluation is see if we can get Confluence to act like newsgroups ... sure it already does, we're doing it now; but it doesn't have that familiar newsgroup look & feel to it (aka Outl**k) with integrated tree navigation. There's a plugin for that now, I know. But it's the organzation that scares me; how do you have nested categories or newsgroups and display them easily, without the size of the space-level view getting out of hand?
Maybe this comment belongs somewhere else, but this conversation made me think of it.
-John
Sep 20, 2005
Brian Hutchison says:
Being able to nest spaces would be key for adoption at my company. We have many ...Being able to nest spaces would be key for adoption at my company. We have many hundreds of projects, far too many to have meaningful navigation at the top level. We have different departments, and each department needs to be able to focus on their projects only. For us, a logical hieararchy would work as follows.
In this case, I see the Departments, Domains, and Projects each being Spaces, with the Domains nesting under the Departments and the Projects nesting under the Domains. To get a feeling for domains, different departments specialize in different things... a software company might have a research division (a department) that includes Human Computer Interfaces (a domain), with various projects to make improvements to the company's HCI. A different department, say the operations team, has domains of lab support, NOC support, High Availability, and various projects under those.
The concept of nesting is pivotal to make good organization use of large amounts of data. Imagine if your hard drive had every folder at the root level. It might sound like a very egalitarian
ideal or something, but in practice its a real headache. When you have hundreds, even thousands of projects to manage, having everything at the top level is unwieldy to say the least.
Oct 05, 2005
A. Mitchell says:
My primary need for nested spaces is to get around the unique page name constrai...My primary need for nested spaces is to get around the unique page name constraints that you confront when you want to put similar pages inside a single space.
For example, at our organization, we want to use Confluence to create and maintain functional specs for software initiatives. We would like to avoid having to create a separate space for each spec, but we want to be able to have the pages be consistently named within each spec. Nested spaces, assuming they would allow you to duplicate page names across nested spaces would solve our problem. We could have a space called "Functional Specs" and then a nested space for each spec.
Like:
In the absence of nested spaces, the alternative is to create a space for each project -- for all the docs related to the project, not just the specs. Unfortunately, this doesn't quite work for us because we may have multiple specs for each large functional area of our bigger projects. Plus, we'd run into the problem mentioned above where you have to navigate through a list of a million spaces to find the one you're looking for.
In short, nested spaces that permit duplicate page names across them (but not within them) would solve our chief issue.
ps. What is the status of the development of nested spaces? Is it already included in a release, and I just missed it?
Nov 04, 2005
Bob Swift says:
I don't think this is the most critical area for enhancement and I think perhaps...I don't think this is the most critical area for enhancement and I think perhaps all that is needed for the near term is groups (or families) and not nesting. Groups would be nice to group related spaces and yes, I would like to use groups to make sure space permissions are the same for the entire group of spaces.
Nov 04, 2005
David Peterson says:
I think that's kind of coming with the 'team label' feature in 2.0. I'm not exac...I think that's kind of coming with the 'team label' feature in 2.0. I'm not exactly sure how this is actually implemented (or if it actually made the final cut), but there were screenshots floating around with a 'Team' tab and selectable sections which would list spaces of relevance to a specific team...
Nov 04, 2005
Mike Cannon-Brookes says:
Space labels, and more specifically team labels, are certainly in 2.0. You shoul...Space labels, and more specifically team labels, are certainly in 2.0. You should be able to see the "Team" tab on the Dashboard of this very instance?
Nov 04, 2005
David Peterson says:
How exactly do you specify that a space is in a particular team? Just team:whate...How exactly do you specify that a space is in a particular team? Just team:whatever as the label?
Nov 04, 2005
Mike Cannon-Brookes says:
Precisely. The space labelling page has a separate UI for team labels, but it is...Precisely. The space labelling page has a separate UI for team labels, but it is effectively a label with a namespace of team - yes. This enables space administrators to put their spaces into different teams without requiring a higher power to do it for them.
New teams can be created anarchically - which we love
Dec 09, 2005
CK Test says:
I have a need for nested spaces for sure. I want to have a space called "P...I have a need for nested spaces for sure. I want to have a space called "Project Management" and under it i would like to have multiple spaces for each project initiative. For each project initiative i would like to have seperate security, email, etc. It would be very ideal to be able to do that for us rather than sticking everything at the root. Also it would be nice to be able to say that a space is not longer "Active", allowing you to filter between spaces (or projects) that are active and not
Jan 14, 2006
Guy Fraser says:
See Space Channels idea:See Space Channels idea: http://jira.atlassian.com/browse/CONF-5186
Mar 15, 2006
Michael Ogrinz says:
I would like to be able to nest spaces to duplicate the functionality of a produ...I would like to be able to nest spaces to duplicate the functionality of a product called twiki, which I've used in the past.
I want to create a single "Sandbox" space. When a new user joins the wiki, I want to create a personal sanbox space for them underneath that using the API. I also want to make that a favorite for them immediately.
Now, every user has their own personal playground where they can experiment w/ the wiki, or build pages that pull in all the relevant content that they want (plus their own annotations).
Mar 15, 2006
Guy Fraser says:
Would the "Space Channels" concept (see comment above) work for this scenario? E...Would the "Space Channels" concept (see comment above) work for this scenario? Essentially you'd just create a channel for that user with the relevant privs and then they could play around in their own channel.
Mar 17, 2006
Michael Ogrinz says:
Maybe; but I think the details need to be fleshed out a bit more. For example, I...Maybe; but I think the details need to be fleshed out a bit more. For example, I wouldn't want the user's personal sandboxes to be part of the search results. They are a playground for learning Confluence, as well as creating unique custom content. Maybe I want a calendar of the days I intend to play golf (but call in sick). My boss doesn't need to be able to search on that
Aug 18, 2006
Bhavin Turakhia says:
The primary reason for us wanting Nested Spaces is to have granular permissions ...The primary reason for us wanting Nested Spaces is to have granular permissions structure on inner content. Currently pages have very limited permissioning capability ie only able to restrict view and edit, and i cannot add multiple groups or multiple authentication rules to pages
in a more esoteric sense, i see no reason to have distinction between "spaces" and "pages". the whole wiki could be a page within a page within a page - each page with copmlete granular permissiobn structure and all other features.
in the current situation, if pages had the SAME permissioning capabilities as a "space" - that would serve our purpose
Aug 18, 2006
Sean E. Kennedy says:
I concur. The essential problem is one of permissions, and since permissions tak...I concur. The essential problem is one of permissions, and since permissions take place at the group level, it's a questions of groups, as much as spaces or permissions.
If you could assign permission to create groups at the space level that would solve most of the problems.
Of course if you aren't going to have nested space, relying instead on page hierarchies with different restrictions, you would also need to be able to create groups at the "restricted page" level.
Aug 18, 2006
Guy Fraser says:
There is already a plugin for managing groups at space level can't find the link...There is already a plugin for managing groups at space level - can't find the link to it though - might be worth asking on the conf-user mailing list or forums...
Aug 18, 2006
Sean E. Kennedy says:
Thanks. Found something atThanks. Found something at http://confluence.atlassian.com/x/yooC
Not quite what I was looking for (no group creation), but I'll look into it.
Aug 19, 2006
Bhavin Turakhia says:
Not entirely correct. The ability to create groups at space level does not resol...Not entirely correct. The ability to create groups at space level does not resolve the ability of giving granular permissions in a nested page. Also in an Enterprise, group creation is typically restricted based on Business Rules. For instance in our company we depend on the Windows Active Directory. A persin and his Group membership is decided at the time of joining a company, and never changed after that unless the role/title/team of the person changes
The most significant current limitation which I believe should be easy to remove is that for EACH page you can restrict View and Edit permissions to only ONE group. I wonder why this limitation was put in. Imagine the following scenario
Space
- Page 1
- Page 2
Group 1: User A, User B, User C
Group 2: User D, User E, User F
Group 3: User G, User H, User I
Now I want to give view permissions of a page to A,B,C,D,E,F only. In this case there is no way to do it, except to create a special group (Group 4) which contains Group 1 and Group 2
This is the preferred order of the required featureset in my mind from "easy to implement" to "hard to implement" -
* Allow specifying mutiple groups in Page restrictions
* Allow specifying granular permissions at page level (as granular as spaces)
* Allow nested spaces
* Blur the distinction between "space" and "page" by allowing everything that is allowed for a "space" in a "page"
Even if the first of the above was implemented, it would be sufficient for the time being. This particular feature (of being able to give granular permissions in internal pages) is the ONLY feature that is preventing me from purchasing Confluence today and resulting in having to investigate other wikis (socialtext etc) to see if they supports this feature.
There is one more feature over and above this which would be awesome from the perspective of an Enterprise wiki - which is integration of Workflows. they already have workflows in JIRA. They can use the same engine in Confluence and allow "content-approval" work flows etc
Aug 19, 2006
Dan Hardiker says:
To extend this further, permissions could do with being added to page versions. ...To extend this further, permissions could do with being added to page versions. This way modifications could also be put into a content approval framework.
I'd like attachments to also have permissions for the same reason - although I'm sure theres more reasons.
Aug 19, 2006
Bhavin Turakhia says:
I just discovered one more issue. It seems that page names cannot be duplicated ...I just discovered one more issue. It seems that page names cannot be duplicated within a space. So the below scenario is not possible currently in Confluence
This is another limitation due to nested space not existing, or the limitations imposed on a "page".
Aug 19, 2006
Dan Hardiker says:
Page namespacing is one of the most eagerly awaited features of Confluence and t...Page namespacing is one of the most eagerly awaited features of Confluence - and the developers at Atlassian are well aware of this mass desire. The complications involved with implementing this feature, along with the other priorities that the developers have to get through is slowing down the progress of it's implementation.
Aug 19, 2006
Bhavin Turakhia says:
From what I understand fundamentally A Space is the logical equivalent of a "fol...From what I understand - fundamentally - A Space is the logical equivalent of a "folder" and a page is the logical equivalent of a "file" in a "store"
If I was to think of Confluence as a repository of knowledge/information/resources - then both "folders" and "files" should have full permissioning capabilities and full nesting capabilities.
By limiting the "permissioning" capabilities of "files" and the "nesting" capabilities of "folders", the end result is a product that does not allow flexibility for enterprise level knowledge management
Aug 19, 2006
Dan Hardiker says:
Think of a page as a folder which can have other pages (folders) or attachments ...Think of a page as a folder which can have other pages (folders) or attachments (files) stored in it.
A space is more like a disk drive, using your analogy.
Sep 23, 2006
Bhavin Turakhia says:
more advantages of nested spaces currently news is related to a space and not ...more advantages of nested spaces -
I would like each team to be able to post announcements (news) for their team. So for instance announcements in "Team Software Engineering" would be visible to everyone, and announcements in Team SubProjectA would only be visible to those folks in that team
Currently if I create Team Software Engineering as a Space, and the rest as pages then all of them share a single Announcements store
This could be resolved, if News Pages had the ability of being permissioned - http://jira.atlassian.com/browse/CONF-3305
Nov 19, 2007
senthilraja says:
\1 We too have the similar scenario. We have lot of projects running over,...+1
We too have the similar scenario. We have lot of projects running over, and the wiki admin would create a space for a project, who would in turn, wish to have sub spaces for each of the sub-projects.
The requirement for us is simple as of now. A space owner should be able to create a sub-space, which has its own space permission.
At present, we have to create more than 3 spaces for the same project.
Advantages of Nested Space:
1. The subspaces share a common namespace. ie, they would be identified as Mainproject/subproject, which would be more useful for classification and maintenance.
2. The subspaces, have its own working space, permission sets, but as a whole be part of the main project. A user of subspace would be able to see all pages in its parent space, but not in the other subspaces, unless permitted.
3. Its a means to segregate and administer contents more effectively, in terms of large project.
4. In a typical large project, the Project managers/leads would like to have their private/confidential information, that they dont want to share with the rest of the team. If nested space is available, they could create a subspace, within the main project area, and have their private contents.
I understand Nested space is complex. But to start with, we can provide atleast one level of nesting, which we can ascertain the impacts, and gradually extend to multi-level nesting. I feel, providing one level of nesting is feasible at this moment.
Oct 06, 2006
Douglas Ko says:
Another use case for Nested spaces in seperate "production" material from "draft...Another use case for Nested spaces in seperate "production" material from "draft" or "work-in-progress". I tried a primatative way of doing thing by create a "Draft" children pages on the relavant parent pages. But there are currently a couple of limitations for this:
Do people have any other best practices for seperating "production" and "draft" material? Breaking them up into seperate root spaces is not acceptable to our workflow.
Doug
Apr 09, 2007
James Mortimer says:
Using the velocity script templates,...Using the velocity script templates, I created four dynamically created buttons on every page(where pagename is the name of the page):
[$pagename - Draft] - draft version of this page
[$pagename - Discussion] - separate discussion and comments for this page (wikipedia style, rather than inline comments)
[HELP:$spacekey - $pagename] - context help
[Links:$pagename] - links to $pagname in all available spaces
note: if a page title cotnains " - Draft" " - Discussion" then I instead showed the root page name. note: you could as easily use the pattern: "Draft!$pagename" or "Discussion!$pagename" note: you just can't use page names with: :, @, /, \, |, ^, #, ;, [, ], {, }, <, > or start with $, .., ~