By Molly E. Holzschlag
Published on January 7, 2001
January 26th, 2001 marks the first birthday of XHTML 1.0 as the W3C recommendation for Web markup. But XHTML has yet to toddle, yet to smile, yet to cry loud enough so as to get the attention of most Web designers.
The problem with XHTML 1.0 isn't a matter of strength, or of importance. XHTML is both strong and important--and not just for markup snobs and hardcore developers. It's not that XHTML 1.0 has a particularly high learning curve. It doesn't--in fact, it's quite easy to learn. And, it's not that XHTML 1.0 doesn't display in browsers both current and past. When written with awareness of cross-browser considerations--just as with HTML, it does.
The problem lies in the fact that XHTML is, quite simply, misunderstood.
Why this misunderstanding exists is a bit more complicated. On a very basic level, XHTML breeds fear in some people because it's XML--and XML sounds a whole lot more abstract than HTML ever did. For the experienced designer who has a more intimate knowledge of HTML, the rationale for XHTML 1.0 can be a bit hard to get at. I mean, who wants to try and decipher W3C documents anyway? Typically convoluted, overly detailed, and most definitely not-user friendly, W3C specifications are not written with the right-brained, creative personality in mind.
Finally, the software companies who provide designers with visual design tools and HTML editors have mostly ignored W3C recommendations to begin with, much less adopted as part of their tool sets. So, for the designer who wants to focus on design rather than markup--well, he or she has to trust that the software manufacturer is adhering to current recommendations.
As a result, the busy designer--if fortunate enough to have a few days to sit down and research current recommendation support in software, or whether XHTML 1.0 makes sense to use, has to unravel so much stuff to get to the point that it's an exhausting proposition.
Kind of like taking care of a one year old.
First, What the Heck is XHTML?
It's important to begin with an understanding of what XHTML is. To do this, let's take a quick look back at the history of HTML. For some readers of Digital Web this information is old hat. But it's going to be the essential kernel from which decisions about XHTML are made, so bear with me.
HTML evolved from the Standard Generalized Markup Language, SGML. SGML is what's referred to as a "meta" language. It exists to create other markup languages. SGML is essentially a collection of language rules that authors then use to create their own document methods. HTML is one of the resulting languages--a child, if you will, of its meta-parent SGML.
Another child of SGML is XML, the Extensible Markup Language. Interestingly, XML is also a meta-language. It, too, exists as a means of creating other languages. The thing to understand about SGML is that it's a very complex meta-language, extremely detailed. XML emerged as a streamlined meta-language suitable for creating Web markup languages that are customizable and flexible for the needs of specific applications. Examples of XML markup applications include Scalable Vector Graphics (SVG), Synchronized Multimedia Integration Language (SMIL), and Wireless Markup Language (WML).
XHTML is the reformulation of HTML as an XML application. In other words, XHTML looks at HTML through the eyes of XML. The rules and methodologies of XML are applied to HTML, bringing syntactical strength back into HTML, which lost that strength during its rapid evolution from text document markup language to the de facto language of visual design.
XHTML 1.0 is the first version of XHTML, which is a fairly rigid markup language. Its rules are very straight-forward, and there's really little extensibility involved in XHTML in that you can't write your own definitions as to how the language behaves. You've got to follow the rules. XHTML 1.0 also adopts concepts introduced in HTML 4.0--which in and of itself asks some structured behavior from anyone using it to markup documents or creating software-be it a visual editor or a Web browser.
Digging Deeper
In its early life, HTML was very simple. It existed wholly to identify a given document as being an HTML document, and allow for some very basic formatting--paragraphs, line breaks. Designers must remember that the Web was first a text-only environment! HTML was not developed with presentation concerns in mind. Rather, its goal was the structuring of data.
Enter the visual browser, which changed this text environment from one constructed of text documents to one that promised growing opportunities for visual design. HTML-and Web browsers themselves--were stretched out of proportion in order to accommodate the rapid-fire pace of the Web's visual and interactive growth. Designers, especially, were naturally more concerned with creating designs that were visually rich and esthetically pleasing.
Trying to manipulate HTML to do what you want is pretty frustrating right? No consistent layout support. No consistent way to control white space. No stable way to manage type. A designer's nightmare--born of the very fact that the Web was never intended to be a visual environment. But it became one, and how to manage that reality has been a challenge ever since.
Admittedly, presentation has always seemed to have taken a back seat with the committees who work on markup languages. CSS might ideally bring a lot more control to designers, but we all know that this is the stuff that turns our hair gray. For designers, the real issue boils down to needing better tools to control design--not technology.
The Cold, Hard Truth
The fact of the matter is that XHTML is not about presentation. What XHTML does do is revisit the concept of strong markup for documents. Using XHTML will help you strengthen the structure and syntax of your markup. Why is this even important? Well, if you consider the direction that technology is going, it makes a lot of sense. The future information designer will have to include numerous user agents in his or her plan. The browser-based Web with which we are so familiar is no longer the only consideration. Documents will be required to appear esthetically pleasing on the Web as well as pleasing and logical in numerous environments--pagers, PDAs, cell phones, etc.
XHTML enables any creator of documents, whether designer or developer, to stabilize that document, which makes it more interoperable. XHTML also allows you to use Extensible Style Language, XSL, with transformations. By using this XML-based style technology, you can actually transform a document from one type to another--say from an HTML document to a PDF document. What's more, learning to author XHTML documents helps designers unfamiliar with programming or more abstract markup transition into the extensible world. Using XHTML means using vocabulary you're familiar with--the HTML tags and attributes you work with every day. But, you're doing it in the context of XML, and that means that when you move to pick up other XML technologies, it's going to be that much easier. Learning XHTML means that learning SMIL and SVG will be all that much more easy.
And XHTML--in coordination with emerging technologies, is also moving us toward options that will allow us to profile a user agent and deliver the appropriate document based on that profile--on the server, not client-side, which means no JavaScript and therefore no cross-browser/user agent considerations. This is all really powerful stuff!
But what's it got to do with a visual designer concerned with and only with designing for the Web? The cold hard truth is, not much.
And herein lies the real question that designers must ask when mapping XHTML into the plan. Are you looking for a means to control visual design for the Web? Or, are you looking for ways to extend your information to other agents such as wireless devices? This is the heart of the matter. If you have no interest in expanding beyond the Web, then XHTML only offers a few advantages, and in some cases may even cause you harm.
When to XHTML, When to Punt
It's imperative that designers view XHTML 1.0 as a transitional methodology. It's here now, but its goals appear to be more about stabilizing technology than advancing it. Newer versions of XHTML and other technologies will do that. So realistically, despite the fact that it is the current Web markup recommendation, it may not be the wise choice for you.
When do you use XHTML 1.0? Consider these questions:
* Do you see a need for your work to be extended to other delivery mechanisms such as wireless devices now or in the future?
* Do you want an educational tool that will transition you and your colleagues from HTML to the XML world with relative ease?
* Do you want to bring syntactical strength to your Web documents, even if it means compromising certain visual considerations?
* Are you concerned with following W3C recommendations in order to promote more stable support from the developers of browsers and Web design tools?
If you answered "yes" to any one, or any combination of these questions, then XHTML 1.0 is something you might seriously wish to consider.
If Yes, Then XHTML 1.0
If you want to look at XHTML 1.0 a little more closely, begin by assessing the information needs of your design group. If you're a one-person shop, it's going to be a bit of a commitment to learn XHTML 1.0 and transition documents. If you are an art director or designer working with a team--this is something you may recommend to your HTML folks to look into. There are some excellent resources on XHTML that are much more accessible than the W3C documents, I recommend them in the Resources section at the end of this article. This will get you or your document folk off to the right start.
There are some considerations of which to be aware when saying "yes" to XHTML 1.0:
* Be aware of presentation limitations. Even though it's not required in transitional XHTML 1.0 documents to use CSS for presentation, some proprietary tags and attributes have been omitted from the transitional definition for XHTML. The ideal XHTML document relies on CSS for presentation. But we all know that CSS, despite its promise, is less than ideal in the way browsers support it. A perfect example of this is anything to do with box properties. Margins and borders are especially problematic. Let's say you've been using the topmargin="x" attribute in your body tag to gain more control over your margins. Well, you can't do it in XHTML. The topmargin attribute was left out of the definition, and CSS support is inadequate. As a result, you lose effective, interoperable control of margins in valid XHTML documents.
* Be aware of integration concerns. Do your sites integrate markup from any other source? One example of this that I learned the hard way came with markup that is provided to WebReview.com by its ad servers. The markup is poorly formed, and when dropped into our sexy new XHTML documents, renders them invalid. Do they still display? Absolutely. But do the documents validate? No, they don't. Any markup that comes at you from another source will have to be rewritten to comply with XHTML syntax. If that markup is delivered dynamically, you'll be facing the difficult task of convincing the individuals responsible for that markup to switch to XHTML--as if doing it yourself weren't time consuming enough!
* Consider the scope of your project. Transitioning large sites to XHTML is a decision that is entirely up to you. You might end up dealing with concerns, as I have, that your markup doesn't validate as XHTML despite your best intentions because you didn't assess what ad codes might do to the site. When you've got a few pages, that's one thing, but when you've got 10,000 pages, it's maddening! What's more, once you've made the choice of using XHTML, you will also need to consider that some of those documents will require further technologies, design approaches, or updates in order to effectively reach wider audiences via wireless or alternative devices.
This is by no means a complete list, but it's a short list of the major walls I've come up against when using XHTML 1.0 in real-time. Hopefully, these points will help you avoid similar pitfalls.
If No, Punt Gracefully, Please
Despite the fact that this article is geared toward helping designers, the bottom line is that technology is what we do--even if our primary job is to make esthetic decisions about the way things look rather than the way they work. Web markup is innately related to design. Without a proper understanding of markup, the designer is at a disadvantage.
Part of the challenge designers have with markup is that they haven't paid attention to recommendations at all, much less what's going on with XHTML. Whether because we have such limited time to spend studying, or the difficult learning curves, most designers aren't even using HTML that conforms the HTML recommendations set forth by the W3C, much less prepared to use XHTML.
Let's back up for a sec and examine what standards are. The goal of a standard is to create consistent implementation of a given technology across the boards. In an ideal world, this would mean that all manufacturers of browsers and visual editors would adhere to a certain level of consistent technology. There are all kinds of technical standards. And, we refer to what the W3C puts out as "standards."
However, use of this language is faulty. The reason is that HTML and XHTML as defined by the W3C are not standards. They are recommendations. The W3C working groups consist of intelligent, visionary individuals and companies seeking to produce thoughtful guidelines by which to create, grow, and guide the Web technologies we use. But they are not the boss of me. Or you. You don't have to follow the recommendations--and in fact, most people do not!
But, there are advantages to doing so. If you decide to not use XHTML 1.0, I'm very concerned that you at least consider following the recommendations set forth by the W3C for HTML 4.0 (specifically, HTML 4.01, which is the final version of HTML).
If we are not self-policing, it's that much harder to suggest to any company delivering a browser or a design tool to be as well. And that potentially hurts us as designers, because we lose consistency. This can be clearly seen with CSS, and it is even more clearly demonstrated with what happened recently when Netscape 6.0--in a valiant effort to support the W3C recommendations as thoroughly as possible--intentionally left its own proprietary layers tag out of the browser. This issue is really upsetting to designers, but the alternative perspective is that at least we begin at the same starting point and work from there. We don't pull out our hair worrying which browser will or won't support our designs. We know they either will, or they won't, and that's incredible empowerment for us.
What About the Future?
If you've been thinking that following recommendations such as HTML 4.0 or XHTML 1.0 is pain enough, Modularization of XHTML, which entered W3C Candidate Recommendation status as of October 2000, is bound to leave you reaching for the Advil. Or a stiff shot of pepper Vodka--whichever is closer.
XHTML Modularization, when compared with XHTML 1.0, is extremely abstract--but in many ways more powerful, giving more control to the individual who's examining which markup methods work best in a given situation. The idea with modularization is that individual control as to what we need when structuring a given document is paramount. All of the components of Web markup: images, tables, text formatting, and so on, are separated into modules. Then, a document type definition (DTD) can be written calling on any of the existing modules as needed. So, if you only wanted text and images in your documents, that's all you use. The resulting markup is very uncomplicated--which makes a whole lot of sense when you're structuring information for a wireless device. But, if you're focused on designing a complex layout with rollovers for a Web page, it's pretty near useless.
Ultimately, XHTML is not something designers should heartily embrace unless there's a real need to do so. I am personally committed to supporting W3C recommendations--so much so that I've spent the last year of my life educating people about XHTML and what its advantages are. However, I live and work in the real world, too, so I can't afford to just be an evangelist. I have to look at the realities, and at the end of the day, it is clear that XHTML was never made for the designer. The harsh reality is that HTML was never made for the designer, either. And usability freaks step aside, please, because the only successful Web technology that's truly been created with designers in mind is Flash. SVG and SMIL are emerging as potential opportunities, but the implementation for each is limited at this time, so they're not real contenders yet.
But of course, our futures as Web designers requires that we learn about and sometimes embrace new technologies. Whether you decide XHTML is something that makes sense for your goals or not is an extremely personal decision. But learning the issues, staying as current as possible with W3C recommendations, and making informed decisions as to which technologies you implement empowers all of us in the end. And that's a very worthy goal.
Friday, October 5, 2007
Beyond the IA Guy
By David Wertheimer
Published on August 20, 2002
What is information architecture, and how does it exist beyond an "IA guy"?
This seemingly simple question was posed to me in June by Charles Hamilton, chair of the World Wide Web Artists' Consortium (WWWAC ) Development SIG. Hamilton was putting together a panel on IA and had invited me to participate.
The invitation was deceptively simple: "We will be looking at 'nuts-and-bolts' aspects of particular business cases," read the email, "where information architecture plays a crucial role in complex online products." That certainly covered my employer's Web site, but I didn't fancy myself an information architect.
Hamilton took another view. While my office does not have a designated information architect on staff, information architecture itself takes place in numerous ways across a variety of departments. While I spend my time thinking about usability, design, and markup, the decisions I make directly influence the information architecture of the sites I create, and vice versa.
I always assumed that IA dealt, on its simplest level, with the organizational flow of data. But as a subject, I define IA as encompassing so much more. Information architecture is a new term for an obvious and necessary aspect of Web site development. Its importance lies not only in stressing the need for good IA but in getting the members of a staff to realize the role IA plays in each of their jobs.
Where the Roles Are
Behind the scenes, developers--programmers, database administrators, and technical staff-have an obvious need for IA. With parameters set by the information architect's deliverables, development can flow more easily than ill-defined tasks. Developers also do plenty of IA of their own, making determinations in database structure and retrieval methods that affect the final presentation and utility of data.
For designers, IA dictates what goes where. Sometimes a designer will be handed a set of requirements to follow; other times, the designer will have to clarify flow and format. All the decisions that are made-from the placement of links and text to the progression from page to page-encompass IA to some degree.
A solid editorial team needs information architecture to know how to arrange information for later retrieval by the site visitor. Both content-rich and commerce-based sites benefit from the definition of solid structural basics that define how items are written and filed. Those same basics, determined in conjunction with the development staff, places each piece of copy in a context richer than its basic existence. As an example, this individual column falls within the regular column Wide Open, as well as within the Columns area of Digital Web. These distinctions also spill into design. By knowing which items go on which pages, and where on those pages items should go, editors can write pieces that make sense relative to their destinations.
What I find interesting is that a sales staff can benefit by knowledge of IA as well. A salesperson with knowledge of a site's hierarchy can pitch ad campaigns based on complementary areas of the site; marketing staff can find ways to simplify processes and promote useful systems. By understanding how a site is assembled, the sales team, which is responsible for championing the benefits of the site, can find new and unique ways to promote it.
That Night...
The night of the WWWAC panel, I started the evening by telling the audience that I was not an IA, and that my site did not employ one. Rather, the entire team, even without defining itself as such, must work as site architects as well as focusing on their own specialties. Working as a department we achieve many important and interesting IA goals.
Rob Larson, the information architect for New York Times Digital, also sat on the panel. His mission was far more focused: He had to make sense of vast amounts of data, dissecting and organizing information into forms that could be accessed by the Times' audience. The complex system used by Times Digital was a result of his hands-on work.
The key in addressing such complexities lies not just in hiring an IA, or using the buzzwords and jargon associated with the field, but also in getting a team to understand the importance of structure.
When a sales team asks how to implement a new sponsorship concept, they need to understand the intended flow of traffic from and to the sponsored areas. When the editorial director wants to add a new text component, the editor can assist in conceptualizing its realm in the main database, and defining its relationships to the literal page on which it will be read. Designers have the need to take page-by-page process into account when creating their wireframes, and developers should think beyond their task lists to visualize the system as a complete, smoothly operating whole.
IA's Worthy!
Remember that IA, for all its worthiness, still has the feel of a new-economy buzzword. Grab hold of its basic tenets and make those into concepts that feel sensible and worthwhile to people other than the actual staff IA. Just as he or she must think about technology and design, so should everyone pay attention to the tenets of information architecture.
Published on August 20, 2002
What is information architecture, and how does it exist beyond an "IA guy"?
This seemingly simple question was posed to me in June by Charles Hamilton, chair of the World Wide Web Artists' Consortium (WWWAC ) Development SIG. Hamilton was putting together a panel on IA and had invited me to participate.
The invitation was deceptively simple: "We will be looking at 'nuts-and-bolts' aspects of particular business cases," read the email, "where information architecture plays a crucial role in complex online products." That certainly covered my employer's Web site, but I didn't fancy myself an information architect.
Hamilton took another view. While my office does not have a designated information architect on staff, information architecture itself takes place in numerous ways across a variety of departments. While I spend my time thinking about usability, design, and markup, the decisions I make directly influence the information architecture of the sites I create, and vice versa.
I always assumed that IA dealt, on its simplest level, with the organizational flow of data. But as a subject, I define IA as encompassing so much more. Information architecture is a new term for an obvious and necessary aspect of Web site development. Its importance lies not only in stressing the need for good IA but in getting the members of a staff to realize the role IA plays in each of their jobs.
Where the Roles Are
Behind the scenes, developers--programmers, database administrators, and technical staff-have an obvious need for IA. With parameters set by the information architect's deliverables, development can flow more easily than ill-defined tasks. Developers also do plenty of IA of their own, making determinations in database structure and retrieval methods that affect the final presentation and utility of data.
For designers, IA dictates what goes where. Sometimes a designer will be handed a set of requirements to follow; other times, the designer will have to clarify flow and format. All the decisions that are made-from the placement of links and text to the progression from page to page-encompass IA to some degree.
A solid editorial team needs information architecture to know how to arrange information for later retrieval by the site visitor. Both content-rich and commerce-based sites benefit from the definition of solid structural basics that define how items are written and filed. Those same basics, determined in conjunction with the development staff, places each piece of copy in a context richer than its basic existence. As an example, this individual column falls within the regular column Wide Open, as well as within the Columns area of Digital Web. These distinctions also spill into design. By knowing which items go on which pages, and where on those pages items should go, editors can write pieces that make sense relative to their destinations.
What I find interesting is that a sales staff can benefit by knowledge of IA as well. A salesperson with knowledge of a site's hierarchy can pitch ad campaigns based on complementary areas of the site; marketing staff can find ways to simplify processes and promote useful systems. By understanding how a site is assembled, the sales team, which is responsible for championing the benefits of the site, can find new and unique ways to promote it.
That Night...
The night of the WWWAC panel, I started the evening by telling the audience that I was not an IA, and that my site did not employ one. Rather, the entire team, even without defining itself as such, must work as site architects as well as focusing on their own specialties. Working as a department we achieve many important and interesting IA goals.
Rob Larson, the information architect for New York Times Digital, also sat on the panel. His mission was far more focused: He had to make sense of vast amounts of data, dissecting and organizing information into forms that could be accessed by the Times' audience. The complex system used by Times Digital was a result of his hands-on work.
The key in addressing such complexities lies not just in hiring an IA, or using the buzzwords and jargon associated with the field, but also in getting a team to understand the importance of structure.
When a sales team asks how to implement a new sponsorship concept, they need to understand the intended flow of traffic from and to the sponsored areas. When the editorial director wants to add a new text component, the editor can assist in conceptualizing its realm in the main database, and defining its relationships to the literal page on which it will be read. Designers have the need to take page-by-page process into account when creating their wireframes, and developers should think beyond their task lists to visualize the system as a complete, smoothly operating whole.
IA's Worthy!
Remember that IA, for all its worthiness, still has the feel of a new-economy buzzword. Grab hold of its basic tenets and make those into concepts that feel sensible and worthwhile to people other than the actual staff IA. Just as he or she must think about technology and design, so should everyone pay attention to the tenets of information architecture.
Information Architecture: Blueprints for the Web
By James McNally
Published on January 8, 2003
I’ve always disliked the “Dummies” books—you know, the ones with the bright yellow covers. Despite the potential for funny titles (“Cooking for Dummies”), I’ve always found them to be vaguely insulting. When it comes to the burgeoning field of Information Architecture, however, a book for beginners (not always dummies) would be welcome. And now it’s here.
Christina Wodtke is an experienced information architect who also happens to possess a unique flair for putting things simply. Her writing is remarkably jargon-free, even conspiratorial, as she walks the beginner through the process of building the scaffolding around a Web site.
She begins with a bang by deflating the so-called gurus of usability. While recognizing how central issues of usability must be, she distinguishes between gurus who lay down rigid rules, and teachers who provide useful and flexible tools. In fact, if I were asked to provide a three-word summary instead of a thousand-word review, I’d write “Tools, Not Rules.”
She takes on widely-held pieces of wisdom such as “Users don’t read” and “Users don’t scroll” and restores them to their place as guidelines instead of inflexible commandments. Wodtke believes that instead of simplifying the process of Web design, the gurus have only made it more bland with their pronouncements. There really aren’t any shortcuts to a well-designed and usable Web site, but the work isn’t that difficult if you have a plan.
Wodtke provides, in the place of rules, a set of general guidelines that don’t shackle the designer’s creativity. They are flexible enough to be considered without being simple good/bad judgments.
* Design for Wayfinding
* Set Expectations and Provide Feedback
* Ergonomic Design
* Be Consistent and Consider Standards
* Provide Error Support—Prevent, Protect, and Inform
* Rely on Recognition Rather Than on Recall
* Provide for People of Varying Skill Levels
* Provide Meaningful and Contextual Help and Documentation
* As useful as these guidelines are, Wodtke irreverently ends the chapter with the advice, “Beware of easy-to-get, easy-to-remember answers.”
The next major section of the book deals with user-centered design. Wodtke advises that before you open up Illustrator or Photoshop or Dreamweaver, you take into consideration who you’re designing the site for, and that you talk to some of them. She provides useful information regarding how to choose users for this task, how to interview them, how to design and then test a prototype site, and how to incorporate user feedback into the redesigned prototype.
Once you have a working prototype, Wodtke suggests you take a look at the site’s content and set about organizing it. Since most users come to a Web site to find something or to do something, they must be able to find the data they’ve come to interact with quickly and without unnecessary work. Wodtke divides up the user’s experience into three questions:
* Am I in the right place?
* Do they have what I’m looking for?
* Do they have anything better?
At each stage of this process, the site’s organization should reassure the user and keep them clicking.
Wodtke introduces the concept of metadata (“information about information”) in Chapter 6, “A Bricklayer’s View of Information Architecture.” By recording all the descriptive terms and organizational categories for an item (the metadata), it helps ensure that each particular item can be found, no matter how the user decides to search. The three major types of metadata are Descriptive, Intrinsic, and Administrative.
Descriptive metadata concerns the nature of the thing described. What is it? What does it look/feel/smell like? What categories could it fit into?
Intrinsic metadata deals with the thing’s composition. Is it a document? An image? What size is it?
Administrative metadata addresses questions surrounding how the thing is to be handled. Does this need to be archived? Who’s the editor/author/photographer?
The most important type for most Web designers is Descriptive, since that is how humans remember and search for information. HTML places descriptive metadata in the < META > tag, using the Keyword attribute.
Having your content all broken down into descriptive metadata won’t help unless you know exactly how and what your user will be looking for. The next major section of the book discusses the use of personas, made-up user profiles that are useful as a target audience when designing the site. Personas were a concept borrowed from an old market research technique. If the research showed that the audience was 68% female, and 52% between the ages of 25 and 35, the marketers would develop a user persona who was a 27-year old woman, and design their marketing campaign for that imaginary person.
Designing for a person, not for an undefined group, is a useful process, no matter that the person is not an actual user. By focusing as narrowly as possible, it forces the design to meet the particular limitations and preferences of that user—not exclusively, of course, but by imagining a single person instead of a huge audience, designers can put themselves in the user’s position.
Wodtke moves on to discuss the specifics of designing the site’s interface, using the following five guidelines:
* Simplicity and Elegance
* Proximity and Relevance
* Focus and Feedback
* A Hierarchy of Importance, A Hierarchy of Task
* The Right Tool for the Right Job
* Each guideline is accompanied by real-world examples, and several different options are explored, including several schemes for navigation (tabbed, left navbar, page-turning, breadcrumbs).
Finally, in Chapter 9, Wodtke teaches what her title hints at: blueprinting. Despite the temptation to pick up pencil and paper (or software) right away, she insists that only after thinking about metadata, the audience, and the interface choices can designers sit down to draw. Here she provides extremely practical information about different types of diagrams, storyboards, wireframes, and site maps to plan the site architecture.
Information Architecture: Blueprints For The Web is a well-written, thorough, and, most of all, fun-to-read primer on the field for the novice. It is not an exhaustive reference (see Rosenfeld and Morville’s Information Architecture for the World Wide Web, Second Edition, reviewed for this column in August 2002), but it is a non-intimidating introduction to a field that has become an integral part of effective Web design.
Near the end of the book, Wodtke outlines a real-world project of hers, the redesign of the site you are now reading. After reading her book, I am confident that we couldn’t be in better hands.
Published on January 8, 2003
I’ve always disliked the “Dummies” books—you know, the ones with the bright yellow covers. Despite the potential for funny titles (“Cooking for Dummies”), I’ve always found them to be vaguely insulting. When it comes to the burgeoning field of Information Architecture, however, a book for beginners (not always dummies) would be welcome. And now it’s here.
Christina Wodtke is an experienced information architect who also happens to possess a unique flair for putting things simply. Her writing is remarkably jargon-free, even conspiratorial, as she walks the beginner through the process of building the scaffolding around a Web site.
She begins with a bang by deflating the so-called gurus of usability. While recognizing how central issues of usability must be, she distinguishes between gurus who lay down rigid rules, and teachers who provide useful and flexible tools. In fact, if I were asked to provide a three-word summary instead of a thousand-word review, I’d write “Tools, Not Rules.”
She takes on widely-held pieces of wisdom such as “Users don’t read” and “Users don’t scroll” and restores them to their place as guidelines instead of inflexible commandments. Wodtke believes that instead of simplifying the process of Web design, the gurus have only made it more bland with their pronouncements. There really aren’t any shortcuts to a well-designed and usable Web site, but the work isn’t that difficult if you have a plan.
Wodtke provides, in the place of rules, a set of general guidelines that don’t shackle the designer’s creativity. They are flexible enough to be considered without being simple good/bad judgments.
* Design for Wayfinding
* Set Expectations and Provide Feedback
* Ergonomic Design
* Be Consistent and Consider Standards
* Provide Error Support—Prevent, Protect, and Inform
* Rely on Recognition Rather Than on Recall
* Provide for People of Varying Skill Levels
* Provide Meaningful and Contextual Help and Documentation
* As useful as these guidelines are, Wodtke irreverently ends the chapter with the advice, “Beware of easy-to-get, easy-to-remember answers.”
The next major section of the book deals with user-centered design. Wodtke advises that before you open up Illustrator or Photoshop or Dreamweaver, you take into consideration who you’re designing the site for, and that you talk to some of them. She provides useful information regarding how to choose users for this task, how to interview them, how to design and then test a prototype site, and how to incorporate user feedback into the redesigned prototype.
Once you have a working prototype, Wodtke suggests you take a look at the site’s content and set about organizing it. Since most users come to a Web site to find something or to do something, they must be able to find the data they’ve come to interact with quickly and without unnecessary work. Wodtke divides up the user’s experience into three questions:
* Am I in the right place?
* Do they have what I’m looking for?
* Do they have anything better?
At each stage of this process, the site’s organization should reassure the user and keep them clicking.
Wodtke introduces the concept of metadata (“information about information”) in Chapter 6, “A Bricklayer’s View of Information Architecture.” By recording all the descriptive terms and organizational categories for an item (the metadata), it helps ensure that each particular item can be found, no matter how the user decides to search. The three major types of metadata are Descriptive, Intrinsic, and Administrative.
Descriptive metadata concerns the nature of the thing described. What is it? What does it look/feel/smell like? What categories could it fit into?
Intrinsic metadata deals with the thing’s composition. Is it a document? An image? What size is it?
Administrative metadata addresses questions surrounding how the thing is to be handled. Does this need to be archived? Who’s the editor/author/photographer?
The most important type for most Web designers is Descriptive, since that is how humans remember and search for information. HTML places descriptive metadata in the < META > tag, using the Keyword attribute.
Having your content all broken down into descriptive metadata won’t help unless you know exactly how and what your user will be looking for. The next major section of the book discusses the use of personas, made-up user profiles that are useful as a target audience when designing the site. Personas were a concept borrowed from an old market research technique. If the research showed that the audience was 68% female, and 52% between the ages of 25 and 35, the marketers would develop a user persona who was a 27-year old woman, and design their marketing campaign for that imaginary person.
Designing for a person, not for an undefined group, is a useful process, no matter that the person is not an actual user. By focusing as narrowly as possible, it forces the design to meet the particular limitations and preferences of that user—not exclusively, of course, but by imagining a single person instead of a huge audience, designers can put themselves in the user’s position.
Wodtke moves on to discuss the specifics of designing the site’s interface, using the following five guidelines:
* Simplicity and Elegance
* Proximity and Relevance
* Focus and Feedback
* A Hierarchy of Importance, A Hierarchy of Task
* The Right Tool for the Right Job
* Each guideline is accompanied by real-world examples, and several different options are explored, including several schemes for navigation (tabbed, left navbar, page-turning, breadcrumbs).
Finally, in Chapter 9, Wodtke teaches what her title hints at: blueprinting. Despite the temptation to pick up pencil and paper (or software) right away, she insists that only after thinking about metadata, the audience, and the interface choices can designers sit down to draw. Here she provides extremely practical information about different types of diagrams, storyboards, wireframes, and site maps to plan the site architecture.
Information Architecture: Blueprints For The Web is a well-written, thorough, and, most of all, fun-to-read primer on the field for the novice. It is not an exhaustive reference (see Rosenfeld and Morville’s Information Architecture for the World Wide Web, Second Edition, reviewed for this column in August 2002), but it is a non-intimidating introduction to a field that has become an integral part of effective Web design.
Near the end of the book, Wodtke outlines a real-world project of hers, the redesign of the site you are now reading. After reading her book, I am confident that we couldn’t be in better hands.
Designing for Scalability
By Jeff Lash
Published on June 23, 2004
All Web sites will scale over time. No site will remain the same as it was when first launched—nor should it. The rise in popularity of content management systems shows that the old days of launching a site, and then not maintaining it, are over. Designers are now working on the same site for months or even years. Over time, new needs will be identified and new features will need to be added; a site needs to be flexible to change so these post-launch updates can be made quickly and easily.
On the one hand, there is the need to create a design that will function effectively for the present, without regard for how and when the site may change in the future. On the other hand, there is the need to allow for change and expansion by creating an architecture that will support transformation without requiring a complete overhaul. So where can we find this balance?
The importance of scalability
The main reason to design for scalability is reduced cost and effort. If a site had to be totally redesigned every time a new product or service is introduced, every time the business goals shift, or new user research identifies new needs, sites would be in a continual state of being redesigned. Major changes will inevitably occur, but the cost and effort of those changes can be reduced by allowing for easier, iterative updates and transformations, thus saving the major redesigns only for when they are really needed.
Whether one believes that major re-launches are unnecessary or inevitable (there are compelling arguments on both sides), it should be clear to all that any site needs to be able to easily support some level of flexibility and scalability.
Too often project teams underestimate the amount of maintenance required to keep a site current and to make normal day-to-day changes. When even normal operational tasks are not anticipated, it is obvious that there will be no understanding of the long term effort needed to make major changes. Additional sections and content may not be able to fit into the initial design and a massive redesign would be required for even the smallest expansion.
Sometimes, though less frequently, project teams focus on the long term without an understanding of the present situation. They look at where the site will be several years after launch and design for that amount of functionality and content without acknowledging and designing for what is currently available. Leaving space for additional navigational elements, for example, is a good idea, but if those additional elements will not appear for several years, it hampers the current design of the site by making it appear barren and incomplete. The initial design needs to be successful enough to ensure the site will still exist in several years, when these long term plans will come to fruition.
Underestimating the amount of scalability that will be needed, and over-preparing for expansion, are both problems that can present themselves in a development process. The key to avoiding them is to have a thorough understanding of the business goals and user needs, for both the short term and the long term, and using that understanding to drive the design and scalability needs of the site.
Getting back to goals
Since business goals and user needs will change over time, some may say it is more important to focus on the current situation and not be hampered by future uncertainty. Business goals and user needs will indeed change, but there are certain basic principles that will not. Knowing today’s long term business strategy will provide a foundation on which to plan.
For example, let’s take the example of two hypothetical record companies. Both Company A and Company B produce children’s CDs—“edutainment” recordings for the under-10 crowd. Both have roughly the same number of recordings, target the same age groups, and sell their products direct-to-consumer. Their sites should be basically the same, right?
Company A advertises their products in media oriented toward seniors, targeting grandparents who buy gifts for young grandchildren. They are thinking of starting to produce children’s DVDs, as well, since CDs and DVDs are complementary items and would be an easy sell to buyers familiar with their current products.
Company B advertises their products in media oriented toward children—like cartoons or kids’ magazines—to get the children to ask their parents to buy the CDs for them. They are sticking to CDs, but are thinking of expanding their offerings to older children since they have a market of growing children who already know the company’s name and recordings.
Think for a moment how these two sites, if designed today from scratch, would need to be different. The short term business goals are probably the same—to drive sales of their current products—but their current user needs are probably different since the needs of grandparents may not be the same as those of parents. It is these differences, in the long term business goals and user needs, which will create the distinctions between the sites.
A site designed for Company A today would need to support their move into DVDs. It should focus on CDs for now, since that is currently their only product, but make it easy to add a section for DVDs, and related material, when those are added several years down the line.
Today, a site designed for Company B would not need to worry about adding a section for DVDs but would need to allow for more differentiation by age groups than Company A. Company B may also need to focus on the children themselves, as primary customers, since older children may be more influential in the buying process and more likely to be heavy users of the site.
One other important factor to consider is the actual likelihood of additional areas being added to the site. Business plans do not always pan out. Some ideas for new products, features, or changes in strategy sound grand on paper but never make it to fruition. Designing for scalability means weighing the likelihood of each type of scalability. This is a tough decision, since business owners do not tend to admit that their plans may not reach the market.
Without a clear answer, it is best to look at all the future plans and consider which of the different features or products are most likely to occur. The comparative probability of success is more important than the absolute; even if all of the areas are eventually added, having some sort of priority order is beneficial for planning purposes.
In the end, the decision needs to be a weighing of the complexity and depth of the new feature or content area, the timeline for this addition, and the comparative likelihood of it actually occurring. It is better to spend time worrying about a small feature that will probably be added a year from now than an unlikely large change that would not take effect for several years.
Successful design teams acknowledge that some change is inevitable and balance their short term and long term priorities, creating site architectures that are flexible and scalable. A successful design team will revisit business goals and user needs on a regular basis and make changes as necessary.
Published on June 23, 2004
All Web sites will scale over time. No site will remain the same as it was when first launched—nor should it. The rise in popularity of content management systems shows that the old days of launching a site, and then not maintaining it, are over. Designers are now working on the same site for months or even years. Over time, new needs will be identified and new features will need to be added; a site needs to be flexible to change so these post-launch updates can be made quickly and easily.
The main reason to design for scalability is reduced cost and effort.
On the one hand, there is the need to create a design that will function effectively for the present, without regard for how and when the site may change in the future. On the other hand, there is the need to allow for change and expansion by creating an architecture that will support transformation without requiring a complete overhaul. So where can we find this balance?
The importance of scalability
The main reason to design for scalability is reduced cost and effort. If a site had to be totally redesigned every time a new product or service is introduced, every time the business goals shift, or new user research identifies new needs, sites would be in a continual state of being redesigned. Major changes will inevitably occur, but the cost and effort of those changes can be reduced by allowing for easier, iterative updates and transformations, thus saving the major redesigns only for when they are really needed.
Whether one believes that major re-launches are unnecessary or inevitable (there are compelling arguments on both sides), it should be clear to all that any site needs to be able to easily support some level of flexibility and scalability.
Too often project teams underestimate the amount of maintenance required to keep a site current and to make normal day-to-day changes. When even normal operational tasks are not anticipated, it is obvious that there will be no understanding of the long term effort needed to make major changes. Additional sections and content may not be able to fit into the initial design and a massive redesign would be required for even the smallest expansion.
Sometimes, though less frequently, project teams focus on the long term without an understanding of the present situation. They look at where the site will be several years after launch and design for that amount of functionality and content without acknowledging and designing for what is currently available. Leaving space for additional navigational elements, for example, is a good idea, but if those additional elements will not appear for several years, it hampers the current design of the site by making it appear barren and incomplete. The initial design needs to be successful enough to ensure the site will still exist in several years, when these long term plans will come to fruition.
Underestimating the amount of scalability that will be needed, and over-preparing for expansion, are both problems that can present themselves in a development process. The key to avoiding them is to have a thorough understanding of the business goals and user needs, for both the short term and the long term, and using that understanding to drive the design and scalability needs of the site.
Getting back to goals
Since business goals and user needs will change over time, some may say it is more important to focus on the current situation and not be hampered by future uncertainty. Business goals and user needs will indeed change, but there are certain basic principles that will not. Knowing today’s long term business strategy will provide a foundation on which to plan.
For example, let’s take the example of two hypothetical record companies. Both Company A and Company B produce children’s CDs—“edutainment” recordings for the under-10 crowd. Both have roughly the same number of recordings, target the same age groups, and sell their products direct-to-consumer. Their sites should be basically the same, right?
Company A advertises their products in media oriented toward seniors, targeting grandparents who buy gifts for young grandchildren. They are thinking of starting to produce children’s DVDs, as well, since CDs and DVDs are complementary items and would be an easy sell to buyers familiar with their current products.
Company B advertises their products in media oriented toward children—like cartoons or kids’ magazines—to get the children to ask their parents to buy the CDs for them. They are sticking to CDs, but are thinking of expanding their offerings to older children since they have a market of growing children who already know the company’s name and recordings.
Think for a moment how these two sites, if designed today from scratch, would need to be different. The short term business goals are probably the same—to drive sales of their current products—but their current user needs are probably different since the needs of grandparents may not be the same as those of parents. It is these differences, in the long term business goals and user needs, which will create the distinctions between the sites.
A site designed for Company A today would need to support their move into DVDs. It should focus on CDs for now, since that is currently their only product, but make it easy to add a section for DVDs, and related material, when those are added several years down the line.
Today, a site designed for Company B would not need to worry about adding a section for DVDs but would need to allow for more differentiation by age groups than Company A. Company B may also need to focus on the children themselves, as primary customers, since older children may be more influential in the buying process and more likely to be heavy users of the site.
One other important factor to consider is the actual likelihood of additional areas being added to the site. Business plans do not always pan out. Some ideas for new products, features, or changes in strategy sound grand on paper but never make it to fruition. Designing for scalability means weighing the likelihood of each type of scalability. This is a tough decision, since business owners do not tend to admit that their plans may not reach the market.
Without a clear answer, it is best to look at all the future plans and consider which of the different features or products are most likely to occur. The comparative probability of success is more important than the absolute; even if all of the areas are eventually added, having some sort of priority order is beneficial for planning purposes.
In the end, the decision needs to be a weighing of the complexity and depth of the new feature or content area, the timeline for this addition, and the comparative likelihood of it actually occurring. It is better to spend time worrying about a small feature that will probably be added a year from now than an unlikely large change that would not take effect for several years.
Successful design teams acknowledge that some change is inevitable and balance their short term and long term priorities, creating site architectures that are flexible and scalable. A successful design team will revisit business goals and user needs on a regular basis and make changes as necessary.
Information Architecture as an Extension of Web Design
By Joshua Kaufman
Published on February 17, 2005
Both information architects and Web designers can be too presumptuous about what the other does. They’re continually putting each other into little boxes, trying to define each other’s role.
On one hand, many Web designers don’t understand information architecture’s role within Web design. Designers think that information architects are the people who keep trying to organize everything. On the other hand, many information architects underestimate the Web designer’s role within a project. Information architects think they should write the site specification and that designers should code it.
One consequence of this misunderstanding is that information architecture and Web design are often considered mutually exclusive. Information architecture involves organizing, structuring and labeling; Web design involves technical development and visual design. In turn, Web designers have been led to believe that they’re restricted to doing what they’ve always done and should leave the information architecture to the information architects. This does not have to happen.
While it’s true that everything in Information Architecture for the World Wide Web cannot be learned in a day, there are several information architecture techniques that Web designers can easily learn and apply to all of their projects. This involves looking at information architecture as an extension of Web design. This perspective has several advantages:
It virtually eliminates the “us vs. them” ideology, which usually ends up hurting both disciplines.
It doesn’t place boundaries around the roles. Instead, it treats the roles as a continuum.
It allows Web designers to realize that they know more about information architecture than they think.
It helps Web designers transition from that role to an information architecture role more easily.
To put this idea into practice, we’ll look at three common Web design tasks (navigation, layout and code) and extend them into the realm of information architecture.
Navigation
Let’s start with navigation, one of the most loved and hated aspects of Web design. As individual pages are added to the site, it’s very difficult for a Web designer to resist immediately grouping those pages into categories that make sense--to the designer. The problem with this, as many of you know, is that the visitor often doesn’t share the same mental model of the site content and may not realize that what they’re looking for is not in the current area that they’re browsing.
As a preliminary exercise, it’s perfectly fine to group the pages into categories in order to develop a navigation scheme. But after this exercise, you should ask some potential users of the site to do a card sort. A card sort is an exercise used to find out how people group things, and what names they give those groups. It’s as easy as 1-2-3:
Write down the names of all your pages on pieces of paper.
Ask the participant to group them, creating subgroups if necessary.
Ask the participant to name the groups.
After moderating several card sorts, patterns will begin to emerge that will help you to find a dominant organization scheme.
Here’s how to make the extension. After you know what content your site will contain, do a card sort with at least several potential users of the site. Afterwards, you’ll have what information architects call a taxonomy, a hierarchical classification scheme. This taxonomy will prove extremely valuable when deciding on your navigation labels and the site maps for your site.
Layout
Next, let’s look at layouts, which have long been an important aspect of Web design. The prominence of the layout has led many Web designers to become very proficient at moving page sections around in Photoshop. Circa 1996, this was sufficient for most projects, and still is to some degree. But for multi-national sites with large and diverse user bases, Web designers need to develop more than just a page layout. They need to develop a page schematic or wireframe.
Wireframes describe the contents of the page through the use of a grayscale block-level diagram. They can range in level of detail, but typically show the location of content, images, navigation and other functionality on the page. It sounds a lot like laying out a page in Photoshop at first, but because it’s inherently focused on information rather than visual design, it’s a valuable tool for examining the relationships between information, content and groups of content.
Here’s how to make the extension. Before you start designing a layout in Photoshop, create a wireframe using software such as Visio or OmniGraffle. You’ll find that it will help you to think more analytically about the content before deciding what color it should be.
So now you have your navigation and site map, enhanced after performing several card sorts with users. You also have your layout and visual design, greatly assisted through the use of wireframes. All done, right? Well, it wouldn’t be a Web site unless we built it, now, would it?
Code
Yes, we’ve reached that point where we need to start coding. What could information architecture possibly add at this point? Well, if you’re a standards-savvy Web designer, it can add a whole lot.
As a Web designer with a keen understanding of Web standards, you know how to create a Web site using W3C compliant HTML and CSS. You also understand the importance of HTML that is semantically structured; that is, using h1 elements for headers, p elements for paragraphs, etc. Finally, you know that semantics can survive across multiple layers of development--from HTML to CSS to the visual design. What you may not know is that just by applying this knowledge, you’re already thinking much like an information architect.
Last year, a presentation by Christina Wodtke and Nate Koechely (“First Things First: IA and CSS”) identified how using standards-based Web development can help drive the information architecture and design workflow. This is done in three key ways:
Making your site map references CSS compatible
CSS-compatible site map references are meaningful names that don’t begin with a number. An example of such a reference is globalLoginForm.
Identifying hierarchies
Next, you need to identify hierarchies in your markup by defining the order of content in a meaningful way. To do this, first look at your HTML and make sure content makes sense when the HTML is read from top to bottom. Second, define the order of headings (h1, h2, h3... h6). The authors of the presentation say that they don’t need to be in order, but the Web Content Accessibility Guidelines clearly state that they should be ordered properly without skipping levels (e.g., h3 following h1).
Cataloging
Finally, you’ll need to make an itemized list of all elements on the page in order to define the relationships and similarities between elements. For example, it is likely that several page elements will serve a similar function, such as headers for content areas, but will be located in different parts of the page. After you know the commonalities between elements, you can design your CSS and HTML for reusability across the site.
Here’s how to make the extension. Before you write your first tag, complete the three tasks identified above. Afterwards, you will have communicated the information architecture throughout the design process, facilitating improved communication between design teams and a better workflow.
Make the extension, fill the role
As I’ve demonstrated, the line between Web design and information architecture doesn’t have to be as clear as we may have imagined. There are many opportunities for Web designers to fill the role of information architect in every project. This is not to say that information architects are no longer needed. On the contrary, with Web sites becoming more dynamic and complex every day, information architects are needed more than ever. But as an information architect who transitioned from a Web design role, I can assure you that information architects aren’t the only ones who can organize things.
Published on February 17, 2005
Both information architects and Web designers can be too presumptuous about what the other does. They’re continually putting each other into little boxes, trying to define each other’s role.
Web designers have been led to believe that they’re restricted to doing what they’ve always done and should leave the information architecture to the information architects. This does not have to happen.
On one hand, many Web designers don’t understand information architecture’s role within Web design. Designers think that information architects are the people who keep trying to organize everything. On the other hand, many information architects underestimate the Web designer’s role within a project. Information architects think they should write the site specification and that designers should code it.
One consequence of this misunderstanding is that information architecture and Web design are often considered mutually exclusive. Information architecture involves organizing, structuring and labeling; Web design involves technical development and visual design. In turn, Web designers have been led to believe that they’re restricted to doing what they’ve always done and should leave the information architecture to the information architects. This does not have to happen.
While it’s true that everything in Information Architecture for the World Wide Web cannot be learned in a day, there are several information architecture techniques that Web designers can easily learn and apply to all of their projects. This involves looking at information architecture as an extension of Web design. This perspective has several advantages:
It virtually eliminates the “us vs. them” ideology, which usually ends up hurting both disciplines.
It doesn’t place boundaries around the roles. Instead, it treats the roles as a continuum.
It allows Web designers to realize that they know more about information architecture than they think.
It helps Web designers transition from that role to an information architecture role more easily.
To put this idea into practice, we’ll look at three common Web design tasks (navigation, layout and code) and extend them into the realm of information architecture.
Navigation
Let’s start with navigation, one of the most loved and hated aspects of Web design. As individual pages are added to the site, it’s very difficult for a Web designer to resist immediately grouping those pages into categories that make sense--to the designer. The problem with this, as many of you know, is that the visitor often doesn’t share the same mental model of the site content and may not realize that what they’re looking for is not in the current area that they’re browsing.
As a preliminary exercise, it’s perfectly fine to group the pages into categories in order to develop a navigation scheme. But after this exercise, you should ask some potential users of the site to do a card sort. A card sort is an exercise used to find out how people group things, and what names they give those groups. It’s as easy as 1-2-3:
Write down the names of all your pages on pieces of paper.
Ask the participant to group them, creating subgroups if necessary.
Ask the participant to name the groups.
After moderating several card sorts, patterns will begin to emerge that will help you to find a dominant organization scheme.
Here’s how to make the extension. After you know what content your site will contain, do a card sort with at least several potential users of the site. Afterwards, you’ll have what information architects call a taxonomy, a hierarchical classification scheme. This taxonomy will prove extremely valuable when deciding on your navigation labels and the site maps for your site.
Layout
Next, let’s look at layouts, which have long been an important aspect of Web design. The prominence of the layout has led many Web designers to become very proficient at moving page sections around in Photoshop. Circa 1996, this was sufficient for most projects, and still is to some degree. But for multi-national sites with large and diverse user bases, Web designers need to develop more than just a page layout. They need to develop a page schematic or wireframe.
Wireframes describe the contents of the page through the use of a grayscale block-level diagram. They can range in level of detail, but typically show the location of content, images, navigation and other functionality on the page. It sounds a lot like laying out a page in Photoshop at first, but because it’s inherently focused on information rather than visual design, it’s a valuable tool for examining the relationships between information, content and groups of content.
Here’s how to make the extension. Before you start designing a layout in Photoshop, create a wireframe using software such as Visio or OmniGraffle. You’ll find that it will help you to think more analytically about the content before deciding what color it should be.
So now you have your navigation and site map, enhanced after performing several card sorts with users. You also have your layout and visual design, greatly assisted through the use of wireframes. All done, right? Well, it wouldn’t be a Web site unless we built it, now, would it?
Code
Yes, we’ve reached that point where we need to start coding. What could information architecture possibly add at this point? Well, if you’re a standards-savvy Web designer, it can add a whole lot.
As a Web designer with a keen understanding of Web standards, you know how to create a Web site using W3C compliant HTML and CSS. You also understand the importance of HTML that is semantically structured; that is, using h1 elements for headers, p elements for paragraphs, etc. Finally, you know that semantics can survive across multiple layers of development--from HTML to CSS to the visual design. What you may not know is that just by applying this knowledge, you’re already thinking much like an information architect.
Last year, a presentation by Christina Wodtke and Nate Koechely (“First Things First: IA and CSS”) identified how using standards-based Web development can help drive the information architecture and design workflow. This is done in three key ways:
Making your site map references CSS compatible
CSS-compatible site map references are meaningful names that don’t begin with a number. An example of such a reference is globalLoginForm.
Identifying hierarchies
Next, you need to identify hierarchies in your markup by defining the order of content in a meaningful way. To do this, first look at your HTML and make sure content makes sense when the HTML is read from top to bottom. Second, define the order of headings (h1, h2, h3... h6). The authors of the presentation say that they don’t need to be in order, but the Web Content Accessibility Guidelines clearly state that they should be ordered properly without skipping levels (e.g., h3 following h1).
Cataloging
Finally, you’ll need to make an itemized list of all elements on the page in order to define the relationships and similarities between elements. For example, it is likely that several page elements will serve a similar function, such as headers for content areas, but will be located in different parts of the page. After you know the commonalities between elements, you can design your CSS and HTML for reusability across the site.
Here’s how to make the extension. Before you write your first tag, complete the three tasks identified above. Afterwards, you will have communicated the information architecture throughout the design process, facilitating improved communication between design teams and a better workflow.
Make the extension, fill the role
As I’ve demonstrated, the line between Web design and information architecture doesn’t have to be as clear as we may have imagined. There are many opportunities for Web designers to fill the role of information architect in every project. This is not to say that information architects are no longer needed. On the contrary, with Web sites becoming more dynamic and complex every day, information architects are needed more than ever. But as an information architect who transitioned from a Web design role, I can assure you that information architects aren’t the only ones who can organize things.
HTML5, XHTML2, and the Future of the Web
By David "liorean" Andersson
Published on April 10, 2007
As workers on the web today, we are dealing with many technologies that have been stable for a long time.
HTML 4.01 was made a recommendation in 1999, XHTML 1.0—a formulation of HTML 4.01 in XML—became a recommendation in 2000, and was revised in 2002. In other words, at the base of all modern web development is an eight-year-old technology.
HTML 4.01 may be a good, stable ground for developers to stand on, but it could be better. Lots of things have changed in the way the web is used and perceived in the last eight years, but particularly from a developer perspective, we’ve gained an understanding of what HTML 4.01 failed at, and where it could be improved. The next generation of these technologies is arriving, and they are worth keeping an eye on. These technologies will affect everyone in the business.
The Contenders
The W3C has long had XHTML2 in the works, a technology that aims to fill the same role as HTML 4.01 and XHTML 1.0, an upgrade or replacement with many improvements and changes to the semantic elements available. XHTML2 is XML—just as XHTML 1.0 is—but it doesn’t have backward compatibility to HTML 4.01. It can, in fact, be considered an entirely new language, something made very clear by the fact it has a completely different namespace.
HTML5 (also sometimes referred to as Web Applications 1.0) is a technology developed by the WHATWG, an open community started by three of the four major browser vendors: Mozilla, Opera, and Apple. HTML5 is not so much a replacement for HTML 4.01 or XHTML 1.0 as it is an upgrade or evolution. It aims for backwards compatibility, tries to remove undefined behavior in HTML 4.01 by defining it, and looks at the various browsers’ tag-soup parsing behavior to try to define the best solution that doesn’t break the web. At the same time, it adds sorely needed semantic elements for things such as improved form validation, interactive elements, and persistent storage.
HTML on the Web Today
While HTML 4.01 is formally an SGML-based document format, the only clients actually treating HTML that way are validators. Browsers, on the other hand, treat HTML documents as tag soup—they try to make sense out of, and display, even the most horridly broken document to their best ability. Very little content on the web is valid HTML 4.01; most of it is invalid and ill-formed, but browsers still have to parse it, or they will soon be disregarded as users switch to browsers that support their favorite sites.
Tag-soup handling—trying to correct errors in documents—is essential, but every browser does it a little differently. All browsers try to get as close as possible to how their largest competitors do it, but even when broken content works the same in different browsers, it doesn’t necessarily mean that they are performing error correction in the same way, just the way that both works for the common case and is most practical for them. HTML5 tries to put an end to this need for reverse engineering of competing browsers by defining exactly how this error correction is to be done. HTML5 doesn’t just define how valid documents are to be parsed, it also defines how parsing should work if documents are invalid, ill-formed, and broken, so that browser vendors can make their products fully interoperable with each other.
XML on the Web Today
The vast majority of all XHTML on the web is served with a content type of “text/html”—in other words, it is parsed as tag soup by browsers, not as XML.
Among the reasons for this is the draconian error handling of XML. XML parsing will stop at the first error in the document, and that means that any errors will render a page totally unreachable. A document with an XML well formedness error will only display details of the error, but no content. On pages where some of the content is out of the control of XML tools with well-designed handling of different character encodings—where users may comment or post, or where content may come from the outside in the form of trackbacks, ad services, or widgets, for example—there’s always a risk of a well-formedness error. Tag-soup parsing browsers will do their best to display a page, in spite of any errors, but when XML parsing any error, no matter how small, may render your page completely useless.
The biggest problem with serving documents as XML on the web is that Internet Explorer doesn’t support the recommended XHTML 1.0 content type (“application/xhtml+xml”). It does support generic XML, but without any knowledge of the XHTML namespace, it has no knowledge of the semantics of any XHTML elements, and won’t even apply the default browser style sheet. (It is possible to apply XSLT to transform the document to HTML tag soup, but since the DOM is different for XML mode compared to tag-soup mode, this means scripts working in one mode may be completely broken in the other mode.)
XHTML 1.0 does allow serving documents as “text/html” though, given that they conform to the backwards compatibility rules of Appendix C of the HTML specification, but—of course—this means that the documents will be treated as tag soup, and is effectively not XML on the web. (The possibility to serve a document as tag soup just to browsers not supporting XHTML as XML exists, with the same caveat as when transforming them using client side XSLT, and more added from differences in character-encoding handing.)
The fact that Internet Explorer doesn’t really support XHTML as XML in any way, and the problems XML can cause when not all tools in the authoring chain are XML tools, means that there has been little incentive for using XML on the web. This is compounded by search engines not indexing XHTML as XML documents; very few XHTML authoring tools for XML; very few CMS or blogging tools supporting XML correctly all the way from input through database to generation; and very few ad suppliers supporting XML.
There is a little incentive if you want to allow MathML, SVG, and other XML applications to be interspersed inline in XHTML documents, but this use of XHTML as XML has found a very limited audience.
XHTML2 is XML
And therein lies the biggest problem. On top of all the concerns that web developers have about using XML for serving documents, XHTML2 adds another layer of complexity. It isn’t HTML 4.01 reformulated as XML; it’s a different but similar language, with added, removed, or modified semantics for many elements, and added or changed element vocabulary for many semantics. In many cases, the changes are steps in the right direction, but at the same time, XHTML2 was not built with web developers in mind. As an example, it doesn’t at all address the deficiencies of HTML 4.01 and XHTML 1.0 in the areas of interactivity, local storage, or script interactions.
XHTML2 is a working draft at the moment. While parts of it have been as they are for years, in general it’s not stable enough to author documents to, it’s not quite ready for implementation, and it lacks support from four very crucial directions: browsers, search engines, content-management systems, and authoring tools. None of the major browser vendors supports XHTML2, and Apple’s Maciej Stachowiak even went so far as stating:
We declined to participate in the XHTML2 Working Group because we think XHTML2 is not an appropriate technology for the web.
Web Applications 1.0 is More than HTML5
The Web Applications 1.0 (WA1) specification updates HTML, but that’s not all it does. It also updates XHTML 1.0 (under the unfortunate and confusing name of XHTML5), and the HTML DOM under the name of DOM5 HTML. While HTML 4.01 is formally SGML-based, HTML5 accepts the reality of all browsers using error-correcting tag-soup parsers, and instead describes a specific non-SGML parsing model that includes a defined error correction model. (XHTML5 is still parsed by an XML parser, and parsing is covered by the rules of XML and not HTML5.)
WA1 also defines several application programming interfaces (APIs) that have been de facto standards, and adds new ones. Where XHTML2 enhances XHTML as a document description language with improved semantics, WA1 does a more modest enhancement to document semantics but also improves on the abilities to use the web as an application platform by adding things such as document state storage in the browser history, local data storage, offline browsing, drag and drop, copy and paste, undo and redo history, cross document messaging, and more.
Unlike XHTML2, which doesn’t have any support from browser vendors, HTML5 has support from all the major browser vendors except Microsoft. The specification is not finished yet, but different parts of it are at different levels of maturity—many parts are already implemented in browsers, for example, the canvas element, which is supported by Mozilla, Safari, and Opera browsers, has been used in many demonstrations of advanced functionality.
W3C and HTML
The W3C has recently chartered a new HTML Working Group, separate from the working group that is chartered to produce XHTML2. The HTML Working Group is open to the public through the mechanism for becoming an invited expert. How it ties in with work from the other W3C working groups—as well as with the WHATWG —remains to be seen. The chairs of the new group are Chris Wilson, Platform Architect of the Internet Explorer Platform team at Microsoft, and Dan Connolly of the W3C.
The W3C has already adopted a lot of WHATWG technologies through the Rich Web Clients Activity, aiming at improving the client side experience of the web. The new HTML working group has a dependency on at least one of the working groups in that activity, the WebAPI working group. The scope, deliverables, and relationship to external groups part of the HTML working group charter makes it a reasonable assumption that the new HTML working group will try to use the HTML5 specification, or at least a lot of the work the WHATWG has put into HTML5, as the ground for the updated HTML and XHTML specifications it is chartered to deliver.
Suitability for Web Developers
XHTML2
Browser support is always a crucial point for web developers. Internet Explorer doesn’t have proper XHTML support at all, and it has severe problems with XHTML sent as XML—character encodings handling, externally provided content, and the handling of content as strings instead of guaranteed well-formed XML makes XML tricky even if you get over that hurdle. Turning an HTML 4.01 or XHTML 1.0 document into XHTML2 isn’t necessarily straightforward—there are changes to the structure of the document that will be required, and, crucially, none of the major browser vendors supports XHTML2.
HTML5
Turning an HTML 4.01 document into HTML5, on the other hand, is in most cases just a question of replacing the DOCTYPE declaration. If a document doesn’t use any of the new elements or APIs introduced by HTML5, the browser just sends it to its tag-soup parser. For most current content-management systems and authoring tools, the change to generate HTML5 instead of HTML 4.01 is simple, and the new HTML5 features can be added to them easily. In addition, many of the new HTML5 features can be emulated using JavaScript for browsers that don’t support them, allowing for a gradual change from HTML 4.01 to HTML5.
Conclusion
While XHTML2 is a semantic improvement over XHTML 1.0, it does not seem likely that it will matter for web developers for a long time, especially when one considers that Internet Explorer still doesn’t offer XHTML 1.0 support. It will take many years for a new version that might support XHTML2—and we have been given no indication that the next one will.
On the other hand, many parts of HTML5 are already creeping into browsers, and, if Microsoft takes an active part in the development of HTML5 in the future, it looks likely that many features that are already very polished will be supported cross-browser in a much shorter timeframe. The fact that HTML5 contains several areas that are already ready for implementation while still being developed in other areas makes it a technology that is easy to partially adapt until browser support is fully evolved for the features you wish to use.
HTML5 will be the future of the web, so my advice would be to pay close attention to it.
Published on April 10, 2007
As workers on the web today, we are dealing with many technologies that have been stable for a long time.
While HTML 4.01 is formally an SGML-based document format, the only clients actually treating HTML that way are validators. Browsers, on the other hand, treat HTML documents as tag soup—they try to make sense out of, and display, even the most horridly broken document to their best ability.
HTML 4.01 was made a recommendation in 1999, XHTML 1.0—a formulation of HTML 4.01 in XML—became a recommendation in 2000, and was revised in 2002. In other words, at the base of all modern web development is an eight-year-old technology.
HTML 4.01 may be a good, stable ground for developers to stand on, but it could be better. Lots of things have changed in the way the web is used and perceived in the last eight years, but particularly from a developer perspective, we’ve gained an understanding of what HTML 4.01 failed at, and where it could be improved. The next generation of these technologies is arriving, and they are worth keeping an eye on. These technologies will affect everyone in the business.
The Contenders
The W3C has long had XHTML2 in the works, a technology that aims to fill the same role as HTML 4.01 and XHTML 1.0, an upgrade or replacement with many improvements and changes to the semantic elements available. XHTML2 is XML—just as XHTML 1.0 is—but it doesn’t have backward compatibility to HTML 4.01. It can, in fact, be considered an entirely new language, something made very clear by the fact it has a completely different namespace.
HTML5 (also sometimes referred to as Web Applications 1.0) is a technology developed by the WHATWG, an open community started by three of the four major browser vendors: Mozilla, Opera, and Apple. HTML5 is not so much a replacement for HTML 4.01 or XHTML 1.0 as it is an upgrade or evolution. It aims for backwards compatibility, tries to remove undefined behavior in HTML 4.01 by defining it, and looks at the various browsers’ tag-soup parsing behavior to try to define the best solution that doesn’t break the web. At the same time, it adds sorely needed semantic elements for things such as improved form validation, interactive elements, and persistent storage.
HTML on the Web Today
While HTML 4.01 is formally an SGML-based document format, the only clients actually treating HTML that way are validators. Browsers, on the other hand, treat HTML documents as tag soup—they try to make sense out of, and display, even the most horridly broken document to their best ability. Very little content on the web is valid HTML 4.01; most of it is invalid and ill-formed, but browsers still have to parse it, or they will soon be disregarded as users switch to browsers that support their favorite sites.
Tag-soup handling—trying to correct errors in documents—is essential, but every browser does it a little differently. All browsers try to get as close as possible to how their largest competitors do it, but even when broken content works the same in different browsers, it doesn’t necessarily mean that they are performing error correction in the same way, just the way that both works for the common case and is most practical for them. HTML5 tries to put an end to this need for reverse engineering of competing browsers by defining exactly how this error correction is to be done. HTML5 doesn’t just define how valid documents are to be parsed, it also defines how parsing should work if documents are invalid, ill-formed, and broken, so that browser vendors can make their products fully interoperable with each other.
XML on the Web Today
The vast majority of all XHTML on the web is served with a content type of “text/html”—in other words, it is parsed as tag soup by browsers, not as XML.
Among the reasons for this is the draconian error handling of XML. XML parsing will stop at the first error in the document, and that means that any errors will render a page totally unreachable. A document with an XML well formedness error will only display details of the error, but no content. On pages where some of the content is out of the control of XML tools with well-designed handling of different character encodings—where users may comment or post, or where content may come from the outside in the form of trackbacks, ad services, or widgets, for example—there’s always a risk of a well-formedness error. Tag-soup parsing browsers will do their best to display a page, in spite of any errors, but when XML parsing any error, no matter how small, may render your page completely useless.
The biggest problem with serving documents as XML on the web is that Internet Explorer doesn’t support the recommended XHTML 1.0 content type (“application/xhtml+xml”). It does support generic XML, but without any knowledge of the XHTML namespace, it has no knowledge of the semantics of any XHTML elements, and won’t even apply the default browser style sheet. (It is possible to apply XSLT to transform the document to HTML tag soup, but since the DOM is different for XML mode compared to tag-soup mode, this means scripts working in one mode may be completely broken in the other mode.)
XHTML 1.0 does allow serving documents as “text/html” though, given that they conform to the backwards compatibility rules of Appendix C of the HTML specification, but—of course—this means that the documents will be treated as tag soup, and is effectively not XML on the web. (The possibility to serve a document as tag soup just to browsers not supporting XHTML as XML exists, with the same caveat as when transforming them using client side XSLT, and more added from differences in character-encoding handing.)
The fact that Internet Explorer doesn’t really support XHTML as XML in any way, and the problems XML can cause when not all tools in the authoring chain are XML tools, means that there has been little incentive for using XML on the web. This is compounded by search engines not indexing XHTML as XML documents; very few XHTML authoring tools for XML; very few CMS or blogging tools supporting XML correctly all the way from input through database to generation; and very few ad suppliers supporting XML.
There is a little incentive if you want to allow MathML, SVG, and other XML applications to be interspersed inline in XHTML documents, but this use of XHTML as XML has found a very limited audience.
XHTML2 is XML
And therein lies the biggest problem. On top of all the concerns that web developers have about using XML for serving documents, XHTML2 adds another layer of complexity. It isn’t HTML 4.01 reformulated as XML; it’s a different but similar language, with added, removed, or modified semantics for many elements, and added or changed element vocabulary for many semantics. In many cases, the changes are steps in the right direction, but at the same time, XHTML2 was not built with web developers in mind. As an example, it doesn’t at all address the deficiencies of HTML 4.01 and XHTML 1.0 in the areas of interactivity, local storage, or script interactions.
XHTML2 is a working draft at the moment. While parts of it have been as they are for years, in general it’s not stable enough to author documents to, it’s not quite ready for implementation, and it lacks support from four very crucial directions: browsers, search engines, content-management systems, and authoring tools. None of the major browser vendors supports XHTML2, and Apple’s Maciej Stachowiak even went so far as stating:
We declined to participate in the XHTML2 Working Group because we think XHTML2 is not an appropriate technology for the web.
Web Applications 1.0 is More than HTML5
The Web Applications 1.0 (WA1) specification updates HTML, but that’s not all it does. It also updates XHTML 1.0 (under the unfortunate and confusing name of XHTML5), and the HTML DOM under the name of DOM5 HTML. While HTML 4.01 is formally SGML-based, HTML5 accepts the reality of all browsers using error-correcting tag-soup parsers, and instead describes a specific non-SGML parsing model that includes a defined error correction model. (XHTML5 is still parsed by an XML parser, and parsing is covered by the rules of XML and not HTML5.)
WA1 also defines several application programming interfaces (APIs) that have been de facto standards, and adds new ones. Where XHTML2 enhances XHTML as a document description language with improved semantics, WA1 does a more modest enhancement to document semantics but also improves on the abilities to use the web as an application platform by adding things such as document state storage in the browser history, local data storage, offline browsing, drag and drop, copy and paste, undo and redo history, cross document messaging, and more.
Unlike XHTML2, which doesn’t have any support from browser vendors, HTML5 has support from all the major browser vendors except Microsoft. The specification is not finished yet, but different parts of it are at different levels of maturity—many parts are already implemented in browsers, for example, the canvas element, which is supported by Mozilla, Safari, and Opera browsers, has been used in many demonstrations of advanced functionality.
W3C and HTML
The W3C has recently chartered a new HTML Working Group, separate from the working group that is chartered to produce XHTML2. The HTML Working Group is open to the public through the mechanism for becoming an invited expert. How it ties in with work from the other W3C working groups—as well as with the WHATWG —remains to be seen. The chairs of the new group are Chris Wilson, Platform Architect of the Internet Explorer Platform team at Microsoft, and Dan Connolly of the W3C.
The W3C has already adopted a lot of WHATWG technologies through the Rich Web Clients Activity, aiming at improving the client side experience of the web. The new HTML working group has a dependency on at least one of the working groups in that activity, the WebAPI working group. The scope, deliverables, and relationship to external groups part of the HTML working group charter makes it a reasonable assumption that the new HTML working group will try to use the HTML5 specification, or at least a lot of the work the WHATWG has put into HTML5, as the ground for the updated HTML and XHTML specifications it is chartered to deliver.
Suitability for Web Developers
XHTML2
Browser support is always a crucial point for web developers. Internet Explorer doesn’t have proper XHTML support at all, and it has severe problems with XHTML sent as XML—character encodings handling, externally provided content, and the handling of content as strings instead of guaranteed well-formed XML makes XML tricky even if you get over that hurdle. Turning an HTML 4.01 or XHTML 1.0 document into XHTML2 isn’t necessarily straightforward—there are changes to the structure of the document that will be required, and, crucially, none of the major browser vendors supports XHTML2.
HTML5
Turning an HTML 4.01 document into HTML5, on the other hand, is in most cases just a question of replacing the DOCTYPE declaration. If a document doesn’t use any of the new elements or APIs introduced by HTML5, the browser just sends it to its tag-soup parser. For most current content-management systems and authoring tools, the change to generate HTML5 instead of HTML 4.01 is simple, and the new HTML5 features can be added to them easily. In addition, many of the new HTML5 features can be emulated using JavaScript for browsers that don’t support them, allowing for a gradual change from HTML 4.01 to HTML5.
Conclusion
While XHTML2 is a semantic improvement over XHTML 1.0, it does not seem likely that it will matter for web developers for a long time, especially when one considers that Internet Explorer still doesn’t offer XHTML 1.0 support. It will take many years for a new version that might support XHTML2—and we have been given no indication that the next one will.
On the other hand, many parts of HTML5 are already creeping into browsers, and, if Microsoft takes an active part in the development of HTML5 in the future, it looks likely that many features that are already very polished will be supported cross-browser in a much shorter timeframe. The fact that HTML5 contains several areas that are already ready for implementation while still being developed in other areas makes it a technology that is easy to partially adapt until browser support is fully evolved for the features you wish to use.
HTML5 will be the future of the web, so my advice would be to pay close attention to it.
Think Beyond - Technology
By Alan K'necht
If there is a common theme that runs through my columns—in this and other publications, and my conference presentations—it is the need for IT professionals, whether they are information architects, database administrators, Java developers, front-end Web developers, system administrators or any other person connected to the IT process, to see and think beyond the technology. What does “think beyond” mean and how does it apply to Web development?
The answer to the first part of the question is easy. To think beyond merely means to think beyond what’s staring back at you and think of it from the perspective of the organization as a whole. As to its implication for Web development, let’s look at a few examples of different IT personalities.
Example 1 – The Code Jockey
The Code Jockey simply takes his assignment and starts coding as fast as he can. He doesn’t look at the impact of what he’s coding in the larger scheme of things.
Evidence of this work can be seen in user interfaces that work from a technical perspective, but fail from a user usability perspective.
When a Code Jockey is given the task to code a web page he merely starts coding in good old basic HTML 4.01 (the official company standard). He doesn’t stop to ask himself the question, “Should I do it this way? If I coded it to XHTML 1.0 standards will this benefit the company in the long run? Perhaps I should talk to someone about this idea.” In simplest terms, he doesn’t review his tasks with an eye to the long-term benefit to the organization. A simple code jockey rides the code into production as fast as possible, missing the opportunity to become a code manager, someone who oversees code and makes sure that the code will yield a value, and perform and work properly for the company not just for today, but for the long term.
Example 2 – The Eager Beaver
We all have worked with Eager Beaver IT personnel at one time or another in our careers. These are the people who believe that just because technology is new or the latest trend, it must be better and they immediately start pushing for its implementation without thinking beyond the implementation. Anyone who has lived through the numerous reincarnations of distributed computing, with thin client in vogue one moment and then right back to the fat client the next, can attest to just how much an Eager Beaver can cost a company.
Eager Beavers also tend to be very enthusiastic and persuasive individuals. They catch the ear of senior management with the promise of the pot of gold at the end of the rainbow.
These are the people who build Web sites that only work on the latest browsers despite the fact that a small percentage of their actual users use the latest browser (they should have checked the Web logs). These people leap before they look, as the saying goes. The result is ineffective Web sites which may turn away customers and sites that need to be recoded after the complaints start coming in. In essence, they simply cost companies money.
While many of us owe these people many thanks for showing us what to do and what not to do with new technology, from a corporate perspective, I would prefer that these Eager Beavers work in a Research & Development area and not on mission-critical and sales-oriented applications. Eager Beavers can’t see beyond technology.
To see beyond technology, the Eager Beavers need to slow things down a little and look at the true cost of implementing new technology versus the long-term benefits of it. If their proposal looks too good to be true, it probably is and someone better shake a dose of reality on it.
An Eager Beaver can exist in the world of Web development, but perhaps would need to be developing sites and using technology targeted at other Web developers. We always like seeing what’s possible even if we know we won’t be able to implement it for a year or two on our own sites.
Example 3 – The Rock
The Rock is basically the opposite of the Eager Beaver. This person is so set in his ways, that he can’t—or simply refuses—to see beyond what he knows or is comfortable with. These people may not be as easy to spot as the always-busy Eager Beaver; you need to look a little harder for their handy work. Typical signs include always recommending technology they’ve worked with and know well. They can be spotted saying things like: “I’ve worked with X for years and it can do everything” (Can it? or did you have to figure a work around?), or “In all my years working with Y, I’ve never had a problem” (Hmmm, maybe other people had some problems with it—ever think of that?). The result of this on Web development can be a five-page Web site developed in Java or a 20-page information-based Web site written entirely in Flash, or, even more hideous, the over- or under-engineered Web site.
Rocks have a tendency not to admit that a better solution to something exists beyond their knowledge base. They fear research and the unknown more than bad results. They build a complex database-driven site using ASP and an MS Access database (because they know ASP and Access) when the use of XML and one of the free SQL databases would have been a better solution for the required robustness.
The decisions of Rocks yield very little negative evidence. After all, the solutions work. The alternative, however, would have performed even better; why would you want to drive a go-cart when, for a few dollars more, you could have a sports car?
If the Rocks would open their minds just a little, to see beyond the technology they know and have right in front of them, they might build the same thing a different way, costing the company less, delivering it faster, making it easier to maintain, easier to integrate with 3rd party applications, etc. By not seeing beyond the technology, the Rock costs the organization time and money.
To see beyond what they know, Rocks need to look at what other people and organizations are doing. Just because a Rock doesn’t know the technology doesn’t mean it’s bad. They need to ask more questions and, in some cases, be forced to evaluate or learn new technology. They have to learn to evaluate the business’s needs versus what different technologies can deliver.
Example 4 – The Lemmings
Do I need to say more? These are people who blindly copy what others are doing. Classic signs are people who say, “Look! They’re doing it. We’d better do it, too, or we’re going to lose business!” While it’s always a good idea to examine what your competition is doing, once again you need to see beyond the technology.
While the competition may have just switched from a SQL Server database to an Oracle database for their Web site, that doesn’t mean your company needs to do it. Their business rational for the change might have something to do with integration into their Oracle Financials, while your company doesn’t have Oracle Financials.
By blindly copying what the competition is doing, Lemmings lose more than just the opportunity to be industry leaders; they may be following the competition off a cliff.
To see beyond the technology, the Lemming needs to pause before every decision and ask the most basic question: "Why?" Why are they doing this and why should we follow? Failure to do this most basic homework can lead to disaster.
Consequences
Regardless of which personality you are, or which ones work within your organization, the need to see beyond the technology is critical. From the most basic perspective, it seems like common sense: the fact that so many people simply do their job the best way they know how shows that not enough people are taking time to see beyond the technology.
Each of us needs to see beyond technology and think, not just of the immediate needs, but of the long-term needs and the well-being of the organization. If we don’t do this, companies will simply stop using our services. They’ll start treating the Code Jockey as a commodity and, as with any commodity, business will look for the best price and that includes off-shore developers. Rocks, Eager Beavers and Lemmings will be seen as obstacles on the road to success; business will either drive around the obstacle or, when it’s easier, simply remove the obstacles from the road.
If we are truly professionals, we need to treat those whom we serve the same way good doctors treat their patients. We need to treat them with respect, provide assistance as required and more importantly provide diagnostics and treatments over the long term, to ensure that these patients will be around for a long time.
If there is a common theme that runs through my columns—in this and other publications, and my conference presentations—it is the need for IT professionals, whether they are information architects, database administrators, Java developers, front-end Web developers, system administrators or any other person connected to the IT process, to see and think beyond the technology. What does “think beyond” mean and how does it apply to Web development?
The answer to the first part of the question is easy. To think beyond merely means to think beyond what’s staring back at you and think of it from the perspective of the organization as a whole. As to its implication for Web development, let’s look at a few examples of different IT personalities.
Example 1 – The Code Jockey
The Code Jockey simply takes his assignment and starts coding as fast as he can. He doesn’t look at the impact of what he’s coding in the larger scheme of things.
Evidence of this work can be seen in user interfaces that work from a technical perspective, but fail from a user usability perspective.
When a Code Jockey is given the task to code a web page he merely starts coding in good old basic HTML 4.01 (the official company standard). He doesn’t stop to ask himself the question, “Should I do it this way? If I coded it to XHTML 1.0 standards will this benefit the company in the long run? Perhaps I should talk to someone about this idea.” In simplest terms, he doesn’t review his tasks with an eye to the long-term benefit to the organization. A simple code jockey rides the code into production as fast as possible, missing the opportunity to become a code manager, someone who oversees code and makes sure that the code will yield a value, and perform and work properly for the company not just for today, but for the long term.
Example 2 – The Eager Beaver
We all have worked with Eager Beaver IT personnel at one time or another in our careers. These are the people who believe that just because technology is new or the latest trend, it must be better and they immediately start pushing for its implementation without thinking beyond the implementation. Anyone who has lived through the numerous reincarnations of distributed computing, with thin client in vogue one moment and then right back to the fat client the next, can attest to just how much an Eager Beaver can cost a company.
Eager Beavers also tend to be very enthusiastic and persuasive individuals. They catch the ear of senior management with the promise of the pot of gold at the end of the rainbow.
These are the people who build Web sites that only work on the latest browsers despite the fact that a small percentage of their actual users use the latest browser (they should have checked the Web logs). These people leap before they look, as the saying goes. The result is ineffective Web sites which may turn away customers and sites that need to be recoded after the complaints start coming in. In essence, they simply cost companies money.
While many of us owe these people many thanks for showing us what to do and what not to do with new technology, from a corporate perspective, I would prefer that these Eager Beavers work in a Research & Development area and not on mission-critical and sales-oriented applications. Eager Beavers can’t see beyond technology.
To see beyond technology, the Eager Beavers need to slow things down a little and look at the true cost of implementing new technology versus the long-term benefits of it. If their proposal looks too good to be true, it probably is and someone better shake a dose of reality on it.
An Eager Beaver can exist in the world of Web development, but perhaps would need to be developing sites and using technology targeted at other Web developers. We always like seeing what’s possible even if we know we won’t be able to implement it for a year or two on our own sites.
Example 3 – The Rock
The Rock is basically the opposite of the Eager Beaver. This person is so set in his ways, that he can’t—or simply refuses—to see beyond what he knows or is comfortable with. These people may not be as easy to spot as the always-busy Eager Beaver; you need to look a little harder for their handy work. Typical signs include always recommending technology they’ve worked with and know well. They can be spotted saying things like: “I’ve worked with X for years and it can do everything” (Can it? or did you have to figure a work around?), or “In all my years working with Y, I’ve never had a problem” (Hmmm, maybe other people had some problems with it—ever think of that?). The result of this on Web development can be a five-page Web site developed in Java or a 20-page information-based Web site written entirely in Flash, or, even more hideous, the over- or under-engineered Web site.
Rocks have a tendency not to admit that a better solution to something exists beyond their knowledge base. They fear research and the unknown more than bad results. They build a complex database-driven site using ASP and an MS Access database (because they know ASP and Access) when the use of XML and one of the free SQL databases would have been a better solution for the required robustness.
The decisions of Rocks yield very little negative evidence. After all, the solutions work. The alternative, however, would have performed even better; why would you want to drive a go-cart when, for a few dollars more, you could have a sports car?
If the Rocks would open their minds just a little, to see beyond the technology they know and have right in front of them, they might build the same thing a different way, costing the company less, delivering it faster, making it easier to maintain, easier to integrate with 3rd party applications, etc. By not seeing beyond the technology, the Rock costs the organization time and money.
To see beyond what they know, Rocks need to look at what other people and organizations are doing. Just because a Rock doesn’t know the technology doesn’t mean it’s bad. They need to ask more questions and, in some cases, be forced to evaluate or learn new technology. They have to learn to evaluate the business’s needs versus what different technologies can deliver.
Example 4 – The Lemmings
Do I need to say more? These are people who blindly copy what others are doing. Classic signs are people who say, “Look! They’re doing it. We’d better do it, too, or we’re going to lose business!” While it’s always a good idea to examine what your competition is doing, once again you need to see beyond the technology.
While the competition may have just switched from a SQL Server database to an Oracle database for their Web site, that doesn’t mean your company needs to do it. Their business rational for the change might have something to do with integration into their Oracle Financials, while your company doesn’t have Oracle Financials.
By blindly copying what the competition is doing, Lemmings lose more than just the opportunity to be industry leaders; they may be following the competition off a cliff.
To see beyond the technology, the Lemming needs to pause before every decision and ask the most basic question: "Why?" Why are they doing this and why should we follow? Failure to do this most basic homework can lead to disaster.
Consequences
Regardless of which personality you are, or which ones work within your organization, the need to see beyond the technology is critical. From the most basic perspective, it seems like common sense: the fact that so many people simply do their job the best way they know how shows that not enough people are taking time to see beyond the technology.
Each of us needs to see beyond technology and think, not just of the immediate needs, but of the long-term needs and the well-being of the organization. If we don’t do this, companies will simply stop using our services. They’ll start treating the Code Jockey as a commodity and, as with any commodity, business will look for the best price and that includes off-shore developers. Rocks, Eager Beavers and Lemmings will be seen as obstacles on the road to success; business will either drive around the obstacle or, when it’s easier, simply remove the obstacles from the road.
If we are truly professionals, we need to treat those whom we serve the same way good doctors treat their patients. We need to treat them with respect, provide assistance as required and more importantly provide diagnostics and treatments over the long term, to ensure that these patients will be around for a long time.
Subscribe to:
Posts (Atom)