Option for top toolbar in new KB article editor

The more I use the new editor, the more I dislike it. Try putting a code block in an accordion control. I think it's impossible. I had to create a separate block and drag and drop it into the accordion.

The usability of the new editor is slow and awkward and unintuitive. At least put the formatting toolbar back. There are a lot of great design decisions made for this product but this was not one of them.

Yes, the new design is frustrating and inefficient to use.

I finally had a chance to try the new editor and the more I used it the more I wanted the old editor back.

Besides the major issue (bug?) of making our existing documentation with images nested inside of a list completely unmaintainable, the new editor is just an overall downgrade in usability. Not having a bar at the top to let you format or add things like a WYSIWYG editor slows things down versus typing commands or scrolling through a list of popup formatting options for a block. The potential benefit of a block section is negated if the section is very long since the drag and drop indicator becomes a buggy mess and is slower than cut/paste to move things around anyway. The final document output is too different from the editor so you have to keep going back to check if the spacing or sizing is correct, especially for images. The classic editor had its quirks but it was at least similar enough to every other text editor that it was intuitive for someone to use with no explanation.

Please make an option to revert to the classic editor so we can actually use our documentation again while you work out the issues with the new one. I think the new editor may be good eventually, but it is clearly not ready for live use.

Yes, this should have never been thrust upon the users. The biggest issues with the old editor bar was that it didn't float or stay put like classic word or text editor. You had to continually zoom up to it in long KBs and long rich field objects in assets.

Agreed, the old editor behavior was more predictable, and while it had some quirks we could work around them. The new editor mangles accordions.

I'm usually adaptable to change, in fact, the old editor was a breath of fresh air from our previous platform, that I looked forward to writing and updating documentation again. It was intuitive, quick, and very customizable. Then, I logged in one day, and I thought the browser simply wasn't rendering the editor properly (until I read about the update). I've also noticed that even though it's retaining previously published documents, I won't be able to edit/republish those without losing custom styles/inline HTML, and edit mode does not always display custom CSS or other styles until it's in published/view mode. I want to be supportive of upgrades and enhancements, but unfortunately this is taking a lot to get used to and experience the benefits.

You guys hid my most used commands behind floating toolbars and a more button. This is a massive step backwards. I want the stationary bar back at the top. This is so ridiculously inefficient and forcing this change is not a "you'll get used to it" It's objectively more clicks for the most common things I do with no / shortcuts.

There should be an option to choose which editor UI or editing experience you want to use, rather than forcing the same interface on everyone.

Different users have different workflows and preferences, so having the ability to switch between available editor UIs would provide greater flexibility and make the experience more user-friendly. A customizable editor experience would also allow users who are comfortable with the current interface to keep using it, while giving others the option to choose an alternative that better fits their needs.