Yahoo!’s status as a bellwether of the Web was apparent in its recent push for standards. Its implementation of Web standards and creation of tools to build standards-based Web applications has not only created a fresh, uniform look and feel, but Yahoo! has garnered a great deal of goodwill with the Web community by openly releasing its research—and the fruits of that research—on its developer site, developer.yahoo.com.

We chatted with Jimmy byrum, a Web developer instrumental in building the new Yahoo! home page, to discuss the redesign process at Yahoo!.

Mark Trammell: Did your position change when you went out to London? Is it the same sort of position?

Jimmy Byrum: It’s similar. I wanted to have less responsibility, so I could focus on traveling around Europe. So, moving to London was more of a personal thing than a work thing—i had been working 12+ hour days in Sunnyvale for a few years. By then, I thought, “Yeah, I could move to London, travel around Europe, work eighthour days, and that’d be fine.”

I still worked on the front pages for a while, the European front pages. It was interesting, because there’s a lot of talk in the States about how to make internationalizable code. For the most part, I take my code from the States and make that work for different countries. The interesting part was seeing where I succeeded and failed as far as internationalization went.

That was probably one of the best things I learned thanks to the move. Now I think that internationalizing code is extremely easy—ridiculously easy, from a front-end engineer’s perspective. I can see some crazy issues on the back end, especially multibyte characters. But from a front-end perspective, I’m amazed that we didn’t figure it out sooner.

MT: How did having the history of going through the Yahoo redesign help?

JB: That was a huge project on its own, plus I had the opportunity of seeing the way Yahoo approached it. I think the way many U.S. Companies approach internationalization is they make a product and then they think, “How do we make this ready for other countries?” Had I known more at the time, I could have done it so the pages were immediately ready for other countries. It’s just a mindset change like any other best practice.

If you have a best practice for how to do things in CSS, then you can have a best practice for how to make code that’s internationalizable, and it’ll just work. Well, I shouldn’t say, “it’ll just work”—any time you say that, something seems to go wrong. Rather, it’ll be on the way to working.

MT: Regarding redesign process at Yahoo, were you on board at Yahoo before this discussion of a redesign, or did they bring you on board for that?

JB: I coded the previous home page as well, so I came in the mid-to-late redesign stage of the previous home page. I built that one. That was a completely different project than the latest home page. I also maintained and developed that home page and did the entire preface for the new one. So, yes, I was there.

MT: So did you choose the team? How did Yahoo build the team?

JB: Yahoo wanted to redesign the new one, and all previous iterations of the Yahoo home page were more iterations than a complete redesign. Though the company would think the page looked different, it still had the same basic structure. It would still even have the same widths of the columns, for instance.

And so with the new one, we decided that we wanted to do something different. We hired many new people, or brought people from other areas of Yahoo to the front-page team. Yahoo hired more engineers, kept a designer who was there for almost as long as I was, a good senior product manager, and a program manager. I had never heard of a program manager before that project. He managed the overall project. Actually, there were a few product managers, and the program manager managed them.

All of this came together in that the team consisted of the senior product manager, the senior designer, me, and everyone else to an extent. The main people designing were the senior product manager and the senior designer and I worked with both of them on how to make things, and what we could do. The senior designer would say, “We want to do this.” I would respond, “Well, we can do this, but it’s going to cost us this much in code, this much in speed,” and we would talk through that.

MT: When you say, “We want to do this,” who was “we”?

JB: The senior product manager and the senior designer. What they would do is talk to all the senior people on the team asking, “Can we do this?” I would come in and help with ideas. Mainly the senior back-end engineer and I would say if it’s possible or not. Then the senior product manager and senior designer would get buy-ins from the top execs.

Many times we would mock up things or we put them into usability testing, where people came in the lab on Yahoo’s campus. It’s like presenting all the evidence for a case to the senior executives to say, “This is why we want to make a drastic change to the home page.” that was the general process.

Once we got the buy-in from senior executives, we developed it and eventually did external bucket tests. It’s a very small percentage of the traffic, about 0.4%, but that’s a lot of people with the home-page traffic.

MT: You said that the previous iterations were an iterative process. In making changes over time, was there a lot of A-B testing involved? How did the team make those decisions?

JB: That’s what we did most of the time in between finishing the first redesign I worked on and starting the new page. Sometimes we would conduct five to ten different bucket tests, and ran them for about four weeks. We’d simultaneously run up to 10 tests and then review all of the data. Yahoo had a data analysis group working on the charts, the graphs, and the numbers.

MT: You said that folks came to the campus to do testing, but was there testing out in the field?

JB: There was for the new home page. They did do some testing where the user research people—obviously invited—went to people’s homes, to see how they used it and looked at what they did on the page.

