archive.Joe Lamantia.com

Endeca invites customers, partners and leading members of the broader search and discovery technology and solutions communities to meet annually, and showcase the most interesting and exciting work in the field of discovery.  As lead for the UX team that designs Endeca’s discovery products, I shared some of our recent work on patterns in the structure of discovery applications, as well as best practices in information design and visualization that we use to drive product definition and design for Endeca’s Latitude Discovery Framework.

This material is useful for program and project managers and business analysts defining requirements for discovery solutions and applications, UX and system architects crafting high-level structures and addressing long-term growth, interaction designers and technical developers defining and building information workspaces at a fine grain, and

There are three major sections: the first presents some of our tools for identifying and understanding people’s needs and goals for discovery in terms of activity (the Language of Discovery as we call it), the second brings together screen-level, application level, and user scenario / use-case level patterns we’ve observed in the applications created to meet those needs, and the final section shares condensed best practices and fundamental principles for information design and visualization based on academic research disciplines such as cognitive science and information retrieval.

It’s no coincidence that these sections reflect the application of the core UX disciplines of user research, information architecture, and interaction design to the question of “who will need to encounter information for some end, and in what kind of experience will they encounter it”.  This flow and ordering is deliberate; it demonstrates on two levels the results of our own efforts applying the UX perspective to the questions inherent in creating discovery tools, and shares some of the tools, insights, templates, and resources we use to shape the platform used to create discovery experiences across diverse industries.

Session outline

Session description

“How can you harness the power and flexibility of Latitude to create useful, usable, and compelling discovery applications for enterprise discovery workers? This session goes beyond the technology to explore how you can apply fundamental principles of information design and visualization, analytics best practices and user interface design patterns to compose effective and compelling discovery applications that optimize user discovery, success, engagement, & adoption.”

The patterns are product specific in that they show how to compose screens and applications using the predefined components in the Discovery Framework library.  However, many of the product-specific components are built to address common or recurring needs for interaction with information via well-known mechanisms such as search, filtering, navigation, visualization, and presentation of data.  In other words, even if you’re not using the literal Discovery Framework component library to compose your specific information analysis workspace, you’ll find these patterns relevant at workspace and application levels of scale.

The deeper story of these patterns is in demonstrating the evolution of discovery and analysis applications over time.  Typically, discovery applications begin by offering users a general-purpose workspace that satisfies a wide range of interaction tasks in an approximate fashion.  Over time, via successive expansions in the the scope and variety of data they present, and the discovery and analysis capabilities they provide, discovery applications grow to include several different types of workspaces that individually address distinct sets of needs for visualization and sense making by using very different combinations of components.  As a composite, these functional and informationally diverse workspaces span the full range of interaction needs for differing types of users.

I hope you find this toolkit and collection of patterns and information design principles useful.  What are some of the resources you’re using to take on these challenges?

A quick rundown on my fall speaking schedule so far.

First up is BlogTalk 2009, in Jeju, Korea on September 15 and 16. There I’ll be talking about ‘The Architecture of Fun’ – sharing a new design language for emotion that’s been in use in the game design industry for quite a while.  [Disclosure: While it’s a privilege to be on the program with so many innovative and insightful social media figures, I’m also really looking forward to the food in Korea ]

Next up is EuroIA in Copenhagen, September 26 and 27.  For the latest edition of this largest gathering of the user experience community in Europe, I’ll reprise my Architecture of Fun talk.

Wrapping up the schedule so far is the Janus Boye conference in Aarhus, November 3 – 6.  Here  I’m presenting a half-day tutorial titled Designing Information Experiences.  This is an extensive, detailed tutorial that anyone working in information management will benefit from, as it combines two of my passions; designing for people, and using frameworks to enhance solution scope and effectiveness.

Here’s the description from the official program:

When designing for information retrieval experiences, the customer must always be right. This tutorial will give you the tools to uncover user needs and design the context for delivering information, whether that be through search, taxonomies or something entirely different.

What you will learn:
•    A broadly applicable method for understanding user needs in diverse information access contexts
•    A collection of information retrieval patterns relevant to multiple settings such as enterprise search and information access, service design, and product and platform management

We will also discuss the impact of organizational and cultural factors on design decisions and why it is essential, that you frame business and technology challenges in the right way.

The tutorial builds on lessons learned from a large customer project focusing on transforming user experience. The scope of this program included ~25 separate web-delivered products, a large document repository, integrated customer service and support processes, content management, taxonomy and ontology creation, and search and information retrieval solutions. Joe will share the innovate methods and surprising insight that emerged in the process.

Janus Boye gathers leading local and international practitioners, and is a new event for me, so I’m very much looking forward to it.

I hope to see some of you at one or more of these gatherings that altogether span half the world!

September in Amsterdam approaches: in addition to the inevitable mix of clouds, rain, more rain, and tiny slivers of sunlight, September means EuroIA 2008, where yours truly will speak about design frameworks.

In case you can’t make the conference, here’s a text only summary of my talk. Pictures will follow the presentation – promise!

