Creative commons photo by limonada on Flickr

As I sat down with my colleagues on Tuesday for a little hack day on our favourite open-source content management system, we had a familiar conversation — one that is probably familiar to all people who hack on CMSs — which is, What is the future of content management?

It’s a conversation that has been unfolding and evolving for many, many years, but seems to be a gaining a lot of steam again in 2011.

The essence of some of the more recent conversation is nicely summarized over on Stijn’s blog.

One of the questions presented is: will tomorrow’s CMS be a monolithic app, or a ‘confederation’ of purpose-built micro-applications — like the app that Talking Points Memo demonstrates for managing their front page, for example.

In the blog post on the TPM media lab about the ‘Twilight of the CMS,’ they describe their solution to the problem of the monolithic CMS — “a simple and flexible API that digests manifold requests from the different applications.”

As I ponder these ideas in the context of my work for online-only publishers like TheTyee.ca, I struggle with a few competing notions…

Read-only API, or Read/Write API

In the case of TheTyee.ca, the monolithic CMS writes data to a data store (Elastic Search) that directly provides the (soon to actually be public) public API. From there, various applications can request the data from the API and receive a structured JSON representation of that data back as a response. Basically, once these clients have the data, they can do what they want.

This is great. It’s a read-only scenario. The CMS is still the ‘authority’ on the state and structure of the data (along with a lot of other information), but there is an identical copy of that data in the store that provides the API.

Now, let’s think about that TPM front page management app: it clearly needs read/write access to their API, because it can change not just layout, but editorial content like the story title, deck, teaser, and so on.

So, if the API is read/write, the questions I have are:

• The schema for the documents (the stories, etc.) must be validated somewhere, right? So… does that logic live in each purpose-built app, or as a layer on top of the data store? And does that then violate a bit of the ‘Don’t Repeat Yourself’ design pattern?

• Do these content-centric writes to the API make their way back to the CMS or editorial workflow system? And, if they don’t, does that not introduce some confusion about mis-matched titles, decks, teasers, and so on? For example, say I change title of a story on the front page, but now I see a typo in the body of story and want to fix that, so I go into the other CMS and search for … whoops! … what was the title of that story again?

• How does this new ‘front page app,’ or the read/write API, handle typically CMS-y things like competing or conflicting write requests? Or version control? Or audit trails of who made which edits? If one, or the other, or both, actually handle these concerns, is this not a duplication of logic that’s already in the CMS?

Perhaps I’m not thinking about this right, but my gut is saying that the idea of a read/write API — a scenario where you have both a CMS (Movable Type in TPM’s case) and a ‘front page management’ app — starts to get a bit tricky when you think about all the roles that the CMS plays in the day-to-day of a site like TPM.

It gets even more tricky when you think about all the delivery mediums that have their own ‘front page’ — tablet experiences, scaled down mobile experiences, feeds, e-newsletters, and so on.

Presentation management or editorial management

The other thing that is immediately striking about the TPM demo is the bizarrely print-centric feel to the experience — I’m immediately transported back to my (very brief) days working at The Varsity where the editors and designers would literally paste up the newspaper’s pages on big boards.

For a publication like the TPM — an entirely online ‘paper’ — it seems like an odd, slightly ‘retro,’ approach in an age that is defined by content that defies containers. One must ask: where does it end? Should there be a purpose-built app for each section’s front page, e.g., Sports, Arts, Life, etc.? For each regional section? For each-and-every article?

Isn’t this just vanity at some level? Endless bit-twiddling to make things look ‘just right’? Kinda’ like those mornings when I just can’t decide whether to wear a black shirt or a white shirt and stand in front of the mirror trying them on for what seems like eternity.

So, coming back to my point: in a time when many believe (like a religion!) that content and presentation should be separated — not as an exercise, but because that content is delivered to literally hundreds of different end-user experiences (phones, tablets, readers, etc.) — do we really want to be building tools that focus on the presentation for just one of those experiences? If so, where does it end?

For the most part, the modern-day CMS has been designed to alleviate these myriad challenges by providing a way for non-technical people to input structured data, and the tools for developers to output that structured data in a variety of ways, formats, and mediums.

Watching the TPM video gives me some ideas about how to improve the experience for an editor to quickly edit headlines, decks, teasers, photos of the morning’s stories — and even to indicate their relative priority in terms of newsworthiness — but I would want to stop there, at the editorial, and let the presentation layer be handled according to the medium, device, or experience the content is being delivered to.

Loosely coupled monoliths & read-only APIs

Many moons ago, I proposed that Wienberger’s Small Pieces Loosely Joined idea held true for content management also. The proposal was simple: instead of investing in one monolithic CMS — a CMS that did everything from manage content to advertising delivery to comments to search to who-knows-what (a trend in CMS projects at the time) — an organization could choose the current ‘best in class’ solution for each need and connect them together through loose coupling. Then, if a better solution came out for, say, comments, the old system could be replaced with the newer system without having to re-build the whole enchilada.

(Of course, the flip side often is that louse coupling can feel like bubble gum and string when you have to work with it every day.)

So, while my own experience is that loose coupling is great, and that purpose-specific applications are usually better than apps that try to do everything, I would personally want to draw the line somewhere. For me, that line is between distinct ‘areas of responsibility,’ like editorial, advertising, design, community, search, and so on.

In this scenario, each area would have the authority over its own data, and the logic for how that data is structured and validated, and so on. If that data was written to a central data store that provided an API — something simple, flexible, and RESTful — the other apps in a ‘confederation’ could read from it, choose what to do with it, how to present it, and so on, but the final ‘say’ on that data would be from the app that is responsible for creating it.

For me, this is a sensible way to allow these apps to work in concert without having the logic about the data living in multiple places, i.e., the API, and the clients that can write to it (which makes sense if you’re Twitter with hundreds of external clients, but not if you’re one organization building exclusively internal client apps).

Would love to hear otherwise, or experiences of how others are handling this or thinking about the challenge.

If you’ve ever sat in a room where I’ve given a presentation on digital publishing, or run into me at a some kind of publishing-related event, you will already know that I am no fan of so-called ‘digital editions’. In my experience, they are often expensive and questionable investments that rarely lead to any significant revenue (unless you’re Playboy).

As each year passes, I think to myself “finally, it must be the end of digital editions.” Alas, that has not proved to be the case.

There is such a burst of new technologies available today for creating divine digital reading experiences that I am just floored that certain well-known digital edition vendors are still (very successfully) peddling crap.

I know they are still successful, because I continue to be asked by publishers “Do you think we should invest in a digital edition? If so, who should we work with? Or what tool should we use?”

Publishers are in a predicament, it is quite clear to see. Readers are asking for digital products as more of their life moves to new devices. The advantages of having a digital product to offer those readers are clear:

• Keep the subscriber instead of losing them
• Deliver a product that (hopefully) costs less to produce and deliver, while still charging a reasonable subscription price
• Provide a ‘free trial issue’ with very low fulfillment costs
• Make international subscriptions more affordable and easier to fulfill
• Access to back issues
• Last but not least, keeping the cost of renewals low because “digital in, digital renewal”

The challenge is that the range of devices that readers are using is multiplying and the digital edition vendors have not caught up. Not only have they not caught up on the devices, but — more importantly — they are not even close to catching up on the reading experience that people expect today.

Anyway, this is turning into more of a rant than a useful blog post, so I’ll try to get it back on track here…

If you’re a publisher and you’re thinking about investing in a digital edition, start with these questions:

1. Digital edition vs. adaptable reading experience: Do you want to provide readers with an experience that is device-appropriate, or one that is simply a replica of your print layout? (The reasoning “We can re-use photos licensed for print in a new medium if we don’t change the layout” should not drive your answer to this question.) The term ‘mobile’ applies to just about everything these days — laptops (increasingly smaller), tablets (various sizes), and smart phones (various screen resolutions) — and it’s unlikely that a print layout is going to be an enjoyable reading experiences across them all.

2. InDesign-centric vs. Web-centric: Do you want to work from the Web version of your stories — the version that includes links to other sites, links to related articles, and so on — or the version that comes out of the print workflow? Remember, if you have a Web site there’s a good chance that you’ve already invested in getting your print-centric content into a digital content management system — thus, you’ve already done the work of the print-to-digital conversion for most devices.

3. “Somebody do it for us” vs. Do-it-yourself: Finally, do you want to have the control to present your publication the way you want, with the features that your readers want, and own all the data? Or do you want someone to just “get it done” and “keep it working?” Remember, it’s pretty likely that you already have a circulation plan that can be adapted to these digital subscribers, and it’s likely that you’re already taking payments online and managing access to your Web site. Integrating those processes and system into your digital products is not as hard as you think.