They often traveled to different parts of the country, or different parts of the world. It was interesting just to see the results that they got. They made up different types of personas of people who use the front page and how they used it and why they used it. That was just another revelation of how much work went into just one page.

MT: How did the team make decisions? How much would the site comply with Web standards and validating code? Was that a big discussion or taken as a given?

JB: From the coding perspective, things like that were mostly in my court, in cases where I was the lead front-end engineer. I told the team that I believe in standards and writing accessible code. Yahoo, as a whole, was very much into that. I sat with a blind guy, our lead accessibility guy, and we browsed the page together. He would tell me what worked and what didn’t work. I made many accessibility decisions just by sitting with someone using a screen reader.

I made the decision to do it and worked it into my time estimates. I told the products people and everyone else why.

MT: With the home-page redesign, the team probably had to somehow push it out to other areas in Yahoo. How did that happen?

JB: Nate Koechley drove the front-end engineering at Yahoo for the GUI and accessible code. I think nate was the first person, back in 2004, who brought up LSMs (layered semantic markup), which is the precursor to keeping HTML, CSS, and JavaScript separated.

Developers coded things so they worked without the JavaScript and things like that. Nate was the first person who pushed it, back in 2004, and then I and others bought into it. Eventually, web-dev/front-end engineering agreed that this is what we need to do. If anyone at Yahoo pushed it, it was those of us in front-end engineering.

MT: Was there a training program put in place, or was it more of “Point to these references and go learn?”

JB: At the time when I joined, I was WebDev #24 at Yahoo. Front-end engineering contained only 24 people. Back then, we’d gather in a conference room and just talk about it. We also relied on email discussion lists and mockups. We didn’t have any accessibility experts at the time. In fact, we took our best guess on how screen readers worked at the time.

Around 2004 and 2005, we operated in terms of, “Well, we think this works and this is good,” and tried to get contacts with the JAWS people to see if they could help us. They advised us to an extent, but we started learning more about it once we had someone at Yahoo who used it as his only Web browser.

Web standards and accessibility started with us holding discussions and using email lists. Now there are over 200 WebDevs in Sunnyvale, so we have classes, best practices Web pages, documentation, and standardization. Standardization is weird because if you standardize too many things, you take some of the thinking out of the job’s daily routine.

MT: But to an extent, isn’t that a good thing?

JB: Yes, yes. YUI (Yahoo user interface) is great, I love the JavaScript portions of YUI, because it’s all these things like drag-and-drop that I would bang my head against for a while to build a good implementation, and now I can just go and take it and it works.

The reason that I don’t like to take all the thinking out of the job is that you can take something that’s prepackaged, but you don’t know why it’s done the way it’s done. And I think knowing why it’s done that way is important, because you understand that code better and you’re going to incorporate that into everything else you write.

MT: So what tools does Yahoo use to make sure people understand the decisions that were made?

JB: Understanding why comes from just communicating with each other through discussions, email lists, wiki pages, or talking to each other. We can also audit sites and do code reviews, but you can’t do a code review with 200 people.

I’d say the best way that I’ve seen it done is, let’s say you have a person at Yahoo who absolutely believes in standards and wants to enforce them. You make sure all your team leads believe in those standards, and those team leads can make sure that their team follows through on them. That’s what I did.

Honestly, working on the front page, you get the best developers. However, if anyone wrote code that I thought was not as accessible or took a shortcut, I’d request changes or say we’re not ready to push the code until this gets fixed. I don’t pass the code until it works, because no one else will do it except for nate and me, and the minority community of Web developers who pay attention to standards. The people using the Web and developing for the Web looked at it and paid attention.

MT: With the redesign, it was nice to work on the code from the beginning. How possible do you think it is to take an existing site and bring it up to the standards that everyone wants?

Because I was working on the home page from the beginning, I could make the decision to make it standards compliant, and I could do that without worrying about buy-ins. But with an existing site, you need buy-ins, because they’re thinking that we need to keep adding features while you’re thinking about making the code good. Making code good, aside from the benefits that we know about, many people don’t see the benefit of it.

MT: And discussions become esoteric, like whether you should try to style for Netscape 4.

JB: I will say that one thing that Yahoo had to face with this redesign—and we actually had a bit of discussion about it—is for the old page to separate HTML, styling, and behaviors; it could have had more, but it was a good step in the right direction. We also had a tables-based page, so that it would look good on NS4.

We also had a blacklist in Apache that would route NS4 and IE3 to the tablesbased page. It was important for business to ensure this page looks good everywhere. We finally have a true semantic page built with a base of HTML, adding styles and then adding behaviors in the newest page. So if you go to the page in NS4, you get the “upgrade browser” message along with links to modern browsers, I believe. We went in that direction with the argument that we’re presenting visitors with usable data because NS4 can process H1s and lists without a problem. From there, we progressively enhanced the page for newer browsers.

MT: How much Apache detection was going on since you would hand NS4 a different page?

