On the Same Page

Chances are you know the work of Jeffrey Zeldman and Carrie Bickner, even if you don't realize it. Zeldman's many private sector commissions and the redesigned New York Public Library (NYPL) pages alike owe a lot to a mutual belief in crisp, clean design and straightforward language. A style guide that Bickner commissioned Zeldman to work on for NYPL staff has been circulating among both library and nonlibrary designers ever since its release at the end of October. Another coproduction, the web site for NYPL's Click On computer training program, has likewise garnered kudos and the attention of imitators.

Zeldman is also the man behind The Daily Report (www.zeldman.com) and A List Apart: For People Who Make Web Sites (www.alistapart.com), a popular journal and online community center for like-minded designers. In addition, he consults through his firm, Happy Cog, recently published Taking Your Talent to the Web (New Riders, 2001), and plays a lead role in The Web Standards Project. That group has fought for adherence to official World Wide Web Consortium (W3C) standards. Before turning his attentions to the web, Zeldman worked in journalism and advertising.

Web coordinator for the NYPL Branch Libraries, Bickner may be better known to library blog aficionados as the Rogue Librarian (www.roguelibrarian.net) or for her articles on A List Apart and TER. While earning her degree at the University of Michigan's School of Information, she worked on both the Internet Public Library and the Humanities Text Initiative.

Any one of their initiatives prove that libraries can produce top-of-the-line web projects to rival and even best those of the corporate world. What is more, their ongoing association shows that a successful partnership is based on something other than just a contract. The client-consultant relationship flourishes when both parties share fundamental beliefs and are clear about their mission from the inception. Last December, they sat down with frequent netConnect contributor Leo Robert Klein to talk about their collaborations.

If you want to hear more, Zeldman and Bickner will be speaking at the Public Library Association meeting in March.

LRK: How did you two come together for your first project?

CB: NYPL had received Library Services and Technology Act (LSTA) money to provide staff technology training. We had several components to carve out of the $48,000 grant, but, in particular, I was developing broad-based training for about 100 people on writing content—everyone from children's services to reference librarians who needed help tailoring their messages for the web. That was to take place last April. I was talking to a colleague about where to turn for help with this, and she pointed out that I had Zeldman.com up on my screen every day, so I gave Jeffrey a call.

JZ: The content talks were for a broad audience at NYPL. The thinking was that even supervisors should understand how their sites are viewed. They should know what makes people come to a site and read vs. what makes people come to a site and be confused and leave.

We went from the macrocosmic level to the microcosmic level. We went through the value of contextual linking, appropriate paragraph length, and the use of title attributes. And we talked about clarity of language.

LRK: Language is obviously important to you. Your NYPL sites ( www.nypl.org/branch/clickon and www.nypl.org/branch/choices ) are refreshingly lacking in library lexicon and jargon.

JZ: It's not a library issue. Corporations have a similar problem when the CEO approves something full of pomposity or feel-good language that doesn't mean anything. My advertising background helped me with that. I learned to take what a client says that makes sense in that client's world and think about who is the actual audience and how you talk to them. As a general principle, that means simple natural language, inviting, not overwritten. It can be quite intelligent and witty, I am not saying you have to write at a fourth-grade comprehension level.

LRK: It begins by understanding who your audience is. So how was the training received?

CB: The evaluations were great, but I realized how much it had sunk in while going around afterwards to staff meetings with various departments. I would hear people in the back of the room saying, "Well, of course you cannot just take a brochure and slap it up on the web," as if this is something that everyone here had always known. That was great.

LRK: You also ran technical training sessions that built on your shared passion for standards.

CB: The second phase in June was to develop web standards for 14 people who build and program the sites. Specifically, we focused on HTML, XHTML, and Cascading Style Sheets. These are talented people who already had expertise with markup. But so often with the web, people come to it with different backgrounds, having learned markup in different ways. That training and the style guide that followed up on it were meant to help everyone make the commitment to standards. It helped us move forward as an institution.

LRK: Let's talk about the style guide ( www.nypl.org/styleguide ), which I have seen people in all different sorts of forums writing about. What led you to think about developing that?

