We prioritized an easy-to-load website that could display 13 languages and allow SMS access. Read about our process, tools and code.
By Pat Sier
A few weeks ago, City Bureau released the Chicago COVID Resource Finder, a filterable database of over 1,300 resources during the COVID-19 pandemic. As the only web developer in a small nonprofit news organization, I think of my role as making sure our priorities and values are represented in the way we use technology to provide information. The small and nonprofit parts also mean it’s gotta be cheap and easy to maintain. We wrote about what this tool is and why we built it, but I wanted to give a look behind the curtain at the details of how we put the pieces together.
Setup
As COVID-related restrictions began in Chicago, our first step was to reach out to community partners and to survey asking social service organizations about information needs. We heard that a lot of good information was out there, but people were overwhelmed and sometimes not able to find resources in their language or in a way they could access quickly and easily.
After running some examples by some of our partners, we settled on gathering and verifying as many resources as we could and making them easily searchable, translated in several languages and accessible for different levels of internet connection.
Compiling and vetting resources was going to be a significant undertaking, so it was important to keep any tech setup as low maintenance as possible. Fortunately, in the past few years more open source software has been developed with similar goals in mind that are often lumped together as Jamstack. Sites like Google and Facebook are considered dynamic sites where huge amounts of servers (read: someone else’s computers) run software that is constantly updating content and determining what you can see online. Jamstack technologies focus on creating static sites where every page is built in advance, and any quickly changing information is accessed through cheaper, more focused tools.
This allows me to focus on building out the site functionality instead of monitoring traffic and doing server maintenance. It’s also a pretty common approach in news organizations, and I’ve learned a lot from projects like ProPublica Illinois’ Ticket Trap, the South Side Weekly’s map of COVID-19 data by neighborhood, and the Chicago Reporter’s GovBook. David Eads of the Chicago Reporter, and formerly ProPublica Illinois, makes a more thorough and convincing case for Jamstack in smaller news organizations in a breakdown of their Ticket Trap project.
Outside of just putting the pieces together on the site, design is not my strong suit. If you have an easy time navigating it you can thank Eads and Paula Friedrich at WBEZ for replacing several of my bad ideas with their good ones.
Online Accessibility
One in 5 Chicago students doesn’t have access to a broadband internet connection. With many households accessing the internet with mobile devices, we knew the site had to work well and load quickly on mobile. But mobile data costs money and the average website requires more and more of it.
To reduce the data required to view our site, everything on the page is GZIP-compressed so the file size can be up to 10 times smaller than it would be. I also tried to avoid the overhead of an address search by using ZIP code search instead, then wrote some code so the site pulls results around the ZIP code that you enter. Plus, when you first visit the landing page all the content you need to search and filter resources is cached, which ensures that users don’t end up downloading the same data over and over again.
Through some of these decisions and a lot of optimization built into Gatsby, the static site framework we’re using, the site loads pretty fast. We’re getting consistently fast page load times and high scores in Google’s PageSpeed Insights tool which measures website performance. That said, there’s plenty of room for improvement. Using front-end frameworks speeds up development, but also means that there was a lot of JavaScript needed to load the site before I started writing any code.
Accessibility online also means that a site is usable for people regardless of differences in vision, movement and other types of ability. We’re following best practices to accommodate people using screen readers or those experiencing colorblindness, but it’s still something I’m actively learning about, and if you notice any problems let us know.
SMS Access
Example of print view for resources
Even the fastest site requires an internet connection. One workaround was creating a user-friendly print view so that social service providers can print and distribute lists easily. It’s also why we made a version of our directory searchable over SMS.
Pulling from the playbook of our friends at Outlier Media, we set up a phone number through Twilio that people can text to get a filtered list of resources. While there are several text alert systems available in Chicago, they function as notification systems with links included, which isn’t much help if you don’t have access to the internet. If you text “covid” to 312-436-2280, you’ll be asked four quick questions and then receive a list of three resources at a time including contact info, hours and descriptions without needing to go online.
We used quick screener questions instead of a chat bot on purpose. While bots can be effective, they can be overcomplicated. Since we’re offering a limited set of options, it’s a lot easier for a user to follow prompts like “Text 1 for Money” than to text using natural language and get a series of “Sorry, I didn’t understand that” responses. We’re using a Jamstack setup here too. The SMS filter runs on “serverless” AWS Lambda functions that are dramatically cheaper and easier to maintain than full web servers.
Language
From the beginning we heard from our partners that language access was a priority. In Chicago, 31 percent of residents speak a language other than English and 12 percent speak English less than “very well,” according to the American Community Survey. But as our list of resources grew longer and longer, translating details for every one didn’t seem realistic. With input from folks in our network, we decided to translate the site navigation and controls only—that way people with limited English proficiency can still find resources confidently even if they need additional assistance going through results. To prioritize which languages to translate, we used data from Chicago Public Schools on languages spoken at home, which we received via a FOIA request last year during our Census 2020 reporting project.
Translating a site into 12 languages (soon to be 13!) in addition to English doesn’t come without some quirks. Unicode makes it possible to represent text in almost all the world’s written languages online—you can also thank it for emojis 👏. But displaying a language isn’t the same as making it useful for native speakers, and this project was a crash course for me in internationalization. The site and SMS needed to support several languages, different types of characters and both left-to-right and right-to-left text for Arabic and Urdu.
We worked with a team of translators all editing a Google Sheet that included all of our English text. After losing a fight with my text editor trying to copy and paste lines with both right-to-left and left-to-right content, I ended up writing a script to load the spreadsheet translations directly into our translation files. Despite my initial struggles, it was a useful reminder just how global the internet and web browsers are that it didn’t require a full site overhaul to let you switch between English and Arabic.
Translating SMS presented its own set of challenges. But a pandemic is as good a time as any to learn that SMS uses GSM-7 characters that only partially overlap with Unicode and are displayed differently depending on your phone carrier... and that this was the reason my phone gave me the option to filter in “Espa?ol.”
Process
Given the amount of work our editorial team did to compile and verify information (special shout out to Sarah and our reporting residents Alex and Justin), we needed to make sure that everyone on our cross-functional team felt comfortable managing resources. But no matter how many resources we compiled, we knew we would miss some, so we wanted users to be able to suggest new ones.
Airtable has been a great way for us to strike a balance. It has an interface that’s easier to navigate than Google Sheets with an API that makes it easy to pull directly into the site build process. It also comes with forms built in, which we’re using to make it easy to suggest new resources or give us feedback.
The resource finder site and SMS filter are both open source and available on our GitHub. Open source might not mean much if you’re not interested in getting into the code, but we think it’s important for journalistic organizations to “show your work” inspired by the Chicago Tribune’s News Applications team which our own board member, Joe Germuska, was a part of. In doing this work in the open, I hope it can be useful for other organizations, media or not, to build off of or learn from in the same way I’ve benefited from the work of other teams. We’re also working on making it easier to set up a version for other areas, so if you’re interested let us know on GitHub.
If you have any general feedback or want to share a resource we missed, don’t hesitate to let us know.
Support City Bureau’s open-source information tools by becoming a City Bureau Press Club member today.
To get monthly emails with behind-the-scenes info on our work and processes, sign up for City Bureau’s Notebook newsletter.