I haven’t had many comments regarding the last portion of the book. Sections have included topics such as building an IA team, making the case for IA, and centralization of IA for enterprises. My thoughts have all been in agreement as I have not encountered opportunities to build a specific IA team. The logic behind the IA “dreamteam” makes a fair amount of sense. What has struck me as odd is a brief comment that has occurred in making the case and centralization.
The authors seem to insist that building an IA for a large Web site should happen over almost a year…that’s great, and all, but I wonder how they would react to the way things are done on Earth. I wholeheartedly believe that the fastest way to kill a case for the need for an information architect would be to say that not only does the company to hire another set of employees or a consulting firm, but it will have to hire the group for over a year before the product they wanted is produced. Ideally it would be great, and after reading the book, I see the benefit to taking a significant amount of time to carefully plan the structure of a site. However, I believe that this timeline is an impossible sell.
Also, the authors don’t address the fact that in a year’s time, the entire structure of the company itself can dramatically change. An architecture that has been in the planning stage for six months could become total garbage with a single board meeting reorganizing the company, introducing a new product line, or discontinuing major services. All realistic possibilities.
Anyway, I suppose this surprised me more than it should have because the authors have regularly acknowledged that it is a tough sell, especially for ROI thinkers, but would also seem that way to “gut thinkers.” Unfortunately, most companies are only going to try to build a new site when theirs is horrendously out-of-date. When the decision is finally made to redesign, the last thing people will want to do is wait a year before they can have their finished product.
I was particularly intrigued by the section on metaphor in information architecture and how it can be a useful tool and a hinderance in working with clients and creating structure for the Web. Gore’s information superhighway was one of the earlies metaphors used to help people envision the Internet. Thinking about this, Web is another metaphor that has been used. Why do we make such heavy use of metaphor when talking about the Internet? The authors do not directly reference the reason, but I think it has a lot to do with a major principle of navigation systems that was discussed earlier. People want to be able to envision where they are and have a sense of where they can go from there.
Perhaps a Web was a good way to reference the Internet in the past, but considering the way that search engines are more prominently used, wouldn’t a more accurate metaphor be a giant candy jar? You tell someone what you’re craving and they try to find something similar. They might find the candy you asked for, or they might find something better. Of course, then they could find stale off-brand candy that makes you ask someone else to look for you. I suppose this wouldn’t be a very optimistic metaphor.
On page 254, figure 11-4 shows a page highly inundated with metaphor that serves as the main page for the Internet Public Library. The links to various sections are provided on a graphic interface that is supposed to portray a library. For example, the librarian’s desk has a “Ask a question” link, while a stack of magazines on a table near a sofa has the link for “entertainment and leisure.” I think that the problem with metaphor based pages like this one is that they deviate greatly from the type of navidation that most users typically expect.
I am not suggesting that creativity is never warrranted, but a user looking for a search button or a home link will have to search through the entire page of scattered links before finding that none of these expected items exist. Perhaps they may click on the “Ask a Question” link for the search, but this is likely to be a question for a librarian given the proximity to the librarian at the desk.
This page is likely older and has since seen a major update that is more effective and standardized than the example in “Information Architecture.” Perhaps as the internet becomes older, it will not need metaphors such as this to be understood. I am having a metaphor experience of my own in the design of the UA Web site. Recently there was a request for a “fund tree” to be added. This tree would outline and categorize all of the various outlets of giving to the University. The “tree” is an excellent idea and it will help donors more efficiently find the particular fund they would like to donate to or make them aware of similar funds they kight be interested in.
However, the “fund tree” isn’t a tree in the sense that I expected. Actually, the “tree” proposed will work much better that what I had envisioned the representatives were referring to, which was a series of pull-down categories that would allow users to select or find more information about a particular fund. If this structure were laid out on paper, it could be drawn up to represent a tree. I imagined what would be put on the Web would be a tree of funds much like a family tree. There was no time loss as I was not in charge of constructing such a tree, but this simple metaphor could have cost time.
To this end, I am considering creating a blueprint of the giving process for the records of those concerned. I have alread created several blueprints (another metaphor) for the main navigations and structureing of pages. However, I feel that a task oriented set of blueprints might shed some light the the reps regarding how our user will be able to accomplish what they need to accomplish on the redesigned Web site.
I am also regretting after reading about wire frames, not using this as a way of deciding how to structure the content. The revised sitemaps worked well, but even without the technical Web knowledge required to build the frame, I could have done a mock version with paper that could have been organized and less confusing than the guides and notes on the site maps. I’ll just chalk it up as the road not taken or hind sight being 20/20.
I just finished the chapter in Information Technology on search interfaces. This is the longest chapter in the book and covered a lot. I think what I got out of it most prominently was the idea that a lot more though goes into creating a search interface (if one is even needed) then most would imagine. I think that the ISU homepage and especially the search options in Milner Library’s page represent a large number of the diverse search options available.
One of the methods the books recommended if a site is not large enough to justify a search system is the creation of an index. The index, which acts as a Web site table of contents, is useful to users who want a fast way to find key pages in a site. I realized that I use a type of index almost daily as a professional as a student and as a professional. ISU offers an A to Z search function that brings up an index that is organized alphabetically. Selecting E will allow access to English, which will bring the user to the English Department Web site. I almost always use this function rather than do a search of the ISU Web page due to the abundance of results retrieved if I were to do a search for it. The authors also site this as one of the issues with creating a search engine. Users can become overwhelmed by search returns that are too high.
I believe that in my case, this is what happens with the ISU search page. I would be interested to know if most other people prefer ISU A to Z rather than the search bar. Both are presented on the same page and given equal amounts of space. Analyzing the page further, I notice that if the user does a search, the only ways to organize the results are by relevance and date. Since there are such a large number of returns, I would like to see the options available to have results divided into documents and site pages. I think it is frustrating to users to click on a link that says “calendar” only to be directed to pdf of an old newsletter calendar. It can be deduced if search result is a document if the user reads further down in the result or the actual Web site link. Dividing the results would make this unnecessary.
The site is readily equipped with a section for search tips right near the advanced search link. It is prominent, which is good. However, it takes the user off-site to a Google Web site. I am not against users leaving the site when necessary (afterall, they shouldn’t feel trapped), but wouldn’t it be a simple matter of creating a page with these same tips. When sent to a google page for search tips, it begs the question to the user, “Will all of these tips help on a non google search page?” I suppose if near the official search bar a phrase reading “powered by Google” would mitigate confusion, but this creates one more thing for the user to think about. By this point they are likely already frustrated that their search was unsuccessful on some level and that they need to revise. However, the site’s search does follow one of the book’s most stressed points, that when searches come back with no results, they should encourage the user with different ways to continue the search rather than shutting down communication.
The ISU search page returns with suggestions. I suppose this one point is something I think is not as rigid as the authors sugest. I believe that most relatively seasoned internet users are used to having searches occassionally coming back with limited or no results and will not even read the tips, but revise the search of their own accord. I suppose though that it doesn’t hurt to provide tips to those new to the Web.
As I have been delving further into “Information Architecture,” I have had the happy coincidence of being able to apply some of the concepts that the authors are talking about in my work. We are in the midst of a unit-wide Web revamp. The actual design work will be done by the Web group on campus, but they have asked the divisions to provide them first with what we would like to see rather than them providing us with a structure and us giving feedback. My boss had already charged me with taking one of the key positions in the management of the Web site. Because of this, we both felt that it would be a good idea for me to be involved in the structuring as well.
Perhaps it would be a good time to point out that the old Web site, though it needed to be oriented towards the user, was not. The leadership of the unit recognized the need to resolve this and commissioned the building of the new site. Since I am not familiar with all of the needs of the users, it has been important for me to rely on others within the unit to help coordinate the information. As of tomorrow, I will have a 4th version site map rendered.
The first question I have had to ask representatives is what the users are looking for when they come to our site. It has been important to emphasize that we are interested in why the USER visits, not why WE would like them to visit. This question is fundamental in structuring the information.
As the different areas are identified, the most logical way to divide the pages up has been in a taxonomy or hierarchy. In doing this, we have removed jargon and non-descript unit names from the pages and have tried to focus on user friendly terms. For example: Now if a user would like to make a donation, they will click “Giving” in the main navigation. What appears are several options including information on giving, types of gifts, etc. But more importantly, we have made the first available link read “Give Now.” This might not seem like rocket science, but it was a very desirable link to bring to the front. A potential donor who just wants to give should not have to work hard or mentally exhaust themselves giving a gift. They click it an they are on the page to give. This element is task oriented. Items such as “Types of Gift” produce task oriented menus where the user can select a method of giving and learn all about it.
I would describe the taxonomy as broad and shallow as special emphasis has been given to bringing items to the top and making them easy to find. There are also additions to the main navigation that centralizes information for the users and allows them to (hopefully) easily find the information they want.
Most of the links withing the navigation are organized by the types that users would like to find easily. However for the majority of the about section, which is filled with numerous staff resources, the links have been placed under an appropriate heading and alphabetized. The alphabetic organization structure works best as when staff are searching for one of these resources, they will likely already know what exactly they are looking for.
The authors earned a few points with me during this reading session. They were focusing on methods users use when trying to find data that they are seeking. They illustrate a simple and commonly accepted model where:
Query is made—–> Black Magic ——> Answer found
That model gives me a chuckle everytime I read it. Partly because it illustrates an interesting point in it oversimplified structure. Users would like this to be the model for seeking information, and they likely don’t care what kind of algorithm gets them to it. However, as the authors point out, this is seldom the case as user searches are not so straight forward. They may want to do a focused search, or they may want to search for a specific item, but then find related information. The authors acknowledge that as information architects it is important to be aware not only the type of information that the user is seeking, but how they will go about seeking that information. This is a perfect illustration of their content/context/user model at work. Once we understand the needs and methods of the user, a site can be structured appropriately so that their experienc eis optimal.
This book is a monster. I will be definitely tackling it in sections.
The authors spend the first section of the book focusing on information architecture, what it is, why we do it, and who does it. Many definitions are provided, and the author acknowledges that there are many ways to look at information architecture. The favorite definition that they provide is, “The structural design of an information space to facilitate task completion and intuitive access to content” (Rosenfeld 4). A pretty broad definition, but one that effectively says just what the heck information architecture is. One thing that I found a little surprising about the book so far is that the authors seem to go to great lengths to convey that information architecture is not page design or color scheme. It is not the text itself nor usability. They rather seem to treat information architects as if they are librarians. Meaning that like librarians, they catalog information and make it easy to find, but do not necessarily create the materials nor do they pick the color of the book covers or the kind of wood that the shelves they sit on.
I already disagree with that point based on Steve Krug’s work and on what the authors Louis Rosenfeld and Peter Morville say mere pages later. (Let me add here that I realize that they don’t want to tackle all subjects related to information architecture and stay focused, but still…) The authors say that information focuses on three main elements. Content, context, and the user. Their job is to consider these three factors in setting up the structure for the site with their main goal being to create a hassle-free experience for the user. How are these three elements not related to other factors in Web development such as design and usability? Krug shows over and over in his book how when something as simple as the colors or size of the links are not right the whole navigation can become ineffective. He gives an example of how content (poor placement or an over abundance) can hinder the user. If pleasing the user is the goal and of course usability will matter. My point is that while they go to such lengths to distance themselves from other divisions of Web design, that is really impractical.
Having ranted on that, I am eager to continue the book which seems to be a very focused on the subject of information architecture. Hopefully in reading this, I will come up with a few ideas of my own for my Web projects and a more insightful analysis paper on the Ecology Action Center.
- Crossing the Digital Divide
- Mouse pad rhetoric
- Sarah Palin rhetoric
- Chapter 9 Postmodernism, Indie Media, and Popular Culture
- Convergence Culture
- Digitizing Race and the Matrix
- Modules in video games
- Weather channel
- Figure/ground, framing, and grids
- Grids, layers, hierarchy, transparency, modularity, patterns
- Readings on disability
- Rhetoric of Walls