Colin Bayer-Information Architecture

Although this is a long time coming and almost a repeat (because i've already read these chapters) I suppose I ought to write in this blog in order to get credit for it.

Anyway, Krug's chapter's 5 and 6- some of his longer writing, but very useful. What I found to be most promising about his analysis is the way he describes navigation as compared to trying to find something in a store. Similarly, users on the web may browse aimlessly to find their product and eventually may do so. In a store, someone might wander around until they find the product. However, once he knows the physical location of that product, he can go directly there next time- with the web, it's a bit more abstract. One cannot just go straight down aisle 3 and turn left at the end- on the web, the only way for someone to get back to the same place is to follow all the same steps as before (that is, if the navigation is bad). This is where searching comes in. Searching allows an intermediate step that skips all the wandering- although it also doesn't show the user the true path to their destination. His diagrams of a typical user browsing a store and a site are interesting- their paths that either lead to their destination or frustration. As mentioned before, Krug says that the web has no sense of scale- that is, we don't know how far we have to browse or wander to find something- as well as no sense of location or direction. This is why navigation is crucial.

Consistency, as always is a key. Global navigation, similar logo placement, a constant color scheme that reflects your site, as well as keeping good and consistent naming conventions (ie. "search" instead of "quickFind" or something).

His reference to page names was kind of amusing- considering we (as bostonians) know that most of the signs here really ARE to see. Keeping this in mind, it's a thing to make sure our naming conventions are in order. Every link name, title label and page title must reflect what's on that page. Breadcrumbs, showing us where we have been (and how to get to where we are) must reflect what's on parent pages. Indicators that show us where we presently are must reflect the page title. And so on. These things, although seemingly obvious, can wreak havok when not followed- if a user expects to find "iPods" and comes to a site that has all portable audio gear, even that can throw him off.

I've since finished the book, and plan on keeping it as it's a great reference and pretty much a quick "bible" for those doing interface design or info architecture. I find the reading easy and the pictures intriguing. Thanks for the good required book!

The article we read from The Inmates Are Running The Asylum about User Personas was perhaps the most interesting and "newest" material I've read so far in this class. It really takes the old adage of demographics and twists it around. For the longest time, it seems as though everyone is forced into a "class-" by income, race, interests, etc; and then the marketing firms or whomever uses these general descriptions to try to appeal to "more" people at once, alienating the individual. However, user personas is the opposite, and takes the path that magazines have taken. Ever notice how there is a magazine for everyone from cigar buffs to skateboarders to eastern European street performers? User personas are similar, in that they sacrifice accommodating EVERYONE so that they might perfectly accommodate one person. This way, while the majority of a population may not read the magazine about Eastern European Street Performers, those who DO will be 100% satisfied. I liked (and understood!) the rule of thumb that the more people- or types of people- you try to appeal to, the less satisfaction level in the product you will get. It makes complete sense.
Creating user personas does seem like a daunting task...You have to create a PERSON, basically, and make sure that this person is not generic. While stereotypes are fine (it helps define a person sometimes) it takes some creativity to ensure that everyone on the development team can create a persona with character. One part I was confused about was...While over-all, we try not to get too general, it's also not a good idea to get too specific when creating a persona- as outlined in the reading, it would be too "realistic" if our personas had the quirks of a real person...How do we account for that in a persona?
For design of interfaces, skill level is always an issue- mostly because we want to ensure that users from different abilities and backgrounds can all use an interface happily. The case study about the In Flight Entertainment was a great example of how they overcame a problem. They did an impressive job of finding the lowest common denominator and designing for him, while still taking into account that users of a higher skill level might be using their interface.
Finally, it was obvious that the author had something personal against programmers.

After reading chapter 3 in Veen's book, I've found that his style of writing is a bit heavier than Krug's- however, the difference is that the topics which Veen touches on requires more in-depth discussion.
One aspect of chapter 3 that I found interesting was the references to the different styles of structural heirarchies and how they vary from site to site, and why it matters which way they are structured. This is directly related to the in class project that is on-going, as we have explored many sites with different organizational schemes while keeping in mind the LATCH theory. It's helpful to read from Veen how many sites require more than one scheme in organizing their information, and cross-referencing them is quite important. For an individual who is say, looking at a product, he should feel as though he can access everything on that site relating to that product from one page, rather than having to fish through a sea of unrelavent pages.
Veen discusses web portals and how they take a plethora of information and are faced with the challenge of organizing it all so the links relate to each other, and so users stay on their site. His anaylsis of the three portals was in depth, and served to prove that there isn't necessarily one "good" way but there are a few "bad" ways to accomplish this. I think the problem comes in with the introduction of just too much information.

After reading the handout about instructions, and also writing instructions on how to use a can opener- I see how arbitrary instructions can be, leaving users pretty much lost. We got these shelves for clothing, that you have to put together yourself. The instructions are entirely visual, and not only that, but everything is out of scale and perspective. You don't know what screw you have to use for which part, and you don't know whether you're looking at the front or the back of the drawer unit. It's still half-assembled in the other room. However, a friend gave us another shelf unit, that had to be assembled, but did not have the instructions. I was able to build it myself, through trial and error, and it was less frustrating than actually knowing what I HAD to do but not being able to do it due to poor instructions. Maybe in the process of "simplification," things are becoming too complicated. I often catch myself giving driving directions to people that are complex- even though to me, the process of getting from point A to point B is simple. I try to give them many details so they know they're on the right track, but for all I know i'm confusing them with things they don't need to know.
As far as the Krug book, I've actually been reading ahead. I find it well written, and even entertaining. Some of the more important and interesting parts include the sections about how users percieve pages vs. how we design them, how users tend to find the first best fitting answers (so you'd better make sure you write what they want), and how using the 'Net is pretty mindless- people are less apt to read instructions and more apt to blindly surf through until they stumble across what they need. It's true, too- I've found myself doing that on many occasions. Again, the whole concept of "not making someone think" is shown as a prime example right there. The site redesigns were good too (chapter 6)- it gave me an opportunity to test out the theories Krug had laid out so far.

