archive.Joe Lamantia.com

Quick update on spring conferences: I’m speaking at Blogtalk 2008 in Cork (Ireland) February , and the 2008 IA Summit in Miami (SOBE – it’s sort of the US, but not entirely…) in April. This is my first Blogtalk conference! I’m looking forward to meeting some new people and getting closer to the social software community.

At Blogtalk, my session is titled “The DIY Future: What Happens When Everyone Designs Social Media? Practical suggestions for handling new ethical dilemmas”

Here’s an excerpt of the description:

Both traditional design professionals, and the growing ranks of DIY designers, must be prepared to address the increased ethical complexity of the integrated experiences of the future. This presentation will share practical suggestions for the design and architecture of ethically sound social media using familiar experience design methods and techniques.

Full details for the session and the rest of the program are available at the Blogtalk site. I’m following Salim Ismail’s opening keynote. (Note to organizers: No pressure in that at all, thanks…)

At the IA Summit, my session is “Effective IA For Enterprise Portals: The Building Blocks Design Framework”. If you’ve been reading the series of articles on the building block in Boxes and Arrows, the talk will tie in nicely. If you’re new to the building blocks or they’re outside your problem space, consider this a great look at a design framework in action.

Here’s an excerpt of the description:

Portal design efforts often quickly come to a point where their initial information architecture is unable to effectively accommodate change and growth in types of users, content, or functionality, thereby lowering the quality of the overall user experience. This case study style presentation will demonstrate how a framework of standardized information architecture building blocks solved these recurring problems of growth and change for a series of business intelligence and enterprise application portals.

Full details for the session are available from the IA Summit website.

Both conferences look good. Make sure to say hello in the hallway!

Boxes and Arrows just published Part 4 of the Building Blocks series, Connectors for Dashboards and Portals.

We’re into the home stretch of the series – just two more to go!
Stay tuned for a downloadable toolkit to support easy use of the building blocks during design efforts.

Boxes and Arrows has published part 3 of the Building Blocks series, describing the Container blocks in detail. Next in the series is part 4, which describes the Connectors in the building block system in detail.

If you’re working on a portal, dashboard, or tile based design effort of any kind, the building blocks readily serve as a common language and structural reference point that allows effective project communication across traditional discipline boundaries. These two articles in tandem (parts 3 and 4) provide details on how the Building Blocks can provide a strong, flexible, and scalable usr experience and information architecture framework for the long term.

My current plan is to release a toolkit at approximately the same time as part 4 of the series. Part 4 is in the editing stage now, so this a good time to ask readers for suggestions on what should be part of the toolkit, and what form it should take. Suggestions?

Boxes and Arrows just published part two of the Portal Building Blocks series – Introduction to the Building Blocks. This second installment covers the design concepts behind the portal building blocks system, and guidelines on how to flexibly combine the blocks into a well-structured user experience.

If you are working on a portal, dashboard, widget, social media platform, web-based desktop, or any tile-based design, this series should help clarify the growth and usability challenges you will encounter, as well as provide a possible solution, in the form of a simple design framework that is platform and vendor neutral.

Stay tuned for the third installment in the series, due out shortly!

The Lessons From Failure Series (curated by Christian Crumlish) kicked off today at Boxes and Arrows, leading with my meditation on being an entrepreneur and what it means to face failure as a member of a rigidly defined society, titled It Seemed Like The Thing To Do At The Time. Stay tuned for three further installments from talented fellow panelists.

Also, look for part two of my series on designing healthy user experiences for portals using the IA Building Blocks in early July. Part one – The Challenge of Dashboards and Portals – describing the structural and usability weaknesses of flat architectures, was published in December.

Many thanks to the hard working volunteers at B+A for creating a forum for these ideas and the community around them!

I’ve created a suggested (and highly original) tag for bookmarking items related to the building blocks:

ia_building_blocks

I’ve tagged a few items on del.icio.us – my default bookmarking service – and will monitor tag streams from some of the other bookmarking services.
http://del.icio.us/tag/ia_building_blocks

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.

They are:

• 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’s Visual 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 Montreal 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 working on a portal project at the moment for a healthcare client, so I’ve heard a great deal about how the concept of ‘portal’ is so diluted as to be effectively meaningless. Following a series of surprisingly muddled conversations with technologists, business types, and end users representatives around the concept for this new portal, I realized that much of the hand-wringing and confusion comes from simple lack of perspective – on the different perspectives represented by each viewpoint. Ambiguity or disagreement about which perspective is the frame of reference in any given discussion is the biggest source of the confusion and friction that makes these projects needlessly difficult.
There are (at least) three different perspectives on the meaning of the term portal.
To technologists and system developers, a portal is a type of solution delivery platform with standard components like authentication, an application server, integration services, and business logic and presentation layers that is generally purchased from a vendor and then customized to meet specific needs. Examples are Plumtree, BEA, IBM, etc.
To users, a portal is a single destination where it’s possible to obtain a convenient and – likely, though not always – personalized combination of information and tools from many different sources. Some examples of this sense of the term include Yahoo, MSN, and a well-developed intranet.
To a business, a portal is a bounded vehicle for aggregating information and tools to address diverse constituent needs in a coordinated and coherent way, with lowered management and administration costs realized via framework features like personalization, customization, and role-based configuration.
One case where all three of these frames of reference intersect is with Executive Dashboard projects. A dashboard is a portal in all three of these senses (unless it happens to rest on a different architecture / technology stack, in which case I maintain that it’s something else, so as an IA it’s prudent to keep in mind the differing implications and assumptions associated with each perspective while dealing with their representatives.

Related posts: