Strona główna

Następny artykuł

Poprzedni artykuł

Stanislaw Skorka: Let's start with basic terms. From among over 900 definitions of "information architecture", could you please choose your favorite one and discuss it? What is IA actually about?

Eric Reiss: The 900 terms to which you refer, Stanisław, are from the very first information architecture summit back in April of 2000 in Boston, USA. Over 400 information architects tried to define information architecture but we didn't really succeed. I think we all agree as to what it is, but the specifics of information architecture have a tendency to change depending on what we do. My own definition is one that my mother understands. It's also one that the business community also seems to respond to. Quite simply, information architects take things - pieces of information - and gather them in useful categories, give them names people recognize, and put these pieces of information someplace where they will do the most good. That means, in practical terms, we're probably all information architects and have been information architects for thousands of years. You can't walk down the street without seeing examples of information architecture. If you pass a fruit stand, you'll see a box of pineapples, a box of lemons, a box of apples, a box of oranges. All this fruit has been sorted and often you will see that there are different kinds of apples in different boxes - but next to each other. This is information architecture. The fruit-stand owner sorted things. In this case he didn't necessarily given the fruit new names, but he certainly put the fruit someplace where his customers are likely to find it when they're out shopping. This is what we have to learn to do effectively online, for websites and online applications, and this is where it starts to get difficult. For example, we might experience good information architecture when a customer goes to buy a vacuum cleaner online, and the site asks "do you also want to buy bags for your vacuum cleaner?" These are two related pieces of information and yet there is a world of difference in what a vacuum cleaner is and what a bag is: the price is very different, they may even be provided by different departments within the same company, but for those of us who are using a website, it is very convenient that the information architect who designed the structure of this particular site recognized that there were two pieces of information that were related and we needed to have them presented at the same time.

- So is it a specific craft, a profession, or maybe a scientific discipline?

- Well, I think it's all of the above. And more than anything else, I think, it really is a way of thinking. Certainly, there are scientific aspects to it when we talk about practical information architecture, which is very closely related to the more traditional disciplines of library science, categorization development, thesauri, indexing, metadata, and so on. These things are very scientific in the way you tackle them, and there are some well-defined sets of practices and methods. And though information architecture is certainly a craft, it also needs to be more, because we need to innovate. This is a very young industry, and to say that what we are doing today is the way things should be done 10 years from now is probably a mistake. When we're teaching people a craft in school, we assume we're going to teach them skills and techniques that they're going to use for the rest of their lives. I hope that in 10 years, today's students will have moved beyond what they learned in school and will be doing things we can only dream of today. I hope they will retain the generic skills, but will have adopted new and better techniques.

- What information architects actually do? Are they web designers, graphic designers, information technologists?

- If we talk about the web and websites, the first information architects often had a technical background. That's because they were the ones who could write HTML. This was back 1995-1996. But websites weren't very complicated back then, so the site structure was very simple: a homepage, and a few pages underneath. This was all very easy to plan. Today, we have sites with thousands, if not millions, of pages. That requires somebody who is not thinking so much about how it is going to be coded, but more as to how this information is going to be used.

So, information architects are people who often design the structure (sitemap) of a website. They may be graphic designers but probably not; they may be the team leaders, but probably not; they could be data analysts, but probably not. I think information architecture is in the foreseeable future going to remain in the hands of somebody who has specific knowledge of the products and services involved, and knows how to communicate these. Often, these will be people with a marketing background, particularly those with a technical writing background, because the content providers are usually the folks who best understand how the content can be used. Website development is much less a technical issue than a communications issue. And that means we all need to understand information architecture, and the professional information architects need to understand other disciplines, too. They don't have to be programmers, but they have to understand how computers think. They don't have to be team leaders, but they have to understand group dynamics. They don't have to be graphic designers, but they have to understand usability and how people interpret visual clues.

- Well, it means that information architecture is closer to content than to technology, isn't it?

