Dannen: I’ll start with my background. I started with Fast Company as an intern in early 2007. I subsequently became a freelancer, and I’ve been freelancing for the magazine and the website on and off since, so I’ve know those folks for a long time. In the intervening time, I was doing other projects — things like working on startups, I did some consulting, I taught myself how to design software. I did a lot of reading. I did some traveling. And when I came back to do more writing last fall, the editor-in-chief and our executive editor and our CTO had this idea of having a lab inside the magazine where we could kind of experiment with kind of formats, different technologies, different ways of publishing.

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.

Dannen: Yeah, actually, it already has. The idea of doing what we call the stub posts was not original to me — it was actually an idea that our top editors had been kicking around for a while, but because our content management system doesn’t support articles in that format, nobody had really tried it. So what we did was decided that we would try to make our article work in kind of a stop-gap way, and that’s what we do, and what my post was about. How do we turn this discrete article format in a more flexible, growing format? So now we’re in the process of retooling our CMS to accommodate that format in a little more of a natural way.

Dannen: I guess, in hindsight, what we were really missing was something between a short news post and a long reported piece. And the reason that there’s a gap there, the reason that we needed something in the middle, was that there are a lot of scenarios where we have a feature or a reported story that is applicable to a greater story line, that is part of a bigger schema of events. The problem is that, when you go to write that feature, the reporter is put in this position of reexplaining all that context all over again at the top of the article, just so that the reader can dive in and make use of the new reporting. That’s a real time suck, and it also makes writing articles a lot more onerous. It makes our features longer than they have to be.

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.

Dannen: Yeah, you could think of it as a really messy version of a wiki. At Wikipedia, their taxonomy is to separate by person, place, or thing. What we’re essentially doing is mixing all those things up, but we’re saying there’s a common storyline here. So, for example, women in engineering is one of our most popular stubs. We’re saying the dearth of women in engineering is a common storyline, but you see that story pop up in all kinds of places, and all we’re really doing is sort of tying disparate events or findings or studies, tying the disparate things together and showing that they’re part of one common narrative, and that makes it easier for us to address that narrative when we go and do features.

Dannen: We use Google Analytics and Chartbeat. That’s what I use on a day-to-day basis. And we also use Omniture on a longer term basis. But I don’t think we look at metrics differently than anyone else.

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.

Dannen: Yeah, this is my sort of thing to prove to the other sites that we can do more with the core group and maybe even grow that core group a little slower.

Dannen: That’s a good question. There’s a lot of ins and outs there. The first thing — I’ll talk about our news hacker in a second — but the first thing I realized early on was that we would not only have to write about technology. Originally we were going to be a developer-centric site and write about issues relevant to developers. It was going to be just another Co site, except more in depth and tech-focused.

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.

Dannen: You know, I haven’t read most of what are considered the flagship techblogs. I visit them so infrequently that it’s become almost a joke. Because all they write about is phones and Apple and Microsoft and Facebook. These guys are not producing news that is really compelling. If you’re not a gadget freak, then this stuff just, it doesn’t really get at the core of what’s interesting about technology, which is people solving real-world problems, bringing in digital and figuring out new ways of doing things. It’s kind of part of the maker culture we’re trying to cover. Gizmodo is also probably moving in that direction, we’re just doing it in a much more self-conscious way. We’re talking about things we’re doing in house.

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.

Dannen: Well, we actually write about those experiments ourselves, he and I. From a staffing perspective there’s myself and Gabe, one lead writer, and anywhere from 5 to 8 freelancers in a given week who are contributing. The freelancers mostly write about whatever is germane to their beat, but Gabe and I are pretty much owning the in-house experiments.

Dannen: One thing that I underestimated was the importance of using and testing multiple headlines for the same piece of content. One of the things that is great about the stub articles that I mentioned is, what we do every time we update one, we change the headline and we change the deck and we put the update at the top of the article and push the old updates down the page. And then we update the authored on date. So the system essentially looks at the new post with a new URL, but it’s really the same old story, it’s just been updated.

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.

Dannen: It is, although comments are a constant quandary, because the comment area is really not the best place to engage with people, and it’s definitely not the best place for a new reader to feel enfranchised on the site.

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.

Dannen: The back page is something that Gabe our news hacker built under the assumption that there might be better homepage formats for certain readers. Right now, our homepage is really pretty and it looks great if it’s your first time for the site. You’ll get a good feel for what kind of content we’re running and it has an overall magazine feel. But it’s not particularly hard hitting — it doesn’t show you a lot of stories at once and doesn’t allow you to quickly browse through a lot of stories at once.

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.

Dannen: [laughs] Well, it’s always related to that women in engineering stub. That word comes up again and again when we interview people. You know, whether it’s bro culture or bro-ing out, I don’t know. It does pop up.

Dannen: We intend on being wildly transparent about what goes on on the site. So far, we haven’t had any pushback from the executive editor or the editor-in-chief, and I think so far they’ve been nothing but encouraging about talking about what we’re doing.

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.

Dannen: My priority right now is to recruit as many individuals and startups who are working in the area of new media or new content publishing aggregation, news, that whole schema — to get as many of those people guest authoring for us and getting interviewed by our reporters. Because there doesn’t seem to be, that I’ve found, a super technically literate place to talk out the future of media.

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.

Dannen: I think it’s going to be huge for us. I think the role of editors in the coming next few years is going to be to determine which stories are going to be the ones that we invest the resources in. Obviously, we have limited resources and a handful of feature stories that we make our big bets on. To me, editorial judgment is going to be much more about allocating resources to a story and figuring out, Where do we take the time for video and infographics, and where do we do just text?

Dannen: I think, like I said, that when it comes down to actually sharing code, the universe of developers is so segmented that right now it’s not feasible to do a tutorial and have it be really popular, because everyone is using different technologies. But I think in a couple years we’ll have it narrowed down: What are the best technologies for front end and back end, and what can we all contribute? Which open source projects are we all going to invest in?

But right now, everyone’s sort of working on different stuff in different offices all around the city.