I’ve been thinking a fair amount recently about life in a post-WordPress world. Specifically, I’ve been pondering what a fully modern CMS might look like if it were designed in 2016 from mature, stable technologies with the goal of giving publishers the flexibility they need to solve their number one problem, i.e. how to make money by typing things onto the Internet for other people to look at.

There are a lot of ideas out there for how to keep the content business afloat: crowdfunding, paywalls, voluntary subscriptions, native advertising, and so on. I don’t know which combination of these approaches will be the answer, but I do know that it will take a lot of iterating for different publications of different sizes in different niches to figure out how to keep going in a world of rising ad blocking and declining CPMs.

Given that there’s a massive amount of business model iteration between today’s online publishing world and a sustainable, profitable future, the number one thing that a CMS can do is enable that iteration. This means maximum flexibility, the kind that a monolithic CMS platform like WordPress can ironically take from you in the name of “extensibility”.

Note that a flexible, modern CMS isn’t just important for folks in the media business. In-house blogs are an increasingly critical part of an online presence for businesses of all types and sizes, as the slow implosion of online advertising is ironically making quality, original content more valuable again in some quarters. If clickthrough rates are in the toilet thanks to either slow-loading banners or ad blockers, then SEO becomes an increasingly crucial source of traffic, and email becomes increasingly important as a user retention mechanism. Google is getting smarter and better at identifying and surfacing quality content to search users, so more non-media businesses are standing up in-house publishing operations because good content brings good traffic and good leads.

The TL;DR of this first section is that publishers need maximum flexibility from a publishing solution – they need to be able to try literally anything to extract money from users and advertisers, and marketers need maximum flexibility for using content to attract SEO traffic.

The NoCMS

Now, I keep saying this word: “flexibility”, and I know what you’re thinking: “isn’t WordPress basically the world’s largest Swiss Army Knife?” Yep, and that’s exactly the problem. As a publisher or content marketer, I don’t need a giant multitool; I need a construction kit. I need Lego, and in particular I need the much-maligned modern Lego with all the pre-fab parts that let me quickly assemble a school bus + Malibu mansion mashup, driven by a cop in riot gear.

I’m going to call the modern, flexible, revenue-oriented CMS that I envision the “NoCMS”, loosely on the model of the “NoSQL” movement. “NoSQL” stands for “not only SQL”, and it’s not so much about ditching SQL as it is about augmenting it with different kinds of key-value and document stores. For me, “NoCMS” isn’t about getting rid of the CMS, rather, it’s about shrinking the CMS back to its original role as a multiuser platform for managing content, while leaving all the other stuff – distribution, monetization, community, and other aspects of online publishing – to a loose collection of more purpose-built tools.

Of course, I’m obviously not the only person thinking along these lines right now, in fact I’m sort of late to the party. Software like Middleman and platforms like Contentful and Netlify are already making great strides in this direction. And here at Collective Idea, we have our own static-site-generator/CMS product, Harmony, that we use on some client projects. We’re in the process of rewriting it from the ground up, and this piece and its followups are part of the internal conversation that we’re having around our “Harmony Next” project.

Stakeholders

Whenever you’re considering a new piece of software it’s important to identify stakeholders. For a CMS, you might think that the process is straightforward, and it is if you’re just talking about a personal blog. But, if you’re trying to build a polished online publication around multiple voices that can not only help you with SEO and lead generation, but also let you experiment with new ways of monetizing content and community, then you have to broaden the circle of stakeholders to encompass more than just “people who hit ‘Publish’”.

Before we can design a new CMS, we need to look at the types of people who matter for a serious online publication, and outline each type’s needs and quirks. This will help us come up with some design goals for a CMS that works the way we need it to in 2016.

Note that my target audience for this hypothetical NoCMS publishing platform is not solo bloggers or the non-tech-savvy. This is for people who are serious about content and who have access to at least a little bit of programming and editorial talent. You shouldn’t need rockstar programmers or editors to run a publishing shop, but if you have access to the talent then you shouldn’t be held back by the limitations of a monolithic blogging platform.

Now, on to the stakeholder categories.

Readers

Readers come first, always. Here are the technical (i.e. non-editorial) things that matter for readers, even if they don’t always consciously know it:

Mobile first: This may mean responsive or separate layouts. But assume that most of your traffic will eventually be mobile and optimize accordingly.

Speed and page weight: 9MB page loads and 30-second waterfalls are symptoms of a broken business model. A great CMS shouldn’t prevent publishers from assaulting their readers with fat, JavaScript-heavy pages that grind away at their bandwidth quotas and laptop batteries, but it should definitely actively enable publishers who want to keep page weights down and speeds up.

Ad blocking: This is here, it’s not going away, and pretty soon it will be as commonplace as email SPAM filtering. There’s no use throwing a tantrum about it, just figure out how to deal with it.

