Entertainment Weekly
October 14, 2013
Earlier this year, I had the extreme pleasure of working with Josh Clark, Brad Frost, Dan Mall, Robert Gorell, and Kristina Franz (collectively referred to as the “globalmoxen”) on a responsive redesign of the Entertainment Weekly website for mobile devices (i.e., iPad Mini and smaller). The site went live recently, and several of the other 'moxen did a great job talking about the process (links below) so I won't rehash that too much here.
I was the token codemonkey on the team, so in addition to wrangling the JavaScript, I was responsible for managing the github repo and code deployment. Below are a couple takeaways that may be of use to other codemonkeys embarking on a responsive project of similar scale.
Project Background
When you are designing a responsive site, it's best for all involved to get working prototypes in front of stakeholders early and often. It's no longer enough to see what the site will look like; folks need to play with the designs to feel whether things are working. Something as simple as page load time could be a deal breaker for a design, but there are a million more subtle interactions that sound great on paper but actually suck when you have a chance to play with them.
The way we worked through this was that Dan (and friends) would create static element collages (e.g., collections of typography, color palettes, iconography, etc), which Brad then converted into “atoms” of working HTML and CSS. Brad then assembled the HTML atoms into larger and larger constructs until they reached the page level. Dan and Brad were working in parallel, so what started as blocky, grayscale prototype pages gradually became more and more stylized.
The trick with all this is that we never had pixel perfect design comps that we could present to the client for sign off. Rather, we presented working code each week during our client review meeting so people could react to the work in progress and potentially steer it in different directions.
For better or worse, this meant that we basically had to set up a continuous integration environment for the development process; we would work locally, push to the dev server, test on the dev server, and once the weekly features were ready, we'd deploy to a client-facing demo server. We'd then go through the prototypes with the client, take feedback, and incorporate requests into the code for the following week (in addition to whatever else was on the schedule for the next week - yikes!)
We had lots of people working on the code simultaneously, fairly blurry lines between who should be touching what (especially in the CSS), and lots of deadline pressure to release working code on a weekly basis.
Git Workflow
To manage all this chaos, we relied heavily on git version control and github webhooks. Here's how it worked:
Folks would work locally on a dev branch (prolly not a great idea - more on this in a sec), land features, and then push to github. The push would trigger a webhook that would in turn call a script on the dev server that would pull the latest copy of the code. With this setup in place, we always knew that whatever was on the dev branch in github was the code hosted on the dev server, and could be considered “ready for testing”.
Once it was time for a weekly meeting, I'd merge the code from the dev branch into the master branch locally and then push master to github. This would trigger another webhook that would cause the client-facing demo server to pull the latest code so we could walk through it with the client. There were some glitches and workarounds along the way, but basically, pushing to dev branch updated the dev server, pushing to master branch updated the client demo server.
Given the option to do it all over again, I'd consider making a bit of a change. A couple of people on the project were git n00bs and while everyone did a good job getting up to speed, there was at least one horrible episode where one of the guys had to go back through and re-make a ton of changes. I don't remember the specifics but IIRC he was working on the master branch instead of dev and the changes he made were so extensive that they couldn't be merged easily. It was brutal.
I haven't tested this approach, but I think that in the future I'd have the team members fork the repo, work directly on their master (or if they are git-savvy, branch however they like and merge back to master on their fork) and then issue pull requests when they had something ready for testing. I'd then accept or reject the pull request into master on the main fork which would update the dev server using the webhook approach. Regarding the weekly client facing releases, I'd tag tested code with a version number and pull that to the client-facing demo site.
This approach is a little more labor intensive for me because I'd have to manually deal with the pull requests, but it would allow git ninjas to work however they like, and would protect n00bs from losing work.
Hover Styles
As Brad iteratively increased the fidelity of the prototypes, he made liberal use of the :hover CSS pseudo selector in order to demonstrate certain types of interactivity. This seemed reasonable at the outset but as we got down to crunch time it became a huge PITA because of the wonky way that hover styles work on touch devices. We ended up having to back out a lot of that work and replace it with the more touch-friendly approach of toggling class names on active elements using JavaScript.
To complicate matters, Brad was using SASS which I was not set up to deal with so I couldn't just make the changes myself. I'd ping Brad on IM, ask for a change to the CSS, he'd do it, he'd push his changes to github, I'd pull, etc... not ideal.
Pro tip: Explicitly limit your :hover styles to non-touch devices using a Modernizr-type approach.
Active Styles
There are lots of elements (e.g., tab navigation, “Read More” bars, etc.) in the EW design that have active and inactive states. Typically, they are implemented as links (A tags) and in early rounds of prototyping, Brad set up some basic JavaScript to toggle an active class on the tapped link.
Later in the process, this became a source of rework because almost without exception, a link would be enclosed in a wrapper element of some kind that also needed an active state. If you're familiar with CSS, you'll know that selecting the parent of a child that has a given class name is a lot harder than selecting a child of a parent that has a given class name.
Pro tip: Toggle the active class as far up the DOM tree as possible to allow for simpler and more robust CSS selectors.
Fancy JavaScript
There's some pretty fancy JavaScript in the EW site that I'll blog about separately. In the meantime, you can take a look at a photo gallery and the date header on the tv-listings page for a sample of the UX outcomes.
The Future of Web Design
On EW, I glimpsed the future of web design. Creating a large-scale, responsive web site requires a complete rethink of every aspect of the process, from the RFQ to the final code integration. It's scary at first but the result is an incredibly resilient, future-friendly product. It's the way web design should have been all along.