All the engineering that goes into democratically designing a help widget
[Edit Notes: Late last year we relaunched the Freshworks’ help widget which sits on a website and helps support customers better. In this multi-part blog written by our engineering team, we talk about how we picked the components and technologies that went into it and the improvements we made to it.]
Freshworks lets businesses collect feedback from their customers directly from the website, portal or any third party webpage with a pop-up widget that can be configured to look like a small tab on the side of the screen. It can also be configured as a widget that can be embedded on a page.
The widget opens up to display a contact form with ticket fields as configured inside Freshdesk, the helpdesk software from Freshworks. The fields can be pre-populated with meta-information like name and email address, making it easier to create a ticket. It can also be configured to let end customers attach files and prevent spam.
It worked well for a long time. But as proponents of Indian Democratic Design, we needed for it to be simple, scalable, self-reliant, well crafted and affordable. For instance, the old widget would collect feedback and create a support request which was then addressed by the support team. But then, we needed it to be more realtime to make things powerfully simple for the user. We also didn’t have ways to proactively engage with users in the older widget. This was important for us to make end-users more self-reliant. Customers were unable to customize the widget; it didn’t carry their brand and looked a little out of place when embedded into a website. This wasn’t good enough for us as people who understand that craftsmanship is all about the details.
So as usual, sometime last year we hunkered down and rebuilt the widget from scratch based on the feedback from our customers. We ended up evaluating various technologies and made several decisions and learned a bunch of things from different sources. This article is an attempt to pay it forward in the spirit of sharing our lessons.
So without further ado, let’s dive straight in. Here are the five key things we set out to do.
Improved UX
The biggest gripe our customers had with the feedback widget was that it wasn’t customizable. The old feedback widget was just a page rendered on our servers and had dated UI/UX patterns. We wanted to choose a framework that enabled us to provide a fresh experience in terms of look and feel to our customers.
The new help widget is completely customizable. This means it can carry brand colors and truly blend into the identity of the customer’s website. One can even pick from a bunch of color gradients.
Performance
The old widget took longer to load and act on a users’ input. That was mainly because the widget was rendered on our server. The markup, javascript, and styling were pushed from the server to the client. If the server took longer to respond, the widget became slower. We wanted the new help widget to be faster.
We were also rendering forms containing numerous fields, configured for particular customer accounts. This meant we were able to render the form only after the server sent the list of form fields to the client. This was another performance bottleneck.
With the new widget, we wanted to make sure that the widget loads quickly in the customer’s browser, and they have a snappier experience. Now we keep a tab on asset sizes and load times as part of our development pipeline for the widget codebase. We also make sure that new features don’t sacrifice performance.
Accessibility
The old feedback widget was not built with accessibility guidelines in mind. We used browser-based accessibility audit tools and fixed accessibility issues that cropped up.
We also wanted to make accessibility a priority. It is now a mandatory requirement for all products at Freshworks to clear certain accessibility thresholds.
Decoupling implementation
The first task at hand was to decouple the widget code from our product since we wanted to rewrite using new technology. We had our old widget code in RAILS and we decided to build the new one using React.js (more on that later in this series). So it was necessary for us to create a separate repository for the widget code. We still rely on API responses from the RAILS application but a lot of things are now being done independently with the widget, allowing us to develop and deploy faster.
Widget Integrations
Among the many asks from our product team, one was to enable third-party integrations within the widget so customers can accomplish many things. This would help prevent our codebase from bloating. To support third party integrations and build interfaces for them in the widget is a serious engineering challenge and we don’t support that yet. But that’s something we want to build and the current version is built with that in mind.
Now that we’re clear on what we set out to do, let’s move on to how we accomplished all of that. In the posts that follow, we will cover the metrics and tools we used to evaluate newer frameworks, why we chose react.js after comparing it with four other frameworks, how we made the user experience and performance better, how we addressed accessibility, decoupled implementation and how we’re accounting for third party integrations in the future.