- Absolutely. Five or six years ago, we used to say that content was king. And that's still true to some extent. If you have a very boring website because you have bad pictures and you've written things that are boring to read, then people are not going to use your website. In that respect content is and remains king. However, what is really king is context. It's the way we put things together that we create value. For example, if you play cards, say Gin Rummy, are you going to collect a straight? Four, five or six? Or you're going to collect fours? What are you going to do? There are different ways you can categorize your cards, and that can make the difference between whether you're going to win or lose the game. The same thing applies when you play Scrabble: are you going to make an expensive word or a cheap word? It's the same bits of information you're working with, the same little bricks, but you can put them together in different ways and some of them will be more valuable than others. The arrangement of information is highly strategic - and that's why the business community should know more about our work. Information architects can help them win in the marketplace, too.

- Who might be an information architect?

- Honestly, I think that anybody can be an information architect. But it has a lot to do with the way we think. Information architects need to be able to recognize patterns and have an interest in recognizing patterns. For example, when we look at a box of Lego, intuitive information architects immediately note that there are more red bricks than there are yellow bricks. This is the kind of pattern recognition at which information architects excel. They also have to be able to sort things in different ways. When I was 8 or 9 years old, I had a collection of baseball cards. Every big city had a baseball team and most boys my age sorted them by team. That was the easy way to sort the cards. Instead, I started sorting people according to whether or not they were wearing a baseball cap, or whether or not they were left-handed - different facets. There is an Indian librarian, by the name of Ranganathan, who developed a theory of sorting back in the 1930s called "faceted taxonomies" - and what I was doing at the age of 8 was creating faceted taxonomies. I didn't know it at the time, but I was taking the different variables, the different lenses through which I could view the baseball cards - "the facets", and creating organizational systems around them - "the taxonomies."

- So collecting things, hobbies is the best way to become an IA, right?

- Well, collecting things certainly provides some early training in classification. I don't know if it's the best way. I do think, though, you have to be naturally curious and you have to really enjoy manipulating the content with which you are working. If you are doing a website for a company that produces medical devices, you have to demonstrate enthusiasm for the products, including stuff that other people find boring, like catheters and colostomy bags. I think good information architects are curious, enthusiastic, and they are culturally literate: they've read books, they've listened to music, they've traveled, they know that people don't necessarily think the same from one country to the next. Naturally, there is a lot practical stuff that you can learn from books and at universities. But if you're asking who should become an information architect, or who can have the best chance, I think it's the people who are curious, who recognize patterns, and who think that creating new and useful patterns is fun.

- According to your words, being an IA depends rather on characteristic not on education, isn't it?

- Sure, but these may be characteristics that you can develop. Let's say you have a bad habit. There are different kinds of bad habits. There are bad habits like smoking; if you are a smoker, it's very difficult to give up smoking. But there are other habits that are easy to break, like forgetting to put the cap back on the toothpaste. When your wife says "Why don't you ever put the cap back on the toothpaste?" you ask yourself "Yeah, that's right, why don't I do that?" The mistake has been pointed out and then you don't do that anymore, it's as simple as that. And then, the third kind of habit is when you're doing something bad, and someone else points it out, and you say "Well, I don't really care because it is not the habit I want to break."

The relation to information architecture is that I do believe you can teach people to develop "thinking habits" that will help them become better information architects. Our educational institutions don't yet spend much time teaching people how to think, but I'm sure this will come. We can create games, for example, that encourage people to seek out patterns. We can give people exercises - for example sending people into a town and asking them look for patterns of information architecture. There's information architecture at the local fruit stand as I mentioned earlier. Or behind the bar in a café - here's all the vodka, here's all the gin, here are all the things necessary to make your Bloody Mary. Everything is in convenient categories and put where it is easiest to use. You see information architecture and you see patterns all over the place. I'm hoping that just like breaking some habits, it will be possible to help potential information architects get into new habits, like pattern recognition. Some of this training is going to be difficult, but hopefully some of it is going to be really, really obvious once it's pointed out. It's like the classic Edgar Rubin vase/profile illusion - are you looking at a vase or are you looking at two human profiles? Once you've seen how it works, then it's almost impossible to miss it in the future, but many people need to have the two options pointed out.

In fact, I think there is something we can do already down at the elementary school level. Kids in elementary school are all going to have to learn information architecture, because they are all using computers and they have to organize files. They're sending SMSs to each other, and they are building profiles on MySpace - all of this requires information architecture.