There have been some incredible advances over the last year in the capabilities of the modern Web browser. It is the idea of ‘the Web in your pocket’ that draws many people to these new digital devices. And these new devices all run ‘the Web.’ Each of the major platforms — iOS, Android, Blackberry, Windows Phone, Palm WebOS, Kindle — have versions of their devices that support current Web technologies like HTML5, CSS, and Javascript. This opens up a whole new field of opportunity for you — as a publisher — to think about delivering amazing digital experiences, not just a ‘digital edition.’

If you don’t know where to start exploring what’s possible, here are a few pointers:

• Adobe’s demo of CSS3 regions: Rich page layout with HTML and CSS3

• HTML5 frameworks for phones & tablets, like Sencha Touch, jQuery Mobile, and TreeSaver

• Straight-up HTML5 adaptations that live-and-breath on the Web, like Phil Gyford’s adaptation of the Guardian UK or Zeit Online’s tablet-optimized site (you’ll need to visit the site on a tablet to see it in action)

• There are also newer cross-purpose frameworks coming out like The Baker Framework, and tools like PhoneGap, that can give publishers the best of both worlds — content stored in web-friendly, future proof, open standards and device-native ‘Apps’ that make it easier to get found in app stores like Apple, Amazon, or Android Market.

Hopefully that will give you a place to start. Still have questions, drop me a line. Are you experimenting with a framework, technology, or approach not listed above, leave a comment.

“Piracy is the result of a bad API” — Brian O’Leary, Magellan Media Partners

This past Tuesday night, I made my way over to the Pilot Tavern for the first Code Meet Print TO meet-up.

I’m glad that I did.

Code Meet Print TO — “Where texts meet technology.” — is pulling together a number of very interesting strings. I’m loath to say it’s about “the future of the book” because, after hearing Brian O’Leary’s talk that night, I’m not sure that Code Meet Print is about books at all.

The talk, titled “Context First,” asks some interesting questions about what is broken in the publishing workflow of today. Cheap publishing tools, ubiquitous Internet, and new start-up entrants into the publishing market are changing the field entirely, and traditional publishers may want to up their game.

What’s really interesting to me, however, is that this same conversation is happening in the context of journalism and news.

It’s not surprising really — after all publishing is publishing — but it is eye-opening to see the two perspectives side-by-side.

Take for example Jay Rosen’s thoughts on the Future of Context (more here, and here).

… Or Matt Thompson’s, or Tristan Harris’.

This is all timely, because I’m pushing myself and my comrades on the Beautiful Trouble project to stop calling it a “book project.” We’re working differently, and we’re thinking Web-first. But what does that mean exactly when working with a book publisher, and contributors who are thinking “book”?

Here are a few quick ideas that we’re exploring:

• Personalization: Andrew was the first to propose a mix-and-match model that would enable people to put together their own view of the content based on their interest. Perhaps they would download that? Perhaps they would print it out? I’m now questioning both. But it’s an interesting idea.

• Background: As contributors work on their pieces, we should encourage them to capture as much of their research process as possible in the content. Links, footnotes, video, audio, graphics, etc. They may not flow into the container called “book,” but they’ll be available to other containers that can make use of them.

• Wikification: Both John Maxwell and the folks at FLOSS Manuals are pushing the Wiki-first, book later model. It’s interesting and I’m keen to explore it, but I fear that our contributors will not use a Wiki (no matter now ‘user friendly’ it is). Writers like something that looks like a word processor, not like a small editing window in a page of distractions. I’ve heard good things about Press Books, so I’ll have to check that out. In the meantime, we’re going to give it a shot with structured Google Docs.

• Incentives: What exactly are the incentives for the contributors these days? Jay Rosen talks about the potentially negative incentives in newsrooms: the rush to break a story, etc. Many young journalists I talk to still want that press clipping to show their parents. Contributors to a book probably expect a book. Are there new incentives that are being missed in the shadow of tradition? The jury is still out on this for me.

• Constraints: We went into the Beautiful Trouble project with a mental constraint about the length of each piece, or module. But as we see the pieces coming in — some shorter, some longer, some much longer — we have to struggle with that question. Yesterday I asked: why are we putting constraints on length at all? I’m all for constraints on quality, and understand the concern about short attention spans that also imply constraints — but the constraints of one possible output container seem artificial when I start to think about a Web-first publication.

Your turn: What else should I be exploring, thinking about, or reading-up on the topic of ‘Context First’?