Enterprise Apps Are Moving To Single-Page Design

Editor's note: Alexander Aghassipour is chief product officer and co-founder of Zendesk. Shajith Chacko is lead software engineer at Zendesk. Both contributed to the development of the new Zendesk product. 

The Web is a far different place than it was when Zendesk launched six years ago. As more and more people use consumer apps like Twitter and Facebook, enterprise applications need to build an interactive experience that doesn't look old or slow when compared to the rest of the real-time Web.

As a cloud help-desk software provider, we recognized that our customers' needs were also changing. A few years ago, web support meant email. Today there's chat and click-to-talk voice support, and most customers demand instant answers and help. These real-time channels benefit from a more modern application approach than our original HTML application afforded. Fron the support side, customer support agents might be chatting with one customer while simultaneously updating another customer's files. Meanwhile, large support teams need to collaborate in real time. The platform can't slow the pace of work.

As our customer expectations have grown over the years, so has the application. Any evolving application reaches the point where another incremental change just won't do. Rip and replace was the only option in order to balance the complexity of features with the simplicity of design. Moving to a single-page, Java-based app enabled us to create an interactive, real- time experience that's streamlined and agile.

Selecting A JavaScript Framework

From a technical perspective, a single-page Web application is delivered as one page to the browser and typically does not require the page to be reloaded as the user navigates to different parts of the application. This results in faster navigation, more efficient network transfers, and better overall performance for the end user.

When it comes to designing single-page applications, there are several JavaScript frameworks available to facilitate the task of writing complex client-side applications. While the choice of frameworks is a rather subjective decision (and each developer will have his or her own opinion), we ultimately went with the Ember JavaScript Framework due to several key reasons:

• Ember.js is constructed with large applications in mind and fits a larger team and project like Zendesk.
• Ember.js has more conventions and structure, and these established conventions make it easier to bring new developers on board.
• Ember.js is primarily based on dynamic bindings that automatically update the UI when data changes; this allows us to easily describe UI that knows when to update.
• Ember has a vibrant, growing community of very clever people.

Other Technical Considerations

In addition to selecting a JavaScript framework, there are a few other things to keep in mind if you're considering a similar move to a single-page app.

• Before we could begin writing in JavaScript, we needed to significantly build out the API to cover everything. Modern one-page apps have a really effective API with the JavaScript client written on top. This was a large task, but the final API can now be used by the whole Zendesk community.

• A JavaScript application relies on browser features, such as advanced CSS. Therefore, supporting advanced features requires a fairly modern browser. Early on, we decided not to support IE8 and below in order to keep our development costs down. It's important to define the supported (and not supported) browsers from the start.

• While JavaScript tools are maturing by leaps and bounds, they aren't quite on par with what developers may be accustomed to using with HTML. For example, we didn't find an out-of-the-box testing automation tool to use, so developers needed to rely on manual testing or writing their own test scripts for testing in the browser.

Transitioning Developers From HTML To Java

Before we began the shift to a single-page application, only about 10 percent of our engineering resources went toward JavaScript coding. That was about to change dramatically. We ended up hiring just two JavaScript-only programmers, and for the rest we relied on ramping up the JavaScript skills in our existing engineering staff.

While learning any new skill takes time, we got buy-in from the engineers early on. Convincing our engineering teams to take on this challenge was relatively easy. This transition gives everyone the enviable opportunity to work with modern methodologies and tools. However, there still is a learning curve that must be factored into the project schedule.

Preparing For The Adjustment Period

No matter how fantastic the next-generation application may be, the simple fact is that existing end users have been happily accustomed to doing things a certain way. Getting used to changes to the status quo takes time.

To help ease the transition, we rolled out the new version of Zendesk for new accounts and trials. Existing customers are free to stay with the original Zendesk version for the time being. In addition, we started with a soft launch to a small subset of customers. This was followed by a four-month beta period, which allowed us to see how customers responded to the new design and workflow.

Ripping down an application to rebuild is a risky proposition. However, it's sometimes the only way to move forward. The journey requires a commitment from all involved – including end users and developers. A major project of this scope won't happen overnight, but the agility, performance, and real-time nature of the results are well worth the effort.