vanderwal.net

Can I tell you how ready for sleep I am? This week included the approach of an ISO audit at work, end of the month usual stuff, tons of paperwork for work and home, spending time with my wonderful parents that were in town (although they stayed in a private club/hotel that lost them when I was trying to meet them for dinner), realized I could not find my running shoes I liked (hello Adidas for home delivery), figured out that the ASIS IA Summit is largely on a weekend that I have not away and close by in Baltimore (hello I am now going), finally got tired of my cell phone and its poor battery life and my non-national call plan for that phone that put me back more than $300 while stuck in SF around Sept. 11 (vavoom a new phone and a national plan, which includes e-mail, text messaging, and Web and a much longer battery life), and allergy season beginning. I also realized I leave for Austin a week from tomorrow.

I think a note of clarification is needed regarding the frames comments from the other day. I am a huge fan of the Content Management Bible and have been perusing it for a couple months (or so) now. The use of frames is not all bad, if used in a proper context.

One reason to use frames is using the browser client as an application interface and there are distinct sections with quasi-interrelated functionality. A mapping application (select any one of these elements on the page to see the use of frames - keep in mind there is a heavy use of JavaScript that requires a version 4.5 browser or higher). The application interface often has command elements that are essentially toolbars and definition selection elements that set the metadata layers of the information to be displayed. These toolbars direct the actions of the other frames or provide tools to be used in other frames (a zoom tool, etc.). The functionality in a toolbar is not an element of the map display and it should not be an incorporated element of the map as it has a much different functionality from the map display. Conversely, our users are familiar with navigation being incorporated into the Webpage and that is now a common and preferred construct. But, we are looking at an application being displayed in a Web browser, which requires a different mind set.

Another use of frames is in a controlled environment that has a plethora of distinct content items that are within a contiguous text, such as an extensive table of contents. Here the Metatorial CM Bible is a good example of when to use frames. There table of contents is a helpful information tool to quickly scan through the information to place the reader at distinct point in a larger body of text. The table of contents is a large (long) element of text that could work as an element is one distinct page, but that would require rebuilding those elements of the page with every snippet of information delivered to the browser.

Frames should be used when the distinct content elements require each other. The table of contents and the page display elements should not work with out the other components (if they can we really have to ask ourselves why we are using frames). If we can enter a page in the CM Bible without the table of contents the functionality of the site is broken. The navigation is not available and the assistive information (navigation and/or metadata elements) is not available.

The last item is to ensure that if a frame can stand alone as its own page, please ensure there are the needed navigational elements on the page. In the example that drove my frames rant (largely because the CM folks understand information and its need to be used, but the site breaks information use constructs we know from experience and research to be proper and needed) the thing that was disconcerting was each of the frame elements needed the other to provide complete information for the user. The user needs context. We need to provide the user a means to get to our front page or to other areas within our sites, because if they like our information we should offer them more. If we build a site using framed elements and these elements can be used on their own (no JavaScript sniffers to ensure the other frames are open as a requirement for displaying the content, or other similar technique) the content must have navigation elements (the footer is an unobtrusive placement) and really should have some branding or other statement of ownership.

We know that users of information have varied purposes and methods of using our information. We need to provide the users the tools to help the user provide this information. We are often proud of our information work, but if a user does not know it is us or we do not want to claim our work is decreases credibility.

We need to embrace functional information architecture to ensure proper information use. This bleeds in to user experience design, but understanding how information is used and the information interface is used must be integrated into the IA. Proper functional IA should keep improper use of frames from occurring. Functional IA would walk through a string of questions using a wireframe of a site and ask how the frame sections would interact. We would ask what information is lost if not all the frames function (a surprisingly common occurrence). We would ask if frames maintain context for the information. We would look at methods of insuring the whole of the frames remains so to provide proper navigation, proper context, and proper metadata to help understand the information provided. Not asking these questions is not being responsible to the information, those that collected the metadata and spent time understanding how the information is to be used, and is not responsible to the consumers of the information.

Peter discusses Social Network Analysis and includes a bevy of links to great resources. This is a great way to learn the interaction of people and the movement and sharing of information.

Intranet Journal provides a card sorting tutorial, which also includes a survey of the users.

The the architecture of information as translated from French. This work offers some understandings of how we got to a place on the Web where people started saying that nobody can find information on my site that is there. [hat tip Christina]

Jesse hits the nail on the head with part four of IA/recon: Then a Miracle Occurs. Now I wait with baited breath for parts five and six.