JB: Right. With this redesign, we used to have a whitelist for the CSS page (CSS as opposed to the other page that used all tables) where we said, “We know IE5 and above is fine on this page, so go ahead. And we know Mozilla whatever-dot-whatever is fine, go ahead.” then we switched to a blacklist that let everyone in. The only Apache detection we do now is send people on mobile browsers to mobile sites. All in all, we switched from a whitelist setup to a blacklist setup, so we’re letting more people in, giving them valid markup, and presenting features to the browsers that can handle it.

MT: Since Nate worked on the YUI stuff, was that stuff available to you as part of the redesign in terms of the timeline?

JB: The YUI stuff, I believe, was still in beta when we were getting ready to go for it. A small portion of the work that I did for the old home page and the redesign was incorporated into the YUI stuff. So it was give and take. They’d give us good code, then I’d change it around and explain the reasons I did it a certain way and then work it into the YUI stuff.

So for the Spirit project—Spirit being the home page—it was half-and-half. Honestly, it was like that in general; the YUI guys are open. If anyone else can improve something in the library or find a better way to do something, we just work with each other to incorporate it and make sure it’s all as strong as possible. So, the general thing is I worked with them to develop YUI and in the end we used YUI stuff heavily in the Spirit page.

MT: How long did the whole process take?

JB: I think the official project took one year. Which, at the time, I was like, “one year?! It’s one page!” But then after doing that year I thought, “Oh, well, fair enough.”

MT: How many people were centrally involved in actually building the page?

JB: So you mean like product people, designers, back-end engineers, front-end engineers?

MT: Start with front-end engineers.

JB: There were two of us before the project started, and the other guy left to go to a startup, so I think I was the only one when the project started. We got a second guy full-time for front-end either right when the project started or shortly after. I would say two full-time for the duration, and we also got a third front-end guy who we borrowed from time to time from another group.

MT: Were there dedicated back-end engineers, or were cycles just siphoned off here and there?

JB: There was a front-end engineering manager, who didn’t really code much, he just managed the front-end engineers, and I believe there were actually two backend engineers who were coding full-time, and an engineering manager.

My manager and the engineering manager worked with each other more on scheduling whose time is going toward what in the grand scheme of things. The back-end engineer would pull in people from other projects. Overall, it was two full-time on front-end, two full-time on back-end, we each had a manager, and we would pull in people from other projects as well if we needed particular expertise.

MT: What about product folks?

JB: There was a senior product guy who worked with three product managers. There were three product managers working on specific parts of the page.

MT: Like how it would integrate into Messenger?

JB: Exactly. It was amazing because one portion of the page was sort of a product. So the product managers would do that and the senior guy would oversee the whole thing, and he also worked in-depth on a lot of it. There were two full-time designers and a design manager.

We made an open request to the design community and said, “Send us your designs for the new home page,” and we worked with Hillman Curtis. The dude is amazing; you want to work with him no matter what.

MT: When the goals of the redesign came about, how many people had input into what they were going to be?

JB: To broadly answer that question: input? A lot of people. because it’s the front page of Yahoo, everyone wants to have his or her input, and every executive is going to give his or her input on something. As far as when it comes down to who is making the decisions, I would say there was a group of about four people, and that would be top executives and the senior designer, senior product person. They would battle it out, and we would see who won.

MT: So, did the management allow the goals to stay constant through the whole thing and be somewhat broad, overarching goals? What were they, and did they change over the course of the redesign?

JB: There were obviously goals to increase number of searches. Generally, I would say the goals were to make the page better for the users, to make a cool page that people would actually enjoy using. Something that’s not just a Web page, but more interactive and gives you reasons to come back to it.

I would say that largely those goals stayed constant and what we argued the most about was how we were best going to achieve those goals. Some people worried about risk because it was a big change. People were concerned thinking thoughts like, “oh my God, are we going to screw everything up by changing it?” I would attribute the personalities of the people who were making the decisions as being willing to take the risks, believing that this is the best way to do it, so we’ll take the risk and do it.

While the main goals were maintained, there were other broad goals to make the page more fun, and these goals were very hard to quantify. But we quantified them through user feedback and by looking at clickthrough rates on A-b tests to see, were people clicking on more stuff, were they interacting with more parts of the page, and so on.

MT: During the redesign process, did the higher executives want to see deliverables along the way?

JB: Oh, yes.

MT: How many sets of deliverables that went up to them?

JB: I would guess, just as far as designs went, not even including any code or HTML mocks, they probably looked at 20 or 30 different designs, with many different variations of that. We tested many designs, and after we tested a bunch, say 10, we’d asked which did the best out of the 10. Based on the answer, we took the best ones from there and tested another 10 to see which were the best ones. There were meeting rooms with walls covered with printouts of different designs that we were testing.