Janus Boye (of CMSWatch) just published an article called The trouble with portal dashboards… in Enterprise Information, in which he discusses the usability problems of enterprise portals.
Janus identifies the essential problem of current portal design approaches built on flat tiles: Today most organisations blindly adopt the default ‘building block’ approach to layout found in enterprise portals — a relic from the early days of public internet portals. But users complain that while such an interface may look slick in early sales demonstrations, in production it typically only facilitates work for technically adept super-users. The occasional user easily gets confused and frustrated working with a cluttered screen of little boxes showing many different portlets. Getting adequate value from the portal typically requires substantial training.
This is a good snapshot of the long term weaknesses of a flat portal user experience, what Janus calls “the default ‘building block’ approach” [emphasis mine]. It strongly parallels my recent post outlining some of the inherent usability weaknesses of portals, and is a great lead in for the building blocks. (Note: Janus uses the term building blocks differently.)
In another highlight worth mentioning Janus identifies six distinct types of portals, referring to them as use cases. I think of these as types of information environments. The difference is a semantic one that’s shaped by your context for the term portal. Janus is speaking from the business perspective, thus his focus on the business problem solved by each type of portal.
Dynamic web publishing; the simplest use case and a common entry point for portal developers
Self-service portal; enabling staff or customers to help themselves and obtain service on their terms
Collaboration portal; enabling dispersed teams to work together on projects
Enterprise intranet; helping staff work more efficiently, often via multiple specialised portal applications
E-business portal; enabling enterprises to extend commercial information and services to external trading partners, suppliers and customers
Enterprise integration; linking systems to achieve greater efficiency and agility.
What’s important to understand from this list is that the default flat tiles approach underlying these different environments is the same, and so are the resulting usability problems, with their attendant business costs. The building blocks will support all six portal types handily.
In a recent comment, Joe Sokohl asked about usability in portals, specifically if designing with the building blocks improves usability.
Here’s his question: One topic I hope you cover is any usability testing results you might’ve come up with. How usable is this approach, for example? How successfully are execs using these tiles? I think it’s a neat way to shortcut the dev process, too.
Portal user experiences suffer from a number of inbuilt usability weaknesses that the building blocks are designed to eliminate. For instance, flat tile schemes assume all tiles are structurally the same, and that they have no relationship to any other tiles. This makes all tiles of equal importance to the portal’s information architecture. [Welcome to Flatland…] Yet any designer or information architect addressing diverse user needs and goals knows that the priorities of users make some content more important than others, and that the structure of the user experience should reflect these priorities and any necessary relationships.
Flatness also hampers interaction design and information design, obstructing the establishment of good visual flows and pathways leading the eye to the right areas of a portal page. The eye and brain (visual system) interprets the features and “terrain” of the current field of view, a process that occurs when users look at a portal page. The absence of conceptual differences between tiles in flat portal experiences makes it difficult to create supporting visual cues that direct the eye to the appropriate features of the field of view. Effectively, it’s a featureless landscape lacking depth that the eye and brain cannot easily interpret, an effect similar to driving through whiteout conditions (an extreme example).
Further, tight scheduling and budget realities often mean design teams inherit the default user experience aspects of tiles from the portal platform, with limited or no leeway for change. In these situations cases, the default designs and navigation become a technology constraint, instead of a point of departure, as intended!
The most common solution to these inbuilt weaknesses is to rely on the contents of tiles to solve all three problems at the same time: indicate structure and relationships, lead users to the right area of the page, and overcome the user experience design constraints of the technology platform or presentation framework.
This is the wrong approach, for many reasons. It counts on content to do the job of structure. It contradicts the purpose of independent tiles. It decreases usability overall, because in many portals, syndicated tiles appear in many different places and contexts where the relationships assumed and expressed in their content are neither present nor valid.
By contrast, the goal of the building blocks is to provide a simple vocabulary for creating useful structures and relationships obviating the need to overload tiles. Using the building blocks eliminates these sorts of emergent usability problems rooted in the weaknesses of flat portal user experiences.
Time and space allowing, I’ll talk more about some of the usability findings in the case study / example material that’s planned for the series. A brief note about executive dashboards, as opposed to portals: Dashboards often serve very small user groups, which means that usability concerns and findings end up being closely tied to the usage patterns and preferences of that small group (sometimes a single user). In several instances, after some very puzzling usability feedback, we discovered the preferred way of using the dashboard was to have an assistant print out a page assembled from a complex set of tiles structured with the building blocks.
Hurray for volunteer publishing: Next week, Boxes and Arrows, is publishing the first installment of a series of articles on information architecture for portals and tile-based user experiences. It introduces a system of reusable building blocks that provides consistent structure for and lowers the costs of designing and maintaining portals.
The building blocks are a portal design toolkit I developed while working on several executive dashboard projects in close succession. I’ve used the building block system in portals, Web applications, business intelligence tools, dashboards, and content management systems: essentially any design relying on or incorporating tiles or portlets. The building blocks play nicely with RIA, AJAX, and other evolving user experience and development approaches, because they address information architecture concerns without requiring any specific technology or platform.
Follow up articles will explain the building blocks in detail, and how to use them quickly and efficiently.
The series will cover:
Basic principles and assumptions
Guidelines for assembling blocks into larger units
Modular building blocks of all sizes (Containers)
Modular navigation components (Connectors)
Standardized Convenience Functionality for blocks
Common Utility Functionality
Suggested metadata attributes for blocks
Assuming the response to the first pieces is positive (be sure to read and comment!), we’ll provide a case study, and create a set of supporting materials to make it easy to use the building blocks for your own projects. The goal is to offer a complete package for someone who needs help creating an effective and scalable user experience for a portal or tile-based environment.
Aside from being a resource for the design of portal user experiences, the building blocks are the first attempt (disclaimer: that I know of…) at creating a reusable IA design framework for a common type of business problem / user experience / information environment. It’s not as broad in scope as Jesse Jame Garrett’sVisual Vocabulary, because it works at a more granular level of detail, but it should support design efforts in a wide variety of settings.
Those who enjoyed the 2005 IA Summit in Montréal might remember I presented a poster on the building block idea. The poster is essentially a preview of what the series will cover fully.
And it’s a perfect excuse to try out Rashmi’s new Slideshare service.
I’ll be on holiday (in Jamaica: did someone say Red Stripe…?) next week, but will try to log on to catch up on comments and questions.
Hope everyone enjoys the articles. Update The first article The Challenge of Dashboards and Portals is live as of December 14th
I’m presenting for the Taxonomy Community of Practice web seminar today. I’ll be talking about a long-term, enterprise-level strategy and design engagement for a financial services client, sharing work that combines information architecture and taxonomy efforts over the past year.
The agenda for the call includes several other speakers; it should be a strong showcase of information architecture and taxonomy work from different settings.
If you’d like to listen, some details are below. Registration and more information is available from www.earley.com/events.htm
Date and time: Friday, December 1st, 2006 — 2:00 to 3:30 PMEDT
Duration: 90 minutes
Cost: $50 per attendee
Register for the session (you will receive dial-in instructions and slides the day before the call) Description:
User Experience design is often thought of as distinct or different from taxonomy design. What are good IA practices and how do they influence taxonomy design? In this session you’ll hear from three experienced IA’s who will share specific examples from their organizations and consulting projects that will illustrate principles that you can apply in your taxonomy projects.
In this session, hear about:
a user experience design effort that combines information architecture and taxonomy approaches for a major financial services client
specific experiences applying IA with Compaq and HP and “business taxonomies” — taxonomies that live within strict business limitations