Try out the new editing experience

[Avinoam]

Hi all,

As an immediate action from our focus group yesterday I've done my best to respond to all the tickets on https://confluence.atlassian.com/confcloud/confluence-cloud-editor-roadmap-967314556.html.

Moving forward, as a team, we'll make sure we're more engaged in these tickets. 

Thanks,

Avinoam

[jim mason]

Thank you for the updates

[Tom Crowley]

Thanks for this, Avi! You might not see any tangible benefits from keeping these tickets updated, but we do appreciate knowing what's happening with them.

[Helen Gosper]

Thanks Avi. Looking forward to chatting next week.

[Bob Sovers]

Thank you Avi, for trying to keeping 38 of the 7,170 unresolved issues updated.  I guess that is better than nothing.

[Dave Jennings]

It seems that our cloud-hosted instance has just lost the "Blank page (old)" option when creating a new page.

A little annoying as indented task lists are a key part of our workflow and https://jira.atlassian.com/browse/CONFCLOUD-65755 is still In Progress.

Why remove the option to use the old editor when features are still not complete?

[Tom Crowley]

Have you tried looking in the Show More section? Someone else I know had this issue, but they could still find the template in a roundabout way.

[Bob Sovers]

If you have any page that still uses the old editor, you can copy it, and (for now) it will still use the old editor. 

If you don't have one, I found that I could cause the system to give me an old-editor page by using the How-To blueprint.  After creating my first "How-To" page, the blueprint also generated an old-editor "How-to articles" page.

I then copied the "How-to articles" page, changed the title to "Blank Old Editor Page", and deleted the contents.

[Andrey Khaneev _StiltSoft_]

That's a great workaround, Bob! Thank you for the idea!

[jim mason]

@Bob Soversis right.

I can't use templates any more so I use an old editor page as  a template.

I just copy and then move it where I want.

You can EVEN copy an old page go a newly created space and the old editor still works.

Without this, I would have to move to a different wiki

[Bob Sovers]

WooHoo!  This discussion is now on page 9!  (and at 202 comments!)

Page 1 -- Original comment postings between 2019-02-06 and 2019-02-21 (with many responses later)

Page 2 -- Original comment postings between 2019-02-21 and 2019-03-21

Page 3 -- Original comment postings between 2019-03-22 and 2019-05-20

Page 4 -- Original comment postings between 2019-05-20 and 2019-07-09

Page 5 -- Original comment postings between 2019-07-11 and 2019-08-20 

Page 6 -- Original comment postings between 2019-08-20 and 2019-09-12

Page 7 -- Original comment postings between 2019-09-16 and 2019-10-14

Page 8 -- Original comment postings between 2019-10-14 and 2019-10-31

Page 9 -- Original comment postings on and after 2019-10-31

[David King]

The new editing experience became active for our company on Cloud the other day, and I have been fielding a steady stream of questions and increasingly frustrated feedback from users. There are a few good improvements, but for the most part, the new experience is a poor one. It's like being handed a spork after using real cutlery for many years and being told that you are getting a better eating experience. In some cases, the implementation is so devoid of useful functionality that it is hard to tell whether it was a design choice or there is an unpatched bug.

For example, a couple of specific items that have come up: https://jira.atlassian.com/browse/CONFCLOUD-65302 and https://jira.atlassian.com/browse/CONFCLOUD-67129. Both are summarized has having been dropped with NO PLAN to restore them.

As someone that works in cloud-based software development, I know that new user interfaces can cause disruption to user workflows- and even more anxiety - and therefore it is incumbent on product designers to "first, do no harm." That is why I do not understand why portions of existing Confluence functionality were completely dropped. Or why some features are not additive: for example resizing images by defining width in pixels OR snapping to a grid. Or why the old experience cannot just be set as a site-wide default permanently. Even Reddit conceded that point in their recent redesign and supports old.reddit.com.

Because of these many issues, I've instructed our users to create pages with the old editing experience while we look at migrating our content to another platform.

[Helen Gosper]

David King's comment above perfectly describes the experience for me.

[Larry Du]

How do we convert old wiki pages to the new editor? I find the older editor infuriating

[JoAnna Black]

I'm not sure how but do this with great care, I've heard of serious issues in converting old pages.

[Tom Crowley]

Raise a support ticket. They can switch your site over, and then any compatible pages will convert to the new editor next time you open them (I think). Any incompatible pages will probably remain in the old editor, unless they've come up with a way of fixing the differences yet.

Example incompatibilities:

• Inline images
• Panel (Note) macros in lists

And there's something about tables as well that seems to cause hiccups for me. 

[Tom Crowley]

And, make sure the new editor does everything you need it to. I don't think they can (will?) convert the site back to "old editor" only, so do a bit of research before flicking the switch.

