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.
Red Handle
•
Sep 19
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.
Bronze Mist
•
Sep 9
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.
Bronze Mist
•
Sep 8
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.
Bronze Mist
•
Sep 8
Yes, the new design is frustrating and inefficient to use.
Turquoise Lake
•
Sep 14
Agreed, the old editor behavior was more predictable, and while it had some quirks we could work around them. The new editor mangles accordions.
Yellow Coaster
•
Sep 8
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.
Yellow Nucleon
•
Sep 15
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.
Yellow Nucleon
•
Sep 10
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.
Tomato Melon
•
Sep 10
Kristen W.
I'm sure you've seen my comments in the MSPG #v-hudu channel
I have to join the rest in the praises I had made for Hudu; but the new UI and what it's doing to existing documentation created manually with Hudu; from the ITG / MS Loop like elements to loss of previously available options that means we have to override in the HTLM source directly (like table formatting), I fully miss the old UI and RTF WYSIWYG editor.
"/" style commands work great in IRC; quick, short-form chat posts, or controlling chat bots in platforms like Discord/Teams.
I find it far less efficient in producing actual documentation -_-
Tomato Melon
•
Sep 23
There are 178 KB/SOP articles under just our own “Partner” in Hudu, broken down as:
KB articles: 127
SOP articles: 51
And we just refuse to update them at this point. Any attempt to do so simply means having to re-format the whole thing again.
And another thing I find funny :
This “Feedback” platform just got a UI lift today; and it still kept the more traditional RTF styled interface. Even left the known markdown formatting characters (such as “*”, “**”, even the “#” headers) functional
Imagine that…almost like it’s intuitive; even for primarily keyboard users!
(since that was an item I believe I saw mentioned in regards to the new UI implementation)
Log in to comment and vote
Comments17
Beige Cascade
Sep 9
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.
Red Handle
Sep 19
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.
Bronze Mist
Sep 9
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.
Bronze Mist
Sep 8
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.
Bronze Mist
Sep 8
Yes, the new design is frustrating and inefficient to use.
Turquoise Lake
Sep 14
Agreed, the old editor behavior was more predictable, and while it had some quirks we could work around them. The new editor mangles accordions.
Yellow Coaster
Sep 8
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.
Yellow Nucleon
Sep 15
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.
Yellow Nucleon
Sep 10
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.
Tomato Melon
Sep 10
Kristen W.
I'm sure you've seen my comments in the MSPG #v-hudu channel
I have to join the rest in the praises I had made for Hudu; but the new UI and what it's doing to existing documentation created manually with Hudu; from the ITG / MS Loop like elements to loss of previously available options that means we have to override in the HTLM source directly (like table formatting), I fully miss the old UI and RTF WYSIWYG editor.
"/" style commands work great in IRC; quick, short-form chat posts, or controlling chat bots in platforms like Discord/Teams.
I find it far less efficient in producing actual documentation -_-
Tomato Melon
Sep 23
There are 178 KB/SOP articles under just our own “Partner” in Hudu, broken down as:
KB articles: 127
SOP articles: 51
And we just refuse to update them at this point. Any attempt to do so simply means having to re-format the whole thing again.
And another thing I find funny :
This “Feedback” platform just got a UI lift today; and it still kept the more traditional RTF styled interface. Even left the known markdown formatting characters (such as “*”, “**”, even the “#” headers) functional
Imagine that…almost like it’s intuitive; even for primarily keyboard users!
(since that was an item I believe I saw mentioned in regards to the new UI implementation)