Compare this to the boxes-and-arrows diagram used in the 4700-word CRS Manual.

What gives the interactive chart its punch is the use of verbs to describe the connections between the elements. Verbs like “contain”, “create”, “perform” are contrasted with “are part of”, “are created by”, “are performed by”. These words identify the relationship between subjects and objects in a much more informative way than lines with arrowheads.

But then Google released its redesign of Reader, and we went from this:

to this:

[Image credits: SheGeeks.net]

Google calls the design “cleaner, faster, and nicer to look at.”  But after reading their announcement more closely, it’s really more about creating a tighter integration with Google+ by turning off Reader’s friending, following, shared items and comments in favor of similar Google+ functionality. Which is okay, since I do see the point of consolidating Reader’s social aspect with Google+. But the redesign has actually made sharing harder, not easier. Former Google Reader Product Manager Brian Shih puts it this way:

Keep in mind that on top of requiring 3-4 times as many clicks, you also now must +1 a post publicly to share it, even if it’s shared to a private circle. That bears repeating. The next time you want to share some sexy halloween costumes with your private set of friends, you first must publicly +1 the post, which means it shows up on your profile, plus wherever the hell G+ decides to use +1 data. So much for building a network around privacy controls.

But then later, an update:

It turns out there is a way to share without +1′ing first. If you click on the top right “Share…” field on the OneGoogle bar [the bar at the very top of the pane], you can bypass the +1 button. It’s just completely undiscoverable.

Sounds like a dark pattern to me.

But let’s put Google+ aside, since sharing wasn’t why I used Reader in the first place. It was about the content. How quickly can I see what’s new and get to an individual story? From an information design perspective, I’d think making the design cleaner would mean maximizing space for original content. Rather it seems they did the opposite, with a thicker/more spacious header bar that pushes content further down the page.

From a visual design standpoint, greeted by a new absence of color, I wondered if they were trying to make it look like a traditional newspaper, removing colored elements as if they were distractions? While there is such a thing as too much color, the new Reader goes overboard in the other direction. With black, white, and grey being the dominant scheme, it’s hard to tell what the priority is in the UI. Google even eliminated the use of the bright blue link color that facilitates scanning.  Now nothing stands out–except for the bright red Subscribe button and the blue Search button.  Maybe it’s time to revisit the pluses of eye candy.

Kvetching aside, I suppose I will get used to the new direction (assuming I don’t switch feeds first).  I also guess I had better brace myself for the upcoming Gmail redesign.

IBM Many Bills is a search engine that presents U.S. Congressional legislation in strongly visual format. Each bill is presented in a single vertical column with metadata at the top and sections in descending order. Sections are color coded to delineate their subject. You can show and hide sections of the bills you have found by subject (in a nice accountability feature, a rollover tells you how confident a subject assignment is), save specific bills, and view the actual text.

The color-coded sections allow you to view results in “minified” form, or as an extremely condensed “collection”, such as this group of American Housing Bills:

Many Bills is compelling on several levels. First is the hope that this kind of presentation can help make the legislative process more transparent to both experts and the general public. Second is the project as a model for content-specific search. By understanding the structure of the data, the Many Bills Team presents it in a way that facilitates findability and understanding. There is some risk that the team’s information architecture and design decisions could reinforce conventional thinking at the expense of the unexpected insight, but the source data is available to anyone who wants to try a different approach.

The database output, by year or team, shows the remarkable variety in baseball uniform design, within the simple confines of cap, jersey, pants, and socks. The outline style shown above was created by Marc Okkonen for his book Baseball Uniforms of the 20th Century which concludes in 1994. Post-1994 slightly more naturalistic — and uglier — images are provided by Major League Baseball Properties.

Sadly, where this online exhibit succeeds as information design it fails as information architecture. The search engine is very clumsy. One cannot compare specific teams or specific years. For example, earlier this season the Boston Red Sox and Chicago Cubs played in throwback 1918 uniforms. There is no way to compare Red Sox / Cubs / 1918 / 2011. For larger searches, one cannot show more than three images in a row, or more than eighteen in a page. Please, BBHOF, publish an API.

The relaunch has given us the opportunity to update our portfolio and present the popular dD Orrery on its own page. For the latter we’ve created free Mac and Windows screensavers you can download.

Let us know what you think.

The Guggenheim Museum recently launched an interactive timeline to accompany its new exhibition, The Great Upheaval: Modern Art from the Guggenheim Collection, 1910-1918. This colorful interactive map and timeline highlights the era’s artists, artist groups, exhibitions, performing arts, publications, artworks, historic events, and cultural movements.  Select one of these categories, then scroll across to choose a particular year.  Corresponding dots appear on the map above, and clicking on a dot displays a lightbox overlay with more information (see detail above).  Overall, the timeline works from linear, drill-down perspective: choose a cultural activity, year, and sample activity within that year.  Navigating the “Selected Artworks” category gives users the most detail (as expected), with an image of the artwork, and links to the artist’s biography and to an essay about the artwork, both housed in the pre-existing online collection on guggenheim.org– a nice way to leverage and highlight what’s already available.  Discovering these individual nuggets is a little like going on a treasure hunt.  The user seeks and finds individual gems scattered throughout.

