Chris Dannen doesn’t much care for gadgets, and he only taught himself to code a few years ago. But that hasn’t stopped him from becoming the editor of a rather innovative and unusual technology blog.
Dannen heads a staff of freelance writers and one “news hacker” at Co.Labs, the most recent addition to Fast Company magazine’s family of web verticals. The nearly 20-year-old magazine has divided their web presence into one home site and four separate verticals, Co.Design, Co.Create, Co.Exist, and Co.Labs. The first three cover design, culture, and innovation, respectively.
Dannen had been a freelancer with the magazine when the editors offered him the job managing Co.Labs, a project they conceived of as an in-house lab that would cater to the tech community, not only as a blog, but as a place for experimentation and reflection. Dannen says he quickly realized the smartest move would be to focus on a topic that both interested and plagued him — the future of publishing.
In our conversation, Dannen discusses some of what he has learned in the first year of experimentation. In addition to their attempts at creating knowledge networks via stub posts (there’s even one about the future of journalism), we touched on Dannen’s openness with problematic metrics, de-siloing developers in the community of small publishers, and gathering data on the perfect headline. Here’s our conversation.
The impetus was really, as it always is, about money. Can we figure out a way create content that is either engaging enough that we can drive online subscriptions, or engaging enough that we can build events around it, or engaging enough that we can package it up and sell it. But the superintending assumption was we can’t live off banner ads forever, and even if we could, we might want to find some ways to make money that have a little more precision in the way that we measure them and the way we measure the engagement.
So that’s a very vague mission that I was given in January, and we launched the site in March. My idea was to take that vision and hone it in really sharply on the future of publishing and focus on, What is the proper format for an article? What is the meaning of rich media? What does it mean that all this stuff is networked? Should we be changing our distribution strategy? There are all these questions that the other verticals on our site don’t have time to experiment with. So we have FastCompany.com, but we also have our vertical sites Co.Exist, Co.Create, Co.Design, and now Co.Labs. So the idea was to basically let Labs kind of experiment and teach the other sites what we learned.
So we thought, when we cover these big, sprawling, slow-moving stories, why don’t we build a stub post, have updates as they come in, and when we get a source that’s really useful or something breaks, we’ll do those discrete articles, reported pieces, but then tie them back to the stub as the way of telling the reader, “If you’re not up on the story, if you need context, go back and read the stub and it will make sense why this is timely, and why this is a person we’re talking to.”
So what it’s really been able to do is let the reporters get right into their features and hit the ground running. For anyone who is not caught up, we always link back to the stub.
So that’s a win for two reasons. It doesn’t just make our feature article a little punchier, but it also helps us with another problem that we’ve been mulling, which is how to make our articles more relational. If you think about articles as a database, we have all these entries in the database, but they’re not very well related to each other. We do related links like everybody does at the bottom of our stories, but there isn’t really a schema that connects one part of a story to another.
So something that we found is that, when we internalized these feature stories and stubs, we get people bouncing back and forth, and maybe even bouncing to other different stubs. The ultimate goal — which I think and I hope based on our feedback anecdotally that we’re getting some limited success — is just introducing these individuals and events in context with plenty of information around, so you can understand what the timeliness is, why is this relevant, and who’s relevant to it.
But then there was a robust conversation in the comments about what types of conclusions you can draw from the types of data you’re using. So I’m curious about your original findings and also your takeaway from that, and moreover, how do you watch your traffic and how do you do it differently from other sites?
Obviously, the number one metric is something around engagement. We always want people to be hitting the site and staying there as long as possible. I don’t have numbers in front of me, but I believe our news hacker told me yesterday that on average, since we’ve started doing those stub posts, we’ve had a 42 percent increase in engagement.
So how exactly do we measure what we’re calling engagement? I’m actually going to do a followup post about that because it’s a big discussion and, as you saw in the comments there, there are plenty of things that you can turn on and off to affect whether you’re measuring someone as engaged. But I think that the overarching thing that we’re doing, that maybe some of our competitors aren’t, is, we’re looking less and less at how wide our reach is and more and more at how often people come back and how long they stay. And I don’t think we’re necessarily that cutting edge in that respect, but I’ve heard a lot of people say it’s better to have a core audience of 1,000 people that come back regularly than 10,000 who only come back once every couple months.
Part of the reason for Co.Labs existing is to figure out…those one thousand core readers, they don’t really represent you well when it comes time to sell banner ads, but it might be really useful to the site when it comes time to make money off of other things. So we’re trying to shift our model a little bit towards loyalty and engagement and not tons and tons of one-off hits and pageviews.
But of course, technology is so big — you have web developers over here and iOS developers and Windows developers, and they all read different stuff, and there are very few common threads, actually, in terms of the culture and the subject matter. So we realized we would actually have to hone in on what we were doing, which was building technology for a publishing company.
We’re hoping to mimic the other technical blogs of startups and companies that you see. There are a lot of really fantastic company blogs out there, and usually what they do is adopt this formula of writing about their own technology, obstacles, assumptions, trends they see, things that are in their wheelhouse, and then they use that as a conduit and a lens to talk about broader issues in technology. So we’re doing the same thing.
And that’s why we hired our news hacker Gabe from Google. He basically builds some of the experiments we’re working on in house and then we write about them. So we’ve got a lot of experiments underway. We really needed that hybrid editorial technical person for that.
So what ends up happening as we do more of these updates is we get more of these alias URLs and alias headlines that all point back to the same piece of content. We make the headlines specific to that days update, and then you kind of see this actually, “Hey, if you want more context on this, this story is actually about this bigger issue X, you can read on to find out more about this bigger issue.” So what we found is that, every time we do these updates, we get a new headline, a new URL, we tweet it out or we publish it on Facebook, our normal distribution methods, and we can actually test which headlines are people liking. Because obviously, it’s the same story, we’re just approaching it from a different angle every time we write the headline.
So it’s been really interesting to see — some headlines, they really hit. We probably should do more exhaustive headline testing, but somehow, we never have the time, or we just don’t have the means, and I think what this has taught us is that we need to be a lot more data-driven about what kind of headlines our readers like and which ones are specific to which distribution method. So, for example, I know that on Twitter, the fewer capitalizations and the less proper English I put in a tweet with a link, typically, the better it does. The more conversational I spin the article, the more people click. Whereas, on some other distribution methods, people want to read a real headline and not so much just my blurb.
I sort of struggle with what we’re going to do about that, but what I like — I should say, our intent is to adapt our CMS to the point where other people can annotate our articles and actually branch off an article and make their own version. We’ve already experimented with this a little bit using GitHub. We have the GitHub repository where the text of our articles get republished into this repository and you can take that text and change it and branch it off and make a new version and make corrections or edits or whatever.
But that’s not the best interface for that, because most of our readers aren’t expecting to find our content on GitHub. But we’re thinking maybe eventually we’ll build some kind of interface on GitHub, build it right into the site, so that if people don’t like the way something is written, or if they have a different or ancillary story to tell, then they can sort of get in there and start writing and people can you know see different versions. In that sense, it is like Wikipedia, as you said before.
So we put together this back page which essentially pulls in the article tags from the last 10 or 15 stories, and puts them in a grid. The idea is to use the tag field, which nobody ever really thinks about anymore since we’re out of the days of SEO, and put little teaser phrases in the tag field an then on the back page you get this derivative of what is essentially clickbait phrases or sobriquets, many of which lead back to the same article.
It’s sort of along the same lines of experimenting with headlines. You might take the article I mentioned about women in engineering. I could tag that one “How to scare away women,” and on the backpage all you see is this box that says “How to scare away women.” It’s hard not to click on that to find out what it’s about. It actually refers to a stub we wrote about that says a lot of job listings for engineers are written in a way that really only appeals to men and sort of makes women want to run. So that’s the back page, that’s one experiment.
I — we may run into issues with that in the future. There’s a lot of information, specifically financial information, which I might be privy to if I wanted to dig, but at the end of the day it’s actually not that interesting. The most sensitive stuff is probably not the most widely appealing to talk about. So, in that sense, I think our interests are aligned with our agenda to be transparent. But, then again, that situation could totally change.
But we’re trying to get really technical about, What are the challenges and what are the results? What should we be building? What needs to be built? What can be bought off the shelf? Really pragmatic stuff, for people who are running small publishing operations, which seem to be popping up all over the place.
What I’m really hoping to learn is actually just, how do we make use of all these new media as what is essentially publishing is becoming software, and software is becoming content? These things are sort of meeting in the middle, and it’s going to be really interesting to see what role video plays, what role audio is going to play. Audio has been really underutilized, I think. And how much of it is going to be livestreamed and how much will be prepackaged? What happens to the concept of having an issue — monthly or weekly issue, when we can just dump everything in a feed. I think the feed is maybe not the perfect paradigm in a lot of ways. I don’t know if that answers your question.
But right now, everyone’s sort of working on different stuff in different offices all around the city.