CB: It was something I had been thinking about for a while. I knew how I wanted pages to be built, but it was only in my head, and I really needed it to be more formal. So I talked to Jeffrey about the parameters of the project and how it related to the material we had already been presenting.

Also, I wanted to have something ready for consultants. I needed a way to weed out people who really didn't know what they were doing. If you have the documentation to refer to, you can get better work.

JZ: I think you wanted a way to help your colleagues implement some of the ideas that we talked about. What better way to do that than with a simple tutorial. One of the things librarians understand is respecting document structure. A lot of people who do web development in libraries know more about SGML and HTML than people in web agencies who just buy Dreamweaver but don't understand that there is a whole philosophy behind structured markup language.

LRK: Okay, you knew you wanted to have a style guide to serve as a platform for how to build pages according to standards. But how do you choose the appropriate level and form for the standards?

JZ: We chose XHTML—Carrie recommended and I agreed—because the web is moving toward XML but not there yet. The web is moving toward a time when we can say, "Here is the content that can be used for wireless devices or a Braille reader or it can be used in various browsers, and separately here are Style Sheets or other technologies that can control the layout." Right now we are in a transitional period away from HTML, which mixes descriptions of content with descriptions of layout.

There is a form of XML called XHTML—the web browser thinks it is regular HTML and displays it properly, but it is really XML. In this way, some people can have an old browser that would access everything on the library's web site, but at the same time it is moving toward the XML ideal and will be forward compatible.

CB: The issue of compatibility was one of the big things. Standards have this preservation aspect. We know our standards-compliant code works on existing browsers, but we know it will work on evolving devices down the line as well. Libraries above all institutions should be concerned about this question of durability, and I wanted the style guide to address that question.

JZ: Of all the things we have done together—the talks, the two fully designed web sites, and the style guide—I think in a way the thing I am happiest with is the style guide because it has gone on to function as a free little book for anyone in web development, in a library or not, that basically gets them up to speed on W3C-compliant standards.

CB: That was an opportunity to share with our colleagues. When you are funded through an LSTA grant, you want to provide something of value. We wanted to put up something other libraries could use.

LRK: Let's move on to the Click On site, which was such an eye-catcher when it came out. The site is the public face for a pretty ambitious program with the mission of minimizing the Digital Divide. How did that program get started?

CB: Planning for this project began in 2000, and we were hearing so much about the Digital Divide and thinking about how libraries could close the gap. We had offered computer classes before, and we knew we were providing access to the public, but we weren't doing a great job of marketing those services. We knew that a more concentrated administrative effort could help us broaden these services. Click On gave us an opportunity to concentrate our efforts and to come up with a branded program that targets a particular audience.

We worked with a very generous private funder who helped us put a structure around the services. We were able to hire a training coordinator, administrative staff, and dedicated staff for the training centers. Up until then it was just whoever happened to be at the branch and was available. There were already eight technology instruction centers; we have added two more. We have 85 branches serving three boroughs, so we try to place them where they will have the most impact. We could put 100 PCs in every branch and still not have enough.

LRK: They are hosting all sorts of classes?

CB: We have classes dealing with using the Internet but also classes just on e-mail basics and even touch on mouse basics. One of the very first classes we offered when we started Click On was Introduction to the PC. The instructor said come back tomorrow if you want to go over it again; eight of the 12 people came back to practice turning the computers off and on.

LRK: It is important never to assume certain knowledge.

JZ: The way devices have been created is not completely transparent: Get rid of something by "putting it in the trash"; go to the "start menu" to shut down the computer. You do have to learn these things.

LRK: Can you talk about the development of the Click On web site?

CB: My RFP had a lot of standards requirements written into it as well. It was the first one I had written where web standards were to be central. I was reacting to previous assignments that didn't deliver basic best practices: Pages didn't have document type definition or clean markup or use of alt tags for accessibility. I had outlined these requirements in detail in my RFP. I knew Jeffrey could respond to these technical requirements so I sent it over to him.