Jesse offers part 3 of the ia/recon discussing the over reliance on user testing for everything. This may be my favorite of the three components Jesse has posted so far. User testing offers a great step up and helps to understand the users better. Understanding graphic design, application development, and information architecture will help to construct solutions to information structure and interface and interaction design problems that user testing offers little insight. User testing in these areas can help let us know we are on the right track, but it will not point us in the right direction as we have not offered the user these choices if we don't have the experience.

I have added two pages to help provide a guide for metadata usage. One page sorts categories by number of times the metadata definition has been used. The other page is an alphabetical listing of categories with their count. These two page builds took very little time to knock together (half an hour or so) and the value to me is much greater than that half hour used.

John Udell looks in to perl to create topic maps and bottom up taxonomy. Making taxonomy and topic maps easier is a great endeavor and quite useful.

CommArts features the Herman Miller Red site design, which includes User Experience and Information Architecture work of Nathan Shedroff (on of the Vivid Studio founders). I went to a session at last year's SXSW where Nathan presented an over view that is essentially the same as this, I am glad this is now on line as I can share it. This article provides a solid insight into decision making, workflow, and the purpose of wireframes.

Jesse explains the role of Information Architecture. There have been many debates over the issue of the Big IA and the small IA. Jesse does a nice job of tying up the camps on these views. I am agreeing with Jesse to a great degree at the moment. The discipline of information architecture is definately needed on any information application (remember this includes Web development too) development project. There must be a person that knows and understands IA and can implement those needed skills, as are propper in the discipline. There must be a person that has the job of protecting Information Architecture on every project. The more people on a team that have some understanding of IA, in addition to the person that has full understanding of IA and is charged with its implimentation, the better the project will be in its final state.

Peter Morville provides Innovative Architecture that looks at the future of IA, which incorporates collaborative IA. The users of many sites create or hone the IA through many components, such as Amazon's "people who bought this item also bought." I like the breadth of this piece and how it encompasses applications and community driving IA.

Content Management Systems Surrounding Me

Content management is back at the forefront of every aspect of my digital life again. Content management revolves around keeping information current, accurate, and reusable (there are many more elements, but these cut to the core of many issues). Maintaining Websites and providing information resources on the broader Internet have revolved around static Web pages or information stored in MS Word, PDF files, etc. Content management has been a painful task of keeping this information current and accurate across all these various input and output platforms. This brings us to content management systems (CMS).

As I pointed to earlier, there are good resources for getting and understanding CMS and how our roles change when we implement a CMS. Important to understanding is the separation of content (data and information), from the presentation (layout and style), and from the application (PDF, Web page, MS Word document, etc.). This requires an input mechanism, usually a form that captures the information and places it in is data/information store, which may be a database, XML document, or a combination of these. This also provides for a workflow process that involved proofing and editing the information along with versioning the information.

Key to the CMS is separation of content, which means there needs to be a way to be a method of keeping links aside from the input flow. Mark Baker provides a great article, What Does Your Content Management System Call This Guy about how to handle links. Links are an element that separates the CMS-lite tools (Blogger, Movable Type, etc.) from more robust CMS (other elements of difference are more expansive workflow, metadata capturing, and content type handling (images, PDF, etc. and their related metadata needs)). Links in many older systems, often used for newspaper and magazine publications (New York Times and San Francisco Chronicle) placed their links outside of the body of the article. The external linking provided an easy method of providing link management that helps ensure there are no broken links (if an external site changes the location (URL) it there really should only be one place that we have to modify that link, searching every page looking for links to replace). The method in the Baker article outlines how many current systems provide this same service, which is similar to Wiki Wiki's approach. The Baker outlined method also will benefit greatly from all of the Information Architecture work you have done to capture classifications of information and metadata types (IA is a needed and required part of nearly every development process).

What this gets us is content that we can easily output to a Web site in HTML/XHTML in a template that meets all accessibility requirements, ensures quality assurance has been performed, and provides a consistent presentation of information. The same information can be output in a more simple presentation template for handheld devices (AvantGo for example) or WML for WAP. The same information can be provided in an XML document, such as RSS, which provides others access to information more easily. The same information can be output to a template that is stored in PDF that is then sent to a printer to output in a newsletter or the PDF distributed for the users to print out on their own. The technologies for information presentation are ever changing and CMS allows us to easily keep up with these changes and output the information in the "latest and greatest", while still being able to provide information to those using older technologies.

I am very happy that Lou finally has permalinks. Not only this, but he has comments and they are attracting some of the thinkers and doers of information architecture. This may become an incredible resource. Wahoo!!

Peter provides great insights on receptivity and modular presentation components in the eNarrative interview with Peter Merholz.