[Nico]

Sorry if i repeat the topic but I can't find a solution or workaround to this. I read that comment while publishing a page to explain why or what changes has benn made in summary, dissapeared from last versions. Still theres is a Comment column in Page History...so....? 

Is there a solution or workaround to track changes in a way of describing changes made before publishing a page, so if someone wants to read why the editor makes those changes, can read revision history of the page with comments made before publishing...hope I am clear about this and find a prompt response.

Thanks,

[Tom Crowley]

Hi Nico, they got rid of commenting your changes, justifying it by saying that you can compare versions to identify changes. This means that you can see what is different, but not why it is different.

As far as workarounds go, I can only think of using the normal commenting feature - not great, but as a desperate measure it might work.

[Nico]

Thanks Tom for spending some minutes to reply. Agree with you that is not a great workaround. I will keep looking for a better solution. May be an Expand macro with Revision History inside...

[Paul_J_McLeod]

"not only are we out here actively listening, but we deeply care and are always looking for ways to better improve"

Hi I know about 'active listening' - it's a technique for making people accept what you plan to do by appearing to listen.  You repeat their words back but without agreeing. It makes the poor dolts feel more comforted and gives them warm feelings of being understood.

May I suggest that you have valuable feedback from a community of (largely) experts in pragmatics of knowledge management. You don't need to make them 'feel' understood:  they are offering you golden words of advice (unfortunately hard advice) about what you need to do to keep your product useful at the one thing it is good for: Knowledge Management.

You owe it to YOURSELVES to get this right. Not merely give us the affect that you are nice and listening. That won't change anything about your product and only by altering your plans and adjusting the product BACK will you retain the goodwill of users, especially those who can already see your problem.

You've been warned.

I hope you appreciate it.

We can't help you more.

[Helen OBoyle]

I want to know if the Confluence Storage Format (XML schema) is still in use. Our org, which uses Confluence Server and thus doesn't have to worry about this QUITE yet, has tools that depend on the Confluence Storage Format.

It would be useful to know in advance (far in advance) whether we're going to have to change the way we programmatically build pages to post to Confluence.

[Michael Corvin]

we are in the same boat - lots of page creation and access automation via the REST API, which requires lots of custom XML mangling

[James Dellow]

I've not seen anything to suggest that the underlying storage format is changing and I can't see why they would want to do that. Comments are still using the old editor as well.

[Helen OBoyle]

James, my concern is around the fact that structural aspects of a page seem to have changed - for example, no macros within macros, tables have changed, etc. These ARE schema changes to the storage format, at the very least. If they're not schema changes, then they've created a new editor that is non-compliant with the existing schema (which allows those things).

[Helen OBoyle]

