5 ms·

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

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.

rhencke 6y ago
How does this relate to the performance issues being discussed?
- freedomben 6y ago
  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.
- runlevel1 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        > 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 6y ago
    I always write my stuff in Word first, then paste into Confluence.
    - runlevel1 6y ago
      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.
- ratww 6y ago
  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.
- etimberg 6y ago
  Half the UI uses textile and half the UI uses Markdown. Shipping two parsers & renderers for the app makes it a lot bigger.
freedomben 6y ago
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 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.

rhencke 6y ago

How does this relate to the performance issues being discussed?

freedomben 6y ago
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.
runlevel1 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      > 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 6y ago
  I always write my stuff in Word first, then paste into Confluence.
  - runlevel1 6y ago
    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.
ratww 6y ago
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.
etimberg 6y ago
Half the UI uses textile and half the UI uses Markdown. Shipping two parsers & renderers for the app makes it a lot bigger.

freedomben 6y ago

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 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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.