UPDATE: July 2013

Since this post was published back in November 2011 there have been a number of improvements to working with wiki markup in the new editor in addition to two plugins released on the Atlassian Marketplace that provide source and wiki markup editing capabilities in Confluence 4 and above. For a quick reference guide see What’s Changed for Wiki Markup Users.

Insert wiki markup into the editor

You can insert wiki markup into the new editor using the Insert Wiki Markup dialog accessible via the Insert menu or using the keyboard shortcut Control/Command + Shift + D.

insert-wiki-markup

Type wiki markup into the editor

Confluence’s autocomplete and autoformat capabilities will convert the wiki markup as you type, including formatting, macros, and links. Watch the short video below for a demo:

Edit wiki markup with the free Wiki Plugin

Bob Swift’s Wiki Plugin for Confluence 4.0 and above allows entry and editing of wiki markup inside a wiki-markup macro in Confluence pages.

confluence-wiki-plugin

Edit the new source with the Source Editor add-on

Compatible with Confluence 4.1.5 and above, the Confluence Source Editor is a free plugin, developed and supported by Atlassian, that allows users to view and edit the underlying storage format for a Confluence page.

Original Post: November, 2011

Confluence 4.0 has been available for over two months now and we’ve been amazed at the uptake by new customers and the number of existing customers who have upgraded. We’ve gotten a number of questions from some existing customers who were surprised by Atlassian’s decision to remove Wiki Markup in Confluence 4.0, so we wanted to take a brief moment to share with you some of the reasons.

Collaboration Should Include Everyone

Our perspective is that product development, and collaboration specifically, needs to include EVERYONE in the organization. Technical teams don’t live in silos – they frequently work with other cross-functional teams, like sales and marketing. Ever since we first released Confluence, way back in 2004, many of you gave us great feedback on the shortcomings of the now legacy Rich Text and Wiki Markup Editors. You told us the Rich Text Editor (RTE) was too basic, slow and unreliable, and that the Wiki Markup Editor had too high a learning curve for most users. Ultimately, we learned that the dual editing experience was the number one hindrance to adoption. Naturally, we challenged ourselves to solve this problem.

Getting New Features in Your Hands, Faster

The dual Rich Text and Wiki Markup editing modes also presented a number of technical limitations that slowed our ability to deliver new features. Wiki markup as a storage format hindered our ability to add new features, like merge table cells, that customers had been demanding. This is because Wiki Markup is a very limited subset of XHTML and because any new editor feature had to be built twice…once in the RTE and once in the Wiki Markup Editor. We also had a lot of bugs when toggling between the two edit modes. We knew for some time that we’d need to unify the dual-RTE and Wiki Markup Editors into one simple-yet-capable editing experience and store Confluence content in a more extensible storage format – i.e. XHTML. After much debate, countless customer interviews, and many months of R&D it was clear that moving away from Wiki Markup was the best way to improve the experience of editing content in Confluence. Needless to say this was a massive project in development at Atlassian over a period of years.

But Why Now?

The idea of moving away from Wiki Markup was first seriously raised in 2006, after the release of Confluence 2.0 with the first version of our Rich Text Editor. The reason we waited five years to implement it was because the last thing we want to do is stick people with a broken editor. Before Confluence 4.0, users could always switch from the Rich Text Editor to the Wiki Markup Editor if you found it not doing quite what you expected it to. Before we could we remove that fallback, we wanted to make sure we weren’t painting users into a corner.

We set ourselves the challenge that we wouldn’t make the move unless we could come up with a solution that the hard-core Wiki Markup users in our own company – myself included – were happy with. Confluence 4.0 shipped with a completely made-over Rich Text Editor that built on all the features we’d added in the past few years – like Autocomplete, Drag-and-Drop, and the Macro Browser – and added a whole bunch of short-cuts and new features – including Autoformatting and Copy and Paste Images. It’s faster, more reliable, and more fully-featured than before, and we think it meets that original challenge and then goes further.

