In almost every app that we build at FlyoverWorks, there ends up being a home page that provides an introduction to the product, its features, and its goals. This is a good example of a page that is content heavy, but is usually fairly complex in HTML structure and CSS styling.

Typically, we waver back and forth between building this page directly into the app and building it in the CMS. Building it into the app makes sense because it affords us the speed benefits of developing locally, inclusion in version control, and makes it impossible for someone to accidentally delete the content out of the CMS. But building it directly into the app prevents our clients from editing the content on their own. They have to ask us to help out with every change -- an obviously unnecessary bottleneck. If we build the page in the CMS, then the client can edit it directly, but we lose all of the benefits of building it into the app.

The CMS packages that we’ve used in the past try to solve these issues in a variety of ways. They come up with new templating languages or complex deployment and migration schemes. The introduction of these things has always bothered me a little. Why do I want an additional templating language when we have one already (erb or haml, for the technical folks out there)? Why do I need a complex migration scheme when we already have a well established one for developing and deploying normal applications?

These issues led us to what we think is a fairly important realization: content, copy, and very basic formatting belongs in the CMS; complex page structure, styling, and interactions belongs in the application. None of the other CMS’s we’ve tried focus on the content part of content management. Encouraging users to build large, complex pages in the CMS is exactly what forces CMS authors to build more and more complex features, so that they can handle the various use cases that complex pages present. But complex page structures are already well served by traditional development environments. What we wanted was a CMS that allowed our clients to edit content in an app, but that didn’t provide so much functionality that it was confusing or easy to accidentally break things in the app.

We couldn’t find what we were looking for, so after several months of work, we’re happy to present Storytime to the world. Storytime is a Rails-based, content-focused CMS engine. It includes the table-stakes features you’d expect of a CMS: static content pages, a blog, image uploads, and role-based user authorization. But in our quest to focus on content, we also introduced a concept that we call text snippets.

Text snippets allow us to provide pieces of content that can be edited in the CMS, but we can build the bulk of the HTML/CSS into the application itself. They’re easy to utilize from the main app, giving us the local development benefits mentioned above, but they also enable clients and non-technical users to edit the content as needed.

We’ve been using Storytime on a number of client projects so far, but we would love to hear feedback on twitter: @flyoverworks or @bcroesch.