It’s been echoing all over the blogosphere today that NYTimes.com “hand codes everything” instead of using a WYSIWYG editor. It all extrapolates from a fairly offhand reference by the design director, Khoi Vinh:

It’s our preference to use a text editor, like HomeSite, TextPad or TextMate, to “hand code” everything, rather than to use a wysiwyg (what you see is what you get) HTML and CSS authoring program, like Dreamweaver. We just find it yields better and faster results.

But really the browser-to-browser consistency that you see (and I have to admit, it’s far from perfect) is the result of a vigilant collaboration between many different groups — the visual designers and technologists in the design team that I lead, their counterparts in our technology staff, and the many, many detail-oriented people who come together to make the site a reality every hour of every day.

One of the things that makes my job here so satisfying is that, among all of these many different kinds of collaborators, there’s a healthy respect for design. Everyone is committed to putting the best face forward for The Times — including paying close attention to visual integrity of the site. Regardless of the tools you use, it’s really only that kind of commitment that makes it possible to maintain consistency on a site as sprawling as ours.

There’s a few things I find intriguing about this. Firstly, everyone has latched on to the first part of the answer about not using a WYSIWYG editor, whereas the actual quote goes on to explain that it’s really “the result of a vigilant collaboration between many different groups”. In other words, to create a consistent looking site you need a bunch of talented people working really hard and being vigilant about it. That shouldn’t be a surprise to anyone.

Secondly, I find it quite hard to believe that with all the content on NYTimes.com that they’re using TextPad or TextMate – implying they either aren’t using a web content management system or are going through a checkout/checkin process to get the HTML into an external tool. It also surprises me a great deal that all the contributors to NYTimes.com know how to hand code HTML.

These things surprise me so much in fact that I’m left wondering if what Khoi meant was that they hand code the design structure, presentation templates etc but that the articles on the site come through a CMS etc, possibly using WYSIWYG editors of some kind. I’ve worked with a number of big publishing companies (but not the NY Times) and this is exactly how the system works. The journalists use a structured WYSIWYG editor, often utilizing some form of XML schema, and that is pushed through the publishing system for review and eventually goes into the final site (advanced systems push the same article to the print and online editions simultaneously, though obviously with different type setting etc before it’s actually output).

In such a system, the overall site design team may well hand code all their HTML code for the overall site structure, the CSS etc. The articles themselves are just slotted in where they fit and generally don’t cause too many issues because they generally don’t have too many complex parts to them. Even insets, sidebars and the like are just an XML tag in the source the WYSIWYG editor creates and the publishing system converts it to carefully crafted, cross browser HTML that displays the right way.

A primitive form of that system is used by many blogs, including this one. All the templates are hand crafted HTML, but all the actual article content is created in a WYSIWYG editor and slotted into the template.

Backing up my theory is Khoi’s answer to what his team actually does:

When most people hear “design” and “NYTimes.com” together, they usually think of the wonderful interactive graphics or multimedia storytelling done by our colleagues on the graphics and multimedia teams. (In fact, Steve Duenes, the graphics director, offered lots of insight into much of this work in his own Talk to the Newsroom session some weeks ago.)

Though we do work with these teams in a support capacity, it’s not the core of what we do. If you think of their work as design for the content that appears on our site, then you can think of the work that my team does as design for the framework for that content. Which is to say, we create the underlying platform on top of which the content sits.

That and the fact that the NY Times blogs are actually based on WordPress which includes a WYSIWYG editor for authors (though it can be disabled):

The challenge is even more complex when you consider that, though each blog has its own needs, the vast majority must be based on a single template (within WordPress, our Web log publishing system) that manages all of the blogs together.

and sure enough, there is a content management system behind the scenes that the editors and writers use which sounds just like the classic set up I’ve seen at other publishers, where the article is encoded in some type of system specific markup (usually an XML schema):

Our director of content management systems, Brad Kagawa, said, “The need to structure data” — encode the content in such a way that it makes sense to our systems — “is sometimes at odds with the desire to have custom layouts. With the C.M.S. publishing to dozens of delivery channels (Web, RSS, mobile, Times Reader, the Times archive, various partner feeds, Amazon Kindle, etc.) we have to store everything in a structured and non-Web-centric way but at the same time retain that flexibility.”

Overall, I wouldn’t take the quote too out of context and get carried away to say that everything should be hand coded. It very much sounds like the NY Times works with a sound balance of hand coding, management systems and non-technical author friendly tools mixed in to maximize overall productivity and effectiveness. You’ll find that’s how most publishing houses work, from small one man blogs like this one right up to the NY Times, Time Inc, MSN etc. Limiting all your work to WYSIWYG editors is stupid, but expecting journalists and editors to hand craft HTML isn’t such a good idea either – that’s just not their strength.