I Miss Staging

The days of setting up your own CMS and publishing all your stuff on your own site are, for now at least, over. Your CMS isn’t social, is the problem. What you’re supposed to do now is use as many media services as you can while building as little as possible, and then promote everything to everything else and hope for the best. For example, at Postlight we use Medium for daily publishing, LibSyn and Soundcloud for podcasts, Mailchimp for email, Meetup for event promotion, and Buffer for coordinating tweets and posts.

On Tuesday Postlight rolled out a new newsletter design and name and moved to a new Medium “collection.” Normal stuff for a company, and no big deal. Lots of little things went wrong—the stuff that happens when you do anything digital, like domain name issues, or things breaking on mobile devices. The problem is it all went wrong in public. It made me realize how much I miss staging environments.

How we lost staging

A staging environment is what it sounds like: A server that you can use for testing, that’s like the real web server in every possible regard, except only a few people know it exists. You develop and test on your local computer, thoroughly test in staging, and then push to production—and only then does the world see.

However when you spread your thoughts and ideas across multiple media platforms there’s typically no such thing as a “staging” environment. You just update the templates, point the domain names somewhere, and hope to god it all works out. Sometimes you can schedule when things post, sometimes you can’t. Staging has been replaced with a tweeted announcement that you’re aware of the problem.

Because there are so many platforms and clients, a lot of the time you can’t even see what your users are seeing—they’re using their own podcast players, their own Twitter client, and so forth. It’s an active challenge to see your own cross-platform media empire as your users see it. (There are services like Buffer or Percolate that let you schedule how your media goes out, and they are great for what they do, but in a practical sense they only let you defer your mistakes.) For example, I’ve had to edit our podcast titles about six times now because some podcast playback software shows titles one way, some another, and the tools I’m using don’t offer advice for how to proceed. Trial-and-error moves us forward.

This is how we used to develop in the last decade, hitting reload on different browsers on different operating systems and adding special cases to our code until everything looked and worked okay. Eventually a consistent platform emerged.

If the future is not in people setting up their own sites, but in people putting things on different sites and letting it all spread out across social graphs, then it’s going to be a pretty amateurish future. (Obviously this may not be the actual future; the actual future may involve us desperately trying to grow wheat on boats. It’s more like the “conventional wisdom of the Internet future.”)

I wonder what happens now

Here are some things that might be helpful:

• Content publishing services (Soundcloud, Medium, etc.) could offer a staging service that lets users preview exactly how things will look. (Mailchimp is good at this—they give you tons of ways to preview what your content will look like and that helps you find all kinds of bugs.) Other content publishing tools should offer the ability to preview—not just the current article, but your entire environment. What will your account look like tomorrow, the next day, or at an arbitrary time in the future?
• A service could arise that lets organizations (like ours) preview how things look to different people. “Here is a one-minute video that shows how an Android user in Bulgaria sees your podcast-newsletter-Twitter-Facebook-Meetup-web-page empire.” What a treat that would be to watch.
• A service could arise that let an organization (like ours) create a single “brand style sheet” that all platforms could use to set up colors, titles, fonts, contact information, high-resolution logos, things like that. Why do I need to upload the same assets/avatars/URLs over and over again across 50 platforms? I should be able to host that somewhere and just point to it.
• There could be a cross-platform standard for notifications that allows them to be managed and aggregated instead of just blowing up my phone and desktop. Notifications from the various services where we publish and do stuff poop on my phone all night. Signal gets lost. It’s sad.

Too many platforms

This is on my mind because I made a list of all the services we use and it turns out, when you count all the Twitter accounts and our Github and Dribble pages, plus the apps and services we ourselves have created or that we manage, there are more than 50 different ways that our company talks to the world. We are six months old and we have more media platforms than we have employees.

This represents a lot of risk, a lot of ways to screw up in public, and a lot of hours down the hole fiddling with background images, all in the name of efficiency.

The traditional tech-industry answer for this level of complexity is analytics to measure reach, but numbers don’t help as much as people imagine and they often distract. The only real measure of success is “are people talking to Postlight about new business and coming to our events?” We can measure success as something like “received one good email this week.” If that’s working, and the list is, basically, growing, then steady as it goes. Every bar graph showing engagement time is basically hand-waving.

My goals are to look buttoned-up, to have good things that people want to read and hear, and to publish in a way that at the very least won’t annoy or inconvenience our readers. I can’t actually be sure about that last part without a ton of labor.

There’s no one solution, and I don’t think most people even see it as a problem. I do, though—I wish there was the shared concept of a staging environment for our multi-platform future, and I’m also cautiously optimistic that, in time, there will be.