Tagging: In most cases tags are terrible UX – I’ve never been part of a site where anyone actually clicked on these – but they’re good inputs to an algorithm that can surface relevant content.

Sidebars and “related content” units: Most popular, most emailed, related stories, stories from partners, and the like are all click magnets and can drive up engagement metrics like time-on-site and pages per session.

Any CMS front-end that’s intended for serious use will have to take into account all of the above, at a minimum. And when someone else comes up with a reader-facing idea that seems to be working really well for them, the CMS should make it easy for you to copy that idea on your own site.

Writers and Editors

Here are some things that writers and editors care about when using a CMS.

Familiarity and ease of use: “We really love to take non-tech-savvy writers and train them to use this flashy new CMS UI”, said no publisher, ever.

Version control (auditing and rewind): Editors need to know who edited what and when, and they need to be able to rewind it.

Locking: If someone is editing a post, then they don’t want anyone overwriting their changes. They also don’t want anyone watching them edit. Seriously, there is no large contingent of writers and editors out there screaming for a collaborative editing interface where they can see each other typing in realtime; there are only programmers who are high on the latest JS framework and who are dying to mangle a UI with it. Just implement a WordPress-style locking function and forget about the collaborative editing thing.

A good source view + preview combination: Any serious CMS needs a good source view, because the people whose job it is to make content look nice for readers need to be able to edit the source. Related to this, I think the Medium-inspired in-place editing trend will fizzle out, at least for everything but casual applications. That sort of thing is fine for a site like Medium that is what it is, but if you’re serious about having a hackable CMS then you can’t box in any of your editors or layout people by tying them down to WYSIWYG-only. They need to be able get in and edit the source.

Image gallery support with ease of upload/import and insert: This is something that WordPress does really well, and it’s a critical element that’s missing from many would-be WordPress replacements. I think that back-office-only solutions like Contentful and ButterCMS don’t take this seriously because they don’t know how huge it is for writer productivity. Selecting images and sprinkling them throughout a post is a giant, tedious pain, and it’s the last thing any writer or editor wants to do before hitting “Publish”. But posts with images vastly outperform large blocks of text, so it’s a necessity. So make dealing with images in the editing view as painless as possible.

Post statuses: The ability to flag posts as having various statuses, and then filter posts by status, is critical to an editorial workflow. A CMS should support “draft”, “pending”, “scheduled”, and “published” statuses at minimum, but bonus points for letting editors create their own statuses and filter by them.

Scheduled post support: Serious users need to schedule posts to go live at a certain time. Also, this feature cannot ever fail: if it’s too early, then you blew an embargo and may get sued. If it’s too late, then you missed a scoop.

Permission levels: Writer and editor roles at the very least are needed to keep everyone in their lane.

I could actually sum up 90% of the above discussion of writer/editor-facing issues by saying, “just copy whatever WordPress does, and make it look like WordPress, even down to the color scheme and icons”. I know that most people reading this just had a seizure when I said that, but the reality is that everyone you will ever hire already knows how to use WordPress. There is zero on-boarding with WordPress, and zero user support. Over the course of my editing and publishing career, I have worked with retirees who live in rural Mississippi and who are still double-clicking on hyperlinks, and even those people know how to use WordPress.

Another way of putting this is that the WordPress has many serious problems, but none of them have to do with the back office interface for CRUDing assets. Everyone may hate the way WordPress looks, but at this point we’re all familiar with it, and that familiarity is a huge advantage for any publication that uses it and hires freelancers.

Community

If you’re putting in enough effort to be at least semi-serious about publishing, then you want to be at least semi-serious about community, as well.

Of course, I should say at the outset that in my experience communities are impossible to build intentionally, i.e. if you start out saying “I’m going to create a community about X” you will probably fail. You can’t just spin up a thriving community out of nowhere, no matter how much money you throw at it, which is why most companies that want to own online communities just identify existing ones and buy them.

That said, you want to have the infrastructure for it if lighting strikes in your particular case, and you happen to get a community of commenters who care about your content and your brand. It probably won’t happen, but if it does then it’s magic and you’ll want to capitalize on it, so it makes sense to leave the door open for it.

User accounts: Users need to be able to make accounts so they can comment, and more importantly, so that they can hand over their email addresses. More on that in the next section, though.

Comments: I know that many publications are moving away from comments, and I understand why. But unless you have a really good, well-thought-out reason for not having comments, you should just have them (see the “leave the door open” bit above). Nested or flat comments is up to you, but I think that Disqus and Facebook have accustomed users to a certain level of nesting, so I’d go nested on any new project.

New comment notifications: One of the biggest things that a good blog does is bring people back, and one of the best ways to do that is to send commenters an alert whenever there’s a new comment in a thread that they’ve participated in. Facebook and Disqus both do this to great effect. (I know that Joel Spolsky thinks these thread notifications actually prevent people from coming back, but Joel Spolsky is wrong about this.)