Michael, are you using Confluence Server as well, or the cloud product? (I mentioned to one of our higher-ups earlier this week that the editor for cloud was changing and that hopefully it wouldn't be migrated to the Server product until it had all the features the current editor does; they did a quick google for the new editor, saw all the "feedback" on it, frowned, and made some notes and a comment about that limiting the upgrade path. Migrating to a cloud solution wouldn't be in the cards if we lost today's functionality which is only a subset of the functionality of the full-featured publishing environment we came from. We've already sacrificed features to adopt Confluence and can't really stand to lose any more.)

[James Dellow]

@Helen OBoyle I guess from an end-user perspective it doesn't really make any difference if the storage format itself has changed or not, the end result is that content is formatted differently when viewed.

[Michael Corvin]

@Helen OBoyle : yes we have several Confluence Server sites and those are where the bulk of our work is.  As it stands the changes - loss of key functionality - that have been made to Cloud would break a lot of our usage.

[Helen OBoyle]

@James Dellow Unfortunately from the perspective of this end user (read: I sit at a customer site), it does make a big difference, because not all end users manually create their content.

[Helen OBoyle]

@Michael Corvin Yeah, I hear you. We'd have to re-engineer a lot of automated processes and likely also change our document formats to live under the new editor as it stands. We generate thousands of pages using a dozen or so automated tools. Given how buggy the original editor still is after years, I'm not optimistic that the shortcomings of the new editor will be addressed in a timely manner. Hopefully we won't have to move to it any time soon in the Confluence Server world.

[James Dellow]

@Helen OBoyle I did a bit of testing (using the Page Source Editor for Confluence Cloud app) and I could still use the Span macro (for example), although the new editor doesn't recognise it. So I'd say for the moment at least, the underlying storage format hasn't been affected.

[James Dellow]

On further inspection, I just noticed a notation on the unsupported macro, which says:

__confluenceADFMigrationUnsupportedContentInternalExtension__

I assume ADF is "Atlassian Document Format", which is something I've only seen in the context of JIRA. However, just looking at:

https://www.atlassian.com/atlascamp/watch-sessions/2019/the-atlassian-platform/the-atlassian-document-format-is-coming-to-an-api-near-you

So, I stand corrected, changes are coming...

[Helen OBoyle]

Oh, @Michael Corvin .... have you read the parent post from @James Dellow ? I am... not particularly amused.

My initial reaction is more like, "Ugh."

File sizes about 50% greater than Confluence XML? Righto.... And that's even before I think about the tooling that will have to be redone and the third party export utilities that will have to be re-tested (if they have been or will be developed for the new format) or alternatives that will have to be found. And the fact that at least so far their library is only available for the typescript language, and not languages more traditionally used in the enterprise in Windows or Linux worlds.

Methinks Atlassian has a thing or two to learn about working with corporate customers who pay the big $$$ to use their products. For example: Microsoft Word still lets users save in the .doc format from ~20 years ago (albeit without support for new features, but the .doc files are perfectly usable).

[Helen OBoyle]

Thanks @James Dellow ... Good to know.

[James Dellow]

There is an earlier presentation from Atlas Camp in 2018 talking about ADF, which is essentially the same as the 2019 presentation except at the end it is a bit more definite about the new format coming to Confluence (although no time frames) https://www.youtube.com/watch?v=YiZAHTHlPjk

It would be great if Patrick Streule could jump in and explain more about the impact of ADF on Confluence pages and also the reason behind some of the limitations, like nesting.

[Tom Crowley]

I sent a long old email to Jessica and Mandy following the focus group, providing some detail and feedback that it wasn't appropriate to give in the meeting, including a summation of some of the issues raised here. I think I was blunt but fair. Jessica responded, and said that she will pass it on and they will do their best to factor the feedback into their plans. 

My recommendation was as follows. If that idea works for you, feel free to suggest or modify it. Maybe the cost of running two editors will be offset by not losing as many customers...

I'm not sure what else I can contribute, so I'll probably rein in the feedback on here. I'll continue lurking in the background, so feel free to tag me if I can be of any use.

Good luck!

The upshot of the list below is that my short-term recommendation, though I’m not sure how feasible it is, is that you do not pull the plug on the old editor. Stop supporting it, fine. Let people use it as is. There are more bugs for it that would ever be fixed anyway, but leave it there. Don’t invest in it, but don’t take it away. Encourage new users on to the new editor, develop it, make it a better version of the old one. In time, if you achieve this, the ‘old guard’ will move across. If you don’t, then at least you’ll still have your customers. As it stands, I can’t recommend Confluence as a tool, and you’ve got work to do before I can recommend Atlassian as a company.

[Helen Gosper]

A sensible suggestion. Not supported but still there to use at our own discretion, or peril. Much like the old 'copy space' plug-in which went unsupported for Donkey's years yet used (still used, I believe) without a problem by many.

[Tom Crowley]

The way I see it, it's the only way for them to move forwards with development of the new editor while not alienating existing customers. They can default the new editor for new customers, while letting old customers move across when they think the functionality meets their needs. It's not quite win-win, but the alternative is lose-lose.

[Shaun Sheehan]

Honestly, we'd be fine with the new editor if we had the same functionality we had before (colors, ability to size and link pics...). Add/enhance functionality, but don't take it away. 

[Tom Crowley]

That's the thing, they're not taking features away, they're creating a new editor without them. It's not a case of them going oh, ok, and flicking a switch to put the features back, or just pasting a bunch of code back in, they need to be redeveloped for whatever the new editor is built on.

Even if they did decide to reinstate everything, it would take months before the new editor reaches the same level of functionality as the old one. And that's a big if.

[Shaun Sheehan]

But from an end user perspective, it doesn't matter what happens technically behind the scenes - we didn't consciously go out an purchase a "new" Atlassian product as one would a new iPhone.  It's still Confluence.  I could do several things before that I now can't.  To the end user, that's loss of functionality. 

[Helen OBoyle]

For the environment in which I work, that idea of "leave it there and let people use it but don't support it" isn't sufficient.

Many enterprises have a policy of not using anything with a status of unsupported due to the potential financial and other business risks of doing so. Leaving something "there" but "unsupported" is the same thing as ripping it out.

In the presentation on ADF, they mentioned that they're using some editing framework that requires pages in the JSON format. Is it a third party thing? Are our editing needs now dependent on someone enhancing a rudimentary web editor?

I'm still back on, editing can be slow in the current environment. With page sizes 50% bigger and much more markup around everything, how bad does it get?

Consider that in enterprise environments, there are often multiple security layers that scan each page at various points in the page retrieval cycle, including proxy servers and client-based web filtering applications. That 50% increase in page size is going to hurt, when it already takes multiple seconds to navigate from page to page in some environments.

[James Dellow]

Re: JSON

It's a well known and widely supported open-standard file format. In some respects it could be better than the current HTML / XHTML-based format that Confluence uses to store the content of pages ("CXHTML"), as it does open up some interesting possibilities for developers across the Atlassian suite.

You can play around with it and see how the new rich text editor stores WYSIWYG content in JSON format:

https://atlaskit.atlassian.com/examples/editor/editor-json-transformer/json-transformer

If you are currently creating content in Confluence via the API, then at some point I assume they will stop supporting CXHTML. When that happens, your process will need to convert your source content to this JSON format. It would be good to get some information about the roadmap for this.

The other question I have is how much of the new editor / the presentation of content being constrained by the new format (e.g. removal of div macros)? Or is this just a design / development effort decision.

[Helen OBoyle]

@James Dellow Yes, and it's still a core format change rather than an addition of an extra format as far as I can tell (given current user reports on the Cloud experience). Different formats can also be more appropriate for different environments.

XML opened up many interesting possibilities as well, as open tools already exist to transform from one XML format to another and eventually get to Confluence XML format. Correspondingly, open tools already exist to get from XML to various export formats like PDF, Word, and so on, and it's very straightforward to adapt those to Confluence XML.

Your comment seems to be saying, "It's different but not necessarily worse." My point is that it's not necessarily better, either, and will cause extra work for some customers.

It seems to be change for Atlassian's convenience because of the editing plug-in they've adopted (they gave that as one of the reasons for using the format), not change because it's necessarily adding compelling functionality.

"If you are currently creating content in Confluence via the API, then at some point I assume they will stop supporting CXHTML. When that happens, your process will need to convert your source content to this JSON format. It would be good to get some information about the roadmap for this." ... is exactly the point I was making when I said Atlassian has a thing or two to learn about corporate customers because breaking changes like this just aren't done due to the major drama they entail; not sure why you're re-stating it... perhaps you wanted to clarify the warning to others who might not be reading as closely.

Forced conversions that break a customer's internal environment just don't routinely occur, as seen in my example of Microsoft Word and the 20-year-old .doc file format. Customers are given YEARS (and I don't mean two) to transition, with full software support and upgrades during that time. This isn't the phone app world where an app can completely rev from one month to the next without affecting anything else. There are tools, business processes, even roles, and (for the Atlassian ecosystem) companies downstream the Confluence platform that rely on aspects of the environment, including the internal storage format for pages. It just feels like Atlassian might not fully understand what it means to be a platform company that sells into the enterprise space.

[Anand Rajaraman]

Hi @Avinoam ,

I also want to take the pride in what you keep saying, but nothing seems to be working. The old editor experience was better. Maybe, Confluence should have moved this transition in stages after doing proper testing. Sadly the formatting is pathetic and its almost more than a month over and still basic things such as formatting of ordered list and images in a task is not working consistently :-(.

[Anand Rajaraman]

@Avinoam , the images within the tables were earlier working perfect in old editor, the formatting goes really bad when exporting to PDF . Now, all are in bad shape. Is someone, looking and tracking these issues. Day by day, its painful and frustrating to keep looking at things that aren't working. Please do something to address all these issues.

Regards,

Anand

[Bob Sovers]

WTF... Someone just posted about yet another site that Atlassian staff comment about stuff...

https://www.atlassian.com/atlascamp/watch-sessions/2019/

This was stuff from the annual developer conference, 11-12 Sep 2019 in Vienna

[Bob Sovers]

Here (https://youtu.be/0JbeRKx5I_k) from Klaus Ihlberg, Engineering Manager

Where he shares his insights into how we (the customers) use Confluence.

This was from https://www.atlassian.com/atlascamp/watch-sessions/2019/the-atlassian-platform/supercharge-your-pages-new-ways-to-extend-the-confluence-editor

[kpink]

interesting he asked how many are using the new editor and not how many liked the new editor

[Monique vdB]

Thanks for the great discussion and feedback. and special thanks to those of you who participated in the focus group that emerged from this discussion!

I’m going to close this thread to give the team a chance to action on the items raised by this group. So you don’t miss future updates, make sure you’re watching for new articles in this space. (Go to the main collection page, click Watch and select articles.)

If you find any bugs in the meantime, please create JAC tickets for those. Questions and discussions are always welcome too, but please keep in mind our voice and tone guidelines.  The team is working hard to make sure your feedback is heard and actioned on. Thanks all!

[Monique vdB]

https://community.atlassian.com/t5/Confluence-Cloud-discussions/Discussion-page-for-users-affected-by-the-editor-change/td-p/1222979

Thread has been rolled over here for those who want to keep the discussion going, thanks Tom!