At the same time, though, this interactive is weak in terms of  providing an integrated picture of the era overall.  Part of what makes studying an artistic era so exciting is the chance to discover connections: between artistic disciplines, or between the arts and historic events.  The timeline misses this opportunity by forcing users to choose only a single category (the checkbox-like bullet next to each category is misleading).  Additionally, once you’ve selected a dot on the map, dots of other colors at the bottom of the lightbox (see above) are indictors of simultaneous activities, but these are only visual cues and not links.  Investigating these further means selecting a different category for that year and clicking through individual dots to eventually make the connection yourself.  Allowing for multiple category selection and including crosslinks to other categories at the lightbox level are straightforward ways to make the pieces of the timeline more tightly integrated, showing that the whole is greater than the sum of its parts.

The Great Upheaval is on display through June 1, 2011.

The broader question of how to measure success is one that we raise with our own clients at the beginning of every project, as this helps us figure out the organization’s priorities and focus.  Definitions of success range from trackable statistics (“more users will see the catalog”) to anecdotal assessment (“employees will complain less about using it”).

There is no one-size-fits-all approach to measuring success.  Moreover, with the exception of online survey tools like Zoomerang or SurveyMonkey, which can be used assess usability and satisfaction, most tools today are designed to measure success from a business or technical staff’s perspective, rather than the users’.  Google’s researchers recognized this problem in assessing their own applications and developed the HEART metrics framework, a method of measuring user experience on a large scale.

The HEART framework is meant to complement what Google calls the “PULSE metrics” framework where PULSE stands for: Page views, Uptime, Latency, Seven-day active users (i.e., number of unique users who used the product at least once in the last week), and Earnings– clearly all stakeholder and/or IT concerns.  While these statistics are somewhat related to the user’s experience (which pages get looked at, which items get purchased), these can be problematic in evaluating user interface changes:

[PULSE metrics] may have ambiguous interpretation–for example, a rise in page views for a particular feature may occur because the feature is genuinely popular, or because a confusing interface leads users to get lost in it, clicking around to figure out how to escape.  A count of unique users over a given time period, such as seven-day active users, is commonly used as a metric of user experience.  It measures overall volume of the user base, but gives no insight into the users’  level of commitment to a product, such as how frequently each of them visited during the seven days.

The HEART metrics framework offers a way to more precisely measure both user attitude and behavior, while providing actionable data for making changes to a product’s user interface.  These include the following, which I’ve described very briefly here:

1. Happiness. This metric is concerned with measuring the user’s attitude toward the product, including satisfaction, visual appeal and the likelihood that the user will recommend the product to others.  The use of a detailed survey as a benchmark and then later as changes are implemented will cover this.
2. Engagement. This measures a user’s level of involvement, which will depend on the nature of the product.  For example, involvement for a web site may be as simple as visiting it, while involvement for a photo-sharing web application might be the number of photos uploaded within a given period. From a metrics standpoint, involvement can be assessed by looking at frequency of visits or depth of interaction.
3. Adoption and Retention. These metrics explore behavior of unique users more in detail, going a step beyond the seven-day active users metric.  Adoption metrics track new users starting within a given period (e.g., number of new accounts opened this month), while retention looks at how many of the unique users from the initial period are using the product at a later period.
4. Task Success.  Successful completion of key tasks is a well-known behavioral metric that relates to efficiency (time to complete at task) and effectiveness (percent of tasks completed).   This is commonly tracked on a small-scale through one-on-one usability tests, but can be expanded to web applications by seeing how closely users follow an optimal path to completion (assuming one exists), or by using A/B split or multivariate testing.

But these metrics are not helpful on their own.  They must be developed in the context of the Goals of the product or feature, and related Signals that will indicate when the goal has been met.  The authors admit that this is perhaps the hardest part of defining success, since different stakeholders may disagree about project goals, requiring a consensus-building exercise.

From my perspective, there is also the additional challenge of clients having both the forethought and resources available to track these metrics in the first place.  In many cases, measuring success requires a benchmark or baseline for comparison.  Without this in place, the new design itself must serve as a benchmark for any future changes.

How do you organize a collection of over one hundred, decentrally-managed micro-sites into a single, cohesive entity that offers a consistent user experience from the home page down to the lowest level?  This was the key issue facing the University of Southern Maine‘s site redesign, and Dynamic Diagrams was happy to help.  The university had plans to migrate the site to a new content management system, and recognized the importance of creating a new architecture to provide both a better experience for site visitors as well as a standardized approach to organizing content for micro-site owners.

After completing a rigorous research and analysis phase that included stakeholder interviews, an inventory of over 5,000 pages (you may have seen the earlier Post-It Note output here), user focus groups, and an online survey, we created a new information architecture (see above) and a set of core wireframes (page schematics) to illustrate the new high-level and page-level user experience, respectively.  The new architecture puts the user’s needs front-and-center by presenting all related information together (e.g., degree information that was previously scattered across the course catalog, academic department, and university system database), rather than forcing users to navigate multiple silos of information.   The architecture and wireframes will guide the development of the site’s new look and feel, which is now in progress.   Look for the new design to be launched later this year.

That a user had “the whole world of knowledge at his disposal” was one of those absurdities like the belief that ultimately computers would think–it will be time to say so when a computer makes an ironic answer. “The whole world of knowledge” could be at one’s disposal only if one already knew a great deal and wanted further information to turn into knowledge after gauging its value.

Information isn’t knowledge. This fact points to a certain friction in the terms we use in our practice. Most often, an information architect really is concerned with information. The goal is to help individuals locate information in a context that helps them gauge its value. An information designer, however, is more focused on knowledge. The designer seeks to communicate ideas within a dataset. I wouldn’t advocate a change in terms. Knowledge designer sounds hopelessly pretentious. But the distinction between the two practices is important.