JZ: What I really remember about the request, aside from the talk about the look and feel, was that the technical requirements focused on three main points. Separation of style and structure through rigorous use of web standards; rigorous support of accessibility; and support of NYPL's baseline browser, Netscape 4.0. Risking the whole thing, I wrote back and said you can have two out of three. I think the honesty helped me get it.

CB: We wanted our site to meet several standards including the W3C priority-one rating for accessibility, but we also wanted to work on Netscape 4, which doesn't really support W3C standards. By going with the transitional rather than strict standard, our pages still validate: the markup is still well formed, and the pages are still accessible. By saying we could have two of our three wishes, Jeffrey helped us arrive at the transitional standard.

JZ: We have a little line at the bottom of a page that doesn't show up in Netscape 4; so be it. Can the people read the content? That's good enough.

LRK: It's never so absolute when you are designing for multiple browsers and operating systems.

JZ: Unfortunately, a lot of web designers are under the impression that the page must look and function exactly the same in every browser. They are willing to write all kinds of bad markup and bad code to make that happen.

In the interests of backward compatibility—that is making it visible on all these current or older versions of various browsers—you are limiting your forward compatibility. At some point these sorts of web sites will stop working. Using certain really common web standards from W3C that are supported in Explorer and Netscape and Opera makes a whole lot more sense when one thinks about the web in terms of going forward and not just writing for here and now.

LRK: Then that was a major concern for the Style Guide but also for Click On?

JZ: I was looking for clients that wanted that, and Carrie was looking for vendors that felt that way. We were very compatible.

LRK: Once you accepted Jeffrey's proposal, what was the development process like? How does the designer fit in with the ideas the institution has? Had NYPL already decided on the categories and organizing the subjects?

CB: We had the basic categories but working together we reworded them and did some regrouping.

JZ: They had done a really good job of organizing it. Before even doing any kind of layout, however, Leigh [Baker-Foley, partner at NotLimitedNYC, a design consultancy, who also worked on the site] and I looked and could say, "If these menu items each have four or five characters and this one has 17, the menu bar is going to look kind of funny." These two categories might melt together and then we could have six categories instead of seven. We helped in that way. But there was a lot of information architectural work done by Carrie and Catherine [Jones, NYPL Branch Libraries' web editorial coordinator] and Kate [Todd, Click On training coordinator].

CB: One of the things that made working with Jeffrey and Leigh so attractive was not just the design but the writing. The two really go together. It isn't just a matter of how to write paragraphs of copy for sites. You use words everywhere, in URLs and navigation, and it's good to use them in ways that are clear and memorable. One should be able to intuit what might be on a page from its URL.

When you look at a site like this, it is really easy to underestimate the impact of this clean navigation. It takes a lot of work to get something that simple.

LRK: That's a wonderful way of putting it.

JZ: So often a client has very literal expectations of wanting this and that included. You end up having 500 paragraphs and 800 links on the first page. When I go to a big portal like that, I leave. I don't know where to begin. I feel that the designer and the client didn't do their job. I don't go to a movie and expect to see all the shots on the screen at the same time. I expect the director to decide this shot should come first. Or for a library analogy, don't put all the books in the front hall.

LRK: Implementing a clean design, intelligible and very open, calls on several skills, and it is easy to lose track of that goal in the process.

JZ: One thing that can make that happen is if certain people are empowered inside the institution. You cannot always avoid committees and you certainly have to keep people abreast and get their input. But sites often fall apart when there is no key decision-maker and everyone on the committee gets a little piece. That is how you end up with these eight-eyed camels for web sites.

LRK: What was the reception to the site?

CB: After the launch, our classes were quite full, and we had to turn people away. The classes are still extremely popular, and we have been expanding hours. Now we don't know exactly what will happen with the budget. Also, we got lots of very positive feedback from designers who went to the site after Jeffrey mentioned it on A List Apart.

LRK: Are you working on anything new now?

CB: Choices in Health Information has been around for about three-and-a-half years, but we are giving it a new web site, with new design and new architecture. It is set to open next week. [The site debuted on schedule, December 14, 2001.—Ed.]