vanderwal.net

Last Days of the Corporate Technophobe the NY Times headline reads. This article on how business is driven by information and the organization of information is paramount. The business world, or now those that did not "get it" before, is a knowledge-sharing and information processing realm. Those with out the ability are lost, or as this article states:

Not being able to use a computer in the year 2002 is like not being able to read in the 1950's.

This is important for us that create applications, Web sites, and other technologies. We have an important job in assisting the ease of information use and the process that helps this information become knowledge. Digging through the heaps of data can be eased so that the user can find the information that is important for their purposes. A large part of this job is creating an environment that will make for the ease of information use and mining the desired bits and bytes. A centralized or a minimum interconnected system of data stores that have the ability to keep information current across resources. Finding the snippets of information is often daunting in a large database centered system, but even worse in environments that have stores of segregated documents and data files (like MS Access). Information Architecture is vital to this effort assisting in helping create a navigatible structure of information. Looking at Google and its great improvements in vast information searching is the right direction also.

Information Week provides a glimpe of the 'New Way to Work'.

Digital Web is out with a new issue. My favorites from this issue are the interview with Chopping Block, the ever needed Flash usability guide, and the hands down my favorite is when design motivates. The rest of the issue is enjoyable and insightful as always, which includes motion design, the future, book review of 'Fresh Styles for Web Designers: Eye Candy from the Underground', and a review of digital video.

