Q&A with Politico: How We Built Our Election Slackchat

We made an open-source tool to bring great banter to the masses, on a shoestring

(Politico election analysis)

A few months ago, we noticed that Politico’s open-source Slackchat tool had tons of interesting potential, and we wanted to know more about how it got built. We’d just run a piece about making a similar app from scratch, but we wanted to ask Politico’s Jon McClure and Lily Mihalik about the philosophy, design, and front-end-focused parts of their work. Behold, here’s our e-mail Q&A with Jon and Lily. —RP & LM

Getting Started

Q: How did this project get started? What were some of your original motivations or inspirations?

Jon: It started as a project to fill a gap in our elections coverage. We have a really strong audience on election nights, but we didn’t feel we were feeding them enough during the primetime hours while results were coming in.

When I came to Politico, our campaign reporters were updating a mainbar story in our CMS, which didn’t do much to encourage readers to stick around through the night. We’d already built our election results pages and wanted something complementary that readers could flip back and forth to between race calls.

Our reporters also have really great banter that we wanted to replicate, because that’s what kept us entertained while we were watching our server logs. Just a lot of deep color commentary on an election night that we felt was being wasted among ourselves.

The idea of using Slack as the platform to produce those conversations for our readers wasn’t ours. It’s been done by several others before us.

We also looked at FiveThirtyEight as a positive example of taking Slackchats beyond live events. The chat style can work really well to break a deep topic into a more colloquial explanation. That was the genesis of our Midterm Monday chats, which are now part of our weekly election routine.

Approaching the project, we also noticed there wasn’t much tooling out in the world to help turn chats in Slack into web pages. So that was an opportunity for us to build something useful for ourselves and others, which made it an attractive project, too.

The Broader Conversation

Q. Why did you decide to open source this tool? Along with that, what does the broader conversation about open source look like at Politico?

Jon: On our team, I would say we start from a default position that our code will be open source, but “open” or “closed” isn’t how we always frame our discussion.

I think there’s a prototyping model for open source projects in journalism that starts with solving a particular problem your newsroom has and then, after that proof of concept works, widening out to more general applications others may benefit from. We try to flip that and start from the beginning of a project to imagine the widest possible scope of the problem we’re solving. So for example, we started working on our Slackchats by asking what a useful library to produce them would look like. What you see now is the result, with one library that handles the general problem of serializing a chat in Slack and a second that renders the design we like for Slackchats at Politico.

In general, I think we treat every project as a framework and frontload the conversation with how we think strangers—foremost, us! —would like to inherit or might use our code.

Our team is made up of transplants from other smart, mature teams, so the process of restarting all our infrastructure from scratch influences our thinking here. I’m originally from Kansas and our team will tell you one of my spirit-tropes is that regularly burning a prairie keeps it healthy. Upshot: our code has to plugin and plugout seamlessly. The easiest way to develop projects that do that, in my experience, has been to take an open source-first approach.

As far as support within Politico for our open source work, that’s something I made sure would be here before I signed on. As small as we are, we don’t have time to reform thinking that’s skeptical about the benefits of sharing.

The Process, a Poem

Q: How did you work with internal stakeholders as you built out your app? The CustomContentTemplate options in your app are a great example here—What kinds of conversations led to things like handling for “ALERT!” prefixes, etc. Did your Slack users ask for a way to flag posts that shouldn’t get published?

Jon: So I think you’re imagining a very user-centered design process for this tool. That actually wasn’t the case.

The truth is we didn’t do rounds with the reporters and editors who used this tool beforehand, and believe it or not, that was intentional. I think maybe that reflects a difference, at least in my newsroom experience, from others that Source features more regularly. Smaller newsrooms have less tolerance for design iterations ahead of a working prototype, especially when the primary users are frontline reporters and editors. That’s well known, but I think we generally put it down as a handicap. I’ve actually found it can be a strength.

Because our window for process is so small early on, we’re forced to really lean into anticipating what future us will need. That’s the same mindset I’m talking about in our approach to open source. So features like CustomContentTemplate don’t exist because someone asked for something; they’re there because we had to imagine what our newsroom will want in six months. The answer to that is, of course, we don’t know and so we have to build in that flexibility.

We also know relying too early on user feedback can make us overfit to a narrow or misdirected initial concept. Half our newsroom when we first talked about Slackchats imagined a chat room, like AOL-style. We knew that was a bit off the mark we were trying to hit. So in cases like these, I like our team to push forward An Opinion. It’s a first draft, but in a lot of cases we are in the best position to have the first say and with it to define some boundaries within which we can adjust and grow a tool in response to feedback later.

I haven’t confirmed this isn’t apocryphal, but they say Frank Gehry stopped asking clients what building they wanted him to design because he found they were just describing whatever room they were already in. I think that sentiment applied in this case.

My minor soapbox pitch is that I think newsroom developers in the same situation should embrace their position rather than wish they could afford the process overhead of a ProPublica/New York Times. In some cases the scarcity produces better tools.

Q: We’re here for all soapboxes! Can you tell us more about how scarcity produces better tools?

Jon: Forgive the deep cut here, but there’s this poem I like attributed to Chuang Tzu called “The Useless Tree.” It’s kind of my cri de cœur for newsroom dev teams on a shoestring. It’s literally a poem about two men arguing over a tree, so I’ll spare the paraphrase, but the Disney-ified sentiment it boils down to is that our handicaps can be our strengths.

