Is Atlassian Marginalizing Confluence Power Users? Guest Post by Steve Goldberg
The following is a guest post by Steve Goldberg. Steve is a technical writer and Confluence administrator working for a software company in London, UK. You can follow him on Twitter at @bergeroflondon. This post is written in a personal capacity of the author and does not necessarily reflect the views of his employers.
Atlassian's 2013 Summit saw the company announce a swathe of new features and updates for their products, namely Questions (a Stack Exchange-style question-and-answer plugin for Confluence) and Service Desk (an end-user orientated UI/portal for JIRA), and was met with the usual fanfare by delegates.
However, as I watched the videos of the presentations I found myself experiencing a sense of apathy, and then annoyance, as I realized that while these are big, meaty additions to their core products, there wasn't really anything for the power user – the specialist end-users of Confluence and JIRA who typically administrate them for an organisation or spend their whole day creating documentation or managing issues. When it comes to Confluence I consider myself to be a power user (I'm a technical writer and Confluence administrator) and I want to air what I think a number of power users have been feeling for some time.
Before I do, though, I want to say that I am a big fan of Atlassian. I've attended their events (including the 2012 Summit at which I presented), used their software for three years, toured their offices, talked to every different kind of employee, and, in sum, consider their software and company philosophy to be amongst the best, if not the best. I work for a software company too, so it comes from the heart as much as the mind.
But after watching the Confluence State of the Union from the 2013 Summit I couldn't help but speak out. I was particularly irked when Bill Arconati talked about the trajectory of Confluence, namely how they were evolving it “from just a departmental wiki for technical teams to a collaboration platform for all teams” and “making it intuitive for business users while maintaining the power for power users”. I was puzzled simply because:
- I could see no evidence in the following 20 minutes that there were new features (or improvements or bug fixes) for power users; and
- I couldn't think of anything that had happened over the past year that was significant for power users.
Indeed, if you look back at the preceding 25 minutes of Matt Hodges' section, you struggle to find anything that helps power users either. Indeed, he repeats the message “we want everyone to get as much value out of Confluence as we do,” saying, for example, how we can set up a ‘knowledge base' in a matter of clicks and how Blueprints are best practice templates from Atlassian. But I reckon these sort of features are not useful for power users and, in fact, can have a detrimental effect on power users.
What is a Power User?
Put simply, a power user is someone who may do/be any number of the following:
- Administrate Confluence for their organization.
- Have higher privileges than other users within their organization by virtue of their technical skill, for example.
- Spend a lot of their time engaged in technical writing – producing, curating, and managing documentation.
These users are important in any organization because they are frequently the go-to person when someone is stuck or requires something done to Confluence. They're called on to remedy or report bugs, make changes, or even produce whole spaces of documentation. They're busy people simply because they're usually isn't a lot of them in an organization – their time is always at a premium and like any busy person they want to ensure that they have the right tools to do their job effectively and efficiently.
Atlassian should love power users. They're like mini-Atlassians running around their customer's organizations filling the gaps between Atlassian's documentation and support channel, ensuring things are running smoothly by problem-solving and ensuring people are getting the most out of the products. However, after talking to a number of power users about their gripes and doing some digging around online, I was able to create a list of things currently plaguing power users – some even for years.
#1 “There's a plugin for that”
Atlassian's ‘ecosystem' for third-party developers has truly exploded over the past year or two. There are so many plugins you can get to enhance your Confluence experience, and Atlassian is extremely keen to promote these. There are, I think, three main reasons for this:
- They plug the gaps in, or simply enhance, Confluence in ways that Atlassian can't or does not consider a priority or appropriate to all customers.
- They increase exposure of Confluence to new customers and third-party developers.
- They indirectly generate revenue for Atlassian via license fees, providing significant ROI for minimal work.
This is generally a good thing – Atlassian is but a single organization and can't tick all boxes for all customers, nor do they have the throughput to do all this work. Significantly, they don't want to bloat their core product: “here's Confluence in its nakedness but it's so simple to plug in new things”.
However, the problem with this for power users comes when there is a feature (or even what you could call a bug fix) available in a plugin that should really be in the core product. Furthermore, many plugins on their Marketplace are paid-for plugins whose price is dictated by the license you have for Confluence, which in turn is dictated by how many users you have. When you take into account the price for enabling a few power users within an organization with a 2000-user license to do their job better with these plugins, they quickly become prohibitively expensive.
By way of example, look at "Confluence search results should include content added to page via the {include} and {excerpt-include} macros". This was raised in March 2010 and the problem is simply that when content is generated in a page by excerpts (snippets of text or another page), includes (an entire page located external to the current page), or even macros (snippets of code that can access Confluence's APIs) then this content is not cached in the page it's rendered in and so does not show up in search results for that page. This is bad simply because it means end users do not find what they are looking for, or they are navigated to the wrong pages where they see information out of context.
To his credit, a third-party developer named Bob Swift came up with a solution to this problem with the [https://marketplace.atlassian.com/plugins/org.swift.confluence.cache](Cache Plugin) which allows you to wrap what you want in a container, which is then cached and therefore indexed by Confluence. This is great for Bob as he earns a paycheck, his customers can work around their problem (and it is a workaround), and Atlassian takes a cut of the profits.
Everyone wins, right? Well, for something so simple as having your dynamically-generated content indexed in search results, it seems weird that you have to pay for such a thing.
Dynamically generated content is so important to power users as it significantly cuts down on the amount of manual work we have to do and helps ensure the end-user is seeing relevant, up-to-date information. Atlassian even has a whole Confluence page on the benefits of re-using content in technical documentation but yet does not mention this major flaw when they mention the include feature.
Admittedly, in this example the Cache Plugin would only be $400 for a 2,000 user organization per year. But it wouldn't instantly solve the problem: the power users in the organisation would have to go through every page with dynamic content in it and manually update each page, moving the dynamic content into special containers, and then educate every user about when they should use it. This isn't intuitive or automatic. It's doing a lot of manual work so that it can be intuitive and automatic for the end user.
Furthermore, cost isn't the only prohibitive influence when it comes to plugins from third-parties. One person I spoke to said their company's policy is not to install any plugin that is not officially supported by Atlassian. This is a justifiable policy to have because a plugin you come to depend on could go out of support at any time and then you're forever locked into it and whatever version of Confluence it is built for.
It's also worth noting that Atlassian adopts a similar policy to third-party plugins with their OnDemand platform: if you let Atlassian host your instance of Confluence then there are even fewer plugins that you are allowed to install on your instance. You're pretty much stuck with naked Confluence unless you take the leap to hosting your own instance. This is deliberate so that their instances are easily upgradable (see George Barnett's presentation at the 2012 summit for more information). Put simply: mo' plugins = mo' problems.
I actually asked Atlassian directly about this caching issue and one of their lead product advocates was kind enough to write back. He gave the answer that I expected, namely that as a software company they can't cater for all of their customers and that in the past 12 months they had resolved over 3,200 customer votes for bug fixes / improvements / new features, which brings me onto my next point.
#2 Voting for Fixes
Again, I have to give credit to Atlassian for this. They make their issue tracker public to their customers so that we can directly see what they are working on, raise our own issues and suggestions, and then vote on the ones we want to see. I think this is great – I'm a big fan of openness and transparency. Sadly, though, there is a small issue with the democracy aspects, namely that numbers aren't everything and that it's easy to go with public opinion.
I spoke with a senior developer in my company about this issue, and he put what I'm about to say far more delicately than I'm about to, namely that there's a risk of ‘dumbing down' when it comes to your end users. It's easy as a software company to emphasize the issues that come up frequently for layman users than the ones raised by power users.
These types of users perhaps spend most of their time doing non-Confluence related tasks relating to their job role and use Confluence typically to consume content rather than produce it; when they do produce it they want things like:
- An easy-to-use and intuitive interface.
- Rich-text formatting.
- Easy to get started and easy to produce content.
And to be fair, as a power user I also want those things, but I want them less than layman of users. What I want are power tools – when I'm producing and curating content it doesn't matter if it takes time to get used to understanding how the tools work as long as I can work with great precision, efficiently and effectively every time. A difficult to use interface is fine as long as it's powerful: anyone can use a hammer, but I'd rather have a chisel if it's the best tool for the job.
So, saying you've satisfied 3,200 is somewhat of a false measurement of success if you're ignoring the expert users of your software: the people who are toiling in the trenches day-in-day-out trying to make their Confluence instance a better place. Yes, you may have saved 1,000 layman users 10 seconds per day with a fix, but what about a fix that saves 100 power users 10 minutes a day? On votes alone the former would win but if you do the math then the optimum amount of time saved was not realized. Yes it's now easier for the layman now to produce content, but what about those who have to manage it?
#3 Managing Content
Indeed, enabling layman users to produce content is something that any new administrator of Confluence struggles with. After all, you want your new wiki (or ‘collaboration platform') to be a success and so you want everyone using it – not just consuming but producing content. This presents inherent problems. As a technical writer, how can you get users who are not professional writers to produce high quality content? How can you curate what is produced so that content is linked and grouped together effectively? How can you ensure that everyone is quickly finding the information they need?
If you've not read Maca's series on the pain of managing content in Confluence on the Kikamaca blog then I highly recommend it. He's written in far more detail than I am able to in this post, but here are the four links you should look at (indeed, they caused such a stir that Atlassian decided to get in touch with him):
- (The pain of) managing content in Confluence
- Managing content in Confluence: Taxonomy
- Managing content in Confluence: Archiving and retention policies
- Managing content in Confluence: Statistics and reporting
Needless to say, I administrate a Confluence instance which is over three years old, with over 200 spaces and nearly 14,000 items of ‘current' content (including attachments). And it's hard. Really hard.
One power tool that we got in Confluence 4.3 (September 2012) was the ability to archive spaces. Put simply, this is a flag you can set on an entire space to exclude it from search indexes, effectively allowing you to deprecate content – this means people can still link and access it but it's not easy to find, thus letting you maintain access to it without it cluttering up your instance.
However, there is a significant issue with it: it only applies to an entire space. In other words, if I have a number of pages that are no longer relevant to my company's current product, I have to move them to a space which is flagged as archived (which actually requires some manual work, see CONF-31352). So I either have one great big space full of deprecated documentation, or I create new spaces for each space that this documentation is from. Why can't I just deprecate a page? What about a job that automatically archives content that hasn't been edited in more than a year? What about other sophisticated archiving options? Oh yes, if you that functionality then there's a plugin for that ($2,400 for 2,000 users per year).
What about labels? Labels could be SO powerful. Don't let me understate that. They could revolutionize managing content if they were properly implemented (read Maca's post on taxonomy for a full-scale epic). Put simply, if we manage content in spaces which act like containers for documentation related to a particular product, project, or department, then labels enable the power user who's keen to curate effectively to traverse these boundaries effortlessly. Oh, you have ten different pages across ten different spaces that relate to each other? Label them all with the same tag and in under a minute they're all related to each other. Want to show them in a list? Use the Content By Label macro. Great!
But layman users don't understand labels. They're not immediately obvious and are frequently misunderstood (I'm still asked if they can be used to artificially inflate a page's ranking in search engine results). They haven't received the same interface and intuition improvements that other features have in recent years.
Furthermore, the power user wants things like label inheritance, label groups, label synonyms, label merging, label descriptions. The only noteworthy change to labels in recent updates is the ability to label attachments. Personally, we haven't made use of this at our organization, but I can see how some organizations with a lot of non-Confluence based documents could find this useful.
Anyway, like I said, read those blog posts. And Atlassian: re-read those blog posts – they're important.
So what is Atlassian doing for Power Users?
I want to try and be fair to Atlassian so I asked what they were doing for power users. I've been told that there is a development team that focuses on improving the life of administrators and power users of Confluence, which, if true, is good news.
Second, in my email from Atlassian about the Cache plugin they were kind enough to also provide a list of things they have done for power users over various recent versions, namely:
- (5.3) Ability to change usernames (CONF-4063).
- (5.0) Delete page versions (CONF-996).
- (5.0) PDF export blogs (CONF-5599).
- (5.0) View page restriction of a child page will be lost once the parent page is removed.
- (4.3) Delete attachment versions (CONF-3079).
- (4.2 and 4.3) Excerpt include to work across spaces (CONF-5752)
- (4.2) Fix broken images in word export.
- (4.2) Label attachments (CONF-3963).
- (4.1) Any character in page titles (CONF-984)
- (4.1) Global custom PDF stylesheet (CONF-16210).
- Various Editor Improvements like - Sortable tables, custom background colours, create WYSIWYG templates, multiple drafts per space, support non-standard link protocols.
So you may say “quit your complaining, they're working as hard as they can!” – and you may have a point. But the point of this post is that there are still fundamental issues that power users experience every day that go unchecked. Some of them may require serious changes to the underlying change to the architecture of Confluence. The problem that I – and many power users have – with the above list is that each item is just the tip of the iceberg.
Yes, it's great that I can change usernames, but what about the bulk management of users similar to what the power users in JIRA get?
Yes, I can now delete historical versions of pages and attachments, but that solves an occasional annoyance – what about proper archiving and version control?
Yes, Word and PDF exports are now a bit better but, honestly, they're still really quite bad – my organization won't use them because they simply just don't look true to rendered web version.
I like that I can now include excerpts across spaces, but what about the caching problem?
The answer from Atlassian on all these sorts of issues is probably “there are plugins that fix this problem,” but just think about the dependencies and costs this is introducing. That's a lot of money and a lot of risk.
Conclusion
To reiterate, I think it's great that Atlassian is introducing many new features to Confluence, although I'm somewhat wary of their rebranding of it from a ‘wiki' to a ‘collaboration platform'. However, I think they've been too focused on this goal at the expense of their expert customers who expect more than just bells-and-whistles in future releases.
My main point is that Atlassian is not empowering their power users. We are like satellite Atlassian evangelists spreading the good word of Atlassian in our organizations. We solve problems for end users without having to get Atlassian involved. We practically live and breathe Confluence as we not only stare it in the face every day but also frequently spend time rooting around in its guts, taking things out and putting new things in. But yet, so many of us feel alienated. Atlassian: help us help our (your) end users by giving us the tools that we need.
The things I've listed here are really just the tip of the iceberg – I didn't even mention the frustration they caused power users by removing the ability to edit a page's wiki markup, or the headache that is their decision to use space-level whitelisting for access permissions, or how their recent announcement about JIRA Service Desk elicited nothing but negative reactions in the comment thread about its pricing (which they've now removed). I mean I could keep going. Luckily I don't have to: it's all available publicly on their JIRA.
If you want to know about some of the longest-standing issues in Confluence, there are two lists you can look at. One is curated by Atlassian, the other is provided simply by virtue of some querying on their JIRA instance (by the way, if you want to run queries on Confluence, you need a plugin for that).
Yes, the latter is based on votes but notice the context of a lot of these issues: they're things that make the lives of administrators and power users a lot easier. Also, look at the age of some of them. Many go back as far as 2004 and 2005, which means these are features that people have wanted for nearly 10 years. I've only used their software for three years, I can't imagine using it for 10 years and not having these issues resolved. Lucky for Atlassian, then, that there's currently nothing that truly compares to Confluence.