In December 2010, the entire Confluence Development Team moved over to using Confluence 4.0 milestones as their day-to-day collaboration space. A couple of weeks after, our Technical Writing Team moved over as well, before shifting the entire company – 400 users of all skill levels – a few months later. After 6 months of the entire company using the new editor and more than a dozen milestones, each adding improvements and tweaks based on over 1,200 pieces of user feedback – from both Atlassian’s and customers – we felt Confluence 4.0 was ready for release.

We Know it’s Not Perfect, Yet

Despite all the extensive dogfooding and 3-month customer beta program, we knew there would be bugs and we greatly appreciate the early adopters that have taken the time to file/vote/comment on those specific issues. This helps us IMMENSELY in being able to prioritize and respond to problems. In fact we are already addressing a number of the issues that have been raised. For example, we know that Find and Replace is an issue for our customers and we will be shipping a solution in our next major release, Confluence 4.1. This is just one example of many issues we have either already addressed or will address in a future release.

We’ll be the first to tell you that the new editor is not 100% perfect and still has bugs that need to be fixed, but we think it’s light years ahead of the previous editing experience in terms of intuitiveness, efficiency, and reliability. To the extent you and your users encounter editor bugs and issues, please keep reporting them. We’re 110% committed to making the new editor work and appreciate all your support in helping us make it the best editing experience possible for all users.

Why Don’t We Allow Users to Edit the Source of a Page?

A lot of you have asked us this and the the main reason we don’t to allow end-user editing of the raw markup is that the editor markup is not really XHTML. It is an XML dialect that looks like XHTML so that it can be edited in a browser, but that embeds a lot of important semantic information so we can turn it back into the storage format when you hit save.

We’re Still Listening

We know the new editor is not without bugs. If you do encounter a bug or find that there are things you can’t do in the new editor, we’d love to hear about it. Here are some ways you can provide feedback:

1. Suggesting Improvements and Feature Requests

We’re collating feedback on the new editor introduced in Confluence 4.0 on a single page in our documentation – Confluence 4.0 Editor – Customer Feedback. If you have feedback on a bug, a task you now find harder or are unable to complete in the new editor then please leave a comment on this page.

2. Reporting Bugs

Atlassian collects and tracks customer feature requests and bug reports in our public instance of our issue tracker – jira.atlassian.com. There, you can request new product features or report bugs, as well as see all of the other feature requests and bug reports that customers have raised. If you agree with another point that’s been raised, you can vote on it to help it along. The Confluence Product Management Team read and maintain the issues in JIRA, so this is the best place to lodge your opinion about the product.

3. Asking “How do I…” Questions

If you have a question like, “How do I do (a given task) with Confluence now?”, then Atlassian Answers is the best place to ask it. There, our vibrant community of power users and developers quickly answer questions of all kinds and provide information on advanced tips and tricks.

4. Suggesting Improvements to Our Documentation

The Atlassian Documentation Team creates and maintains our documentation. If you have specific feedback on the content of a Confluence documentation page, you can get in touch with our Technical Writers by sending email to confluence-docs@atlassian.com – they’re listening, and always interested in improving the content of our documentation.

5. Planning an Upgrade?

Be sure to check out the set of resources on our Planning for Confluence 4.0 page, which includes our Confluence 4.0 Editor FAQ and guide on What’s Changed for Wiki Markup Users.

What’s Next for Confluence?

Our next major release – Confluence 4.1 – will be available in the first half of December. On top of some killer new features, including Find and Replace, which many of you have asked for, Confluence 4.1 will deliver a number of bug fixes and improvements to editor reliability.

We’ve made these editor changes in response to feedback from a majority of our customers and have been transparent and inclusive with our customers throughout the entire release process. We do find that a single Rich Text Editor, combined with all the powerful new features we’ve added in 4.0, benefits the vast majority of our users. Thank you for being a Confluence customer.

- The Confluence Team