I am creating an space on confluence that will act as a internal central repository for product knowledge in the company.
The problem I have come across is that I can not create a page with the same name in one space.
This is how we want to structure the space:
Any ideas on how i can set this up in one space.
It seems the directory tree within a space is not being taken into consideration when trying to create pages with the same name within 1 space. I will look if there is an improvement request pending for this, and if there isn't, I will create one.
In order to work around this, I would suggest you keep all information relevant to 1 product on the same page, use anchors on the headers of the sections you previously wanted to put on separate pages, and put an index at the top of the product page to navigate through them. This might even be easier to set up as a template whenever you want to add new products to the space, but I guess that is a matter of opinion :)
You may be correct in that it's technically not broken and created by design. However, this feature provides a very poor user experience. It would be similar to a car manufacturer adding the steering wheel to the back of the driver's seat. Although they may think it's a good idea, it doesn't add any value to the consumer footing the bill.
No, it's the other way around in real life. Duplicated names break searching for the users, and this actually provides a far better experience for the users. What you're asking for, in your analogy, is for everyone in the car to have a steering wheel.
I respectfully disagree that duplicate names break search functionality. This is a feature that exists in many similar wiki applications with adequate search functionality. It's software. It's just a matter of how much and how long – how much is it going to cost and how long is going to take to build. A simple solution would be to append an arbitrary numeric value to the page name in the URL string.
Unfortunately, that's not quite right - duplicates always break search because you can't get a definitive answer in one go. Sticking a random number on the end is just making the page non-unique by botching it and making it ugly for the user.
Consider a simple case - 400 software products, each with a space dedicated to looking after them. Some pages are standardised and common, but users are free to add more if they want. So, one standard page that exists for each space is "run book". Search instantly fails if you allow multiple names in a space because "<product> run book" could not be unique. Better, you also know that confluence/browse/product/run+book is always going to get you the right page, so you can dodge the search as well.
I've yet to see a wiki search that works with duplicate names. The fact is, they do not. You do get there eventually, but you shouldn't have to. You used the term "adequate" and that's right. Not allowing duplicate names improves an adequate system by a number of points (I have a number of other issues with Confluence search, but non-duplicates really helps). I've actually seen places select Confluence because it doesn't break searching.
This approach actively encourages people to think about their page names as well, rather than breaking the searches.
I think my point has been missed and that’s probably because I did a poor job explaining myself. The issue covered in this thread appears to be a symptom of the root cause and not the actual root cause. That’s how I stumbled upon this thread. If you analyze the original issue in this thread, it could be avoided if Confluence provided support for nested spaces, something that most applications (including many wikis) do support.
Based on the votes, there are at least 245 other users that have had similar thoughts. https://jira.atlassian.com/browse/CONF-1095 It’s also worth noting the “top25” tag, half of which have been resolved, so maybe there is light at the end of the tunnel.
Obviously, I cannot speak for all users, but my thought is that most users that experience this problem (like the ones on this thread and in CONF-1095) are less concerned about how pretty the URL looks and more concerned about maintaining organizational hierarchy within the application. A flat structure is not sufficient. Nested spaces that permit duplicate page names across them (but not within them) would solve the crux of the issue.
Nic, I do not think the argument "duplicate names break the search" holds up given that you'd merely need to add the significant part of the page hierarchy to the result. I.e. when searching for "Pricelist" in the original example, the search could return:
Just take a look at how your proposed solutions end up working out. If Richard were to create individual spaces for each product and did the same search, what would the result look like? Exactly the same as my proposed solution, merely using the space name. You chose to add a hirarchy, yet you refuse to acknowledge the fact that the location of a document in a hierarchy is contextual information that can be used just like all other information when doing a search and displaying the results.
Adding this to a good search engine cannot be impossible and would permit thousands of users to do as they please whenever they have to. Neal Riley from your Amsterdam office suggested that every team should have the those tools available to them, which they prefer to use. Permitting the use of duplicate names would not degrade the experience for those who don't want to use them. Anyone who doesn't like this feature, would not end up being forced to use it. Instead, teams requiring a different documentation layout than you would finally be able to use Confluence properly.
It doesn't break it, because it already doesn't break it. How is having duplicate page names in one space different than having duplicate page names in different spaces when searching? Your search algorithms treat all spaces the same, thus there is no difference. If I have two spaces A and B and each of them has a page named "Home", searching for "Home" will return both pages. The result will have the spaces' names in small grey text underneath the page title to indicate the pages' locations. This works just fine as is. Adding duplicate page names would not change this behaviour other than adding parent pages in addition to/instead of the space. Claiming this would add an unmanagable amount of information to page results is not a valid argument either, because as is people must resort to adding the page hierarchy right in the pages' names (i.e. "parent title - page title".
At this point you're not arguing against duplicate page names in spaces, you're arguing against duplicate page names across all spaces. If my search criteria is the page's name, duplicate page names, regardless of scope, breaks the search.
But this isn't a problem of duplicate page names. It is either a problem of how you decide to organize your content or your searching habits. Currently, you resolve the problem by specifying the space you're looking for, thus eliminating the duplicate page name problem across spaces. If unspecific searches not magically returning the result you want is an issue, no searching algorithm will ever be able to satisfy you. You must adjust your search to the way your content is organized, noone will argue about this.
I'm not sure you're understanding the points made before, but it's clear we have differing opinions. Mine is that you're wrong because duplicate page names breaks search and fast use of the system for the main reason I use it. You think I'm wrong because you want the (in my opinion broken) search behaviour.
I do understand your points, but I do not accept your conclusion.
You want some unique identifier by which you can find content. You have chosen the page title to be your personal unique identifier. Therefor, if the system supported non-unique page names, your unique identifier would break.
But your prefered method of searching content must not define how other people organize theirs. If you want to use unique page names, so be it. If the content you and your team create can be organized such that your method works, fine. But literally thousands of users do not want to use your method of organizing and searching for content, which is why you shouldn't create an artificial restriction.
Enabling the use of duplicate page names doesn't break any search algorithms. It merely changes the output if duplicate pages exist in one page. Therefor a minor change in how the results are being presented might be necessary. Adding this feature does not reduce usability for anyone who doesn't want to use it, but it adds loads of usability for those who need it.
So is there an alternate solution that makes sense? We have a similar situation and we ended with page names like:
Its really weird when others see it the first time, but we really have no choice at this point, given than confluence has technical challenges with implementing a workable solution.
Nic, if I have several pages called Pricelist <1, 2, 3, 4, etc.> and I search for Pricelist, is my search broken because I get multiple results? o.O
Your definition of "broken" is what's broken here and you're just plain wrong. Christopher did a great job trying to explain it to you.
Yes. It is broken. For the reasons already given that you have not read.
Christopher's answer was a good attempt, but still failed to answer the simple question of how a search for one thing returning many results is a good thing. Because it is not.
@Nic Brough - Dont try to justify a technical concept by neglecting the user behvaiour for structuring content. It was possible pre 2013 as I remember correctly (the last time Ive used confluence). Now, in 2017 , Im using confluence again for another company and Im observing this exact same problem. Which is definetly, also by reconsidering the amount of users having the same issue with this, an UX/Usability problem and not just justifiable with unique identifiers and search result opportunities. It is just annoying!
p.s. : everyone can have his opinion on a product/feature ! And the prefix solution is not very nice.
You can't. The names of pages within a space must be unique.
If you weren't using OnDemand, I think there's a plugin that can help, although it doesn't quite solve the problem completely. It slips my mind what it is though, sorry.
Fantastic. Seems odd that each page has its own unique pageid in the url but it wont allow you to have duplicate names, even though they aren't referenced in the url.
I feel a feature requirement in this.
thanks for the answer, even though it wasn't what I wanted to hear
My suggestion would be to allow duplicate pages and to tweak the way search returns results.
Now it's easy for me to throw out a recommendation there... I didn't engineer the product. If there's a deeper philosophy that would help us uninitiated understand the way it is the way it is, point us to it! I wanna read the Atlassian manifesto.
While I'm at it - I'd love to see some really nice examples of a super well manicured Confluence pages. Maybe even industry specific ideas... think SquareSpace for Confluence.
Below is my potentially Atlassian philosophy busting search idea that would allow for duplicate pages.
It definitely does it but is very expensive addon if you only use it for that. It creates permalink to solve the problem. Bad thing is that the link name will never change and moving a page to different space, or renaming a page does not affect the link name anymore. That can be very confusing when browsing through links in emails for exmaple
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
...there's anything I've learnt from working, it's that people are lazy! No offense to anyone reading this, but it's true and we can all admit it. The easier you make something for someone, the more...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs