Customizing Zendesk

We use Zendesk for our support site, but even though it’s a third party site we want our users to feel right at home when they are visiting there. In order to accomplish this, we have made use of Zendesk’s impressive customization options, which let us write our own custom CSS and Javascript.

It’s All About the Widgets

As part of Zendesk’s service, users have access to an array of “widgets” that can be leveraged to customize your presence. These widgets have the capacity to be exposed to as many, or as few, end users as you’d like. Zendesk breaks it down into three groups – “Agents,” or members of the support team, “Logged in end-users” and “Anyone.” For our customization, I used the CSS and Javascript widgets.

I broke up my CSS into two widgets – one for all users, and one just for Agents, since Zendesk offers added functionality for Agents that’s not present for everyone else. The bulk of my CSS was applied to the Everyone stylesheet, and then I just tweaked the Admin stylesheet to account for the differing interface elements.


Javascript to the Rescue!

The trickiest aspect to this customization was that I needed more “hooks” (unique identifiers) to attach CSS rules to than I was provided. I applied a handful of scripts that used Prototype’s addClassName method to get some extra classes (my biggest target was the navigation links). We also wanted to update some of the links in the header of the Support site. Unfortunately, Zendesk doesn’t offer any mechanism to adjust those links through their management console, but Javascript again came to the rescue. Using Prototype’s update method we changed the content of a handful of the navigational links, and then with insert we added a few new links (back to the main site, for example). This was all relatively painless, and so far has worked without issue.

Something to Keep in Mind

Widgets (at least the CSS and JS widgets) are loaded in alphabetical order. So if you name you CSS widgets ‘admin’ and ‘everyone,’ the ‘admin’ widget is going to get loaded first, which means that anything you’re trying to reset in the ‘everyone’ stylesheet won’t work. In order to offset this, and still give the widgets meaningful names, I just numbered them – “1 – Everyone”, “2 – Admin,” etc. With the Javascript widgets you’ll want to keep this in mind, too, since occasionally load order is important.

Also, the presented experience varies widely from user to user, with the forms that are being filled out and the different potential use cases for the application, so make sure to test as many of those paths as possible. Submit forms as an anonymous user, then have an Agent interact with that ticket, and make sure that all of the presented experiences are what you would expect. This does mean that you’ll clutter up your help desk a bit, but you can always go back in and remove the extraneous content before you deploy the site.

Customing Zendesk was largely an easy and pleasant experience. Getting all of the pieces in place was simple, and load times weren’t noticeably hampered by our customization. Furthermore, when we had questions, Zendesk’s support crew were quick to respond with informative answers that solved our problems quickly. Feel free to check out our support site and let us know what you think!