nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

[Wiki Markup]

Cedric PORTE

I have about 5000 users that use confluence and wikimarkup.

This modification just block us to migrate to confluence 4.0.

Following this modification, we already have discussion to migrate to an other wiki.

Hope that wikimarkup functions will be add in plugin or in a patch...

Accepted answers

All comments

xkey

I'm in same boat, and posted a question on this forum a couple of days about same complaint/reqeust.

The wiki markup has some kind of support in new editor, but not the same convenience as we've enjoyed in previous releases. I've been reading wikimatrix.org, recommended by this forum, searching for an alternative.

The best thing I liked confluence about is powerful plugins and ease of wiki markups. I fully respect atlassian's decision on WYSIWYG editor, my guess is to win mass customer base, but difficult to retain advanced users. We may have to go back with plain mediawiki, there have been lots addition of new extensions (or plugins in confluence's term), with help of Google charts and etc.

I'd be interested in know your evaluation on other tools.

Kevin Buchs2

I suggest, and others agree, that you give Confluence 4.0 a try for a week before rejecting it. Many minds have been changed by doing so. Please see this posting also: https://answers.atlassian.com/questions/12073/wiki-markup-in-confluence-4-again

briburt

We tried 4.0 for a week in a test environment and are rejecting it after negative user reactions. Our users (mostly "advanced users" such as devs and QA folk who loved wiki markup) want a plain text editing option that is simply no longer there -- and from everything I've been reading on these forums will never be there again as part of the core product. Atlassian have made their choice and are not budging -- other than to offer lots of tips to power users on how to work around the numerous inefficiencies in the WYSIWYG editor.

Maybe if they offered just plain old XHTML source code editing, it might change some people's minds. But all WYSIWYG all the time (and no choice for plain text editing) is a deal killer for us. We were considering an upgrade, but are now looking at alternatives and planning a migration to a different platform. Too bad, as Confluence suited us in so many other ways, but the text editor is the one feature that makes or breaks a wiki, and this change is a deal breaker for us.

Kevin Buchs2

Did your users who had the negative reaction use the wiki for a week, or just a short time?

briburt

Users hit it pretty hard over the course of a week or so. Overwhelming feedback was that the new RTE was better than the old one (esp. wrt tables) but more cumbersome for things like setting required macro parameters (such as the language parameter for code samples) and for numbered lists that contain screen shots or macros between the steps.

The gist of most feedback was that plain text editing of some sort had to at least be an option in any system we use. Without that option, we'd risk that the "power users" (again, mostly developers and QA) who push adoption across the board and provide informal support for non-techies would lose their enthusiasm and overall use of the system would decline. These power users *want* plain text only, and because Confluence used to offer this option, they were all in on previous versions. So for now, we are sticking with 3.5 and exploring alternatives such as Mediawiki or something similar (sigh...)

BTW, I'm not trying to say that everyone should be like us, but I get the feeling that groups with our needs (i.e. most users strongly prefer plain text editing) are no longer the target market for Atlassian. I guess somebody did some business math and figured that making the editor more "Word-like" and forcing everyone to use it would gain them more customers than they lose. They've made their decision to go with their version of "New Coke" and clearly have no plans to offer a plain-text editing option, so users like us are being forced to vote with our feet. Others, of course, will have their own needs and opinions about this issue, but for us it feels like we've been given no choice.

Sherif Mansour

Hey Brian,

Thanks for taking the time out to try this out with your users. We've spent a LOT of time understanding what it is people love about wiki markup

I'm not going to outline the reasons why we moved to a single editor. They've already been outlined here. However, I quickly thought I'd share with you the general concerns we've heard (and I presume you have) about the loss ofwiki markup and what we are doing in each of these areas:

After gathering all this feedback, I'd group the wiki markupconcerns intro three key areas:

It's faster
People love wiki markupbecause it's much faster. With this in mind, we've introduced Autoformatting for wiki markup. This allows you to still writewiki markupin the new editor and it gets converted on the fly. Everything from font formatting to lists as well as tables! In fact, we've heard this "I want a faster editing experience" feedback since Confluence 3.0 and we've been making speedimprovements since then in the lead up to moving to a single editor (e.g Keyboard shortcuts, Drag-and-drop attachments in the editor, Paste images from clipboard, Autocomplete for links, attachments and macros...)
It's more reliable
Without a doubt, wiki markupis reliable. You don't have to deal with the complexities and inconsistencies between various browsers. With that in mind we set ourselves a challenging task of making this editor more robust then every before. Web technologies and browsers have made some great leaps over the last few years and we are confident now is the time to move to a single editor.
Some users prefer to author content without formatting
This was certainly the minority of users, but still a valid use case. For that we've created thewiki markup styler plugin to allow people to see content non-formatted as they work in the editor.

With all this in mind, we still plan to make an investment in each of these areas. In particular, the move to a single editor highlights our on-going commitment to the reliability of the editing experience. Every release we plan on making these improvements.

We are committed to a single editor moving forward. We cannot continue to invest in two separate editing experiences, if we are to move forward as a product and start attacking a lot of the highly-requested problems our customers want solved, we must be a on a single editor.

I'm really excited about the prospect of this editor and the amazing things we can do with it. I've also spoken to a lot of customers that feel the same way and have helped us get here today. So if you've got some specific feedback, we would love to hear form you as well. You can help contribute to it by raising bug requests and improvement suggestions at jira.atlassian.com. The "technical team" is still our target customer, so if you feel that is not the case and have some specific reasons as to why, please let me know.

xkey

The fundamental editor preference for plain text is a profound habit deeply in a large user community (not confluence user, but overall editor user base). It's same as nice email editor with HTML and/or rich text capability vs. plain text email, or like nice Microsoft Word vs. LaTex, Wordpad vs. Emacs/Vi. _A LOT_ of people still prefer plain text, the ability to abslutely contol the format rather than some editor's interpretation, which may vary over the release.

Going with a single powerful editor seems to be the trend of many wiki/collaboration/social software, and I'm not going to argue with this. But the decision does upset quite some "advanced" user community and may lose quite some interest from some customers.

Sherif Mansour

Yeah, I see your points xkey. Have yout tied this plugin?

AM12

Please check:

https://answers.atlassian.com/questions/21735/occupy-confluence-markup-provide-a-wysiwyg-xhtml-markup-editor-to-edit-the-markup-source-of-confluence-4-wiki-pages

A-M

Marko Marko

I am another user deeply frustrated by the removal of the markup.

I understand that having a back-and-forth conversion between the formatted page information and the wiki markup is costly. But couldn't there be a plugin allowing a (poor) wiki markup such that, once the page is converted to the richer wysiwyg format, no possibility exists of returning it back to the wiki markup?

I believe the large majority of us (users frustrated with the abandon of the markup) would be satisfied with such a plugin. Most of the time we don't need fancy features. And we wouldn't mind to use the wysiwyg editor in such rare occasions.

Thanks,

Marko

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence