Posts Tagged ‘polarbearBook’

The IA iceberg

June 5, 2008

The information architecture iceberg

The information architecture iceberg
From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p.358, Figure 18-8

Blueprints (site-maps)

June 5, 2008

“Blueprints show the relationships between pages and other content components, and can be used to portray organization, navigation, and labeling systems. They are often referred to as “sitemaps,” and do in fact have much in common with those supplementary navigation systems. Both the diagram and the navigation system display the “shape” of the information space in overview, functioning as a condensed map for site developers and users respectively.”

From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p. 272

The value of IA (checklist)

June 5, 2008
    Why good IA is worth the money:

  1. Reduces the cost of finding information
  2. Reduces the cost of finding wrong information
  3. Reduces the cost of not finding information at all
  4. Provides a competitive advantage
  5. Increases product awareness
  6. Increases sales
  7. Makes using a site a more enjoyable experience.
  8. Improves brand loyalty
  9. Reduces reliance upon documentation
  10. Reduces maintenance costs
  11. Reduces training costs
  12. Reduces staff turnover
  13. Reduces organizational upheaval
  14. Reduces organizational politicking
  15. Improves knowledge sharing
  16. Reduces duplication of effort
  17. Solidifies business strategy

From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p.344-5

Architectural styleguide

June 5, 2008

“An architecture style guide is a document that explains how the site is organized, why it is organized that way, and how the architecture should be extended as the site grows. The guide should begin with documentation of the mission and vision for the site, as it’s important to understand the original goals. Continue with information about the intended audiences. Who was the site designed for? What assumptions content development policy. What types of content will and won’t be included and content development policy. What types of content will and won’t be included and why? How often will it be updated? When will it be removed? And who will be responsible for it?”

From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p.302-3

Wireframes guidelines

June 5, 2008
  1. Consistency is key, especially when presenting multiple wireframes. It ensures that clients will be impressed by the professionalism of your wireframes. More importantly, colleagues take wireframes quite literally, so consistency makes their design and production work go more smoothly.
  2. Visio and other standard charting tools support background layers, allowing you to reuse navigation bars and page layouts for multiple pages throughout the site. Similarly, Visio’ s stencil feature allows you to maintain a standard library of drawing objects that can be used to describe page elements.
  3. Callouts are an effective way to provide notes about the functionality of page elements. Be sure to leave room for them at the sides and top of your wireframes.
  4. Like any other deliverable, wireframes should be usable and professionally developed. So tie your collection of wireframes together with page numbers, page titles, project titles, and last revision date.
  5. When more than one information architect is creating a project’s wireframes, be sure to establish procedures for developing, sharing, and maintaining common templates and stencils (and consider establishing a wireframe “steward”). Schedule time in your project plan for synchronizing the team’s wireframes to ensure consistent appearance and for confirming that these discrete documents do indeed fit together functionally.

From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p. 288-9

Wireframes

June 5, 2008

“Blueprints can help an information architect determine where content should go and how it should be navigated within the context of a site, subsite, or collection of content. Wireframes serve a different role: they depict how an individual page should look from an architectural perspective. Wireframes
stand at the intersection of the site’s information architecture and its visual and information design.”

From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p. 283

Three common information needs:

June 5, 2008
  1. The perfect catch (answers straight away, e.g. telephone numbers, facts and figures) a.k.a. ‘ known-em seeking’
  2. Lobster Trapping (you don’t know much about sth but you are interested) – You are setting out the equivalent of a lobster trap – you hope whatever ambles in will be useful. – a.k.a. ‘exploratory seeking’, typically open-ended,
  3. Indiscriminate Driftnetting (you need to know the complexity of a subject so you need every little fish…) a.k.a. ‘exhaustive research’

From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p. 31

Other terms used:

Information foraging (Morville)

Info Architecture: the whole is greater than the sum of its parts

June 5, 2008

“Each building serves its purpose uniquely. Architecture, design, construction, furnishings, inhabitants, and location all play major roles in shaping the overall experience. All elements must work together. In successful buildings, the whole is greater than the sum of its parts.”

From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p.3

Information Architecture components

June 5, 2008
  1. Browsing Aids
    These components present users with a predetermined set of paths to help them navigate the site. Users don’t articulate their queries, but instead find their way through menus and links. Types of browsing aids include:

    1. Organisation Systems – The main ways of categorizing a site’s content. Also known as taxonomies and hierarchies.
    2. Site-wide Navigation Systems – Primary navigation systems that help users understand where they are and where they can go within a site.
    3. Local Navigation Systems – Primary navigation systems that help users understand where they are and where they can go within a portion of a site (i.e., a subsite).
    4. Sitemaps/Tabies of Contents – Navigation systems that supplement primary navigation systems; provide a condensed overview of and links to major content areas and subsites within the site, usually in outline form.
    5. Site Indexes – Supplementary navigation systems that provide an alphabetized list of links to the contents of the site.
    6. Site Guides – Supplementary navigation systems that provide specialized information on a specific topic, as well as links to a related subset of the site’s content.
    7. Site Wizards – Supplementary navigation systems that lead users through a sequential set of steps; may also link to a related subset of the site’s content.
    8. Contextual Linking Systems – Consistently presented links to related content. Often embedded in text, and generally used to connect highly specialized content within a site.
  2. Search Aids
    These components allow the entry of a user-defined query (e.g., a search) and automatically present users With a customized set of results that match their query. of these as dynamic, automated counterparts to browsing aids. Types of search components include:

    1. Search Interface – !he means of entering a search query, typically with information on how to improve your query, as well as other ways to configure your search (e.g., selecting from specific search zones).
    2. Query Language – The grammar of a search query; query languages might include Boolean operators (e.g., AND, OR, NOT), proximity operators (e.g., ADJACENT, NEAR), or ways of specifying which field to search (e.g., AUTHOR=”Shakespeare”).
    3. Retrieval Algorithms – The part of a search engine that determines which content matches a user’s query.

    4. Search Zones – Subsets of site content that have been separately indexed to support narrower searching (e.g., searching the tech support area within a software vendor’s site).
    5. Search Results – Presentation of content that matches the user’s search query; involves decisions of what types of content should make up each individual result, how many .Its to display, and how results should be ranked, sorted, and clustered.
  3. Content and Tasks
    These are the users’ ultimate destinations, as opposed to separate components that users to their destinations. However, it’s difficult to separate content and tasks from an information architecture, as there are components embedded in content and ks that help us find our way. Examples of information architecture components embedded in content and tasks include:

    1. Headings – Labels for the content that follows them.
    2. Embedded Links – Links within text; these label (i.e., represent) the content they link to.
    3. Embedded Metadata – Information that can be used as metadata but must first be extracted (e.g., in a recipe, if an ingredient is mentioned, this information can be indexed to support searching by ingredient) .
    4. Chunks – Logical units of content; these can vary in granularity (e.g., books and chapters are both chunks) and can be nested (e.g., a chapter is part of a book).
    5. Lists – Groups of chunks or links to chunks; these are important because they’ve been grouped together (e.g., they share some trait in common) and have been presented in a particular order (e.g., chronologically).
    6. Sequential Aids – Clues that suggest where the user is in a process or task, and how far he has to go before completing it (e.g., “step 3 of 8”).
    7. Identifiers – Clues that suggest where the user is in an information system (e.g., a logo that specifies what site she is using, or a breadcrumb that explains where in the site she is at the moment).
  4. ‘Invisible’ Components
    Certain key architectural components run completely in the background; users rarely (if ever) interact with them. These components often “feed” other components, such as a controlled vocabulary that populates embedded metadata fields. Types of invisible information architecture components include:

    1. Controlled Vocabularies – Predetermined vocabularies of preferred terms that describe a specific domain (e.g., auto racing or orthopedic surgery); typically include variant terms (e.g., “brewskie” is variant term for “beer”).
    2. Thesauri – A controlled vocabulary that may also include links to broader and narrower terms, as well as descriptions of preferred terms (a.k.a. “scope notes”).
    3. Rule Sets – Groups of rules that can be used to guide information retrieval (e.g., if someone searches for “handheld,” present these three manually identified results).

From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p. 46-49

Balanced navigation systems

June 5, 2008

“The trick to designing navigation systems is to balance the advantages of flexibility wth the dangers of clutter. In a large, complex web site, a complete lack of lateral and vertical navigation aids can be very limiting. On the other hand, too many navigation aids can bury the hierarchy and overwhelm the user. Navigation systems should be designed with care to complement and reinforce the hierarchy by providing added context and flexibility.”

From: Morville, Peter and Rosenfeld, Louis (2002), Information Architecture for the World Wide Web – 2nd edition, Sebastopol: O’Reilly, p. 111-2