- Let us move on to the business roots of information architecture. I'd like to know whether information architecture could be applied in other domains of everyday life?

- Certainly. Everything from arranging your spice drawers in your kitchen to how you put your tools together in your workshop. We are constantly sorting things, arranging them, and putting them places where they would be easy to find and use - and that's what information architects do. We just do it with electronic information, pictures, documents, whatever. But it is common sense that allows us to arrange our spices or our tools in a sensible manner. Often, we forget these common sense methods when we start working with electronic information. We should teach children at a very early age that the content itself, the document or the photo, is not enough in itself. We also have to start giving these information chunks names and descriptions - metadata - so we can find them again. We've all experienced having taken a picture during a vacation, and then six months later we try to find this picture on our computer and we can't, we don't know which file we put it in. It would certainly help if we started learning the basics of information architecture at a much earlier age. And that also includes related disciplines like learning how to search on the internet. There ought to be a course in grade school, third or fourth grade level, that teaches people how to search on the internet. I don't know of any school system that's including it yet.

- Let's move on to the next topic, because I've learnt new terms. I mean: "knowledge architecture". Have you heard about it? Is it a new discipline, or a branch of information architecture?

- I have to admit that there are all kinds of new phrases coming out. The three related but distinct disciplines one often hears of are: document management, knowledge management, and content management. These three things have a tendency to get confused. Document management is basically about building good filing systems so that we can find documents again - and information architecture is at the heart of DM in that we are providing the metadata that allow people to find that vacation photo they took six months ago. Knowledge management is sharing ideas and creating systems like intranets, or extranets, or other kinds of interactive environments where people can share their knowledge. And then there is content management, which is basically about publishing information, for example on a website. As always, information architects find groups of related information, display them in a useful way, and with a name that people will remember - and these tasks cut across all of the disciplines I just mentioned.

- You have written a book about IA in 2000, are you going to write the next book devoted to IA?

- Probably not. It's time for other people to write about information architecture. I think my book was fine back in 1999, when I first wrote it. And it continues to provide value for the business community, which is sill learning what information architects have to offer them in terms of building value for their business. As to learning the trade, or the craft of information architecture, then there are now better books on the market, and some of them have even been translated into Polish.

But I am working on ideas for other books that are related to information architecture. One is about "Web Dogma '06", which I introduced a couple of years ago. Basically, my "dogma" represent ten good-practice rules for how to build a website. What is special about these suggestions is that they transcend technology. So it doesn't matter what kind of a browser, or what kind of a programming language you are using, the dogma help you create a website that is easier to use and to understand. I'd like to write a very short book that would explain in greater detail what I meant with each of the ten points. The second book that I'd like to write is about shared references. Shared references ensure that we're all on the same page, that we all understand what we're talking about. For example, Stanisław, if I say to you: "I have here, hidden under my coat, a standard 60-watt light bulb. Do you know what I've got under my coat?

- Yes, I know.

- A standard 60-watt light bulb?

- Yes.

- Actually, most people do think they know what this light bulb looks like. But I didn't really provide a very good description. And if this was the description on a website, it would be very bad. For instance, we don't know if I have a frosted light bulb or a clear light bulb or a colored light bulb. Is it a daylight light bulb to make plants grow? Does it have a carbon-thread filament? Does this have a standard screw base or a bayonet fitting? Is it 110 volts for Northern America or 220 volts for Europe? These are all questions that need to be explained so that we establish the proper shared reference. And this is often why e-commerce sites fail, because potential customers are uncertain as to what they are about to purchase. When people design websites, they need to use images and sounds and words to create stronger shared references with their readers. And that applies to whatever you're trying to sell. For example, if you were a political party, you could be selling an idea, or if you were the boy scouts, you'd be selling the idea of ethics and good citizenship - "products" are not always physical. Most sites fail these days because someone has arbitrarily decided that text should only be ten lines long instead of long enough to explain whatever stories you have to tell.

There are so many myths and misconceptions about on-line communication. And many words and concepts that are misused, such as "innovation". I'd like to do what I can to help the business community understand what we do, why we do it, and why it's important for them.

- Thank you very much for your interview and we wish you good luck with your writing.