CovidProtocols

I'm writing this retrospective in late 2022, but the majority of actual development on this happened (understandably) in April of 2020. There are going to be two aspects to this story, and they're quite different.

• The first is the personal / human angle
• The second is the technical side

I'm going to try to balance these two sides, because while the challenge of this project was really fun, I also can't talk about that without also talking about why it was something to fight for.

Let's dive in, yeah?

Background

One of my favorite things about working at Upstatement is that we make time and space for work we believe in, even at a loss. I'm not saying we didn't get paid at all for this project, and I don't know the exact numbers, but knowing what Nathan and I put into it, I'm reasonably confident in saying the company took a loss, financially.

We can't always do those kinds of things, but we make it count when we can, and I really appreciate that. Especially in a time of uncertainty and instability. And like. Look, I'm a web developer & writer. I don't build houses for the underprivileged, I'm not a doctor, I'm not a therapist, I'm not a firefighter. And I'm not saying that the sites I've made in the past haven't mattered, but I never, ever, ever expected that I would work on something that literally helped save lives. As I said to my mother and brother when they were arguing over who had higher government clearance: "I just make pretty websites."

Let's go back to March of 2020. It's March 10th, I'm in Philadelphia with Upstatement, spending time with the Philadelphia Inquirer. Things have begun to shut down and I'm nervous about getting stuck in Philly. But I manage to fly back. I go into the office the next day, and that's the last day we have an office. Sometime during those few days (at the Inquirer office, hotel, airport, plane, trains, or our office), I caught Covid.

Catching Covid at that time was both scary and not scary. I wasn't super concerned at the time because I was "healthy" and I also had already seen things that were threatened to be world-ending and weren't (Sars, swine flu, 2012, Y2K, etc). But at the same time, so little was known, and people were dying, and there was no vaccine, and there were no tests, and there was nothing you could really do. It would be weeks before there would even be a mask mandate.

I mentioned I was down there with the Philadelphia Inquirer - In my time at Upstatement I've often worked with multiple clients at a time. At this point in time, though, I wasn't: I was in Philadelphia for our project wrap-up. My next project would be the Kendall Square Assocation, which would start on ~April 20th. Having downtime between projects is rare for me because I usually work with multiple projects, but when it happens, it's a great opportunity to do work on some internal projects, so I was looking forward to it.

Slotting into this month gap, Covid Protocols is the shortest project I've worked on (I've done more on it since, but in one engagement, I mean), and I was doing it while also being ill myself. It was a lean team, and we (willingly, of our own volition) put in a bunch of overtime on it, because it was Important.

The Problem

Let's talk about what Covid Protocols is and what they were trying to do. It was a project that originally started with some doctors from Brigham and Women's Hospital. Obviously, at that time, there was a lot of reseach happening, a lot of new findings, a lot of changes in how Covid patients should actually be handled.

Think about it - there's not only no vaccine, there's not even a test at this point. So these doctors had been using Google Docs to share information around between each other, and keep each other up to date as of the latest findings.

There were a few reasons that using Google Docs was not optimal.

• Hospital Privacy: Some hospitals didn't allow Google Docs through their site blacklisting.
• Mobile Optimisation: Google Docs is not ideal to use on a mobile platform.
• Loading: Holy god were those pages slow to load - and even worse on hospital wifi. The documents were growing to be hundreds of pages long, with images and numerous comment threads and changes suggested by dozens of doctors.
• Relational Content: Because of the above, it had already begun to split into multiple documents. And while you can link between those in Google Docs, the hierarchy of navigating those is not the best.

It was obvious that what was really needed was a slimmer way to consume this content as a user. There are lots of options for us to do that, right? But, here's where the complication came into it. Let me restate that there were hundreds of doctors using this often. Highlighting things, adding links, sharing new research, having discussions in comments.

When it comes to a new CMS platform, there's a lot of functionality there that has to be accounted for, plus a lot of training that would have to be done, and not a lot of time to do either of those things. I kept coming up with other solutions, but they all fell short in one of those areas, and even more than that, the doctors wanted to keep using Google Docs. I advised against this, because Google Docs is many things but it is not a CMS, but it wasn't hard to see their point - Google Docs worked for them. Alright. Google Docs it is.

Data Reliability

So how the hell do you do that? The first thing I came across was Library, a collaborative tool put together by the New York Times. It used the Google API to access the data and build pages around that. Rudimentary in some ways, but very cool and promising.

But there were two real problems with this approach. The first is that fetching the data live from Google Docs was still slow, and the second was that we didn't want to be fetching data live. All of this stuff was being touched by so many hands and going to so many eyes that it was really important to have new content essentially be verified.

