Once we have uncovered the information components required in a solution, the next steps are to establish what pieces of information (attributes) we want to capture about the component. These attributes depend on the uses of the system we are building.
Let’s see how a book is represented on Amazon.com. If we call up Content Everywhere by Sara Wachter-Boettcher, we see that Amazon has chosen to display the following information about this book
- Title: Content Everywhere
- Format: Paperback
- Author: Sara Wachter-Boettcher
- Book Description: Care about content? Better copy isn’t enough …..
- Price: $39.00 Paperback: 240 pages Publisher: Rosenfeld Media; 1st edition (December 11, 2012)
- Language: English
- ISBN-10: 193382087X
- ISBN-13: 978-1933820873
- Product Dimensions: 8.9 x 6 x 0.6 inches
- Shipping Weight: 1.1 pounds
- Average Customer Review: 5.0 out of 5 stars See all reviews (3 customer reviews) Amazon Best Sellers Rank: #164,241 in Books (See Top 100 in Books)
- Only 14 left in stock (more on the way)
This is a SURFACE presentation. Looking at this list, the last three items seem a bit different than the others; after all, the book is still the book regardless of the reviews or rank or number in stock, all of which can change moment by moment. This is a clue that at a DEEP level, we have other information components, which we might call REVIEWS, SALES, and INVENTORY, and that review, rank, and number in stock are attributes of these systems, respectively, pulled together into a useful surface presentation. So let’s mentally remove them from the list of attributes of BOOK.
The remaining attributes seem reasonable for an e-commerce site. We can imagine user scenarios for most of these, for example “User wants to find a specific book, e.g. by title”, “User wants to know more about this book, e.g. price”.
If we were designing a system for a public library, we might also have an information component called BOOK. In their case, however, there might be no interest in recording or weight. We would ask them about whether we would record size, as it might have an impact on shelving a book in the Oversized section.
Going back to the e-commerce site, one of its goals is to help customers find products they might be interested in. The attributes already discussed help the customer find a specific book if they know the title, author, or ISBN, and get more details about it once they have found it. But sometimes customers are browsing for a book on a particular subject, and we have to determine how they might frame their search. User research might give us a list of potential queries such as:
“I’m going to Italy and want a travel guide with lots of pictures of historical sites” “I want a pulp romance to read on the beach” “I want a book of inspirational Easter verses for my grandchildren” “I want an easy introduction to content strategy”
To help users find candidate books, we tag the book with additional information such as topic (computing > web design > human-computer interaction), genre (travel guide, romance), classification (fiction, non-fiction), audience (children, teen, young adult) and other terms that might be useful.
These tags are somehow different than an attribute of a single book such as author or title. It is more like information that structures or segments the set of books to help readers find books that they might be interested in. We call this type of information metadata.
It is instructive to look at a couple of online bookstores to see what metadata they provide about their books. You will see a variety of access methods hopefully offering the site visitor useful ways to browse for books.
Some metadata aims to provide a systematic hierarchical categorization scheme into which all books would fit in at least one place. These structures allow the reader to systematically narrow or broaden their search scope. If they want to find books on a specific subject, they can start near the top of the hierarchy and drill down into an area of interest. If they have found a book they like, they can see what other books are in the same category, and even broaden their search by going up a level in the hierarchy.
Other metadata such as audience (children, teen, young adult) doesn’t allow systematic exploration of the space of books, but does provide criteria to rule books in or out of a selection. For example, the user could narrow their search to include Children and Non-fiction. These are examples of facets, and allowing the user to choose from a number of independent dimensions is called a faceted search.
For large heterogeneous information spaces, you will not be able to to answer all browsing queries with metadata. For example, consider the query
“I’m going to Italy and want a travel guide with lots of pictures of historical sites”.
We could probably devise metadata to identify travel guides of Italy. But for characteristics as loose as “lots of pictures of historical sites”, it might be difficult and/or unproductive to try to devise metadata to reliably tag books. In this case, we use hierarchical and faceted search to take the user to a reasonably small area in the space of books. Then we let them make their own decision. We do this by providing publishers reviews, picture of the front cover, reviews and ratings from other customers, and giving the customer the opportunity to read selected pages.
To summarize, this step of information architecture provides attributes and metadata to address the questions “what do our user need to know about the information we are presenting to them”, and “how can they search and view the information?”. Practically speaking, these questions can be asked early in the design cycle. There is often a lot of user involvement, sketching out various formats for views, reports, and search results.