It’s a DIY Future
The Web is shifting to a DIY [Do It Yourself] model of user experience creation, one where people assemble individual combinations of content gathered form elsewhere for expressive, functional, and (many) other purposes. The rapid growth of widgets, the resurgence of enterprise portals, the spread of identity platforms from social network destinations to blogging services, and the rapid increase in the number of public APIs syndicating functionality and data, are all examples of the DIY shift.

Architects of the Future
For design professionals, the defining characteristic of DIY future is co-creation: the participation of a broad spectrum of people in creating experiences. In this new world, the role of designers is to define the tools co-creators use to assemble experiences for themselves and others. These tools will increasingly take the form of design frameworks that define the modular components of familiar structures such as social networks, functional applications, collaboration platforms, personalized dashboards, and management consoles.

Why Frameworks?
Frameworks are the future for three reasons. First, everyone can create sophisticated information structures now, and designers no longer serve as a gateway. Second, the definition of frameworks allows designers to continue to provide valuable services and expertise in a cost effective manner: It’s something designers can sell in a commodified digital economy. Third, designers have an good combination of human insight and architecture design skills; this hybrid way of thinking can serve as a differentiator and strength.

One example of the sort of design framework information architects will create more of in the DIY future is the Portal Building Blocks system described herein. Providentially, this design framework addresses many of the problems inherent in the current architectural schema for DIY self-assembled experiences.

History Repeats Itself: The Problem With Portals
The rise and fall of the Web 1.0 portal form offers a useful historical lesson for creators of the new generation of design frameworks underlying DIY self-assembled experiences.
Despite early promises of utility and convenience, portals built with flat portlets could only grow by expanding horizontally. The resulting experience of low-density information architectures was similar to that of navigating postwar suburban sprawl. Like the rapid decline of many once-prosperous suburbs, the inconvenience of these sprawling collections of portlets quickly overwhelmed the value of the content they aggregated.
The common problem that doomed many very different portals to the same fate was the complete lack of any provision for structure, interaction, or connection between the self-contained portlets of the standard portal design framework.
Looking ahead, the co-created experiences of the DIY future will repeat this cycle of unhealthy growth and sprawl – think of all those apps clogging your iPhone’s home screen right now – unless we create design frameworks that effectively provide for structure, connection, and interaction.

The Building Blocks – An Example Design Framework
The building block framework is meant to serve as a robust architectural foundation for the many kinds of tools and functionality – participatory, social, collaborative – that support the vision of two-way flows within and across the boundaries of information structures. This means:

• Allow for rapid growth and structural change
• Establish a common language for all co-creation perspectives
• Encourage construction of scalable, reusable structures
• Create high-quality user experiences
• Enable sharing of assets across boundaries
• Enhance social dynamics, such as 2-way conversation flows

The Building Blocks framework defines two types of information architecture components in detail – building blocks (or Containers), and navigation components (or Connectors) – as well as the supporting rules and guidelines that make it possible to assemble complex user experience architectures quickly and effectively.

The Containers and Connectors specifically provide for structure, interaction, and connection at all levels of the information environment; from the user experience – visual design, information design, interaction design, information architecture – to functionality, metadata, business rules, system architecture, administrative processes, and strategic governance.
Case Study: Evolution of an Enterprise Portal Suite

The Building Blocks began life as an internal tool for lowering costs and speeding design during the course of sustained portal work done for a Fortune 100 client. Over a span of ~24 months, the Building Blocks provided an effective framework for the design, expansion, and eventual integration of nearly a dozen distinct portals.

The design framework evolved in response to changes in the audiences, structures, and contents of portals constructed for users in different countries, different operating units, and several organizational levels.
The portal suite went through several stages of evolution and growth:

• Experimentation
• Rapid expansion
• Consolidation & integration
• Stability and continuity

Lessons In Designing Frameworks
Successful co-created experiences – Flickr (commercial) and Wikipedia (non-commercial) – combine deliberate top-down architecture and design with emergent or bottom-up contribution and participation in a new kind of structure Kevin Kelly calls the “hybrid”. Frameworks support hybrids!

Hope to see many of you in Amsterdam!

I’ve posted slides for my recent Effective IA For Enterprise Portals presentation at the IA Summit in Miami. Portals are not a traditional space for user experience practitioners, so many thanks to the packed house that turned out, and stayed as we both started late to accommodate the crowd, and then ran long.

These slides include a substantial amount of case study and example material that I didn’t cover directly in the talk. For the repeat session on Sunday, I showed additional examples beyond those included here in the starting slides.

Stay tuned for a more detailed writeup of both published and unpublished example material – one that shows the building blocks in action at all levels of a multi-year portal effort from initial strategy through design and into governance / evolution – in part six of the Building Blocks series running in Boxes and Arrows, due out once the post-summit flurry settles down.

Boxes and Arrows just published Enhancing Dashboard Value and User Experience, part 5 of the building blocks series that’s been running since last year. This installment covers how to include high-value social and conversational capabilities into portal experiences built on top of architectures managed with the building blocks. Enhancing Dashboard Value and User Experience also provides an explicit user experience vision for portals, metadata and user interface recommendations, and as tips on making portals easier to use and manage / administrate.

Thanks again to all the good people who volunteer their time to make Boxes and Arrows such a high quality publication!

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!

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: