Mobile web

The Opportunity

As with many of KDIs in-house projects, Onscribe grew out of our personal need for a seamless way to add subscription payment gateways to our products and services. Whilst there are existing solutions in the market, there was nothing that met with our company requirement to have tools built on open source APIs, that let us maintain control of our own data. After refining the API to meet our own requirements, we decided to shape the service into an easy to use web and mobile interface and release it to the public.

In the true spirit of "eating your own dog food", the Onscribe service features flexible subscription plans, including a free tier, that are managed using the Onscribe API.

The Stack

Whilst we love new technologies, we have come to respect our chosen stack, affectionately known in house as "BUJH". To the uninitiated, that's Backbone.js, Underscore, JQuery and Handlebars.js. On the server side, these days our preference is Node.js.

Our Approach


KDI is a small team, and we follow a true agile methodology, meaning that our designers and developers work in collaboration throughout the development process. It's fair to say that in our team, everyone is a designer and everyone is a developer.

Good designers code

All our designers code. And we don't just mean they dabble with some prototypes that the "real coders" will have to fix later. Our designers are encouraged to write solid, production ready code. And whilst they are all experts at the regular suite of design tools, our designers start designing the product where it's going to live: in the code.

To assist with this we develop and maintain our own boilerplate for both client and server side code. Yeah, we know, there's a mountain of existing tools out there, HTML5 Boilerplate, Twitter Bootstrap, Foundation, to name a few. Don't get us wrong, these are good tools. They give you everything AND the kitchen sink. And that's exactly the problem for us. We want to keep our code lean and mean. And more importantly, we want to ensure our code is reusable and easy to maintain. Any innovation we make when developing a project gets fed back into the core.

Code IS art

Just as our designers code, our coders are artists. There's a story about Steve Jobs insisting Apple's hardware be beautiful on the inside - that every part of the computer be aesthetically pleasing, including the circuit boards. We get this idea. We keep this in mind when we code. We have a firm disdain for hacks, and avoid writing temporary code that needs to be fixed later. Good cooks clean as they go and so do good coders. In a small team, we know only too well and there never is a "later". Or rather, later is for the poor guy or gal who inherits your code.

View the source

Visit Onscribe and take a look at the source. The first thing you might notice is that everything is minified. Secondly you may notice that there's nothing in there that shouldn't be. We take the separation of concerns very seriously. Look carefully. You won't find any in-line JavaScript polluting the code. For example, it's considered standard practice to inject the JavaScript user object into the markup. We don't follow this practice. IOHO, doing so pollutes the markup, makes the initial page load slower and blocks rendering. Instead we contain the code that is dynamically generated from the server and is unique for each user, in an external JavaScript file, and load it neatly at the bottom of the code, with the other JavaScript call. Yep, just one other JavaScript file (not a plethora of third party plug-ins).

Less is more

Same goes for our CSS. We use Less as our preprocessor of choice. In development, we maintain separate styles sheets that roughly match each Backbone.js view. In production we end up with just three minified styles sheets, including the common.css, adding up to just 21.1kb total.

Product Highlights

  • All assets are compressed and minified as part of the Grunt render
  • Require.js allows us to include one main javascript call, minimising server calls and improving site performance
  • The javascript user object is generated dynamically from the server and store in an external js file, rather than being injected into the markup
  • Designers and Developers work in collaboration
  • Designing in code allow us to create rapid prototypes and iterate quickly

More stories