Part 1: The Adaptive Path and improving web design

Hi Jeffrey, a thrill to talk to you. Can you briefly tell us about your path to the Web and your company Adaptive Path?
Thanks for the opportunity. Let's see, I guess this all started at Wired Magazine when we launched hotwired.com back in '94. The next six years were a blur of innovation and experimentation, building HotBot, Wired News, Webmonkey, and so many others.

Webmonkey in particular holds a special place with me. I think we've helped a lot of people with that site, and we continue to. But Wired was bought by Lycos and Lycos then got swallowed by Terra and things just got too big. I left with the thought of taking some time off, then maybe doing a little consulting.

Turns out I wasn't the only one in that sort of situation. After a few weeks of traveling, I started talking to some of my peers and friends who were thinking of also doing some consulting. We realized that by joining forces, we could do a lot more interesting work. That became Adaptive Path, seven user experience consultants doing hands-on work in Information Architecture, Usability, and Design Strategy. It's turning out to be a lot of fun.

In your column in Webmonkey, you wrote about the "magic" of monolith Microsoft's Doctype and how it will affect the browser standards problem, can you talk about that a bit?
Sure. Ever since there has been more than one browser, things have been a mess. While browsers were never really designed to display HTML consistently with other browsers, that's been the expectation of most Web designers. The unfortunate reality of this is that many of the bugs in the browsers have become a sort of defacto standard. So designers come to depend on them and the browser developers refuse to fix them because they rightly fear the "You broke my website" complaints they'd get.

To solve this problem, both of the latest versions of Netscape and Internet Explorer have included the ability to switch how they display HTML and CSS based on what DocType declaration you've included in your source code.

So, if you say, "This is HTML 3.2" the browser will render your content with all the visual bugs that have always been there. If, though, you say, "This is xHTML" the browser will show everything as it is specified in the specification. It means that we can start writing standard compliant code and label it as such and get consistent results from both browsers.

Your book "The Art and Science of Web Design" was written to help one "think like a web designer," what are the ways to do that?
It's amazing to me that more Web designers don't understand why the Web works the way it does. I talk in the book about the print designers I worked with at Wired Magazine. They were amazing in their knowledge of not only the design process, but the print process. They could tell you more than you'd ever want to know about how inks interact with one another, how paper absorbed them, how different types of light reflected off them and on and on. It made them better designers.

That's why I'm astounded by designers on the Web who feel that HTML is too limiting for their creatively. Granted, HTML is primitive when compared to the typographic and visual design capabilities of even the simplest desktop publishing program. But it's also a universal format for displaying information globally. Understanding those limitations and capabilities and exploiting both is the key to becoming a good Web designer.

And along with understanding limitations as a designer, why are design strategies for multi-browsers important to address?
Can you imagine a world where you have to upgrade to the latest NTSC color specification in your television just to watch "ER" next week? Of course not. Unfortunately, that's the case with the Web today, and it will be for some time to come.

To account for this, we need to make our sites as accessible as possible. And this isn't just between those who use Netscape and those who use Internet Explorer. We need to consider alternative browsers.

For example search engines can be considered browsers since they send indexing scripts to our websites to gather our pages into their databases. Does your site accommodate them? How about people who can't see the screen, and are having your pages read aloud to them with screen reading software? What's that experience like? These are the things that keep me awake at night. They should do the same for you.

Tell us about your term "OOP" and how designers can use it for empowerment?
Object Oriented Publishing is a term I use to refer to the kinds of systems that are used these days to build dynamic, database-driven websites. The idea is relatively simple: You strip your content of all design and put it in a database as its component parts. Then, you create templates that suck the content out of the database, wrap it in your interface, and send it out to the user. Systems like this are built using Microsoft's Active Server Pages, or Macromedia's Cold Fusion, or the open source PHP.

Many designers I've spoken with feel like systems like these are the domain of engineers and programmers. I totally disagree. Designers can harness the power of systems like this by understanding a few basic principles of writing code and then just jumping in and getting their hands dirty. The benefits are amazing.

You can control the appearance of thousands of pages on your website by manipulating just one template. Designers can stop worrying about mundane tasks like adding FONT tags to HTML pages and moving files around on a server. They can start focusing on the architecture of their sites rather than the individual pages.

And yet as a designer, can you ultimately control the way the page will be displayed?
You cannot tell what your pages will look like on everyone's computers. You can try, but you will fail. Print designers have a hard time with this. The try to have the same control over their design on the Web that they did when they were creating layouts on paper. But on the Web, we send the source code of our design to our users, where it gets interpreted in a variety of ways. We don't know what fonts they have installed, what platform they are using, how much color resolution they have, how big their browser window is.

Using client side scripting, however, we can start to get a glimpse into our users' environments. We can ask the browser how wide it currently is, and create interfaces that exploit that information. That's just an example. Eventually, every piece of your interface can be based on a relative value (rather) than an absolute one, and you end up with a page that completely adapts to the user, rather than forcing the user to adapt to it.

Have you ever been to a website that requires you to have certain fonts installed, or to stretch your browser window open to a certain width? That's just crazy. Designers need to account for those variables.

Continued...