Help Center Article Editor needs to support (easy) source code formatting
Posted Jan 20, 2014
I'm currently testing out the new Help Center before we migrate over. From what I can tell, the new WYSIWYG interface for drafting/editing articles has been cleaned up and hopefully is less buggy than the previous version (e.g., text randomly getting displayed with blue backgrounds). However, one feature has been removed and will undoubtedly cause some serious pain points for our agents in easily creating help articles: formatting options, specifically for source code.
Previously, the WYSIWYG drop-down menu for "Preformatted" would allow us to set in grey-boxed code blocks. Now, the only option is to open up the "Source Code" pop up and edit the HTML, a rather tedious process that seems to format things inconsistently in relation to the previous method. I want to stress that I'm not advocating for the previous article editor. Because our support frequently involves reading/writing code (both inline and block style), the Markdown capability in tickets has been great, and we wish this were an option in the Help Center. Currently, I don't even seen where you can use preset header styling.
Since we're hoping to leverage the Help Center's "Self Service" model more, we really need these features if we want to supply pro-quality support pages that are truly helpful , without it being so cumbersome for our agents to create them. Will Markdown be available at some point? Or better yet, plugin support for additional editor features (code/syntax styling)?
Do you have any suggestions/workarounds that lend themselves to a good workflow in Help Center regarding this type of formatting?
92
77 comments
Official
Katarzyna Karpinska
Hi All,
Thank you very much for all the comments in this thread. I can see that there are a few requests over here, namely:
I'll start with the last one. We are working on changing the rtf technology powering our editors to make sure that we provide the same experience across all the products. At this moment we have already unified the ticket editor and the content block editor and in 2023 we'll move the article editor to it as well.
Changing the rtf technology will allow us to implement a lot of changes to the content creation experience that should address some of the needs raised here.
For example, you can already see in the Content block editor you can see that the code block is allowing language-sensitive formatting. We also started supporting markdown in Content block editor, you can read more about it here. We plan to extend this functionality the article editor as well.
The last thing that I'd like to address here is advanced article components (like pre-formatted alerts, notes, info boxes). It's definitely on our roadmap and we hope to start working on it sometime next year. You can always check our roadmap here.
2
Nick Bolton
This is easy to do: click the code button and use the `<code>` tag instead of `<pre>`.
Zendesk just didn't add a WYSIWYG button for it, but the HTML tag still works.
0
Official
Katarzyna Karpinska
Hi All,
Thank you very much for all the comments in this thread. I can see that there are a few requests over here, namely:
I'll start with the last one. We are working on changing the rtf technology powering our editors to make sure that we provide the same experience across all the products. At this moment we have already unified the ticket editor and the content block editor and in 2023 we'll move the article editor to it as well.
Changing the rtf technology will allow us to implement a lot of changes to the content creation experience that should address some of the needs raised here.
For example, you can already see in the Content block editor you can see that the code block is allowing language-sensitive formatting. We also started supporting markdown in Content block editor, you can read more about it here. We plan to extend this functionality the article editor as well.
The last thing that I'd like to address here is advanced article components (like pre-formatted alerts, notes, info boxes). It's definitely on our roadmap and we hope to start working on it sometime next year. You can always check our roadmap here.
2
Ryan McGrew
Glad I could help Matthias Miltenberger!
0
Matthias Miltenberger
Adding jQuery did the trick! Thanks, Ryan!
0
Ryan McGrew
Hey Matthias Miltenberger,
It looks like your upgraded theme is still dependent on jQuery. You can include the latest version of jQuery in your theme and that should address the issues you're seeing.
Thanks!
1
Matthias Miltenberger
We have been using highlight.js quite successfully in the past for our community, the guide, and ticket comments, but since upgrading the Zendesk theme to v2, the highlighting stopped working. This is very unfortunate and difficult to debug because it still works on some browsers/environments...
A native, built-in solution is much appreciated!
0
Daniel Wood
Have to admit, I am kind of amazed that it does not seem possible to create my own custom styles to be applied via the WYSIWYG drop-down, but am instead stuck with only 4 header styles.
I mean, what do you guys imagine a good help article to look like, format-wise, in 2020? Because I'm guessing it involves more than 4 different header sizes and the occasional bullet point list.
The fact that switching to code view does/can not grab my cursor position is just icing on the time-wasting cake. Hundreds and thousands of human-hours, wasted every day in this product, just scrolling back down through the Code View trying to find the paragraph or header where you need to apply that custom style...
4
Christophe LANDRET
There is a conflict between Prism.js and Zendesk which creates artifacts which deteriorates code reading. Zendesk Support confirmed this conflict but does not support this as Prism.js is a third party software that is not declared as officially compatible...
The fact that we have to deal with Zendesk code and possibly meet compatibility issue is a problem. A web developper is required to tackle all this stuff. And it takes time...
I really think Zendesk Guide should integrate code snippet hightlighting instead of relying on other open-source libraries for this purpose. Freshdesk does it perfectly and it is so easy with it. So why not Zendesk Guide?
1
First Data Support (MG)
@RyanMcGrew,
The code snippets that you mentioned are basic. Would be nice if Zendesk KnowledgeBase would support something like prism.js natively and not as part of additions to themes.
Often, the person that tries to edit the knowledge base is not the person that is responsible for the theme of the knowledge base.
In addition, these days, when a code snippet is provided, there is a need to provide several tabs for different languages.
For example, it is impossible to do an API Spec in Zendesk Knowledgebase. It doesn't look good.
0
Ryan McGrew
Hey Sean Leonard
We added support for code block snippets in the editor a little while back. It doesn't natively support code highlighting in the theme, but that can be added with the usage of of prism.js or hightlight.js in your theme. It doesn't yet support inline code snippets if that's what you need.
If this doesn't support your needs, please let me know more about what you need out of it.
Thanks!
0
Sign in to leave a comment.