Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-6992

Markup umbrella issue - errors switching between modes or rendering escaped content

XMLWordPrintable

      This umbrella issue covers markup bugs caused by switching between wiki markup, rich text and the rendered page.

      Atlassian Status as of 16/07/2010

      The Confluence team are actively working on Confluence 4.0. This new version will remove the round-tripping issues. We currently 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.

            [CONFSERVER-6992] Markup umbrella issue - errors switching between modes or rendering escaped content

            Mark Mielke added a comment -

            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...)

            Mark Mielke added a comment - 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...)

            MarkZ added a comment -

            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.

            MarkZ added a comment - 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.

            Rick Hadsall added a comment -

            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

            Rick Hadsall added a comment - 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

            Mark Mielke added a comment -

            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.

            Mark Mielke added a comment - 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.

            Matt added a comment -

            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

            Matt added a comment - 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

            Rick Hadsall added a comment -

            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.

            Rick Hadsall added a comment - 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.

            Sherif Mansour added a comment -

            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

            Sherif Mansour added a comment - 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

            Marcus Eby added a comment -

            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

            Marcus Eby added a comment - 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

            Sherif Mansour added a comment -

            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.

            Sherif Mansour added a comment - 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.

            Rasmus Scholer Sorensen added a comment - - edited

            Thanks Sherif, and thanks to the whole company for being open about your plans. It is really good to know what exactly you are focusing on.

            This will likely also make it easier for us to get people to adopt Confluence, since the editor is currently one of the largest drawbacks with Confluence. Can't wait to see this in action myself.

            Do you know if it is going to use HTML5 for e.g. file-uploads etc? We got quite a lot of users complaining about browser compatibility, since many users are on linux or mac, and most users normally use Chrome, FireFox or Safari. In our mind, IE8 is normally only for legacy use, so it is rather odd to us that many features are not supported in a more modern browser like Chrome or Safari. (Ironically, Linux Chrome does not support Google Gears as they are trying to push the use of HTML5, so Chrome users don't even have drag'n'drop uploading...)

            Rasmus Scholer Sorensen added a comment - - edited Thanks Sherif, and thanks to the whole company for being open about your plans. It is really good to know what exactly you are focusing on. This will likely also make it easier for us to get people to adopt Confluence, since the editor is currently one of the largest drawbacks with Confluence. Can't wait to see this in action myself. Do you know if it is going to use HTML5 for e.g. file-uploads etc? We got quite a lot of users complaining about browser compatibility, since many users are on linux or mac, and most users normally use Chrome, FireFox or Safari. In our mind, IE8 is normally only for legacy use, so it is rather odd to us that many features are not supported in a more modern browser like Chrome or Safari. (Ironically, Linux Chrome does not support Google Gears as they are trying to push the use of HTML5, so Chrome users don't even have drag'n'drop uploading...)

              smansour Sherif Mansour
              david.soul@atlassian.com David Soul [Atlassian]
              Affected customers:
              139 This affects my team
              Watchers:
              87 Start watching this issue

                Created:
                Updated:
                Resolved: