Editor’s note: In this 50th anniversary year of IEEE Spectrum, we are using each month’s Spectral Lines to recount some pivotal moments of the magazine’s history. Here, Digital Editorial Director Harry Goldstein describes the origins and evolution of Spectrum’s website.
Websites are about the content they feature, the technology they’re built on, and the people who make them. And all three of those elements are always changing. If you take a ride in Brewster Kahle’s Wayback Machine, as I did recently, you’ll find six distinct IEEE Spectrum websites spanning 18 years. There were three radically different designs in the last 7 years alone.
It all started in 1996, with a lot of hand coding and head scratching. Richard Comerford, then a senior editor at Spectrum, and Craig Engler, electronic publishing editor, led the effort that created our first site by writing its code in HTML, line by line. A typical coding session would have Comerford or Engler at the keyboard and Mark Montgomery, now our senior art director, offering design guidance over their shoulders.
Hand Coded: The 28 June 1996 Spectrum website was crafted by editors Richard Comerford and Craig Engler.
I took charge of the site a decade later, in 2007. I was not a newbie—I’d written for first-generation websites like Utne Lens and Tripod in the mid-1990s and I had crudely coded some HTML for a hypertext novel I put up on the Web around the same time—but I was basically thrown into the deep end of the pool. Fortunately, I had company: an intern named Joshua J. Romero, who would eventually become Spectrum’s first senior interactive editor.
The site we inherited was hard to read, difficult to navigate, and, in general, outdated. So we soon set about planning the one that would replace it. Like many publications, we were feeling our way into this burgeoning world of online journalism, and there were bumps, false starts, dead ends, and crashes. But it was a great opportunity to learn the nuances of website engineering.
After sketching out the basic structure of the site with the usability experts at Interface Guru, we assigned the task of building it to Agile Partners. Agile practices the iterative software development methodology known as scrum to prioritize and manage its programmers’ daily tasks. I’d written about complex software projects, but I had not been involved in one myself, and I was quickly plunged into an intense routine of daily stand-up meetings and perpetual iteration. I would often have a phone pressed to each ear, with a project manager on one and the lead developer on the other. I’d be clarifying requirements for the content management system and the website’s front end, which is what users see when they visit the site. After six months, the code was finished.
We’d taken the prototype for a few test drives, but there was no formal beta-test period. We were going to cut over from the old site to the new one and, at the same time, migrate the thousands of pages from the old site to the new one. It was, to put it mildly, a high-risk maneuver.
We started that migration on a Friday night at the end of May 2009 so everything would be live on Monday morning. Yes, there were pizza boxes and cans of Red Bull scattered around our office in New York City, and the 12-hour sessions staring at our screens left us all bleary-eyed. Lead developer Franqueli Mendez, a black-bearded giant, enveloped his laptop like a serenely calm, code-cranking Buddha. Josh and I sat next to each other, frantically tagging content from the old site with our production team of Jacqueline Parker and Michael Spector at their cubes in Piscataway, N.J., and in the virtual trenches with us.
At the heart of a publication’s website is a content management system (CMS), which we use to produce and track all the articles, videos, audio segments, still photographs, and other items that constitute the entire site. During that cutover weekend, our group became intimately acquainted with our new CMS, the four of us slotting old articles and blog entries into topical channels and loading visually exciting stories onto the home page. Meanwhile, Franqueli’s fingers danced across the keyboard, fixing bugs on the fly.
When the site launched, we high-fived and hugged each other like we’d just won the World Cup. We took a few moments to appreciate the magnitude of the change. Visually, our site had been instantly transmogrified from a dull blue smudge that you had to squint to read to a (maybe too) vibrant green-and-orange frame for the best tech journalism on the planet. And then we got to work fixing the bugs Franqueli hadn’t gotten to.
In comparison with the rough-and-tumble of that fifth-generation launch, the design and implementation last year of our sixth-gen site, the one you are probably viewing right now, was downright dull. Josh, Kenneth Liu (our lead developer), and I had learned much in the intervening four years. The site redesign had a clear goal: to provide a great experience for people viewing it on anything from a smartphone to an HDTV screen. Our scrum planning meetings were tightly structured, our requirements very clearly defined, our sprints more efficient. Testing happened in concert with development. Our design partners at Method delivered detailed, documented specs and front-end code. A five-month-long beta period gave us time to migrate all our existing content to the new formats and also to elicit user feedback that we incorporated before launch. When the site went live in May 2013, it did so with little fuss and no glitches.
Our site now has the flexibility to feature new kinds of content, such as the interactive Top Programming Languages app, and new blogs, such as Cars That Think and View From the Valley, which both debuted in May. And we’re not done. Like organisms, the only websites that don’t change are the dead ones. The Wayback Machine is littered with them.