A Case for Innovation is a video series to inspire newsrooms to break out of tradition and innovate.Read More
Remember back when people used to write about their work on their personal domains instead of Medium? Remember when I had time to write about every project I was involved with instead of being more concerned about shipping things and keeping my teams happy? It seems as though I will only ever find the time to write about my teams' work on my own website once a year now. So here is my annual brain dump.
What we worked on in 2016
Last year was a weird one for me, where I spent the entirety of it directing two amazing but very different teams: (1) a multimedia storytelling team (2) a brand identity team. Though I haven't been writing about it here, we've made sure to write about it elsewhere:
- Brand Identity: We relaunched Curbed, our home brand
- Brand Identity: In relauching Curbed, we got the ball moving on a new and very important version of Chorus, our publishing platform
- Brand Identity: We relaunched Recode, our tech/biz brand
- Brand Identity: We relaunched Racked, our retail brand
- Brand Identity: We made a new design system to support Vox's first conference
- Storytelling: We merged our R&D team and storytelling tools team into a new studio within editorial, The Storytelling Studio
- Storytelling: We published an exhaustive interview and essay with Hillary Clinton
- Storytelling: Worked with Racked on their first foray into menswear
- Team & process: Continued our culture of quarterly documentation days
- Team & process: Formalized our culture of moodboarding and early ideation
- Team & process: Tried a bunch of different ways to fight meeting burnout
- Storytelling: Dabbled in AI-based audio storytelling
- Team & process: Reimagined scrum as a project-based standup
- Team & process: Continued our tradition of weekly team bonding
- Storytelling: Designed for user screenshotting behavior in our Trump Tax piece
- Team & process: Worked harder at making design reviews more productive
- Team & process: Got smarter about integrating content testing into user testing
- Storytelling: Started building out multiplatform design systems for every storytelling project
- Storytelling: Played with integrating personalized dynamic data into longforms
- Storytelling: An exhaustive guide to how immigration shaped American food culture
- Storytelling: Worked with our OpenNews fellow to launch an open source tool for video editing
- Storytelling: Worked with the Vox team to build election tools
- Brand Identity: Relaunched The Verge
Phew, that was a lot! And that's just the big stuff for teams that I touched in some ways — a very small part of what Vox Media does overall. Just a few months into 2017, we've already done a ton more (live inauguration annotations, a massive FF7 Oral History, dabbling in video games, launching a Facebook bot, more dynamic personal data).
As you might notice, the last few years I've gone farther away from the actual bylined work as an active contributor, and have been working more on creating frameworks for teams to work efficiently.
Now that the Storytelling Studio and Brand Identities have found a good rhythm for continuing to grow, I'm moving on to a new role...
What's new for Lauren in 2017
As of this week, I'm Vox Media's new Executive Director for Operations, working closely with our first-ever COO. What a COO does is different at every company, depending on the CEO and the immediate needs. For me and Trei, that focus will be on creating frameworks to move quickly, make decisions, and execute efficiently on the company's most pressing cross-departmental initiatives. My role specifically is one deeply immersed in the "execution" piece of that last sentence. Basically taking what I've always done best, and elevating it to the most business-critical projects: building teams, making documentation core, organizing and communicating, and unblocking people to do their best work. Onward through the fog!
We like to iterate a lot at Vox Media. Not just on our software and our content, but also on our internal team structure. I started in January 2014 as the Product Manager for The Verge, and in mid-July 2015, I stopped doing that and joined forces with a freshly-hired Ryan Mark to start a new group, the Vox Product Editorial Apps team.
In creating the apps team, we were looking to solve for silos of work happening across all our media brands, which had dedicated storytelling designers and developers building out different solutions to solve the same problems. We brought those teams into a smaller, centralized team to work on standardizing and scaling our products. In January 2015, we further evolved the Editorial Apps group, and created a new group called Editorial Products, broken into three themes — editorial apps, embedded data and design, and platform editorial tools.
I am incredibly excited about where this team has gone and how much we've done in a year. Our output of work has been so fast and so frequent that I haven't had time to properly document what we've done, this consider this my State of Editorial Products report, a recap of some of the best work the team has done in the past year.
Please note, this report is about the Editorial Products team that I help oversee, not the product team as whole, or any of our other very important groups.
- We grew from a team of 5 to a team of 18, including all of our embedded hires.
- We've written more than 48 pages of internal documents about our processes and best practices, not including all the wiki pages in Github.
- We've worked on 311 projects. I'm counting projects here as anything that got a Trello card on my board. Things range from documentation, to building out quick graphics, to working on multi-month projects with newsroom teams.
- We've open sourced 7 projects.
We've published about 50 big editorial apps, all of which I will not recap here. These are examples of a few of the big ones for each of our media brands.
Interactives and data
Part of what our team does is serve as an art department for Vox Media. Our stellar illustrators Dylan Lathrop and Brittany Holloway-Brown are to thank for all of these.
As you can tell from some of the work above, a lot of what we do on this team is take a project we did for one site, then redo it with different information or content or art or data for another site. So we've done a lot of work on our Middleman Rig to reduce redundancy.
Our biggest project was the release of Autotune, which deserves its own post about how amazing it is. We built this application to address the problem of reusability in our work. This project is open source and available to everyone. Ryan Mark says it best:
As any news hacker knows, one of the most challenging requests we get is for "more of those things." We'll make a neat chart, visualization or map, which sees some success: our readers or reporters like it or maybe it helps tell a better story. You better believe other folks will come around asking for "one of those charts like on that one story."
One of the most difficult messages to communicate to our non-developer colleagues is how tricky "reusability" is. The common misconception is that once software is built, it can be reused. In reality, software is almost always built to accomplish a specific task in a specific context with no thought to how it might be reused.
It may sound as if this is a problem, a lack of foresight or a rookie mistake, but it is not. It is almost always a mistake to attempt to build reusable software from the start without taking the time to understand how it will be used and why. Working under deadline, building something for a specific story, is the worst time to try to anticipate how the code will be used in the future.
The goal of Autotune is to shorten the gap between building a one-off website or interactive graphic and building a reusable tool for generating many things.
We've come a long way with how we get things done on the team. Taking project requests from seven different newsrooms isn't easy. Through our team structure and process, we're being very deliberate about enforcing a product lifecycle that lets us continue to innovate, while making sure we institutionalize the successes — building once for use, and rebuilding for reuse.
You can read more about how we're doing this on the Vox Product Blog, though it shouldn't be surprising to hear that we're about to change this all up again, now that we've grown to a nearly 20-person team.
That's where we're at with the Editorial Products group at Vox Media after nearly a year of existing in varied structures. This is just an overview of what we've done in the past year. We've learned a lot about how to make this work scale even better, and I hope to share more about our findings and experiments in Q3 and Q4.
The morning after Nilay became Verge's editor in chief, I got a phone call from him telling me that he wanted to do a hack week. "That's a great idea, let's do it!" I said, agreeing to a thing that I thought would happen in a few months, after much planning and scheming.
"Let's do it next Monday," was Nilay's original suggestion. We pushed it out a week from there, hosting a hack week from Aug.18-22.
Lesson 1: Not planning can be a good thing
The hack weeks I've personally organized in the past have been very meticulously planned out, much like product team's Vax was. People submit ideas, they do a bunch of upfront work, there's sometimes a theme and predefined teams. And that works for certain types of events. What I never anticipated was that it would also work to not plan.
We did this a week after the idea came about. By not having a strict set of projects lined up and set teams, ideas were able to naturally arise and editorial-product collaborations could happen more organically. We ended up hacking on a per-story basis, rather than the overall systems.
Lesson 2: Ok, but a little bit of planning is also good
That all said, we did make sure to have a few tools lined up (all 100% stolen from Yuri) to get people's brains turning about what's possible. The Wednesday before Hack Week, I set up a little dashboard that included links to all the tools, docs on how to use them, and other resources relevant to getting hack week started. This ensured that we could have a few items ready to go on Day 1, since we were playing out our hack week in real time, in public.
Lesson 3: It's about more than hacking on technology
We were hacking on content and on culture and on relationships. It was under this premise that we were able to get away with less planning. People who had never interacted were talking to each other. Editorial got insight into what makes a good product, and product got insight into what's important editorially. We were able to peek at each other's workflows and ask each other questions.
Takeaways and planning your own hack week
- Make sure someone from each discipline is involved. I mistakenly totally forgot about including designers the first time around (apart from the interns) and we would have struggled and failed without them.
- Make sure to secure actual, physical space. On day 1, we ended up making a mini product room outside of the product room because there wasn't anywhere to sit, and more importantly, there was nowhere to plug in our dying laptops. By day two, we had cleared out space in the main newsroom to sit with plenty of outlet real estate.
- If you're not going to plan, do a daily scrum. Without people working on dedicated projects, it quickly became easy to lose track of who is working on what and easy to not set and meet goals. Doing a daily scrum helps you achieve this. Hell, I'd throw in an afternoon checkin as well, since the pace of work is much quicker.
More reading about our hack week:
The Verge has been really good at doing and designing longform storytelling — telling a single story, as a single snapshot in time. When Matthew Schnipper joined The Verge from Fader magazine in April, he asked what was next of the features department.
Although our definition is continuing evolve — away from features and more toward a special projects desk — the interim place where we landed is to make all-encompassing guides that tell many sides of a story using many types of media and letting readers jump in and explore in whichever order they want.
Our first project taking this approach is our Virtual Reality series. Virtual Reality is a perfect topic for The Verge, a site about the future, because it's just making the transition from being super techy subculture, to being mainstream mom n' pop tech. Verge wrote about VR from every angle — its roots, its present, projections for the future. Here are some screenshots:
This project is also one of our first using our new middleman rig built by Ryan Mark, which lets us more quickly spin up editorial apps and template them.
- Ryan Mark, developer.
- Rebecca Lai, developer.
- Uy Tieu, designer
- Matt Schnipper, editor.
- Thomas Houston, editor.
- Adi Robertson, primary reporter.
- Lauren Rabaino, product manager.
Also check it out on your phone and in your browser to see the awesome cover interaction that follows your mouse and uses your accelerometer.
It's August, meaning I've been in New York and at Vox Media for almost eight months now. It's been crazy and energizing and a ton of fun. Here are some things I've worked on and what's next for me.
What I've been working on
Product manager is a new role for me. I've done very similar things in past roles, but this is the first time my sole focus has been solely on seeing a product through and making sure it succeeds. It's super refreshing to have so much focus, and I'm 100% sure I was made to be a product manager. It's a role I love and keep learning more and more about.
In addition to launching two bigger projects, an email newsletter and new series called This Is My Next, I've been working with engineers to make many small product improvements. My role as Verge's PM means I manage the entire site as a product, and am in charge of its backlog. We've added cool behind-the-scenes product improvements like:
- Changing the behavior of our linksets at the bottom of each article to have more granular control of which "read these next" links display where and when.
- Added video support to our end-of-page linksets.
- Added the option for "promo headlines" to the site, empowering editors to have a different headline at the homepage level than other spots on the site where a headline might appear standalone, without other contextual details of the story page.
- Changed the "trending now" bar on The Verge from being updated manually to being powered by realtime analytics data
- Ongoing project to responsify The Verge, which will launch by the fall.
In addition to managing the backlog, we've also worked with the newsroom to build out cool storytelling features:
When I started with Vox Media, we had dedicated product teams on each vertical, which is how we were able to build some of the features referenced above. But a few months ago, all of the product managers got together and did an inventory of the kind of work we were doing and the amount of time we were spending on art-directed storytelling, and we reassessed that structure. Which leads me to...
What I'm up to next: Editorial Apps Team!
About a month ago, I started product managing a new team, called the Editorial Apps team. Ryan Mark, who just started at Vox about two months ago from The Chicago Tribune, is leading us from the engineering side. We have a crazy strong team, which consists of:
Our team works with reporters and editors to tell stories on the web in impactful, innovative and engaging ways. In the day-to-day, we participate in art direction and presentation of stories, editorial planning and analysis of data. Through our work, we'll focus on big-picture thinking and experimenting around how Vox Media continues to evolve its storytelling. But a key to all this is that we'll develop software and processes and provide training to support, streamline and scale the most successful of these endeavors.
And of course, we maintain close communication with video, sales, Vox Creative and the ad products team to ensure that editorial work drives revenue.
Specifically, we'll focus on these areas:
Light art direction, code reviews, training, photos sourcing and treatment, and other light production work. High-touch graphics, illustrations, logos, interactive visualizations and other experiences that can engage our readership beyond what is possible with text alone.
Assisting reporters in retrieving, managing and analyzing data necessary in the course of their work. Building relationships with reporters and help them find interesting stories in datasets. We want to build data products that are told accurately and ethically, but also beautifully and scalably.
Collaborate with editors and reporters to find ways to involve readers in the reporting and story generation process, not just at the point of publish.
Through participation in both the day-to-day and long term collaboration on news generation, reporting and presentation, we'll identify ways to automate common tasks and templatize common designs, processes and frameworks. The software will be made available to everyone in the organization, thoroughly documented and open-sourced as much as possible.
Processes, Communication and Training
The team will continue to iterate on its process and keep up-to-date documentation that will be accessible to the entire organization. We plan to provide tools and training to editors and reporters to make them more efficient and self-reliant. The team will host quarterly show-and-tells in New York and DC to share interesting projects, inspire reporters and editors and provide a forum to surface ideas and spark collaboration (we just had our first one last week!).
I'll keep you updated on this work as the team progresses. These first few months, we're doing a lot of cleaning up and standardizing on templates and processes to make the initiation, build and deploy of projects way better. You can see a few examples of small data things we've worked on here and here, but keep an eye out for some bigger projects we have cooking.
That's right. A newsletter in 2014. They're making a comeback, haven't you heard?
Before I started as The Verge's product manager, the newsroom was already set on making a newsletter — it was just a matter of how and when, and we had a lot to figure out: Should we do it? Using which technology? Will it integrate with our publishing platform? Who is going to write it and curate the content? What's our base user list? How do we grow it? What time of day will we send it?
Somehow, we managed to answer all of these questions and are now two months strong into a successful newsletter launch.
Should we do it?
We ultimately decided yes.
Using which technology?
We decided on SailThru because we already had a contract with them for SB Nation, and their platform is robust enough to stay with us as we scale.
Will it integrate with our publishing platform?
Not yet. It's completely manual, but I did make a sweet little Google Spreadsheets workflow using tabletop.js that very nicely outputs all the markup, meaning editors don't have to sift around in code or use a bad WYSIWYG editor.
Who is going to write it and curate the content?
We have one owner who is in charge of writing the content daily, but other editors contribute suggestions throughout the day to help inform the final stories that make the cut.
What's our base user list?
We started with every Verge user who had ever signed up for an account and opted into receiving an email newsletter. After concerns about spam traps, however, we narrowed that pool of users (dating back three years) to only the users who had been active on The Verge for the past year, then sent them a forced-re-opt in — basically, an email that said, "You once wanted to receive this, and we know your inbox is precious. If you still want it CLICK HERE." Doing this cut our initial user list by 75 percent, but it's a far more engaged audience.
How do we grow it?
What time of day will we send it?
We experimented a bit with 7 a.m and 11 a.m. and various times throughout the afternoon. We landed at the same conclusion as everyone else, though — they perform best around 4 p.m.
Developing in the newsroom has always been my jam. Even when I'm not directly developing — like now, at Vox Media where I'm a product manager — my core responsibility is facilitating and helping define the development that happens in the support of the newsroom. Here's why you should do it too, and especially as part of Knight-Mozilla's 2015 Fellowship. The short answer for why you should develop in a newsroom is because it's fun, you will be working with insanely smart peers serving an insanely smart audience, there will be lots of whiskey and cursing, and election night pizza, all while building news and information solutions no one else ever has before. But if that's not enough, let me break it down for you... Build things that matter.
Every day, you get to build software that helps tell stories that matter. Stories that impact people's lives. Stories that can uncover corruption or expose mass health dangers or just entertain and inform.
Be shippin' it all the time.
The world is always changing. At a much more rapid pace than you'd have at your standard technology company, you get to be working at an extremely fast pace and shipping your work on the reg. This means your opportunity for experimenting and iterating on projects is also at a much quicker pace, and often being published to a receptive audience who will tell you almost immediately whether your work is awesome or whether it sucks.
Collaborate with subject matter experts.
The reports and editors with whom you'll be working really know their shit. They have the sources, the years of knowledge and research for their beats, the trust from readers. You get to work with those experts to collaborate on awesome solutions daily.
Work on a diversity of different projects.
Whether you're at a newspaper — which has everything from a sports department to entertainment databases to metro desk — or a place like Vox Media with its seven varied verticals or a place like ProPublica, which covers the spectrum from fracking to America's racial divide, you will be always exposed to a wide range of subjects.
Always continue learning.
To my previous points about diverse projects and working with subject matter experts, this means that you get to always keep learning. In order to execute on products that work, you have to force yourself to learn about processes and history and key players for topics you previously knew nothing about. Working in a newsroom with journalists is like going back to school, but more fun (there's often a lot more cursing and whiskey and no tests except whether you've met the user's needs).
Always continue teaching.
But it's a two-way street. In addition to learning what others have to offer, you get to always be teaching as well, whether that's teaching an editor about which data is most relevant for which formats, or teaching an ambitious reporter about python. You'll be continually surprised at how eager the newsroom is to absorb your knowledge. And the best feeling is then catching someone teach their peer what you've taught them.
Always be challenged.
This work isn't easy. We're often dealing with sensitive, high-visibility topics. Credibility and trust are on the line. One mistake in your scraper will send incorrect election results to the masses. Publishing the wrong information can hurt people's lives and get your publication sued. The deadlines are often quick and the data is often dirty. But you get to challenge yourself in new ways, and always.
Serve communities who care, and who you care about.
Because you'll be shipping your work all the time, you get to do that experimentation much more publicly than you would in any other industry, and directly interact and build relationships with that community you're serving. These are often the same communities that we're a part of, covering topics our families and friends care about. (Hi, Mom!)
Invent new solutions.
The information industry has come far in recent years in evolving how we do storytelling in a digital world, but there's still so much more to do, so much more progress to make, so many more problems to solve. This is a world that has immense and ever-growing potential at building the kinds of information solutions that help people live richer, more informed lives. And you can be a part of that. You can shape that. You can lead that. We need more leaders in this space.
Change the world.
No matter what newsroom you're working in or how big your audience is, you're going to be work that ends up having a big impact on the industry as a whole. The number of people doing the kind of work we do is still relatively small, and we're all doing our best to show our work and learn from each other. If you come over to a newsroom and do good work and share that work, you're going to influence and inspire people in newsrooms all over the country and world, who in turn take those learnings back to inform their own communities. It's a never-ending cycle of stealing each other's work, making each other stronger, and using all that feedback to continue building bigger and better products.
If you're at all intrigued by these ideas, scadoodle on over and apply for a Knight-Mozilla fellowship in one of the many esteemed newsrooms across the country. Become a 2015 Knight-Mozilla Fellow by applying today.
One of my first projects at The Verge as a product manager is a buying guide series called This Is My Next. I can't take any credit for the concept, but I can talk you through what's happening behind the scenes.
What is it?
A product buying guide. Technically, it's a new entry type on The Verge (derived from the reviews entry) that has its own sweet look, feel and branding. It integrates with our product database and adds affiliate commerce options (!) to really bring product data to the forefront in the name of reader utility. Entries feed into the reviews hub page and the reviews section on the nav.
What's the point?
There are a million kinds and iterations of every imaginable gadget, device, and gizmo on the planet. Yet these are increasingly the devices we spend our time with, and they're how we see and interact with the world. Buying things is hard, and The Verge wants to make it easier.
Verge's editorial staff is going to test everything, and tell you what to buy. They'll also help you come up with the answer for yourself, but ultimately when you want to know which $250 camera is best, or which Windows 8 ultrabook you should own, This Is My Next will be the place to look. It might not be the only option that will make you happy, but we’ll always have something that you’ll love. We've seen everything, tested everything, and we have the answers.
Here are the first few This Is My Next articles:
- The best tablet you can buy
- The drone you should buy right now
- The best calendar app for iPhone
- The best set-top box you can buy
- The best weather app for Android
- The best weather app for iPhone
- The best portable bluetooth speaker you can buy
- The best camera you can buy for under $250
How does it work?
Basically, it's an article. But an article based on structured data. For each This Is My Next entry we write, authors can attach products from our product database, and assign a winner, runner-up and other contenders. Each attached card links to an entry in the product database, which contains information about specs and release date. Integrating the Pricegrabber API and Amazon Affiliates, we also give readers an option to purchase the products we recommend (it is a buying guide, after all), which also means a tiny share of each transaction comes back to Vox Media.
Huge Ma, engineer
James Chae, designer
David Pierce, editor
Lauren Rabaino, product manager
Vox is the perfect next home for me, having first been with a start-up that was trying to change the industry from the outside, then to a newspaper to reinvent from within — now, to a media company that does great journalism, builds kick-ass technology and ties it all together with modern design and a vision for the future. A little insider, a little outsider. A huge influencer on the future of media. And not afraid to shake things up.
Owning development of editorial features and products at The Verge is one of the most exciting opportunities I could have asked for. It’s a brand that’s, in some ways, still in its infancy, but already beats its peers — HuffPo Tech, Gizmodo, Wired, Engadget and TechCrunch — in monthly unique visitors. As the product manager (the product is storytelling, by the way... brilliant) I’ll lead design and development projects with a mix of management and hands-on participation. Though I get to help shape strategic goals through product innovation for the Verge specifically, the work of myself and the rest of the product team will impact all six of Vox’s sites.
I’ll be based in New York City. I start on January 21. Someone please teach me about how to hail a taxi and whether I’m supposed to sit or stand on the subway.
Since we just announced our Thanksgivukkah contest tonight, this might be a good time to dual promote a side project I've been working on with Mark Briggs and Scott Falconer: a little app called Fork. It's a simple but awesome app that takes the food porn out of Instagram and Facebook and gives it an actual home. It's meant for people to share photos of the stuff they actually cook in their kitchens. For someone like me (who isn't much of a foodie and doesn't make the most beautiful looking meals), it feels like a safe space to celebrate little victories, judgment free.
The app is really Mark's brainchild, but I've been helping out on the whole concept and design for more than a year now, working closely with him and developer extraordinaire, Scott. You should read Mark's story about what inspired the whole concept (hint: it was his kids). Key functionality: You upload photos, choose among filters, add a description and title, then share. You can make lists of favorite meals by adding them to saved folders.
The name "Fork" is intentionally inspired by the concept of code forking. We want people to see what their friends are making and riff off it, creating their own deviations. It has changed how I eat and it's my new favorite app to fire up while I'm browsing around for dinner ideas or aimlessly wandering around the grocery store. (And I'm getting really good at plating my food!)
We had our official launch party here in Seattle at Local 360 in the middle of September, with awesome turnout, including NYT contributing food photographer Andrew Scrivani there to give us photo tips (natural light is the key, folks). Below are photos from the launch party.
So, you should download it. And remember that it's still pretty beta right now, but that you can send me feedback. And you'll be downloading it just in time for the Thanksgivukkah contest! Prizes listed below are pretty cool.
Since Thanksgivukkah won’t happen again for about 70,000 years, we’re celebrating with a food photo contest with our friends at Foodista, What Jew Wanna Eat and the folks behind @Thanksgivukkah. We want to see your best food photos when these holidays collide on Nov. 28. The winning photo will be selected from all photos added to the Fork app and tagged #Thanksgivukkah. The prize package includes: A $200 Whole Foods gift card to (for your next holiday cooking adventure), an ‘American Gothikkah’ Thanksgivukkah poster, a special Fork T-shirt!
We can’t wait to see your creations! More information, including recipes and suggestions, can be found here: http://bit.ly/18NhJg7
I'm a little late in writing about this one, but it's worth posting about the second iteration of our mayoral guide that we launched for the general election. (You may remember V1, which we launched for the primary).
Version 2 featured candidates Ed Murray and Mike McGinn side-by-side, with the ability to easily compare their backgrounds and issue stances. We brought the two candidates in to be photographed specifically for this guide, which was the first time we've ever done a photoshoot for a news app!
The bar charts pull in data about campaign financing, breaking down the totals by inside Seattle vs. outside. We also have a neighborhood breakdown view (created in Tableau), which shows you the amounts against a map.
The individual profile pages show you biographical information at a glance, stances on issues, a biography (complete with childhood photos), campaign finance data and financial disclosures.
The app was built in django, off our elections app that we previously wrote about. It works off a custom template for the race page, then reuses many of the blocks from the primary guide for the profile pages. This year's general election results fed into the same app, using the same templates and mostly the same scraper from the primary. Yay for resusability.
The goal of the app was to help readers understand the nuances in the views of two seemingly similar candidates. Both tend to align on a surface level on many issues, but have different paths for getting the end result. Big shoutout to Emily Heffter for doing the bulk of the reporting (and inputting the data into the django admin!), John Lok for the photos and Dean Kramer (who recently left The Seattle Times :'( for the development. As usual, I did the project management and design.
Kill the article.
That was the theme of the Global Editors Network hackathon that I participated in with Seattle Times teammates Ben Turner and Justin Mayo. This was one of 20 hackathons happening worldwide, with winners of each event going to Barcelona to compete against each other. Unfortunately, we didn't win. But we still think our idea is pretty kickass and we're excited about implementing the concept (to some degree) into our CMS overhaul over the next few months.
We decided not to kill the article entirely, since the concept developed at the hackathon is something that's supposed to be implementable in our newsrooms, and ours isn't one to kill the article anytime soon. But we did want to take the focus of the "digital story" away from individual articles and direct it toward the individual pieces of data that connect those articles over time. Because what's an article, really, but one episodic slice of content in context of a larger, evolving narrative?
A little explanation about what's going on here:
- A seemingly normal story appears on the left, but what you don't see is the back end (shown below), which allows journalists to markup various components of the text — names, locations, key facts, key quotes, tweets, multimedia — to provide additional metadata about them and their relevance to this story.
- A curated stream of content to the right, which is generated based on the metadata from all the articles in this topic over time. This means you can see where one little sliver of an article exists within the larger meaning of the story.
- You can filter by newest or jump to the beginning if you're new to the story. If you want the high-level overview, you can see "only the important stuff."
- You can explore by content type or data type. For example: Key people, key locations, all videos, all photos, all tweets, thematic filters (for this particular story: arena design, concerns, investors, etc.) Thematic filters are determined at a topic level, chosen by editors.
Here's what the input interface might look like:
Why we decided on this approach
Our team felt like the premise of "killing the article" may have been a little off. The internet was created as a place to easily read, share, interconnect text. What's missing is the context. How can we stitch together individual pieces of information that make up disparate articles so they make sense in the larger meaning?
This idea was born out of meshing together two concepts: the wiki(ish) approach to news, plus an activity stream. We wanted to focus not on breaking news — though this concept could be applied there — but to the stories that are most important to our mission as local, independent newspaper. We wanted a format that gives meaning to longterm reporting that impacts many sectors of our community, enterprise reporting that is watchdog in nature.
You can check out the functional prototype that Ben built. We'll let you know when the real thing is implemented into our systems.
Part of me can't believe we're still asking this question. It comes from Patrick Thorton:
Student news organizations have traditionally existed to give students experience before entering the workforce. The kinds of journalism jobs and journalism companies have changed considerably in the past 10 years, and most student news organizations are set up to mimic traditional print or broadcast news outlets. How would you set up a student news organization in 2013 or how could an existing college news organization modernize itself?
It's the same thing we were asking when I graduated in 2009. I wrote a letter to my j-school about what they should do to modernize by revamping existing tracks rather than creating new multimedia ones. I wrote a post urging other student newspapers to not be afraid to break the rules. A group of us around the country hosted an open chat between students and educators about risk-taking.
And here we are, five years later, dealing with the same struggles.
Except that many educators didn't listen back then, and our 2009 urgings are already long out of date. Catching up is now that much harder. What's a j-school to do? It starts in the classroom.
Create curriculums that are concept-based
Technology changes quickly; approval for curriculum changes does not.
You can't create classes based on certain platforms or strategies. Classes need to be concept-based to allow flexibility of easily swapping out technology as the times change, and focusing more specifically on goals to achieve rather than tools for achieving.
A few examples:
- Rather than having a class about how to use Twitter, create a class around finding sources and doing solid reporting, which touches on elements of engagement and community. Twitter can be a part of it, but not the focus.
- Rather than having a class about video editing, focus on visual journalism, the elements of visual storytelling. Editing a video can be a part of that, incorporating a ton of self-teaching (more on that soon).
The tools are just the vehicles that get us to the heart of what we do as journalists. The tools don't define our journalism.
You can never teach students everything they need to know because two months into the workforce, the tools will have changed. And students, you shouldn't wait around for your professors to teach you what you need to you know. Ideas I'd integrate into classes without telling students how to accomplish the following tasks, or which tools to use:
- In a basic reporting class: Tell students to create a searchable database.
- In a visual communications class: Have students plot data on a map.
- In a narrative/features writing class: Have students creatively integrate multimedia into the narrative process.
The point would be for students to figure out how to solve the problems, using whichever tools they have at their dispense. It doesn't matter how they get there, so long as they do it in a way that is accurate, usable, elegant. Extra points for mechanisms that are reusable, integratable, responsive, etc.
Programming isn't about presentation
At the same time, remember that coding isn't just about what you see as an end user. I've learned from spending time with students that this is often the misconception. "Why would I want to build a website to show my work? Won't other people at my news org be responsible for that? I want to focus on the storytelling," is a question/statement I've been asked when speaking to journalism students. Programming is also about what happens on the back end. It's about how information is organized, and how we use it. It's about using technology to bridge the gaps, to make our jobs more efficient, to tap into information we could never access.
Which leads to the next, related point...
Data, data, data, stats, stats, stats
Why wasn't a data analysis / statistics class a requirement for my journalism major? It should have been. Multiple classes of it. Not as electives. With the wealth of information that's publicly available, and the wealth of information for us to record ourselves, how are we still teaching interviewing as a primary source of information-collecting? Students should be learning how to find data, scrape data, analyze it, make sense of it, display it.
More innovation labs
And to tie all these concepts together, we need more safe places for students to collaborate and experiment. Bringing it back to the original question about how student media organizations can modernize, they need to function more like innovation labs, implementing all of the core functions I've outlined above. I've always pointed to how college should be environments ripe for disruption and failure and experimentation. It's theoretically a safe space to try new things, though the culture can often be as stagnant as professional organizations because of business implications.
How to bring the innovation lab idea to life at a news organization:
- Partner with other departments (computer science, software engineering) to do projects on a quarterly, or even a monthly or twice-monthly basis.
- Add an advertising/business student to that mix.
- Rotate reporters/editors into those teams throughout the year to give everyone exposure to the team.
- Make it a goal to release code into the open source community quarterly.
- Kill the print publication all together, or cut it down to just once a week.
- Create brand new products that are completely separate from the publication itself (think: Circa, reddit, Evening Edition).
And if I was a student today, you know what I'd do? Ditch the traditional organization all together and create my own news start-up on campus.
What I look for when it comes time to hire
Yes, a website/portfolio helps. I immediately look at a student's website to find a sampling of their "clips." These clips should come in the form of links to the student's projects, and hopefully some blog posts that explain how the projects were done, and what plans are for the projects moving forward. This doesn't have to be anything overly-fancy. I just want a place where links are easily collected. Even a Delicious feed works.
No, I don't care if you can use Tweetdeck or Google Analytics. So can my 12-year-old cousins. Where are you pushing the boundaries? How are you thinking outside of the box? How are you reinventing? Don't show me how you can use tools that other people made. (Derek Willis writes about this more eloquently than me in, "The Natives Aren't Restless Enough." Just stop now and read that instead.)
Write about your ideas. Share you knowledge. Spread your knowledge. Ask questions. Deconstruct concepts we all take for granted. Contribute to the community. Contribute to the greater good of this mission we're all working toward. Then I might give you a call.
I would by no means call myself an expert at multiscreen, as our first foray into it was just last month with the launch of our Seahawks GameCenter, but what I did bring to the panel was a realistic look at how to experiment with second screen using free tools, cheap tools, open source tools and very few developers.
Below I've embedded the entire presentation and audio (my slides are the last chunk).
To recap my points:
- Not everyone has full-time teams of multiple people working on projects. At The Seattle Times, I'm the sole news applications person, stealing developers from sales and marketing. We were able to pull off our first GameCenter with 2 weeks of development.
- We built our GameCenter using WordPress. There's a page that pulls in the_content of any post categorized as "GameCenter", which usually is always going to contain a ScribbleLive chat.
- The right column of the page on desktop uses WordPress widgets to populate the content. The mobile version of the page flips that menu horizontally to become swipeable tabs.
- The blog uses a child theme, so we can spin up a GameCenter on any blog. All we have to do is create a category called "GameCenter", a page called "GameCenter" which uses our custom page template, define the core colors in our sass and plop in some widgets and IDs for the team stats.
- The entire GameCenter fits within the workflow of our bloggers who have to do nothing but add a category to the live blog posts they were already used to creating weekly.
- We were able to monetize it by selling a sponsorship that injects an ad every 10 posts.
- Time on page is about 6.5 minutes, and half of the GameCenter's traffic is via mobile, compared to only 29% sitewide.
- It's been an easy way for us to experiment with mobile-first design and responsive design, two things we aren't able to do on a large scale yet.
Rent is a touchy subject in any community, so it's no surprise that when we created a way for readers to share their rent stories, they responded en masse.
How it works
Dots on the map represent major neighborhoods within Seattle and other major areas outside of Seattle. Readers can click a point to get more information about it, submit a rent story for that neighborhood and read others' stories for that neighborhood. We're using the Mapbox and tabletop.js to display the map and submissions from our readers, which are inputted via a Google form. This is our last map that will use tabletop and Google spreadsheets to store data. The next one is using a django form and spitting out data as json.
Why the big dots to represent neighborhoods?
Not sure whether I need to explain myself on this one, but since it was the source of much discussion in our newsroom when deciding how to represent neighborhoods, the thought process is worth noting. We used big dots to represent geographic locations for a few reasons.
- Rather than using shapefiles: Neighborhood boundaries in Seattle are very ambiguous, and there aren't any official definitions of what is where. Rather than nitpicking about where one boundary started and other ended, we used big dots to ambiguously represent the neighborhoods so readers could self-identify. Eventually (soon!), yes, we're going to have to just settle on some boundaries and create neighborhood shapefiles for our city.
- Rather than letting smaller dots represent each individual submission: This would require asking readers to input an address, then map that address to a longitude/latitude. Because of privacy concerns and time limitations, we opted not to do this.
First time doing full-screen maps
You may remember our reader state parks map, which we were able to build off of for this project. It was a clunky experience (and not responsive) because we were forced to embed it into our CMS on a fixed-width flatpage. Though doing full-screen maps is certainly nothing new, it's a first for us and will likely be an issue other smaller newsrooms have to deal with.
Here's are the points I made to our UX team in sales and marketing when I made the case for why we should be able to do this:
- Google, Bing, MapQuest, etc. have already set a precedent, meaning it won't be "unexpected behavior" that surprises our users.
- If we want our maps to be responsive (yes, of course we do), an iframe on a flatpage won't do the trick and makes for weird scrolling within scrolling panes.
And speaking of mobile, here's how it all looks on a phone:
Huge shoutout to Alexa Vaughn, Dean Kramer and Gene Balk for their work on this.
It was a busy summer this year for Seattle Times news apps, with a fall lineup that's looking even busier. While I have a second to breathe this weekend, I'm catching up on writing posts about some of our notable summer projects. The mayoral guide is at the top of that list. It's one of the first projects we launched this summer, and also marked the first time we'd ever worked directly with a reporter, the talented Emily Heffter, on information gathering that was specific to a news app and completely independent of any kind of print product.
In a super-congested primary mayoral race, we wanted to give readers:
- A way to easily, digestibly learn about each candidate on the ballot
- A visual way to compare where each of the candidates stands on each of the major issues facing the city of Seattle
- A home for primary coverage leading up to the election
How we did it
What resulted was a django app built off our legislative guide and the prior year's election guide. We built off the politician model to add candidate, people and issue models, setting the groundwork for what could be an extensive database of all candidates, campaign financing, vote totals, endorsements, etc. for Washington state.
We now have (though forgive the ugliness of them right now) a view for all election years, each election within the year, each race within the election, each candidate in the race, and both a race detail and candidate detail. See the potential now? API is next!
One of my favorite pieces of the app is the "issues" section, which visually breaks down where each candidate stands on an issue by displaying his/her mug in one of three categories that represents the common stances on major ballot issues. The tone of the guide was also a little more straight-talk than other political resources we've written, which made it more fun and approachable.
The entire app is, of course, responsive. It builds off a responsive grid that originally looked a lot like the 1140 grid system, but has since been extremely modified for our needs. We're not doing anything fancy other than that. The hardest part of getting this thing out the door was building out the models to be as reusable as possible.
Stay tuned for the general election version of the guide which launches sometime this week!
“Will you play it safe, or will you be a little bit swashbuckling? When it’s tough, will you give up, or will you be relentless? Will you be a cynic, or will you be a builder? Will you be clever at the expense of others, or will you be kind?” Jeff Bezos
In an act of rapid turnaround, deadline-driven development, Dean, Cheryl and I bring you a map of all structurally deficient bridge in Washington state.
Thursday night the I-5 bridge over the Skagit River collapsed and fell into the water. Yes, this is a big deal because I-5 is the main corridor through the state. Two cars fell in but everyone survived. This news broke while Dean and I were enjoying a lovely dinner at Ben and Katrina's house after work, so naturally we turned her dining room into a breaking news headquarters: I maintained the social feeds while Katrina worked with homepage producers to build out the package and Dean started working immediately on the map (I jumped in after our social media producer go to the office).
We worked all night on the map, spending most of our time attempting to get PDF data into a spreadsheet before we got a better data set from our data editor. We started with a Google Fusion table and quickly moved over to Mapbox (thankfully, we knew what we were doing after building our state parks map).
We used basically the same technology I described in my state parks post. We launched the map on Friday morning then updated a second-iteration version Saturday that has filters to see: bridges built more than 50 years ago, bridges with low sufficiency ratings, facture-critical bridges and high-trafficked fracture-critical bridges.
This one of our first heavily deadline-driven news apps projects and probably the best job we've done of really telling a story through our apps. We're getting good at dumping a bunch of stuff into a well-packaged space (maps, political guides), and are trying to get better at truly finding the stories within those data dumps. Hats off to Cheryl and Dean!
This week the news apps team launched a fun little user-generated content project:a map with reader reviews of the best, worst, most kid-friendly state parks, and the best places to camp. We put out a reader callout using a Google form to celebrate the 100th Anniversary of Washington state parks and received more than 300 responses. We didn't previously have a plan for what we'd do with those responses, but thanks to all the answers being in Google Spreadsheets and tabletop.js, we were easily (ok, not that easy, but still) able to plot the points on a map.
How it works: You click a point. Point pulls up reviews, photos and number of "best camping" votes for that park. You can filter by category. Relatively simple, but it helped us start to define what our standards are for mapping, and create a few reusable templates so we can do projects like this more quickly in the future.
Here are some of the awesome resources we used to pull this off:
- Google forms to solicit answers
- Google spreadsheets to store the responses (had to significantly restructure the responses and do a lot of manual splits because our form was poorly structured in the beginning. Thanks to our awesome intern Daimon for fact-checking the shit out of every lat/long point :))
- Tabletop.js + Flatware
- Google spreadsheet script from Mapbox to handle geocoding
- A flickr scraper thing that I stole from John Keefe
Special thanks to:
- Developer Dean Kramer for ninja skillz
- Digital news production intern Daimon Eklund for fact checking, geocoding, QA testing, and generally good feedback and ideas and catching all our flubs.
- Data editor Cheryl Phillips for helping me merge, split, tear apart and reassemble the original mess of spreadsheets from our Google forms.
- Art director Whitney Stensrud for her eagle eye for UX and colors and fonts.
- News artist Kelly Shea for all the lovely graphics and cute icons.
- Travel editor Brian Cantwell for editing all the content.
- Features producer Holly Henke for managing all the promotion across the website, teases in print, and social media promotion. And for putting together the original forms and doing a reader callout, even though we weren't quite sure yet that we'd do anything with it.
- Engagement guy Bob Payne for feedback and keeping the ball rolling.
Yes, we are highly collaborative here at The Seattle Times, even on small projects. :) Now, time for some summer outdoors adventures!