[igetspam]

Know what would be great? Markdown support. The WYSIYG is full of bad assumptions and has been forever. In the beginning, we could at least opt out but that's long gone. I actively encourage companies I consult for to use anything but confluence because it seems to be designed specifically for the lowest common denominator with no allowance for people who work faster with a keyboard.

[freedomben]

Yes, agreed. I get that confluence is supposed to be for everybody, not just programmers, but there are plenty of great WYSIWYG implementations that use markdown under the hood (and make that accessible). If I could clone the underlying git repo (or an abstraction or something) like Gollum allows, I'd advocate for confluence everywhere. As it stands now I advocate for either markdown/asciidoc in the code, or gitlab wiki (which allows doing that).

[confluence_perf]

followup questions: what level of support are you looking for, and what would be sufficient?

1) markdown macro (limits markdown to the body content, and not interacting with other macros or styling)

2) copy/paste markdown -> autoconvert to WYSIWYG (limits markdown to copy/pasting, so no editing Markdown inside)

3) "markdown pages" (something like 'this page is Markdown only, no WYSIWYG)

I make no comments/promises on any of these becoming real but looking for what's most valuable

[epage]

Not who you are respondin to but some thoughts

1. Don't be Slack / Teams :)

What I mean by this is if you support it, support it correctly rather than "markdown as keyboard shortcuts" that some products do where if you make the simplest of editing changes, your "markdown" isn't recognized.

2. Devs want to consistently use Markdown across their entire suite

At my last job, we were switching to Azure DevOps. They support Markdown in the developer workflow (PRs) but rich-text-only for Tasks (to be non-dev friendly?).

At my current job, I'm involved in developer productivity and have been interviewing people to collect input for where we want to take development. We currently use Phabricator which uses Remarkup. This is a source of frustration because its not quite the markdown they use everywhere else.

From these, I'm thinking Markdown Pages would be the top choice since it allows developer-only interactions and marketing-only interactions to stay within what they are comfortable with,

[confluence_perf]

Thanks for the detail! Point (1) is very interesting

on (2) -> it sounded like you're saying (a) 'across entire suite identically is good', but that also (b) 'if there's a clear separation of Dev vs nonDev apps/docs, having different support is okay', did I read that right? please correct me if wrong.

[nickdonnelly]

The correct answer here: use the same editor in the entire suite, everywhere. Give the user a setting to decide if they want that editor to be WYSIWYG, or markdown.

In my personal opinion, Atlassian's rich text editor (or, seemingly, the 4-6 different one's you guys have built) is unforgivably terrible, so true markdown is the way to go if having both isn't an option.

[saagarjha]

As a programmer, being able to have something like what GitHub does (Markdown text, you can preview what the rendered version looks like) would be great. I assume that people who are less technical would like a more WYSIWYG editor but as long as the ability to write straight Markdown is there I am sure that I wouldn’t care. Oh, and make sure it’s actually a reasonable subset of Markdown, not like Discord or Slack where you support bold and italics but mot much else.

[confluence_perf]

Thanks! I'm not sure this is the most doable thing (I'm not familiar with the technical aspects of the editor storage format) but can definitely discuss with that team.

The "reasonable subset of Markdown" is also a very useful specific detail, exactly the kind of specificity that helps us do our jobs.

[Kinrany]

There's CommonMark, a standard for Markdown. You could make that your goal, instead of feature parity with any of the proprietary implementations like Github.

[TeMPOraL]

FWIW, check out the new Reddit interface. For all the well-deserved hate it's getting (some of which for the same reasons Jira is), it showcases that you can have a dual WYSIWYG/Markdown editor that works, and allows switching back and forth between modes during editing.

[chrisseaton]

Just normal Markdown for all edit fields! GitHub manages to have a single (almost) Markdown format everywhere. Could we have that in all Atlassian products. There’s no need for your own format.

[SaladFork]

The biggest request I have of JIRA aside from performance is that whatever markdown/markup language you choose, that it be consistent across the entire product.

It is so frustrating to have to remember to use double-curlies for inline code/pre sometimes, and backticks other times. In each case, the other doesn't work. More than once using one has resulted it rendering correctly on the immediate page but not on the next.

This is one I encounter regularly but is far from the only inconsistency in support.

[rhencke]

How does this relate to the performance issues being discussed?

[runlevel1]

In the case of Confluence specifically, it makes the cost of experimentation a lot steeper.

Confluence's WYSIWYG editor will often make changes that can't be reversed with "undo" -- especially those involving indentation. Copy-paste frequently screws up its formatting as well.

So if you don't want to risk losing lots of work, you have to make many smaller changes. With each change taking a few seconds, it adds up quickly.

If it was markdown or some extended set of it, that wouldn't be a problem.

[confluence_perf]

We're trying to collect and fix such occurrences, so if you have something with specific repro steps please send them to me and I'll make sure they get to the right team.

[runlevel1]

The WYSIWYG editor makes it extremely difficult to give repro steps because formatting information is hidden from the user and is not perfectly preserved during copy-paste.

More generally, the issues I see reported only ever seem to be fixed in the Cloud version. I currently have to use the Data Center version.

Why go through the trouble of reporting an issue I'll never see fixed involving a feature that I loathe using?

[throw_jirauser]

> More generally, the issues I see reported only ever seem to be fixed in the Cloud version. I currently have to use the Data Center version.

> Why go through the trouble of reporting an issue I'll never see fixed involving a feature that I loathe using?

I find the same issue with Nessus Professional. They too are trying to funnel everyone into using tenable.io (SaaS nessus scanner). And they also are very resistant in doing much of any changes (other than removing the API) from their onprem solution. But tenable.io keeps getting regular updates.

Worse yet, when you talk to anybody there, the first thing is "Why arent you using tenable.io ?" My response every time is, "Has it been fedramped YET?".. Of course it hasn't. Not entirely sure they even plan on doing that.

For maintaining data integrity and preserving a secure environment, these companies are demanding that we open our networks and store our critical data somewhere we really don't have access to.

[MandieD]

I always write my stuff in Word first, then paste into Confluence.

[runlevel1]

I do that too when creating a new page.

Editing an existing page is more perilous. I sometimes write out my changes in plaintext first, and then paste and format it into the doc piece by piece. Even that can get janky, though.

It's like Confluence is punishing my attempts to write documentation.

[freedomben]

Not GP, but I'd say because it's heavy, and if you didn't have to use it (as there are alternative methods) then you don't pay the performance penalty.

[etimberg]

Half the UI uses textile and half the UI uses Markdown. Shipping two parsers & renderers for the app makes it a lot bigger.

[ratww]

Don't know if that's what OP was thinking, but a WYSIWYG editor is normally slower than a plaintext editor, so it could make the product more bearable.