We spent the summer building native articles and redesigning our website from the ground up. Here's what we learned.
HODP's goals are fairly simple.
Each of these goals fuels the others. The more cool projects we publish, the more traction we get, which in turn helps us promote data-driven policies to the university.
In the past, we've kept these components separate, publishing articles on Medium and hosting web apps and data on our website. While Medium made publishing convenient, it made it difficult for people who read our articles to explore our other work.
This past June, we decided it was time to bring the pieces together. We spent the summer redesigning and re-implementing the website from the ground up, building native articles with the flexibility of web apps.
With the vision in mind, we needed to figure out the implementation. Our first decision was to start from scratch instead of editing our previous site, which was written in Flask and templated in Jinja. Switching the frontend to React was a natural choice: each of our core components has several configurations, and we could encode those as props. React was also the most commonly known JS framework among board members, and we wanted to minimize the barriers to working on the site.
After deciding on React, we needed to figure out how to store our articles. Markdown was out, because we needed custom code. We ultimately decided on a headless CMS, which is a system that stores content without dictating its presentation. (Read: they give you an API; you write the frontend yourself.) After lurking on StackShare and forking some starter repos, we decided on Sanity.io. I wrote a schema to store information about articles, blog posts, and other page content, and then I built an embedded React component type into our article model. This infrastructure allows HODP members to code interactive stories and manage them from the Sanity Studio.
We chose Gatsby as a site generator to interface between Sanity and our React code. With Gatsby, we could set up our Sanity data layer and write content queries in GraphQL. More importantly, Gatsby pre-generates raw HTML / CSS / JS from our React code, which optimizes our site for speed and SEO. Hopefully you can confirm that this site is truly “blazing fast.”
During our website planning meeting at the beginning of the summer, we mapped out user flows alongside HODP goals. (For the record, our users are “interested Harvard students,” “HODP members,” “potential partners,” and “randos.”). Some wild ideas made it onto the brainstorming doc — building an IDE inside HODP, anyone? I left the Zoom meeting with a sense of buoyant idealism.
Then, I built a basic version of the website and realized that it looked bad. Not terrible, but nowhere near our aspirational Google doc. The body copy looked sloppy, the margins were huge (ostensibly to make up for the lack of substance), and the article layout somehow looked mediocre at all sizes.
Ultimately, we realized that we couldn’t design and code simultaneously and expect a good result. I ended up sitting down with Figma for a weekend and redesigning the website from the ground up, from the style guide to the component hierarchy.
Anyways, I got really excited about this Figma design. Then my internship got busy, and I procrastinated for a month.
Fast forward to mid-July. I implemented the design, schemas, and project page generation. Kevin built in article comments, the MailChimp embed, and an interactive dashboard to visualize COVID-19. Alex built search and filtering into the data catalog, Sahana built the all things People, Matthew planned the Firebase infrastructure, and Daniela designed the homepage.
After completing those features, we met as a board to migrate all our past content from Medium to Sanity. We had only ~50 articles to transfer and 16 board members to help, but the process was still more tedious than expected. (We also needed to add roughly 70 HODP contributors, whose headshots we sourced from Facebook and LinkedIn.)
After months of work, roughly 150k API requests, and 200 Netlify build minutes... we made it!
We now have native articles, live-updating maps, and plug-in content that doesn't require us to submit a PR to fix a typo. We've come a long way since our original website.
I hope this was helpful for future HODP members and / or other student organizations that want to undertake similar projects. If you’re looking for the code, this project is open source.
When you don't start with a playbook, you get to design your own rules. Instead of working within an existing framework, you can reexamine the premises. Instead of figuring out how, you get to take a step back and ask why. In our case: instead of screenshotting a graph to meet Medium constraints, why not build NYT-style scrollytelling? By starting from scratch, we could set the parameters that future users will take for granted. Our code is far from complete: it’s a part-present solution, part-hypothesis about what we’ll need in the times ahead.
Here are some of our takeaways from that process.
In the year since Kevin (Bi), Lucy, Seth, and I first discussed moving articles off Medium, HODP has started a survey group, a predictions game, and a wiki. These initiatives were all started on a whim, but they quickly became some of our most impactful projects.
We don’t have a set agenda each year, except to teach a bootcamp and see what happens. HODP gives you the freedom to ask “what if…” and the skills to follow through with it. There aren’t many clubs that offer that much agency — I think that’s what makes HODP special.
To HODP members: we’ve created a platform that allows you to publish cool stuff. People will see it, and it will make an impact. The last part is up to you.
I'd like to thank:
If you're interested in working on the website, please reach out to me on Slack :)