Recently there’s been some discussion about the possibility of Zendesk removing Markdown support. I wanted to add some further clarity, explaining why we’re thinking of doing that and how we would go about it. Then, I’d like to have a calm, constructive discussion with you all on that topic.
This post is going to be very in-depth, so buckle in for a long ride.
First, some background into what brought us to this point.
About “Content Creation” in Zendesk
As we have expanded our product, *content creation* has become a big part of what you (especially if you’re an agent) do within Zendesk. This is a non-exhaustive list of where we consider content creation to exist:
- Ticket comments (both inbound and outbound)
- Macro comment actions
- Notification bodies (Triggers, Welcome, Password Reset, etc)
- Knowledge base articles and comments
- Community posts and comments
That might seem like a small list, but all these items generate tons of content collectively.
When reading back that list, an experienced Zendesk user will be able to tell you that each have their own rather unique ways of creating that content. It will be some sort of inconsistent mix of nothing, Markdown and/or HTML. Where possible, we believe inconsistency across anywhere you create content makes Zendesk difficult to use and learn.
About “Compose” in Zendesk
Only a couple of years ago we began observing and researching agents working in Zendesk far more closely. Previously we were focusing mostly on support managers and upper-management.
As a result of doing this, we formed a team of product managers, engineers and designers to look after what we now call the “Agent Experience”. That is anything that an agent does as part of their day-to-day job within Zendesk. Our aim is to make it as effortless as possible for agents to get their job done.
We began by focusing on collaboration which saw improvements made to agent collision and ticket real time updates. Then we moved our attention to “Compose”, which looks at what it takes for an agent to craft a response to a customer and move on in their workflow.
Compose actually includes much more than the editor, it includes all the interactions taken by an agent when making a response. Macros, KB lookup, parts of the comment stream, etc are all part of compose.
Putting Content Creation, Agent Experience and Compose together
Over the past year we have been watching agents do their jobs (it’s as creepy as it sounds) and generally talking to a whole lot of them.
The resounding feedback we get is that creating content in Zendesk *is* a lot of effort. While most of our research went into Compose within the ticketing system, that research also included Help Center.
It became clear to us that the majority of agents either:
- Didn’t know that you could do rich content in Zendesk by using Markdown
- If they did know, they usually couldn’t get on with it. Learning a syntax is hard, but being flawless in its execution is even harder
- Agents wanted *way more* content tools than Markdown would be able to offer, else we begin coming up with our own “flavors”
Agents cited tools such as Gmail, Outlook, Word, Google Docs, Hangouts, and of course competitor products which those agents had used. They expected not only visual tools to help them format their content, but expected that content to look exactly as it will when saved.
They expected a WYSIWYG (What You See Is What You Get) editor.
From Text to HTML
With the exception of Help Center, Zendesk does not save HTML content. In fact, everything to do with tickets has - up until now - been saved as plain text.
You might be wondering, then, how is it Zendesk is able to display Markdown as rich content if we’re not saving HTML? We render on-the-fly. The save pipeline goes something like this:
Receive > Sanitize > Save Text
And the rendering pipeline something like this:
Read > Turn Markdown to HTML > Turn Liquid to HTML > Render
So when you’re typing your ticket comment in Zendesk today (i.e. within the comment box), what you’re seeing before you hit “Preview” is exactly what gets saved. It only looks different because we run it through a rendering pipeline before it reaches you.
This makes a few of things rather challenging:
- When we receive emails, we have to convert them to plain text in order to save them. Luckily most emails come with a plaintext version so we just use that. This also means you lose a lot of formatting as an agent reading an email processed through Zendesk
- There isn’t *really* such thing as a good Markdown editor, or at least not WYSIWYG. They all involve some amount of crazy hoop jumping to render, which causes an unreliable experience between composition and final rendering
- Markdown has a deliberate limitation on exactly what you can do with it - it was never intended to replace HTML, instead just a tool for web writing. This means any adjustments to it (such as resizing images) would have to be done with a “flavor” of Markdown, complicating the syntax
Removing Markdown from the equation makes the saving and rendering of comments very different in Zendesk. The save pipeline now looks something like this:
Receive > Sanitize > Transform > Save HTML
Both the Sanitize and Transform steps are significant. We essentially normalize the HTML, stripping anything we don’t allow. We then transform things which essentially means manipulating elements, adding data attributes, etc.
Rendering, then, becomes much simpler:
Read > Render
Admittedly that’s a gross simplification as there’s some transposing going on to extract a data layer, but we are able to essentially render what we saved.
By us going through this little transition into another save/render pipeline, we’re able to do a lot more:
- We can finally begin preserving formatting on inbound emails. This is underway at the moment, and the early progress looks good
- We can add far more robust support for formatting which Markdown does not have outside manipulating it (tables, resizing images, etc)
- We can offer a far better experience for dragging or pasting in images, where adding images to comments is a huge effort with Markdown
- We can take advantage of data to enhance the compose experience. For example, when you add a placeholder we can render that placeholder’s value immediately but it will actually be saved *as* the placeholder. This can go further in Macros, for example, where we can introduce templates, hot areas, and other things you’ve been asking for
So all in all, we believe HTML will give us a far, far superior experience for you, agents and end-users. That’s right, end-users will finally be able to submit comments from the Web UI using bolds, italics, and inline images without needing to learn Markdown or HTML.
Considering removal of Markdown
We are considering the removal of Markdown from Zendesk. Along with the above, here’s a few more reasons why that’s a consideration:
- Markdown has a learning curve to it. If you are unfamiliar with syntax in general, there’s added complexity
- Markdown is limited in its formatting capabilities. While we can add more by essentially making it up, that simply adds to the complexity
- Markdown usage in Zendesk is low, namely due to it being perceived as hard to learn and use, or seen as less efficient
- Having two very different rendering pipelines is not something we would like to support. It’s not something we can easily make a per-use preference, and even at the account level switching between them becomes an issue
- Similarly, we will end up investing far more effort into the Rich Content Editor than we will Markdown
- The Rich Content Editor can be used almost anywhere - including end-user requests via Help Center - without much if any learning curve
There’s plenty to discuss here, and I also appreciate there’s some strong feelings around the whole thing.
We’re looking for feedback on this topic: comments, questions, concerns, and fears. Please keep it constructive, and be nice!
Please sign in to leave a comment.