That is to say I think small newsrooms are generally undervalued as a source of problem solving. Devs in these shops necessarily must have a wider vantage across their organization that benefits tool-building and often have a better sandbox to test systematic changes to the way journalism gets done. I think small newsrooms are also facing the most important problems in journalism right now.

I’ve Twitter-ranted about this before, but I think we’re going through this phase that values feats of technical achievement over work that multiplies our effect in newsrooms. That necessarily benefits newsrooms with generous dev teams doing large collaborations and undervalues people in smaller shops solving discrete problems on their own.

You asked for soapboxes, so here’s mine: I like small newsrooms for producing journalist developers. You have to scrap in them, and as an industry we need more scrappers than artisans right now. For me, I’d rather see the Timeses and Posts become retirement communities for our legends and instead see every hungry young graduate try to mint her name by changing the way a newsroom works in Wichita. Those avenues are available, but the more our apprenticeship path is oriented toward internships and jobs in a half-dozen marquee newsrooms, the more tenuous our community becomes, I think, and the less good we do capital-J Journalism.


Looking for Feedback

Q: Excellent execution of the soapbox! Ok, switching gears somewhat: Did you have a particular process or framework to get feedback from internal users?

Jon: I’m ranted out. Lily (co-lead on our team and news design editor), you’re up!

Lily: Our feedback process is still evolving, but it’s a balance between desk drive-bys and a formal postmort meeting. We tend to get an onslaught of early Slack messages or feedback drive-bys, but find an organized meeting around what went well and what didn’t to be the best way to pinpoint bugs and tease out future improvements.

For this project, we gathered immediate feedback from reporters who used the tool with engagement numbers to help steer the conversation of a more formal meeting with reporters, editors, and homepage and engagement teams to make tickets for future improvements. There, we heard reporters and editors were getting lots on the page— waiting for updates to flow into the top of the chat. When these readers saw no action up top (coupled with an older chat timestamp) they bounced.

Taking that feedback onboard, we’ve added a “jump to bottom” button and will soon launch a UX that places readers at the bottom of the page where the chats are loading— not unlike jumping in on a group chat with your friends. They key here is to still allow for enough context so the reader isn’t disoriented by the new display. Things like a sticky headline and a clear way to jump to the top of the conversation will help with that.

Q: What about external users? How did you go about thinking through what would work best for them? And why did you decide to emulate the features of social chats?

Lily: As I mentioned, we wanted this to feel like sitting in on a group chat with your most politically savvy friends. We wanted it to feel native to other chat experiences our readers have from day to day. We added the little ellipses animation as a cliffhanger for readers, the same way you don’t put your phone down when you see your best friend is writing back. The animation only appears when the chat is live. We feel small animations like that help communicate the immediacy of the conversation and keep readers engaged.

Beyond the UX, we knew that varied content would be important. That meant images from the news and a more compelling way to link to articles in context. The team worked to ensure our reporters had these storytelling tools (and knew the syntax) to readily deploy them.

Q: How do you create a pleasant reading experience and build in context, not just dump readers into a simulated chat room?

Lily: We’ve talked through this one a bunch. Including, “Do we optimize for a live reading experience or for the hours after?” For now, we’ve focused on optimizing for live chats which included some early success integrating Q&As from readers via Twitter. Since the initial iteration, we’ve tweaked the design to reward those interactions in the flow, highlighting them with a prompt where readers can open Twitter directly from the chat and write their question there. We realize Twitter is not the only place that readers may want to ask questions. Comments might be next, or a Google form. What’s most important is that we have the staff to engage with reader questions in real time before we develop too many engagement points.

Last Thoughts

Q: What advice would you have for someone doing a similar project?

Lily: Be ready to iterate. As Jon mentioned, in small newsrooms and on fast moving deadlines, there is not always a ton of time to align completely around each new project. We can and do set larger goals, but the nitty-gritty often needs a prototype to test hypotheses and UX. That means we need to build with flexibility in mind, while ensuring those larger goals are a clear guiding light for the project. Ask your team: Is the purpose of this to highlight the voices of the reporters? Is it for readers to ask questions? Do those have equal or partial shares in the way we build and design?

Another key question: If you’re a reader, how would you expect to share this? This question has been uniquely valuable in our approach to the Midterm Monday chat. Initially we headlined these around the chat’s brand “Midterm Monday” but realized we needed a more focused headline and throughline for the conversation, instead of a “look ahead” or “5 things you need to know going into TK race.” Once we focused the chat, we saw higher readership and engagement across the board.

Q: Is there anything we haven’t asked that seems important?

Jon: Whether we’re hiring. We are! :)



  • Jon McClure

    Jon McClure is the interactive news editor at Politico. Previously he was the data and news applications editor at The Dallas Morning News, a data reporter at The Detail in Belfast, Northern Ireland, and a data librarian at the National Institute for Computer-Assisted Reporting at the University of Missouri.

  • Lily Mihalik

    Lily Mihalik is the editor of news design at Politico. Lily is a proud alum of the Los Angeles Times Data Desk, The Berkeley School of Journalism, KPCC, Flipboard and KCAW in Sitka, Alaska.

  • Lindsay Muscato

    Editor of Source from 2015-2020

  • Ryan Pitts

    Ryan Pitts is a developer and journalist in Spokane, WA. He’s the director of network development for OpenNews, a nonprofit organization that helps newsroom developers, designers, and data analysts collaborate on technology and support each other as a community. (OpenNews also publishes this website.) Ryan is a board member and developer at Census Reporter, and was the senior editor for digital media at The Spokesman-Review.


Current page