Thanksgiving 2.0
Thanksgiving overhaul
Seasonal content always gives us an opportunity to improve the design and functionality of the site. (Compare to the Topics page design from the year before.) [link]
Last year the product team focused on just getting *something* together for Thanksgiving on a tight deadline, but this time we had the luxury of an existing code base to work with, a year's worth of experience making these pages, and a much longer lead time. One of the things that I really enjoy about working on a site with lots of evergreen, seasonal content is that I have the opportunity to revisit ideas, put gained knowledge into practice and make improvements. We decided to focus on integrating a new visual design language, refactoring the existing code and improving the editorial workflow.
Over the summer we worked with a design firm on a new visual design for the site. Updating the Thanksgiving section was the perfect time to execute the new look and feel and build our stylesheets from the ground up because it's mostly self contained. The current site relies on Bootstrap, but it's been feeling too kitchen sink-y and I often find myself overriding many default styles that I didn't need in the first place. I chose Bourbon after evaluating other frameworks like Pure and Foundation as it seemed the least obtrusive and most flexible. Although there was a bit of an adjustment going from LESS to Sass, I'm happy that I made the switch. Bourbon (and its related packages) has a tiny footprint compared to Bootstrap and the extends and syntax help keep the project more organized. Semantic naming for layout and columns is supported and the responsive grid is easy to modify. I set up naming conventions based on SMACSS principles, which should allow us to scale the stylesheet more easily and enable others to jump in and contribute with more consistency. Moving towards packages managed on the command line will enable us to keep the framework at the most up to date version.
We also refactored the template code with what we've learned over the past year by chunking out blocks of functionality for reuse in other areas. Just as we're approaching the visual design in a more modular way, we've been creating patterns with context based rules.
Lastly, we set up a new way of collecting questions from readers. Rather than just soliciting questions in comments or Twitter, we set up a form on the Thanksgiving landing page It was important to build a solution that fit into the existing editorial workflow, as the editors would be more likely to use it since it's less cognitive time spent on learning something new. Considering the size of the Product team (two!!) it was also imperative that we follow the path of least resistance and quickest implementation.
When a reader submits a question, Formstack syncs the submission to a Google sheet. An editor reviews and copies approved questions into the master spreadsheet, and a script exports the data as a JSON file on the server. Google spreadsheets are already a part of the daily workflow and the data can be easily updated with a single command. We had used this technique in previous projects inspired by this solution, but this time we made it into a reusable script customized for our environment and data. (And we were heartened to know that other publishers are using a similar technique!) We're excited about using this for an upcoming gift guide and ideas that require more flexibility than our current CMS allows. One tradeoff of flexibility that we've run into is that the process can be prone to error; we can't lock down parts of the spreadsheet that are crucial to exporting the JSON file (column headers, anyone?), so we'd have to think about error handling to make this process scale better.
The biggest takeaway, for me, is how tightly visual design and front end development have become woven together; in fact, I don't really see much separation between the two. Projects are most successful when they're taken through an iterative process and it's especially crucial for responsive design, where I need to see it in action before I can decide whether or not it works. And overhauling a limited area of the site is much less risky and allows time for testing. It also gives us the opportunity to refine the design because we can see it in the wild and get feedback -where does it not work? How can it be improved? Where can we take chunks of design and code and make them reusable in other places? Ultimately I hope that the experience we've put together will help improve everyone's Thanksgiving game!