The Power of Smart Design in Business week. This interview with Dennis Boyle, design engineer at IDEO, brings out the importance good design can play in making a successful product. He states, "what regular people want is a product that does a few things really well". [hat tip Tomalak's Realm]

Kevin Fox adds New to You functionality to his site. This is the best idea I have run across in a while. It is a great idea that beats the problems I find on sites I frequent often. It also seems to cover the territory between visited links and not providing them. [hat tip Dinah]

The U.S. government's usability Website provides summaries of why it is good to perform iterative usabilty testing and showing usabilty testing saves money. Both of these are good discussion points when talking with clients and setting forth processes for information applications (including Internet sites and applications).

Stewart mulls the positive feedback loop in interaction design in his weblog. Stewart also links to a nice report/bulletin article highlighting designers of the future (kids) for SIGCHI Bulletin.

Stewarts article brings to mind the problems with capturing process and tasks when observing users perform their jobs in the early stages of contextual design. The last thing the observer wants to do is to influence what the user is doing. Asking questions on how to improve and working through the logic of the tasks and conditional elements of the task will come later. Understand the conditions the user has in place, don't ask why at the beginning, just capture as if you were going to have to repeat the exact same task.

The next step after capturing the information allows for understanding why there is a "wrk" button (using Stewart's example). Understanding what is behind the conditions will help build an application that is used as it maps to the user's cognitive understanding of the process. Some of these conditions may/can be broken when they are built into an algorithm. Breaking too many of the conditions can create an application that is quite foreign to the user and therefore possibly shunned.

One method of getting through the non-essential conditions is to use a transitional process. This would entail keeping some of the non-essential conditions in an applications interactive process with the user, i.e. sending an e-mailing to verify a fax was received. Including a verification notification for delivery of information may be included as it is engrained in the user's work pattern. As the user's learn to trust and respect the information in the new application they are using is reliable the verification notice may be altered to show only information not delivered or turned off completely.

Getting back to the starting point, if an observer would propose turning off the verification process and notification in the task capturing procedure there may be one individual that understands why there is not a verification process. The application being developed may be for many users that use the standard procedures. The user being observed may offer suggestions and these should be captured.

An USA Today article on poor product design provides insight that is helpful not only to product development, but also application development. The insights (while not new to most of us, but most likely very new to USA Today readers) include not including the consumer early enough in the process, product design team not well balanced, and technology runs amok.

These very closely apply to Web/Internet/Application development's downfalls. Not including the user in the development phases and/or testing with users early and throughout the development process. Having a development team that does not have a balance of visual, technical, and production skills can be problematic. Lastly, projects that are technology for technology's sake, very rarely offer success.

Conversely, success comes from getting these things right, involving the user and understanding how users would interact and use what you are building. Having a balanced team so that visual, technical, and production issues can be addressed and solved appropriately. And lastly knowing when and how to best use what technologies will drive success.

This last element, understanding the technologies, will help you get over the hurdle of accessibility/508 compliance. It will also help you find the best tools to interact with the users of the site/application. Having DHTML elements to provide action on a site or to serve information, when the user audience does not fully have the capability of addressing or handling the presentation, will have detrimental effects. Know what your elements your users have turned on and off in their browsers and what versions they are using. It is important to know what threshold of user profile can be the cut-off for developing a site. If 10% of your users have JavaScript turned off should you still develop elements of your site that are JavaScript dependant without providing an alternate service? Know and set this percentage threshold, as it will help understand why you can and can not use certain technologies.

Google shares its 10 things they found to be true, which starts off with, "focus on the user and all else will follow". There are many other truths in this list. [hat tip eleganthack and Digital-Web New]

37signals' design not found offers an example of letting your users know restrictions. This is not only important for restrictions, but letting users know which are required fields. Users are not mind readers, so don't treat them like Uri Geller or David Blaine. [hat tip Christina]

The BBC reports that Intel is running field studies on mobile device use in London. The research is an ethnogrphic study of interactive use. The article states, "'One of the things that makes a successful technology is a technology that supports experiences that people want to have,' explained Ms Genevieve Bell, senior researcher and design ethnographer at Intel." This is nice news, but slightly more impressive is the general media's explainations of the study, (you go Beeb!!).

We are all trying to make our sites more accessible. Some of us do it because we have to and others of us do it because it is the right thing to do. No matter what our mission to many of us it is a new twist to our regular routines and we could use some help. Those of us that use Macromedia products now have help in Macromedia's Solutions Kit of Accessability.

Joe Gillespie's Interface Design Primer offers a wonderful background of the computer interface. There are wonderful nuggets that we designers and devleopers need to keep in mind. Knowing how, why, history, and reasoning behind elements of interface understanding are some of the best tools we carry in our tool belts. We also need to keep testing what we know to ensure there are not new shades that will help get all of us around a corner to a much better method of providing the user an intuitive interactive interface. [hat tip Jeffery]

In digging through the v/d wal net access logs I found a pull quote at Cognitive Architects from my brain dumps on Information Architecture. This is an interesting way to parse information and ideas from one's own head.

I promise I will not make a habit of pointing to others quoting me. Although I may point to outside sources where I am posting my braindumps, as this site is my method of culling information of interest and tracking my own thoughts along with a resource to track other ideas of interest to myself.

Is Information Architect the Term for the Work of Setting Plans for Information Applications

There has been quite a bit of discussion about the moniker Information Architect on the sigia-L listserve lately. I tried to post a response, but it never made it to the list serve. I am not too concerned about the name or the label attached to the skills and practice of these skills, but to me IA is rather apropos for what I find to be a core part of information application development. The following is my input and a description of what I do as a foundation for developing information applications.

I am finding a lot of common ground in the descriptions of IA, User-based terms, and Experience Design. I tend to lump the whole, to a large extent, into Information Architecture. My work focuses on building information applications from static Web pages to Content Management Systems (CMS) driven sites that extend access to the information to wireless/mobile devices and work between systems. There are two key elements of this development: the information and the user.

Information architects put structure to the information to better understand it by looking at it through the eyes of the user. How does the user think about this information? How does the user structure the information in their mind? How will the information be used and in what context? Where do users look for this information? These questions are essential to building an information application that can and hopefully will be used. I can not have a successful project or product result unless these questions are asked, answered, and put in to a logical structure. This is the basis for navigation systems, metadata gathering, synomic databases for searches, the foundation to build a wireframe, and extends to the framework to create an information facade in the Richard Saul Wuhrman/Nathan Shedroff understanding of IA.

Louis Rosenfeld sees IA as an intersection of three areas: users, content, and context. Which are the base elements that most of us come to the table to understand. These elements are the core elements that need to be understood for an information application.

Christina Wodtke's big tent includes three elements to an IA: content architecture, interaction design, and information design. These elements are the action elements to Lou's component level approach.

The Experience Design folks (of the Richard Saul Wurman and Nathan Shedroff fold) have the same elements in their tool kit and approach the questions much the same manner, but have an experiential end goal the are trying to achieve.

Much of my understanding of these elements came initially from Communication Theory, advertising, public relations, and direct marketing. The user/audience is the focal point of communication and to target a message one needs to answer the same user centric questions and understand the information at hand. I added this background to my then hobby of playing with computers and trying to make applications function in a way that helped me do my job and try to extend that passion to helping others use technology to aid them. The core focus is the user, the task, and the information.

I really like Marc Rittig's hub-and-spoke approach to find a core set of understanding, which there is plenty there to build upon. The joining of disciplines where there is common ground is important as we have a lot to learn and a lot of experiences to share.

I did not know what to call the foundation skills that I found needed to be employed in a project to lead to success. At SXSW last year information architecture kept popping up as a viable choice. After six to seven years of working off a modified process, based on the one I read on vivid studio's site and married it to my process background learned in communication theory, I had a name. I worked for six years with out a name for what I did and found helpful. I know that much of what I do is based on examining how an information space will be used to provide a structured understanding to the user for accessing and using that information. Understanding the user and the information allows a map/schematic/blueprint to be drawn, upon which an information application can be built.