On Redesigning the Front Page of Talking Points Memo


This week, we launched a redesign of TPM's front page. This project has been my labor of love for the past month, so I'd like to talk a little bit about its genesis, process and eventual fruition.

the homepage


When sitting down to redesign the site, the prime directive from Josh was to make it easier for the reader to get a gist for not only the stories we are driving, but a complete picture of the day's news. That meant getting more news "above the fold," getting non-breaking but larger important stories on the page and presenting a bigger variety of news (not just our Political bread and butter). We also wanted to carve out an opinion section on the front page to showcase writers and bloggers both at TPMCafe and influential voices around the web. (Here's Josh's main blog post on the redesign.)

In addition to this, I came at the project both through certain frustrations about the current page and inspiration I drew from other media organizations and designers whose work I respect and adore. My biggest problem with the legacy homepage was its monotony. The feature was always in the same place, the boxes dutifully marched down the page in the same row all the time. The wires became unreadable to me because they had morphed into undistinugishable blocks of text with nothing novel to pull me in. Even though our news staff was constantly hard at work with the sysephean task of refreshing the page, it didn't seem fresh to the eye because the layout was so uniform. With that in mind, my foremost goal with the redesign was asymmetry. The eye likes being stimulated to bounce around an uneven page moving from wide horizontal elements to long vertical elements to text to image all at different sizes. I recalled the "dollar bill" rule from high school journalism-- there shouldn't be a text area on the page large enough to fit a dollar bill without bumping into an element-- a pullquote, a photo, a headline, etc. Though on the flip side, I wanted this entropy to be forced to live within a rigid structure-- a strict grid. Through my long obsession with Khoi Vinh's work both at Behavior (where he redesigned The Onion on a strict 16 column grid) and now at the New York Times, and my more recent infatuation with the work of Antonio Carusone, Wilson Miner and other proponents of grids on the web, I knew I needed this project needed a strong grid backbone. The other reason I needed a grid was because I wanted the design to be modular, so a maximum of "controlled entropy" could be achieved.

the gridIn considering the grid skeleton, rather than reinventing the wheel, I decided to base the project on the 12-column framework (though in a slightly modified 1020px version). It's open source, easy to use, standards-compiant, browser-agnostic, inspired by designers I respect, extremely flexible and a pleasure to use. I can't recommend enough, and it became very important when building in the kind of advanced modularity I was going for.

Once I found my skeleton, Andrew Golis (our Deputy Publisher) and I started sketching out various kinds of news sections that could be acommodated. Rather than have the wires, boxes and other elements always be in the same spots, the new homepage is designed to easily allow different kinds of news wells to exist around the page. The basic building blocks are the same (the news wire, the HuffPo style big picture box, the basic headline and blurb or simply a raw hed), but they are now arranged in a more inviting and varied way, and they can be reconfigured on the fly. I also added a new element, what I call the "eyebrow" or topic text, which sits above headlines. I drew inspiration from various news sites for the different wells, though primarily drew from the Times (for elegant typography, colors and refer styles), the Guardian (for their grid and below-the-fold varied news well), the Onion (for their belt and grid), the Huffington Post (for their big picture boxes), Naz Hamid's Gaper's Block (for its clean design and beautiful CSS) and Coudal Partners (they made Times New Roman awesome again and also happen to do wires, what they call 'fresh signals,' really really well).


Inspirations. From left to right, a HuffPo news box, a Times newswire, the Guardian's varied news section, Coudal's Fresh Signals.

Areas within the Grid

the gridSo, how do these various elements come together within the 12 column grid? First, the news hole had to be defined. So, 4 columns out of the 12 are reserved for the blog (not an uncontroversial move since it meant squishing the blog ~30 px from its current, already narrow, width). We also had to allocate a 150px space on the right side for BlogAds (a tricky proposition since BlogAds are 150px and had to coexist with standard 160px wide skyscraper ads). Out of those constraints, arose an 8 column feature area, and a 6 column news hole under it. To further emphasize the concept of the "fold," there is a "belt" halfway down the page with a scrollable carousel of big think or big picture stories which we are tentatively calling the Must Reads section. So, in total, three news areas emerged-- the Feature (area A), the news well immediately under it (area B) and the below-the-fold sub-belt well (area C). Area A would primarily hold a big feature pic and headline, with an optional wire. This area was the part of the news section most similar to the legacy page. I spruced up the styles and type, but for the most part, that would live on in a similar way. But what would become of areas B and C?

I wanted areas B and C to be swappable into a number of pre-defined configurations. And I figured I'd design for this even though I didn't know yet how I would implement it in the CMS or allow for it to be changed by noncoders. With the assumption that there would be a way, I decided to chop up the areas into the following configurations: a full 6 column wide large headlines section, a 4 column/2 column section with HuffPo-style big pic boxes on the left, and Coudal-type wires on the right, a two 3 column wide section that would look a little like the lower part of the Guardian's homepage with varied boxes and blurbs and finally three 2-col wide columns which would create a "wire grid" a little like the lower half of the Times or the Onion homepage.