It wasn't just a matter of changing how the data was displayed, but rather, it needed to become even more of a CMS, where even the current version of the document was a draft with a process for publishing it. I had already been familiar with the static site generator Gridsome - which as of 2022 is actually what this portfolio is made using. Gridsome essentially works with any API, and what it does is it retieves all of the data, and uses a GraphQL layer to dynamically create pages of content, and then makes a static site out of those. It is one of the coolest things.

When I say it works with any API, what I mean is that it is agnostic and you write the fetch requests and transform the data however you need to to get into the GraphQL layer. This means that people have written all kinds of plugins and starter kits for it. You can pull from Craft CMS, or WordPress or Markdown files in your repository or Shopify or Airtable, etc etc etc. I used one with Ghost for the blog on the Half-Life: A Place in the West site.

But there really wasn't a good one for Google Docs. Why would there be? It isn't a CMS. (To be clear, there was one, but its functionality was extremely limited and it had a lot of problems with its transformer code). So, what to do? I really liked this approach. Having Gridsome meant we could use Vue components for some of the UI elements and make the code really clean, and it would generate into a much more reasonably sized package than the raw Google usage had been.

So I said, "Well, I'll use both of these ideas. And I'll make my own transformer."

Content Needs

Over the course of a few days, I used the Google-Source plugin as a starting point, scrapped its transformer, and rewrote the New York Times one to fit into that context. So, it "worked" - you could get it to parse header tags and paragraphs and bold and italics and links. It would parse out comments.

But. We needed more than that, and here's where I had to get a bit... creative.

We needed to expand the transformer to account for links to other chapters. Plus we wanted to add rel="noopener noreferrer" and target="_blank" to external links. That wasn't so bad.

We needed to account for superscript and subscript, because a lot of the content was scientific. That also wasn't bad - check for the text vertical alignment property and apply a class. We need to convert YouTube links into iframe embeds, no problem.

We need to add tooltips. Okay, that one's a bit of a problem.

We can't really add new features to Google Docs, only work in the confines of the style options they give us. And at the same time, even if we could add, it's also a bit reliant on someone knowing to use that tool, and how it works. So I said, okay. What can we do to just signal that this content is something else? And we decided that the best approach was to use strikethru - they weren't going to use that for real text anyway, so part of the transformer was adapted to change all strikethrough text - wrapping it in a tooltip with an inserted icon where it had been. Problem solved.

Publishing Updates

Because it was a static site, we opted to use Netlify to host it.

And for a time, we manually deployed when something needed to be updated. Nathan Hass, the creative director and I were working super closely together on this project, and he would get calls and texts at all hours that an update needed to go out. They were moving fast, everything was.

There were a few people on the BWH side who could have easily understood logging into Netlify and hitting the big Deploy button when they needed to make updates, but, man, did that feel like a bit of a barrier, and it felt likewise that there was a degree of instutional knowledge required, and we don't want that.

So we created another Google Doc, one that would not get counted as content. And in this one, we added a custom app script that would kick off the deployment process.

Future Developments & Lasting Impact

I came back to this later for a few more additions. I added language support, allowing them to present the site in Spanish, which also involved revisiting the transformer somewhat. There was also talk of using Hindi and Arabic at certain points. The demand ended up not being there to warrant all of the content being translated, but that also involved changes of making sure that we could handle different character sets, and right-to-left formatted text.

Another team within Upstatement would come back even later than that to create native applications, to further increase the accessibility of this tool for doctors.

In May of 2021, We received an Honorable Mention in the Fast Company World-Changing Ideas Awards, specifically in the Pandemic Response category. Nathan and I were also interviewed by Liz and Casey from Scout, a student-led design organization as part of Northeastern University.

But the highlight for me has been getting emails like this, as recently as 6 months ago:

Hi all, I’m Mark, a Chief Resident [...]. During the peak of the pandemic in 2020 I was a daily visitor of the CovidProtocols website which served as a huge help to myself and my colleges during such a stressful time when ‘best practices’ were evolving so rapidly. I really appreciate the amazing work your team provided in helping BWH efficiently deliver and disseminate their content.

I think in tech, we can often be caught up in the interesting problems and lose the human element. It isn't helped by the fact that we so often don't have a direct line of contact to the people who actually use what we make.

In the case of Upstatement, most of our users are our clients - when we're designing a new CMS for someone like The Philadelphia Inquirer, we're looking at what pain points their editors have, how we can enable them to better do their jobs - they're our users more than the readers of the Inquirer. That doesn't mean we don't consider the readers, but our role is more often to find ways to empower the editors to be able to reach their readers more.

And don't get me wrong, this was a fun and challenging project, but it's hearing the impact from the doctors who used it that elevates it into being one of the things I am most proud of in my entire life.