Last week I introduced you to one of the original animating ideas behind Inkling Habitat, treating books as software to transform the eBook production process. Today I'd like to take you behind the scenes and show you the technologies and processes we used to build Inkling Habitat itself. How did we build this software?
Going deeper, much of the application follows what's called a Model View Controller (MVC) architecture. We use Backbone.js as our general MVC system, while using Handlebars.js as the templating language for rendering our views.
querySelector and CSS Flex Box layout.
Early in our history we used a little bit of MooTools, but found it frankly unnecessary. We have mostly ripped all of it out of the system and are close to eliminating it.
In order to keep our CSS manageable we use SASS, which makes large scale development with CSS much easier. We also use Compass above that as a kind of reusable set of SASS primitives that we can lean on.
Inkling Habitat on the client side is well encapsulated from the server. The server exposes clean RESTian APIs that have a number of resources we can lean on, creating a nice division of responsibilities. Behind these RESTian APIs is a mix of Python and Scala; I won't go into the server side of the system as I concentrate on the client side, and we are well encapsulated on the client side from those details.
The system itself is divided into several major areas of functionality. We have our blueprints, which are interactive pieces of functionality that a user can add to content, such as slide lines, assessments, audio/video, maps, etc. These blueprints can be previewed and edited. Behind these blueprints is actually an XML-based dialect rather than HTML. We have a simple XML binding infrastructure to pull these different blueprints in and turn them into Backbone models. Backbone views can then manipulate the Backbone models behind these blueprints for editing and previewing; as they do the XML behind them seamlessly update and can be saved when the user is finished. We call this simple binding system XML Templates, as they are roughly similar to Handlebars templates but for XML.
Next, we have a general document infrastructure to deal with our different kinds of documents, whether they are HTML5-based or the XML-based blueprints. The general application shell works with this document layer in order to provide consistent navigation, saving, URL history, etc. independent of the kind of document we are dealing with. Layered on top of our general document types is our proofing infrastructure, which allows us to create tickets on either blueprints or HTML content.
Next, we have our rich text editing system. This includes our code editor based on Ace and the rich text editor itself for visually editing HTML. These two editors are bidirectional, allowing someone to either directly edit the markup or visually edit the preview depending on their needs.
The visual HTML editor itself wraps ContentEditable under the covers and includes several fixes for ContentEditable to work as expected, mostly around ensuring that visually edited markup stays as semantic HTML. We also have a bidirectional undo/redo system that works across both the HTML code editor and visual editor. The rich text editor also includes our pattern picker, which makes it easy to drop in chunks of content.
We have a very strong culture of shipping, are action oriented, and work iteratively. We are on two week sprints and are continuously getting code out the door.
At the same time we also have a very strong product and UX culture, so we're constantly asking "are these the right features that serve peoples' needs" and "is this the best user experience possible?" We actively work with prototypes, visual design, and user research as we are developing, creating a great mix of shipping (Real Artists Ship) and continuously refining the direction that we are going. This produces a nimble culture of shipping and doing the right thing at the same time.
We internally use GitHub and have a strong code review culture. Everything that lands on master is reviewed by two people. GitHub is great to work with; our internal revision control system is Git itself for all of our code. The combination of strong tests and code reviews makes for a robust culture in terms of quality.
In all of our sprints we generally try to spend ten to fifteen percent of our time addressing tech debt, and work hard to both ship great features and UX while also addressing tech debt and making sure that we keep our code and architecture elegant and straightforward.
We also have a strong software craftmanship ethos. We think both the little things and the big things are important. If the small things are clean in your code (and in the UX!), then the big things will also be clean. We really take pride in the code we create.
Engineers are a big part of also having empathy with our users and working in conjunction with product managers and user experience folks to craft what's the right thing for our users and customers. Engineers regularly meet with actual customers and work in conjunction with the team to craft the best solution to problems.
Sound like an interesting way to pass the time? Consider joining the Inkling Habitat team and redefining how digital publishing is done! Feel free to email me if you are interested.
Subscribe to my RSS feed and follow me on Twitter to stay up to date on new posts.
Please note that this is my personal blog — the views expressed on these pages are mine alone and not those of my employer.