Yes. That is correct.
All wiki systems have to have some unique identifier for a page. Confluence does it by using the space and title. You can't create pages with the same name in the same Space. (So foo:contacts and bar:contacts is fine, but you can see there's an immediate problem with foo:contacts and foo:contacts)
But they're not. I know they are in a parent:child relationship in the tree, but the urls for the pages are unique, and keyed by space and name only.
This has two huge advantages. For structured documentation (for example, product layouts, run books, project guidance), you know that standardised names and structures are there. So foo:contacts will take you to the only contacts page in foo, and when you go to bar:contacts, you'll get the only contacts page in there as well. Secondly, when people move pages, no links are broken because the parent page is not in the url (there's a third one too - you don't end up with ridiculously long urls, but that's minor)
So, you can't create duplicate pages.
Thankfully Microsoft/UNIX/Linux don't have the same limited view for creating a file structure. Using the name as a key is probably the poorest implementation any beginning designer uses. So pretty much the users have to create their own unique keys when creating a new page. This sounds very optimal.
Or you could keep a simple recognisable human scheme that prevents duplicates. FWIW, it always uses a unique page ID, and there's nothing stopping you from using the ID all the time. The named page url is additional convenience to make life easier for the humans and help them not be confused by duplicate page names in the same space.
I am sorry.. you will never convince me that using the name of anything as a key is a good idea; it is limiting people who want to implement this differently for no good reason. Duplicates can be restricted by parent/child.. not root/child. I guess it is far better to have people adding leading and training spaces, punctuation, numbers, weird characters or extra text to a name until it accepts it and keep the root/child enforcement. If the only human readable system is the one provided, my mailman must get confused at all the duplicate house numbers in canada. (it does explain a lot actually).
Mmm, that's the point of my last comment - the name of the page is not the key. I completely agree with you that a name should not be a key, and it isn't in Confluence, the key is the page id. The name of the page is a human construct which, to use your "postman" analogy, works really well. I live at 75. There's loads of these across the UK. But it's fine because the rest of my address (i.e. my Confluence Space) makes it unique. In my case, <road name><town><uk> covers it. And the post office uses 75 + post code as the unique key. The simple fact remains that in any documentation space, it confuses humans when there are duplicate names for pages. If I have a space for "looking after system X", how does it help me to have four pages called "Configuration"? Even the argument "well, you have to look at the tree" makes me have to work to understand which one I'm looking for. Very very bad human design.
I think you just made my point "In my case, <road name><town><uk> covers it". As for confusing humans with duplicate names, it may well depend on the audience. Maybe your customers want this unique index (sorry I used the term key before ) and that is fine. I am not here to tell you or them how to run your/their business, especially when I have no idea what their business is. However others may not agree with this one strategy and we may want something else. We would prefer that Atlassian be more open to peoples requests. Maybe we are not the power user you are, but we pay for our licenses too. To everyone else who is sick and tired of this conversation and the email dump, I am sorry.. This is my last post on the subject.
No, I did not make your point, I showed that your point was invalid. You're saying "deliver this letter to 75, <town>" works, when <town> contains a lot of roads numbered with "75". Which 75 do you want to deliver to? In end-user terms, it doesn't work.
I do agree that it depends on the audience. But for such a small audience that duplicate names are implicitly understood, you would generally restrict them to their own "name space". And once you do that, do they not get confused when you use the same name to describe two different things?
One last thing I'd like to say here. Thank you for making me think about it again. It's really good to have views challenged, questioned and re-evaluated. I've not changed my mind - duplicating names *really* fail for our users, but it is great to think it through and get it confirmed.
I'd much prefer Atlassian get off their high horse and implement what many of their customers have been asking for for years. MANY people use Confluence for documentation and want the native feature to have multiple pages of the same name in the same space.
The VERY EASY workaround would be to change the stupid URL structure to use a UID. I don't care what the URL says. It could be http://mysite/display/SPACE/PAGE which does nothing for me. I don't care that it says SPACE and PAGE. It could just as easily be http://mysite/display/UIDSTRING
A VAST majority of users are not hard-typing URLs into their browser, so having this as a UID is just fine. It's what EVERY major site uses...you don't go to YouTube and type in youtube.com/watch?v=cat-fighting-a-monkey for good reason. There are too many similar videos.
If it impacts search, it's only because search was designed poorly, and a simple workaround should suffice, e.g. showing full breadcrumb trail on mouseover or many other solutions.
I perfectly agree with you. This has always been a big shortcoming of all wiki's, especially those that allow hierarchically structuring of their pages. Introducing hierarchy without releasing the constraint of unique page titles inside a space is a mistake. I assume there is a good intention behind this (keeping things simple). But as often this good intention generates the opposite: turning authoring hierarchically structured wiki spaces into a really complex and awkward task (considering all the suggested workarounds like prefixes, turning everything into a space that contains duplicate titles, making TOCs by hand etc.). And in the end even then you do not get what you really want. So, Attlassian, please please please: consider changing this. Either by not requiring space-uniqueness of page titles, or by providing optional page identifiers that will be used instead of the titles when specified. These identifiers could then be used for links etc. Solving this problem would open Confluence to whole new area of applications, an so turn it into a much better product.
I've been using Confluence for documentation for all of 12 minutes and I've already encountered this shortcoming. We're integrating our help wiki with Zendesk Help Center, so my plan was to make our "Help Center" space's page hierarchy exactly match the Category/Section hierarchy of our Zendesk Help Center. However, where Zendesk allows multiple sections to have the same name, Confluence apparently does not. Zendesk, for all of the shortcomings of their help center as a CMS, had the foresight to use a URL format like Michael describes above. In fact, it's kind of the best of both worlds, as it includes UID followed by article name i.e. /sections/UID-Aricle-Name. It looks like they are appending the article name with the section ID. Too bad Confluence isn't doing something similar. Ugh.
I also see the need for unique page names as a real problem.
The typical chapter structure in my technical documents looks like this:
But since I cannot use the same page name twice I am forced to create something like this:
I wouldn't mind about that if these page names where a purely technical setting. But they are not: My problem is that these page names are also the basis for the automatic table of content and for headings.
In other words:
If I create a PDF document the table of content will look like the one above and if I go through the chapters they have headlines likes "2.3.4 PTF Maximum Premium II - Functions - Converters - Intelligent Temperature Control Tool - Implementation - Automatic Setting".
Doesn't that look pretty strange?
And if so, what would be the way to get out of that?
Don't forget the effect of duplicate page titles on Confluence search ...
It could then be that the search results page shows a list of pages like that:
How will user find out, which contacts page is the one he's looking for? He probably has to click every page to find out.
Contacts of Department A, Contacts of Department B, ... is a much better search result here. So I can understand, that Confluence uses the page title as a unique key.
The Scroll Versions plugin allows for duplicate page titles and this has the following effects:
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot