Rick: I agree. Luckily, most word processors are "growing up" here. Word processors like Word and Open Office are starting to pick up on this - for example, it automatically converts "*" followed by an item into a list. It even does a somewhat decent job of automatically correcting my typos as I go. Confluence 4 takes this concept and applies it to wiki. You focus on putting your content in. Just type. Let it focus on how to store and to do a decent job at guessing how you would like to see the content presented. But if you do need to access features that are truly not ideal for "just type", the GUI is available with context dependent popups and a tool bar. And for the people extremely familiar with wiki, the wiki characters like { trigger particular "do what I mean" behaviours.

I agree with MarkZ. Understand what is being provided before drawing conclusions. Then, if its still insufficient - complain loudly with real use cases. That way Confluence 4 has a better chance of being a success.

(Personally, I'm trying to find time to do what I say above and install Confluence 4 in a test area using our production data and assign different types of users to play with it and provide feedback...)

Before making any additional comments here, everyone should first read the details around the editor change at http://confluence.atlassian.com/display/DOC/Confluence+4.0+Editor+FAQ. (I'm surprised this hasn't been linked to here, yet.)

Early on, I was also fearful of the where this was going. However, especially after watching the demo, and reviewing the details in the FAQ linked above, I am completely sold on this, and am eagerly awaiting the official release of Confluence 4.

And then, I downloaded the Confluence 4 early access version, did a test migration into it - and was only more impressed. The fact that everything is now stored as XHTML is very cool. While the Wiki markup used in Confluence is quite nice, it isn't a standard. The only wiki "standard" I've seen is Creole, and it's not even used by Confluence. XHTML is an accepted standard, and will only allow for increased interactions between Confluence and other tools. XHTML is also MUCH easier to parse - even without the many available libraries available for parsing XML.

I think the main benefit to Confluence's wiki syntax wasn't for as a storage mechanism - but for speed of user creation. As shown in the video, the Confluence 4 editor provides the best of both.

It's not a preference for wiki text per de, it's avoidance of the significant clicks, mouse drags, etc with a wysiwyg editor versus just typing. It's easier and faster to input lots if information when you aren't interrupted and frustrated by the UI.

If the new editor avoids all the button clicking and dialogs and other distracting and momentum reducing aspects of the old wysiwyg I'm all for it but I've yet to see one do that. And I have seen the reduced productivity when that thing is the only option...

Sent from my iPhone

To contrast Rick's opinion - I have to say that although wiki text is powerful on the surface, it easily becomes cow dung for anything complex. It has just enough syntax to make it appear flexibility, but not enough to actually achieve true structure. For example, the inability to nest wiki macros is a huge problem. The arcane and not quite consistent parsing rules is terrible to explain. Table rendering for anything complex becomes really disgusting unless using a set of macros on top that pretend that structure actually exists. I think "power users" are not quite the power users they think they are. It's just what they have become accustomed to and it is a workflow that they personally feel comfortable and efficient in - ignoring the rest of the users who are unable to spend as much time investing in learning the subtleties of how to properly escape literals. There is a particularly ugly set of pages that we are reviewing right now and we've basically determined the pages are unmaintainable except for the author, and we're not convinced the author isn't spending more time quoting literals than providing content. The result is impressive, but the implementation is ridiculous.

This said, I also find myself fearful of "what's next". Once the wiki revolution is over, and wiki's "grow up" to become true structured document repositories, I'm sure life will be great. Will Confluence 4 be the leader of this successful revolution? Or will it be one of the inevitable false starts that are likely to occur in any revolution?

Having attended one of the demos (Atlassian Summit 2011) - I'm optimistic that it will be the former.

Unfortunately, bad ideas sometimes only die with bad people. There will be people who refuse to accept change, no matter how positive it is. Raw wiki is an idea that must die one day.

Probably others will be insulted by what I say above, but I feel it is necessary to balance the opinion of others.

Hi Rick,

I'd recommend watching the in-depth demo of the new editor coming in Confluence 4. I'm what you consider an "advanced power" user of Confluence and I'm 100% convinced that the new editor is the way forward. We've been using the new editor internally for almost 1 year now and I can honestly say I cannot switch back to the current editor. You really have to give it a try.

Demo starts at 16:15:

http://www.youtube.com/watch?v=gVa_H3z_BTg

This is very disappointing that Atlassian is joining the rest of the
crowd and making Wikis less usable for moderate to advanced users by
removing Wiki code.

Hi Marcus,
There is no further update to this issue other than the one stated above. We are still working on the new unified editor for Confluence 4. Will update this issue once we have made progress. We hope to have something by mid this year.
Sherif

Hey guys, I just wanted to comment to the person who responded to my initial bug, Niklas.

Just so nothing is unclear:

• You remarked that I should stop switching between wiki view and wysiwyg. I had't switched between the wiki interface and the wysiwyg, all of my corrupted bulleted lists and indents have been coming from typing them in directly into the wysiwyg. From direct interaction with the wysiwyg interface and the 'at-save-time' parser. Which has been causing us to lose data and corrupt entire documents in the wiki.
  I've done this several times, and the corruption after editing/saving/editing/saving/editing/saving just makes things worse. In fact, to the point that entire sections of the document are removed by the 'at-save-time' parser.

• Also, is there an estimated time on when the parsing engine will be fixed?

Thank you.

Amazing tool by the way.

Marcus

We are looking at supporting HTML5 for file uploads. If we did this, we would want to ensure that we support all the supported browsers for this feature (regardless of what mechanism they would use - HTML5 or Gears). We don't have this planned for the new editor at the moment but it is in our roadmap.

Hi Al,
If you watch the 2010 Summit video you will see that we are working on all these issues: http://www.atlassian.com/summit/2010/presentations/general-sessions/atlassian-summit-2010-keynote-1.jsp in the new Confluecne Editor.

The Confluence team is actively working on Confluence 4.0. This new version will remove the round-tripping issues. We current don't have an estimated date for this but will update this issue as we make progress.

We appreciate your patience with this as it involves major re-architecture of the new editor.

Sherif

I just got an email summarizing the 2010 Summit, and it mentions several cool improvements to the RTE for 3.2. Yet, the issue(s) described here are apparently still unresolved. These issues are fundamental to gaining user acceptance of the RTE. The new improvements are nice, but irrelevant given the RTE's inability to do key basic functions reliably. Does Atlassian management realize thay are adding embellishments to something that's still fundamentally broken?

Can we have an update on when this will be fixed?

This page is becoming the shame of Atlassian. Every new customer should see this evaluating their products.
I have no word to describe my disappointment on atlassian behaviour.
Complaints started in 2007 and now we are approaching 2011.

In 2007 we had the first dual core pentium processors... In this time frame we usually see building highways, underground lines...
But here we are speaking of software bugs, more than 3 years and still no schedule.

I am having a similar issue to this with version 3.1.1. When I create a link either via manual entry or the insert link button, the link doesn't work. If I switch to RTM, preview or save the page the link just the text with a pink background. I've noticed that it only occurs in IE 6 & 8 (7 is not being tested as we only use those two versions) If the action is done in Firefox is works fine. I also noticed that the link gets changed in that [test|^filename.pdf] or [test|testpage] gets changed to [test\|^filename.pdf|] or [test\|testpage|]. Any way this can be resolved?

we are rolling confluence out as a replacement for our internal Intranet. However, this bug has cropped up numerous times and is frustrating our users as when they try to edit pages they get messed up with the additional or sometimes removal of code. this prompts calls to IS to fix their pages. Please make this a priority issue to get corrected. we are running 2.10.2.

Hi All,
We are recruiting existing Confluence customers to provide feedback to Product Management now on the Rich Text Editor; we are looking at improving the RTE and would like to be able to get feedback now on your top editing concerns and issues. If you're interested in providing feedback, please join by signing up here:
http://www.surveymk.com//s.aspx?sm=ZnUnhSSTWWAgM0Egv4pgZA_3d_3d

Thanks,
Audra

Totally agreed with everyone here. A user just reported "frustration" because of CONF-5896 - unwanted backslashes appeared in image markup. We have recently upgraded to Confluence 2.10.2 but the problem was in earlier version too.

Hi All,

Thank you for raising your concerns over this issue. I know the round-trip bugs are extremely frustrating. We have been working on them recently. Several were addressed in the 2.10 release, another CONF-14018 will be done in 2.10.2 (due out in three weeks). So if you are not on 2.10 yet you may want to upgrade.

I am currently working on this group of bugs. Hopefully I will get through the most important ones by the time we finish Confluence 3, which should ship before the middle of the year. Unfortunately I will probably not be able to fix them all by then, so a definite fix date for the whole group of them can not be given yet.

Cheers,
Don

I agree 100% with Davide. I just went rounds with my local support team. The response from our local support is, its a known problem and Atlassian knows about it. They "talk" about re-writing the RTE from the ground up for version 3.0 which has no ETA.

I no longer recommend that people use this wiki, because they just get upset with me when they learn the RTE is buggy and corrupts their output. The response is usually something to the effect of "You knew it didn't work, and you still suggested I use it."

This is core functionality that is broken. Who cares about all the other little enhancement, when the core piece of the product is so buggy.

Yuuuuuuu Huuuuuuuuuuu
Is there anybody out there?

I'll copy part of my commnet at the Atlassian support:

Matt Ryall of Atlassian more than one years ago stated: "This problem will be the focus of a major release in the near future."

The markup umbrella issue was opened two years and four months ago and the task it's still unassigned.

Not to be polemic but I see new functionalities and features added at every release but Atlassian forget to consolidate the product solving nasty and ancients bugs like this.

Believe me that this is one of the main complaints about Confluence (along with PDF export functionality) from our users.
In the last months the wiki adoption in my department collapsed mainly for this reason.
Managers and paperworks people just uses RTE and when they ned to insert a simple macro, they are forced to switch to markup and going back to RTE everything breaks.The first time they will call a colleague for support believing they made something wrong but when they discover that the tools has a bug... they simply will not use it again. Only the guys from sw dept. loose their time fixing pages (professional bias)

We strongly suggest to our users to keep things simple but really it breaks for simple pages too.

So, it is possible to have fixing date/release for this bug?

Any ETA on getting this fixed. This is a CORE issue. Our company's officers promote and push the wiki, but they aren't really aware that its fundamentally broken like this. These defects make this wiki tool's WYSWIG editor useless.

Ah, another "critical" bug that's now hit its second anniversary. Any thoughts on fixing any of this soon?

Found and linked an existing bug in JIRA which describes the "rich-text editor adds CR's before/after macros" problem that I'm experiencing (and which I commented on within this bug).

Just wanted to add a comment to describe a problem I'm seeing on our installation of Confluence. I originally reported the problem under CSP-19298.

I believe that the fix for the present umbrella markup issue will likely incorporate a fix to my problem, but because I do not see my problem specifically described in any of the issues linked in this issue, I'm documenting it here.

Approximately 95% of our wiki content for our company uses the expand user macro embedded within tables. An example of something that might appear in our pages would be:

|| Description || Image ||
| Make Tea
{expand}
| Place tea bag in tea pot | !SPACE:Space Attachments Directory^teapot.jpg|thumbnail! |
| Pour boiling water into pot | !SPACE:Space Attachments Directory^water.jpg|thumbnail! |
{expand} | !SPACE:Space Attachments Directory^teacup_and_saucer.jpg|thumbnail! |

As with Andy Brook's comment above, as soon as this page is even opened with the Rich Text Editor (even if nothing is changed), the page breaks because the rich text editor inserts <CR>'s before each user macro. Because our {expand} macros are embedded within tables, adding a <CR> significantly corrupts our formatting to the point of the page being hard to follow.

This is what even just viewing the page (forget about actually editing the content) within the Rich Text Editor does to the above:

|| Description || Image ||
| Make Tea

{expand}
| Place tea bag in tea pot | !SPACE:Space Attachments Directory^teapot.jpg|thumbnail! |
| Pour boiling water into pot | !SPACE:Space Attachments Directory^water.jpg|thumbnail! |
{expand} | !SPACE:Space Attachments Directory^teacup_and_saucer.jpg|thumbnail! |

Actually attempting to edit the page corrupts the page content (or otherwise makes the resulting Wiki Markup less and less consistent with the original) even more.

The many Rich Text <--> Wiki Markup issues already described above, but particularly the issue reported in this comment, are preventing our company from full-scale, gung-ho adoption of Confluence and purchasing of a commercial license because we will end up with Wiki content that is highly difficult, if not impossible, to update by our employee base.

Do you have an estimated timeframe or release that this will be fixed in?

Not being able to copy and paste links is one of the most frustrating issues I have with Confluence. Going into wiki markup is a bandaid fix at best, especially when a lot of the links I use word wrap on a full screen.

When switching between 'Wiki Markup' and 'Rich Text:

_For a full list of EUROPE Meeting Minutes_ [{color:blue}*Click here*{color}|TEST:ABC_EUROPE_Meetings] 

is changes to

_For a full list of EUROPE Meeting Minutes_ [Click here|TEST:ABC_EUROPE_Meetings">Click here]  

As for cross-browser support - I highly doubt it's really the important point right now.
Cross-browser support should be considered after at lest having one browser support.
As currently Confluence WYSIWYG is best described by "zero-browser support" - so we had to prohibit rich text editor in our corporate wiki.

One mainstream browser (either IE or FF) support is perfectly enough. I think it doesn't really matters whether it would be IE6, IE7 or FF - the important point is that WYSIWYG should be 99,999% bug-free and reliable.

I don't know much about the mechanics going on behind the scenes, but just to float an idea - are there any possible stop-gap measures that could be implemented while you guys are working on your master plan? One idea - and I'm not sure if this is possible or practical - could be to take 'snapshots' whenever a user switches between markup & RTE, and merge changes rather than converting and re-converting the whole lot.

A simple example to try explain a bit better... say a user creates a table with the following markup:

|| A || B || C ||
| d | e | f |
| g | h | i | 

Then they switch the RTE - a snapshot is taken of the markup at this point. The RTE would show an HTML conversion of the markup, but the actual markup itself would be preserved in a snapshot. Say the user then deletes the letter 'e' and replaces it with a '' using the picker.

At this point, snapshot is basically split into 3:

Snapshot #1:

"|| A || B || C ||
| d | "

Snapshot #2:

Snapshot #3:

" | f |
| g | h | i |"

When the user then switches back to the markup editor, the only portion of the code that would need to go through any sort of conversion process would be snapshot #2, eliminating the possibility of the table markup becoming corrupted.

In theory, this approach should alleviate quite a few of the incorporated issues - it wouldn't fix the problem completely, but a lot of the issues such as excess whitespace, problems with escaped characters, corrupted table markup etc should see significant improvements (if not complete resolution).

"I have no idea why you think this is so hard?"

Because it is.

HTML and wiki markup are sufficiently different that any translation between the two almost necessarily involves a loss of data. Throw an editor component into the mix that is forced to rely on the browser's implementation of editable HTML content, and you end up with a huge pile of edge-cases where the conversion does not do what you want it to.

Most wikis solve this problem by severely limiting the available markup in rich text editing. Tables are rare, programmable macros and nesting block-level markup inside tables non-existent. Others do it by removing support for wiki markup. Many remove support for wiki markup and complex HTML.

We're working on a solution for the problem that tries to retain the richness of Confluence's markup and cross-browser support without causing too much disruption to people used to the way things work now. Unfortunately, it's just not something we can throw together overnight.

I have no idea why you think this is so hard?

Anyways, it would be good if this also had a split screen mode so you can see what markup it generates as well. This would be a great way to get people into how to edit markup.

Thanks for the feedback. The team is acutely aware of the problems surrounding the WYSIWYG editor, and its conversion to and from wiki markup.

We are discussing solutions to this, but it is a challenging problem, and one that will not be resolved in the short term. Sorry for any inconvenience this causes. This problem will be the focus of a major release in the near future.

I'd like to echo the comments from the previous posters. I'm still fighting adoption issues in my company, but a lot of people, myself included, really like Confluence. Our Product Management team just spent a lot of time creating a nice set of templates to create documents for their release management tasks. The main template has several panels on it and as soon as someone edits the page (in IE, not Firefox) the wiki code gets mangled. The team is close to scrapping Confluence for Word, which is unfortunate, but even worse would be the opinion that "Confluence is not stable". We are a small company, around 150 employees, and it only takes a small subset to become unhappy with Confluence, which could lead to us scrapping Confluence entirely. I'd hate to see that happen. Atlassian, please slow down on feature development and just make sure the current feature set works and is reliable.

Any updates on this issue? I can mirror Andy sentiment: "very unhappy users".

I have users with pages that break as soon as they are even loaded into the WYSIWYG editor. This results in very unhappy users. This is a serious problem because it is so visible. Novice users will be put off and potentially, adoption could suffer.

Hi John,

This issue is on our development roadmap. We hope to have a release focusing on this soon.

Cheers,
Chris

We just started using Confluence in our company and this is one of the most frequent complaints, especially the adding of extra
line breaks. People have pages with panel macros and stuff, and every time someone uses the WYSIWYG editor the panels get moved further and further down the page.

A "various WYSIWYG <--> wiki switching error fixes" release would make people so happy.