Options. Clockwise from left, options for the B and C sections: 6 wide, 4 col/2 col,2/2/2 col and 3 col/3 col news wells.

So I hardcoded that into the skeleton, spruced up the typography-- I went for Helvetica Neue (where available) for Headlines and eyebrow text and stuck with TPM stalwart Times New Roman for blurbs, related links and other text. As before, for various UI chrome, we use Trade Gothic Bold Condensed No. 20.

The Code and CMS

Hardcoding HTML with is almost criminally easy. Some of its detractors decry its anti-semantic method of naming its selectors grid_xx, but this can be overcome by adding semantic class names to each node in addition to the framework's structural ones. One of its best features is the ability to nest grids by use of the alpha and omega selectors which cleverly add and subtract gutter space when you put grids inside of grids. It also comes with easy clearing divs. As complicated as this grid got, I could never stump it-- and it just worked in every browser. All the IE6 and 7 headaches that inevitably arose were problems in my own css, never the framework's.

And while I'm gushing about frameworks, let me say that on this project I got into jQuery in a big way. Yes, it's the new hotness, and that is wholly deserved-- it's very easy to use, and is helping me quite a bit in getting over my JavaScriptPhobia. The scrolling belt is powered by jQuery and the excellent jCarouselLite plugin. There is also other jQuery stuff under the hood for prettifying ad placements, adjusting CSS, manipulating the DOM to adjust internal URLs for stats collecting, and, as I'll explain in the next section, in the backend for page layout. I really love how jQuery, through its design, encourages (almost forces) you to write semantic markup and keep your JS as unobtrusive as possible. It also abstracts browser bugs away, while at the same time steering you towards coding for browser feature incompatibilities rather than raw user agent sniffing. All in all, it's a fantastic framework, can't recommend it enough (especially for JS noobs like me). Digression over.

My Front Page meta-CMS

Needless to say, I needed to find a way to allow editors to switch these possible news sections around without having to touch the code. To do this, I wrote a kind of meta-CMS in PHP and jQuery that would live outside the Movable Type universe. Flat HTML files that Movable Type wrote would be PHP-included in this meta-CMS (which I call the FP Config), but by the time they reach it, they are simply raw text-- a series of pages for the chooser to select.

To start, I just took the code out of the news areas and saved them in separate files (one for each configuration for each area), then included them back in with PHP. Then I wrote a PHP form which wrote a small preferences file to the disk. The form provided options for the various configurations, and when the editor submitted the form, it would write the PHP prefs file which contained variables specifying the desired configuration for each area. This prefs file was then included onto the homepage and would dictate which configuration's file would be included.

The prefs file looks something like this:

<?php $featurewire = "false"; $area1 = "true"; $area2 = "fourtwo"; $area3 = "threethree"; $breaking = "false"; $banner = "false"; ?>

This worked splendidly, though I decided to take it a step further. What if the HTML form could be reduced to simply a floating box above the live homepage that allowed you to instantly see what the other configurations would look like inline as soon as you made a selection? And, if you liked what you saw, you could hit save and it would write the prefs file which would be included on the live page. This idea was too awesome to pass up, so I set about coding it by throwing the whole form onto a fixed div so it would scroll along with the page, and I included the live page under it. Then, in the code on the live page, I demarcated the boundaries of each area in a div that jQuery could target. From that point, I could do an ajax call which would "inject" one of the other configurations into the live page's DOM when one of the radio buttons was selected, giving the illusion to the editor that the page instantly flipped. Then on save, it would submit the form and write the file just as the old version had, and reload the settings page with the new live configuration just as it had looked when previewed.

Here's what it looks like in action. (H/t Ben Craw for the screencast):

This was a big advancement which firmly enabled my concept of the variable news areas. At this point, all the HTML was still hardcoded. I needed to get it to play along with Movable Type.

Integration with Movable Type

There are actually four separate MT blogs feeding the front page (five if you count the main left column blog). Once again, SqueezePlay, our custom homepage managing plugin from SixApart came to the rescue (I described a bit about how it works here). In a nutshell, it allows you to explode any blog into its constituent entries and rearrange them at will independent of their creation times. In the new modular homepage, every possible story placement gets its own slot, allowing editors to assign stories very precisely anywhere on the homepage. Each Area is handled by its own blog, with the various configurations spread out among available slots in that blog. And with FP Config it is now it is possible to actually preview what the homepage will look like before it is published, because you can save and assign a post to a slot in a nonvisible configuration, preview it through the ajax-loaded Config page, and then, once satisfied, publish it to the world.


All in all, I'm very happy with the way it turned out. One thing to note -- while I have written most of this explanation from a first person perspective, many of these design considerations are products of discussions and hashouts between me, Andrew and Josh along with feedback from the staff at various points along the way. That being said, as the sole developer, I appreciate the extraordinary amount of freedom I had in choosing and implementing the technologies, methods and frameworks used to bring the project to fruition.

If you have feedback, comments, concerns, etc. please email me at [almshaw] at [that very popular google email service] .com or find me on twitter at @a_l.