Launching Vox Media's first-ever editorial apps team

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:

Apps team at Rittenhouse Square in Philadelphia writing our team manifesto, June 2014. 

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:

Visuals

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.

Data

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. 

Engagement 

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. 

Applications

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. 

Product launch: Verge Daily newsletter

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?

Putting forms on the site. Implementing Twitter newsletter cards. And partnerships. Partnerships are key. We more than doubled the size of our list with our first giveaway.

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.

Why develop in the newsroom

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.

This Is My Next: Verge's new buying guide series

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:

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. 

Credits

Huge Ma, engineer
James Chae, designer
David Pierce, editor
Lauren Rabaino, product manager

My next: Vox Media!

Photo by the lovely Genevieve Alvarez. It is with giddy, bouncing-off-the-walls excitement that I am announcing I’ll be joining Vox Media in 2014 as product manager for The Verge.

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.

Fork app for food, friends

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

Happy forking!

Seattle Times mayoral guide, V2

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.

Screen Shot 2013-11-18 at 8.19.33 PM
Screen Shot 2013-11-18 at 8.19.33 PM

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.

Screen Shot 2013-11-18 at 8.20.36 PM
Screen Shot 2013-11-18 at 8.20.36 PM

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.

Refocusing the "story" away from individual articles to the overarching narrative

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?

Here's a mockup of our idea, something I've been dying to sit down and think about since I wrote a post in 2011 (crap, that long ago?) about the convoluted life cycle of a story and in 2010 (yikes!) when I wrote about structuring metadata within articles.

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.

Related coverage/links:

How universities and student media organizations should modernize themselves

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.

Teach self-teaching

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.

 

 

ONA13 second screen panel recap and behind-the-scenes peek at our GameCenter

At ONA13 this year, I was on a panel with ESPN's Patrick Stiegman and Al Jazeera's Rami Khater to talk about second screen experiences in a session called, "Broadcast For All: Mastering Multiscreen Production."

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).

uw
uw
screens
screens

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.

Map & UGC: Puget Sound rent map

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.

Screen Shot 2013-09-21 at 11.34.18 PM

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.

  1. 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.
  2. 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:

Screen Shot 2013-09-21 at 11.36.03 PM
Screen Shot 2013-09-21 at 11.36.03 PM
Screen Shot 2013-09-21 at 11.36.18 PM
Screen Shot 2013-09-21 at 11.36.18 PM

Huge shoutout to Alexa Vaughn, Dean Kramer and Gene Balk for their work on this.

News app: Seattle Times mayoral guide

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.

mayoral-guide
mayoral-guide

The goals

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.

mayoral-detail
mayoral-detail

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.

Screen Shot 2013-09-21 at 10.56.38 PM
Screen Shot 2013-09-21 at 10.56.38 PM

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.

Screen Shot 2013-09-21 at 10.55.21 PM
Screen Shot 2013-09-21 at 10.55.21 PM

Stay tuned for the general election version of the guide which launches sometime this week!