Moderation tools: You will have to moderate, period. Don’t even consider a comments system that doesn’t offer at least basic moderation tools. You don’t necessarily need things like upvotes, karma, and user messaging, but users should be able to flag a post, and mods should be able to delete posts and ban users by IP.

You might argue that the items above shouldn’t really be part of a “CMS” discussion, and you may be right. But I put them in here because community is such an important consideration when thinking about the big picture, that it’s critical to keep it in mind when thinking about a CMS.

Number Crunchers

Number crunchers are the people who are responsible for taking the assets in the CMS’s database and turning them into money. That doesn’t just happen all by itself, and in fact in many cases nowadays it doesn’t happen at all. But if you’re going to have a fighting chance, then here are some things you need to think about:

User accounts: Giving away your user accounts to FB and Disqus is a mistake. Don’t do it unless you absolutely cannot spin up and host your own commenting system. Make people give you an email address in order to sign up. I say this, because in 2016 comments aren’t valuable – everybody in the world has comments on everything all the time, and most of them are abusive, off-topic garbage. No, what’s important is having users. If you’re not going to have users that are your users, then there’s no point in having comments. Furthermore, if a user isn’t committed enough to your brand to create an account, then they aren’t likely to contribute anything worthwhile via a comments box, so you won’t miss them. (And on the flip side, if you’re not offering enough to users to entice them to create an account and engage, then you need to reevaluate what you’re doing.)

User analytics: You can’t get money from people you don’t know, nor can you sell an undifferentiated mass of “eyeballs” to an advertiser. The more ways you can slice and dice your audience’s data, the better. If at all possible, you should own your own user data. Don’t just give it away to Disqus, FB, or Google Analytics.

User communication: One reason that you want to own your own user accounts and data is so you can communicate with your users in order to ask them to come back and visit your site, or so you can sell them things. Email marketing works really well, so you need to be able to capture email addresses so that you can do lead generation and implement user retention strategies.

User payments: Whether you’re building a paywall or doing some crowd-sourcing scheme, you need a way for your users to give you money directly. That way, you can experiment with offering different things and figuring out what, if anything, people will pay you for.

Advertising: In this age of ad blockers, it’s important to be able to serve your own ad assets in a variety of sizes and formats that are loaded server-side. If you can insert ads server-side, you can make them indistinguishable from content. And when I say “ads”, I also mean lead-generation widgets and the aforementioned “related content” widgets that sell more of your content to users who’ve landed on an article page from a search engine.

Gated content: More publications are going to start experimenting with paywalls in various forms, and probably sooner rather than later. They’ll do this because they’re going out of business anyway, so they might as well give charging readers a shot before they close up shop. Thus a publishing platform in 2016 must be able to painlessly accommodate tons of experimentation around different types of paid content strategies, whether it’s per-article payments, site-wide subscriptions, network-wide subscriptions, crowdfunding, or whatever else someone will try next. Even lead-gen sites will want to “paywall” content by requiring a user to give up some data – an email address or some survey answers – before viewing certain content. At some point, therefore, you’ll need a way to determine if a reader has taken some action on the platform that has granted them permission to access a particular piece of content.

TBD: The most important revenue-related item on this list is “TBD”, because it’s the one that you’re going formulate, deploy, measure, and then either iterate or abandon. And you’ll do this over and over again until you either win or run out of money.

Dev and ops

These are the folks whose job it is to support and empower all of the above folks, and who worry about new features and web-scale delivery of the assets that are in the CMS’s database. I throw them in here because they think about things like query and view caching, query plans, CDNs, static pages, and all of the platform-dependent plumbing that goes into making a site fast and scalable. Increasingly, they also have to find ways to get half a dozen different pools of user data to sync up.

I won’t break out any of their issues in detail, though, because we’ll have to sort out what the CMS tech stack looks like, first.

Conclusion to Part 1

If you’re shopping for a publishing platform, or you’re considering designing one, then all of the above are things that you need to think about.

Yeah, you can just use WordPress and get most of that stuff. But it’s also the case that there are tons of third party services and mature, maintained plug-ins for popular frameworks like Rails and Django that do everything (and every little tiny sub-part of everything) I’ve described above. Not only do you not need a monolithic CMS platform like WordPress, but you’d be a lot better off if you could and mix and match and play around with all of the options that are out there, to come up with a combination that works for you. Nothing listed above is rocket science – all of the problems outlined here haven’t just been solved, in most cases they’ve crushed five or six times over.

The challenge lies in integrating all of these elements in a way that’s performant, scalable, and (above all) flexible. The question for the NoCMS in 2016 is, what sort of platform will let a publisher – one who can afford only a part-time, intermediate-level developer – put all of these pieces together, and then swap them out swiftly and cheaply as they iterate their business model?

Stay tuned for Part 2, where we’ll talk about software, and about how to divide up the above along meaningful application boundaries.