In the article we were assigned, I found the confession of the author intriguing- that he "wasn't a very smart person." Obviously, one could read his writing and look at what he's done and recognize that this creator of Information Architecture is in fact quite an intelligent individual. But what did he mean by not being very smart? He is only as smart as he lets other people know- and the less he informs others what he does and doesn't understand, the less smart he becomes. As Americans, we are chided for saying we don't understand, and it becomes commonplace to smile and nod as if everything is perfectly clear, even when it is not. The author wants this kind of behavoir to be abolished; but he also wants there to be no reason for anyone to pretend not to understand. One of the goals of information architecture, then, is to construct things in a way that makes sense to those who are using it. With the dog example, the best way to organize them so that most anyone could pick one would be by weight and size- people have a strong concept of what weight is usually, and how it relates to size. It would not be beneficial for the layman to look at a chart of dogs organized by the date they were inducted into the American Kennel Club, or their country of origin.

Nathan Shedroff created a spectrum of "understanding," organized into categories: Data, Information, Knowledge, and Wisdom. This spectrum starts with data- one can see a "factoid" on TV, but has he really learned anything? Data is part of research, creation, and discovery. Finding out the basic information about a product, or subject. Information is a step above data, as it is organized data. It is the data organized into a format for presentation. Knowledge of the subject is the ability to integrate it into conversation- it requires a concrete understanding of the subject that mere organization and research does not capture. The highest step of understanding is Wisdom. This step requires one to be able to operate with the information inside their heads rather than relying on outside sources- it's entirely an internal process.

With this spectrum in mind, information architecture can be organized to cater to individuals at different stages of their understanding of a topic.

This is my Information Architecture web log. It will be updated at least once a week with responses from the reading assignments.