Getting a Form’s Structure Right: Designing Usable Online Email Applications

by:   |  Posted on

I started writing this article with an emphasis on the financial domain. I then realized that I would like to broaden the focus because my findings are also applicable to a general domain like email account registrations, for example. In this article, I would like to take a simple example of how users register for an email account online. For a first timer, is the transition from a real world of letter writing to the online medium easy? And for a frequent user, is he or she motivated enough to create an email account with another service provider?

Yes, this is for all of you out there—my fellow usability practitioners, information architects, designers, managers, project leads, editors, and people who are looking to develop their UX practice.

In the modern family, where often both parents are working full-time and the children are involved in many after-school activities, people may only have a few minutes to spare on an important task during the day. And it’s the Internet that supposedly helps people achieve this. But do we, as designers and usability practitioners, always help them do it? I say, “No.”

Just the other day, a friend of mine begins to complain of the spam mails that she receives everyday. “I have two separate email ID’s to keep myself away from such mails—one for official purposes and the other for my junk emails. But even my official ID seems to be flooded with these emails. So I found myself moving to another email service provider. Again, I found myself grappling with the registration process.”

There are three people who determine success of a web-based form: the usability practitioner, the designer, and the user (Image 1). Taking a simple everyday example like an email service, I aim to discuss the various aspects that lead to a great forms structure.

Image 1: Success of a web-based form requires involvement of a usability practitioner, designer, and user.

There are a million websites out there. There are a million email service providers out there. How do you ensure that you gain the right audience to join your service? What are those factors that will help users move ahead and become your loyal customer? Part of the answer has to do with the first step: REGISTRATION!

In the first part of this series, I will focus on the basic issues that a usability practitioner must address to create a usable web-based form:

  1. Affordance
  2. Orientation
  3. Chunking

1. Affordance: The Lure

We all know how grueling and tedious a registration process can be. Therefore, we need to ensure that our sites adequately “lure” users into the process. To do this successfully is not just a matter of providing the right cues, but how and where we provide them.

Coming from the real world

Every online form was created keeping the real world in mind. We all once began filling in forms in real life before we began moving to the online medium of getting things done quicker.

Email service providers must allow for a smooth transition from a real world scenario to the internet, for those who are petrified of it. Users should know the advantages of the service provided as compared to the real world scenario of letter writing. Why would users move to your service when they can just write a letter? What are the advantages of sending an email? Is it quick? It is easy? These issues should be addressed upfront to ensure that they are lured forward.

None of the websites that I reviewed follow this practice effectively.

Entry points

An entry point to an application must be clear and appropriate to the specific needs of the user. For example, let’s say a user visits a website to send out an email to a distant relative. He or she has never used a web-based email service before. Not knowing that he/she needs to register, they would look for a direct cue to send out an email. Where do you think this user would look for a cue? This is where you need to perform a quick goal-task analysis. Let’s consider a scenario:

A first timer enters the website to send out an email. This user is hauled because he/she is unsure of their next step.

Let’s have a look at Gmail, our most used email provider. Most websites that I reviewed allow you to register. But users are not lured into it. As a first time user of a website, they need to know the benefits of registering clearly, up front. Gmail does a good job of this (Image 2).

Users often hate to register. Therefore, as usability practitioners, we need to tell them of the benefits of registration when they enter a website for the first time.

Image 2: A good example of enticing users to register online by clearly listing the benefits up front.

Service/Product comparison

Remember, your users are watching your competitors as well. So if you aren’t that big in the market, how exactly would you think big? Compare your features with that of your competitors to formulate your strengths over the others in the market. Let’s see how Bluebottle effectively does this (Image 3).

Image 3: Bluebottle’s website allows users to take a peek at service comparisons. Users also have the freedom to view a detailed comparison.

Online benefits

It is important to inform the user up front of what they will gain after registering. It’s a competitive world out there and users must and should know what the website is selling them. This affirms the brand’s identity and responsibility to gain customers online. A basic cue reassuring users about the benefits helps build trust which encourages them to use your services. As shown in image 2, Gmail clearly provides the online benefits.

Another clever way to entice them is to provide a view of what the service looks like once they have registered or applied. In this case, it would be ideal to show users on the homepage a view of what their personal landing page (the inbox) would look like once they have registered.

None of the websites that I reviewed follow this practice rightly.

Security

It is essential that users know that the information they are entering will be secure. A basic “Lock” or “Key” icon would do the trick. Also, providing them with security information and its benefits improves customer loyalty and trust. With the case of Yahoo, the website uniquely utilizes this feature to grab users towards their secure service (Image 4).

Image 4: Providing a security message increases loyalty which moves users towards registering.

Taking a tour

Before users move ahead to encounter a form, it is necessary to tell them why they need to do it and most importantly how they need to do it. Again, taking the same examples forward, if you look at the example below, you will see how AIM Mail allows users to take a tour (Image 5). This also gives an edge to its competitors as they are showing them of what’s inside even before registering.

Image 5: The website allows users to take a tour before registering.

User’s path forward

This doesn’t just end with the benefits. Users have to be told where to go after they have been guided. All websites do provide a way to move ahead. But I specifically want to use an example that can show improvement in terms of placement of this cue, which is most important while users are making a decision.

We love Gmail. But we sometimes wish it were always right.

Provide users with a clear path forward AFTER you are done enticing them with the meat.

Image 6: The website must provide a clear path forward after enticing users with the benefits.

Consistent design

As users transition from the homepage to the form, it is important that the design of the pages remain consistent. Any small change in the design or layout could affect their performance and decrease the overall experience.

Most websites get this right. But we can still look for improvement. Let’s have a look at the example below (Image 7). Here, as users move from the landing page to the form, we see significant changes in the layout and the visual design.

Image 7: The design of the page is inconsistent with the previous page.

An overview of what’s to come

As users enter the application, they need to know what to expect, however short it maybe. Therefore, throwing users directly into a form is not the best way to help them achieve their goals. Instead, the website must first provide users with an overview of what’s to come, including the application requirements and the next steps. This can be just a few lines telling them of the benefits, the things that are expected and an instant access to their emails soon after they are done.

Let’s have a look at Yahoo as an example (Image 8). It doesn’t do a perfect job. But it’s nearly there. All the information that the user is expected to provide during the registration process is described up front.

Image 8: The website informs users of what is expected of them while registering.

Lending a helping hand

We all know that people fumble along the way. Heck, sometimes I come across forms that I don’t understand. Therefore, it is essential to provide users with online help whenever needed.

For applications that drive business, a toll free number is essential as this brings in the revenue. But with the case of an email service provider, online help would suffice.

The visibility and location of the help link is equally important. By providing this, you can ensure that users not only find it quickly but also feel safe just by seeing it. This is also useful for first time users who are just transitioning from the real world of letter writing to the web world of emails.

None of the websites that I reviewed follow this practice successfully.

Language aid

There are websites that allow users to view their services in the language they choose. This should also be the case with web forms. Choosing the language of their choice gives them freedom and control. It also helps them move forward and register as they can be assured that the website caters to their needs as well.

Image 9: The website provides a way for users to set their language preferences.

Save and continue

Let’s say that the basic goal is to register online, so why not just save users’ information automatically as they proceed? A basic “Save and Continue” button would not only tell users that their information is automatically saved but it would also allow them to access the information if they need to resume the application later.

Now if your form is just a page long, you would obviously need a button that reads “submit” or “done”.

Most websites only follow the later.

2. Orientation

Form title

Ensuring that the page header follows a clear task flow from the preceding cue helps applicants orient themselves to the page. Most websites do this successfully. Let’s take a look at the example below (Image 10). Gmail follows a clear flow from one page to another, telling the users where they are at each specific point in time.

 

Image 10: The website provides a clear orientation feedback to the users as they move from one page to another.

Progress indicator

How ever short or long your application form maybe, users need to know their path ahead. A well-positioned progress indicator outlining the entire application process helps users see what lies ahead of them. There’s no use of providing the progress indicator on the left or the right of the form. Users need it up front as they do not tend to look to the left or the right of the form when they are entering information into an application. The best way to grab the user’s attention is to display the progress indicator on the top of every page of the application.

Let’s have a look at an example below (Image 11). This website has got the concept right. Yet, it can further deliver what’s best for users at this point. If you are providing users with a form, make sure that you tell them what each step entails. For example, Step 1: Enter your personal details. The example below does provide a progress indicator by telling users of the number of steps ahead. Yet, it fails to mention the step details.

Image 11: An example of a progress indicator. Though, the website needs to take a further step to provide the step details.

Progress feedback

More than 60% of web-based forms that I’ve encountered add in extra steps along the way, ones not included in the progress indicator. As applicants do not see all the steps up front, they are baffled when additional steps start appearing. When you tell users that the form entails 3 steps, don’t cheat them. Keep it to 3 however tempted you might be. With the example above (Image 11), users are probed into a number of pages, viewing the same orientation feedback for pages to come. Make sure that each step is provided on the same page. Moving them through pages and providing them with the same orientation feedback is only going to cause confusion.

3. Chunking

People perceive information more easily when related parts are grouped. This increases users’ efficiency and reduces reading effort. Chunking information into related parts helps users better understand information to navigate more effectively.

Headers

Ensure that you break the form into logical content groups and provide relevant headers for each information chunk. I have seen more than 90% of web forms that just provide the main header and then continue with about 20 questions on the same page. This can overwhelm a user. A quick way to organize information into groups would be to do a card sort with potential users of the application or even your co-workers. An example of effective chunking is found at Yahoo and My Way (Image 12 and 13).

A clever trick is to number the chunks to allow users to perceive how much is left and also to perceive that they are moving forward. It provides clear direction of a way forward.

Image 12: The form is well-chunked, with clear headers describing the grouped content.

Image 13: The form is well-chunked, with clear headers describing the grouped content.

Labels

Labels on individual pages within the application process must be related to the main header as well as its elements. For example, forms should display a clear and simple header along with related sub-headers. In the example above (Image 12 and 13), the sub-headers (labels) are clearly grouped with their header. You have personal information and password information separated with clear headers that define the structure. This provides clarity and direction.

Summary

As usability practitioners, we need to first and foremost understand the user’s intentions and expectations, in order to provide an online experience that accommodates them. The image below (Image 14) shows the mapping between the user’s intentions and expectations and the ways in which the usability practitioner can help accommodate them in order to ensure the ultimate success of online application forms.

 

Image 14: The usability practitioner ensures that the form’s structure accommodates the user’s mental model, experience, and expectations.

The journey of creating a successful online application form requires three people working in parallel: the usability practitioner, the designer, and the user. The usability practitioner needs to keep in mind the big picture. The designer needs to have a clear understanding of all the details that will go into the form’s structure. The user helps shape the overall approach to the application form and ensures its ultimate success.

You might agree, partially agree, or even disagree with my thoughts. You might even have something to add to this. Let’s hear your point of view. We are innovating, remember?

Coming up…

The next part of this article will focus on the designer’s role in the process of creating the form’s structure, layout, segmentation, widgets, color schemes, formatting, alignment, and consistency.


References

  • “GUI Design for Dummies” by Laura Arlov, 1997
  • “GUI Bloopers: Don’ts and Do’s for Software Developers and Web Designers” by Jeff Johnson, 2000

 

Information Architecture for Audio: Doing It Right

by:   |  Posted on

Content today is increasingly delivered by audio both online and in the real world. We have radio shows and newscasts, and in recent years, podcasts, audio books and navigation/car assistance systems have been added to the field. Audio is more emotional, as sound effects and acoustic atmosphere enhance content to help deliver its messages. It also affords users the opportunity to interact with content while their hands and eyes are busy (i.e. when doing physical work, driving, walking, etc).

However, the inclusion of audio often results in usability issues that make it difficult for users to access and understand content. That is why we need new tools to organize linear content like audio. Luckily, a wide range of techniques employed in information architecture, journalism, usability engineering and interface design are available. All that’s required is the knowledge to combine them effectively. This article presents a practical framework for designing and implementing audio-based content, such as podcasts.

“There is no reason to over-estimate the importance of writing and thereby under-estimate other technologies of information processing.” Harald Haarmann in History of Writing.

Continue reading Information Architecture for Audio: Doing It Right

On A Scale of 1 to 5

by:   |  Posted on

Where would we be without rating and reputation systems these days? Take them away, and we wouldn’t know who to trust on eBay, what movies to pick on Netflix, or what books to buy on Amazon. Reputation systems (essentially a rating system for people) also help guide us through the labyrinth of individuals who make up our social web. Is he or she worthwhile to spend my time on? For pity’s sake, please don’t check out our reputation points before deciding whether to read this article.

Rating and reputation systems have become standard tools in our design toolbox. But sometimes they are not well-understood. A recent post at the IxDA forum showed confusion about how and when to use rating systems. Much of the conversation was about whether to use stars or some other iconography. These can be important questions, but they miss the central point of ratings systems: to manage risk.

So, when we think about rating and reputation systems, the first question to ask is not, “Am I using stars, bananas, or chili peppers?” but, “what risk is being managed?”

 

What Is Risk?

We desire certainty in our transactions. It’s just our nature. We want to know that the person we’re dealing with on eBay won’t cheat us. Or that Blues Brothers 2000 is a bad movie (1 star on Netflix). So risk, most simply (and broadly), arises when a transaction has a number of possible outcomes, some of which are undesirable, but the precise outcome cannot be determined in advance.

 

Where Does Risk Come From?

There are two main sources of risk that are important for rating and reputation systems: asymmetric information and uncertainty.

Asymmetric information arises when one party to a transaction can not completely determine in advance the characteristics of the other party, and this information cannot credibly be communicated. The main question here is: can I, the buyer, trust you, the seller, to honestly complete the transaction we’re going to engage in? That means: will you take my money and run? Did you describe what you’re selling accurately? And so on.

This unequal distribution of information between buyers and sellers is a characteristic of most transactions, even in transactions where fraud is not a concern. Online transactions make asymmetric information problems worse. No longer can we look the seller in the eye and make a judgment about their honesty. Nor can we physically inspect what we’re buying and get a feel of its quality. We need other ways to manage our risk generated by asymmetric information.

The other source of risk is not knowing beforehand whether we’ll like the thing we’re buying. Here honesty and quality are not the issue, but rather our own personal tastes and the nature of the thing we’re buying. Movies, books, and wine are examples of experience goods, which we need to experience before we know their true value. For example, we’re partial to red wine from Italy, but that doesn’t mean we’ll like every bottle of Italian red wine we buy.

 

Managing Risk with Design

Among the ways to manage risk, two methods will be of interest to user experience designers:

  1. Signaling is where participants in a transaction communicate something meaningful about themselves.
  2. Reducing information costs involves reducing the time and effort it takes participants in a transaction to get meaningful information (such as: is this a good price? is this a quality good?).

Reputation systems tend to enable signaling and are best utilized in evaluating people’s historical actions. In contrast, rating systems are a way of leveraging user feedback to reduce information costs and are best utilized in evaluating standard products or services.

 It is important to note that reputation systems are not the only way to signal (branding and media coverage are other means, among others), and rating systems are not the only means of reducing information costs (better search engines and product reviews also help, for example). But these two tools are becoming increasingly important, as they provide quick reference points that capture useful data.

As we review various aspects of rating and reputation systems, the key questions to keep in mind are:

  1. Who is doing the rating?
  2. What, exactly, is being rated?
  3. If people are being rated, what behaviors are we trying to encourage or discourage?

 

Who is doing the Rating?

A random poll of several friends shows about half use the Amazon rating system when buying books and the other half ignore it. Why do they ignore it? Because they don’t know whether the people doing the rating are crackpots or if they have similar tastes to them.

Amazon has tried to counteract some of these issues by using features such as “Real Name” and “helpfulness” ratings of the ratings themselves (see Figure 1).

Figure 1

Figure 1: Amazon uses real names and helpfulness to communicate honesty of the review.

This is good, but requires time to read and evaluate the ratings and reviews. It also doesn’t answer the question, how much is this person like me?

Better is Netflix’s system (Figure 2), which is explicit about finding people like you, be they acknowledged friends or matched by algorithm.

Figure 2

Figure 2: Netflix lets you know what people like you thought of a movie.

Both these systems implicitly recognize that validation of the rating system itself is important. Ideally users should understand three things about the other people who are doing the rating:

  1. Are they honest and authentic?
  2. Are they like you in a way that is meaningful?
  3. Are they qualified to adequately rate the good or service in question?

The last point is important. While less meaningful for rating systems of some experience goods (we’re all movie experts, after all), it is more important for things we understand less well. For example, while we might be able to say whether a doctor is friendly or not, we may be less able to fairly evaluate a doctor’s medical skills.

 

What is being rated?

Many rating systems are binary (thumbs up, thumbs down), or scaled (5 stars, 5 chili peppers, etc.), but this uni-dimensionality is inappropriate for complicated services or products which may have many characteristics.

For example, Figure 3 depicts a rating system from the HP Activity Center and shows how not to do a rating system. Users select a project that interests them (e.g., how to make an Ireland Forever poster) and then complete it using materials they can purchase from HP (e.g., paper). A rating system is included, presumably to help you decide which project you should undertake in your valuable time.

Figure 3

Figure 3: The rating system on the HP Activity Center site: what not to do.

A moment’s reflection raises the following question: what is being rated? The final outcome of the project? The clarity of the instructions? How fun this project is? We honestly don’t know. Someone thoughtlessly included this rating system.

Good rating systems also don’t inappropriately “flatten” the information that they collect into a single number. Products and services can have many characteristics, and not being clear on what characteristics are being rated, or inappropriately lumping all aspects into a single rating, is misleading and makes the rating meaningless.

RateMDs, a physician rating site, uses a smiley face to tell us about how good the doctor is (Figure 4).

Figure 4

Figure 4: RateMDs.com rating system for doctors.

Simple? Yes. Appropriate? Perhaps not.

Better is Vitals, a physician rating site that includes information about doctors’ years of experience, any disciplinary actions they might have, their education, and a patient rating system (Figure 5).

Figure 5

Figure 5: The multi-dimensional rating system on Vitals.com.

While Vitals has an overall rating, more important are the components of the system. Each variable – ease of appointment, promptness, etc. – reflects a point of concern that helps to evaluate physicians.

When rating experiences, what is being rated is relatively clear. Did you enjoy the experience of consuming this good or not? Rating physical goods and products can be more complicated. An ad hoc analysis of Amazon’s rating system (Figure 6) should help explain.

Amazon's rating system

Figure 6: Amazon’s rating system is not always consistent.

In this example the most helpful favorable and unfavorable reviews are highlighted. However, each review is addressing different variables. The favorable review talks about how easy it is to set up this router, while the unfavorable review talks about the lack of new features. These reviews are presented as comparable, but they are not. These raters were thinking about different characteristics of the router.

The point here is that rating systems need to be appropriate for the goods or services that are being rated. A rating system for books cannot easily be applied to a rating system for routers, since the products are so entirely different in how we experience them. What aspects we rate need to be carefully selected, and based on the characteristics of the product or service being rated.

 

What behaviors are we trying to encourage?

Any rating of people is essentially a reputation system. Despite some people’s sensitivity to being rated, reputation systems are extremely valuable. Buyers need to know whom they can trust. Sellers need to be able to communicate – or signal based on their past actions – that they are trustworthy. This is particularly true online, where it’s common to do business with someone you don’t know.

But designing a good reputation system is hard. eBay’s reputation system has had some problems, such as the practice of “defensive rating” (rate me well and I’ll rate you well; rate me bad and I’ll rate you worse). This defeats the purpose of a rating system, since it undermines the honesty of the people doing the rating, and eBay has had to address this flaw in their system. What started out as an open system now needs to permit anonymous ratings in order to save the reputation (as it were) of the reputation system.

While designing a good reputation system is hard, it’s not impossible. There are five key things to keep in mind when designing a reputation system:

 

1. List the behaviors you want to encourage and those that you want to discourage

It’s obvious what eBay wants to encourage (see Figure 7). A look at a detailed ratings page shows they want sellers to describe products accurately, communicate well (and often), ship in a reasonable time, and not charge unreasonably for shipping. (Not incidentally, you could also view these dimensions as source of risk in a transaction.)

Figure 7

Figure 7: eBay encourages good behavior.

 

 

2. Be transparent

Once you know the behaviors you want to encourage, you then need to be transparent about it. Your users need to know how they are being rated and on what basis. Often a reputation is distilled into a single number — say, reputation points — but it is impossible to look at a number and derive the formula that produced it. While Wikinvest (Figure 8) doesn’t show a formula (which would be ideal), they do indicate what actions you took to receive your point total.

Figure 8

Figure 8: Wikinvest’s reputation system

Any clarity that is added to a reputation system will make your users happy, and it will make them more likely to behave in the manner you desire.

 

3. Keep your reputation system flexible

Any scoring system is open to abuse, and chances are that any reputation system you design will be abused in imaginative ways that you can’t predict. Therefore it’s important to keep your system flexible. If people begin behaving in ways that enhance their reputation but don’t enhance the community, the reputation system needs to be adjusted.

Changing the weighting of certain behaviors is one way to adjust your system. Adding ratings (or points) for new behaviors is another. The difficulty here will be in keeping everything fair. People don’t like a shifting playing field, so tweaks are better than wholesale changes. And changes should also be communicated clearly.

 

4. Avoid negative reputations

When possible, reputation systems should also be non-negative towards the individual. While negative reputations are important to protect people, negative reputations should not always be emphasized. This is specifically true in community sites where users generate much of the content, and not much is at stake (except perhaps your prestige).

Looking at our example above (Figure 8), Wikinvest uses the term “Analyst” (a nice, non-offensive term … if you’re not in investment banking), to mean, “this person isn’t really contributing much.”

 

5. Reflect reality

Systems sometimes fail on community sites when people belong to multiple communities and their complete reputations are not contained within any one of them. While there are exceptions, allowing reputations earned elsewhere to be imported can be a smart way to bring your system in line with reality and increase the value of information that it provides.

 

Conclusion

Our discussion of rating systems and reputation systems is certainly incomplete. We do hope that we’ve given a good description of risk in online transactions, and how understanding this can help user experience designers better manage risk via the design of more robust rating and reputation systems.

In addition, we’d like to begin a repository of rating and reputation systems. If you find any that you’d like to share, feel free to submit them at http://101ratings.com/submit.php.

Comics for Consumer Communication

by:   |  Posted on

The rising popularity of the comic as an internal communication device for designers has increased our ability to engage our stakeholders as we build interfaces. Yet, social service agencies looking to provide services to hard-to-reach groups like immigrants, cultural minorities, and the poor have taken pride in innovative outreach methods. In situations where traditional printed matter is a barrier, graphical methods can be used very effectively to communicate with audiences.

From guerilla theatre to testimonials, posters to graphic instructions, users have benefited from alternative communication methods, particularly in situations where education or cultural barriers make it difficult for people to access services important to their well-being and safety. In some cases, the comic book format has been used as a way to help people get access to critical legal help. This case study from my time as a publication manager at the Legal Services Society (LSS) of British Columbia (BC) could inspire the use of comics outside the development process. Continue reading Comics for Consumer Communication

Enhancing Dashboard Value and User Experience

by:   |  Posted on

This article is the fifth in a series sharing a design framework for dashboards and portals.

Part 1 of this series, The Challenge of Dashboards and Portals, discussed the difficulties of creating effective information architectures for portals, dashboards and tile-based information environments using only flat portlets, and introduced the idea of a system of standardized building blocks that can effectively support growth in content, functionality, and users over time. In enterprise and other large scale social settings, using such standardized components allows for the creation of a library of tiles that can be shared across communities of users.

Part 2 of the series, Introduction to the Building Blocks, outlined the design principles underlying the building block system and the simple guidelines for combining blocks together to create any type of tile-based environment.

Part 3 of the series, Building Block Definitions (Containers), described the Container components of the Building Block system in detail.

Part 4 of the series, Connectors for Dashboards and Portals, described the Connector components of the Building Block system in detail.

In Part 5, we look at ways to enhance the long-term value and user experience quality of portals created with the building blocks by encouraging portability and natural patterns of dialog and interaction around aggregated content.

For the reader’s convenience, this article is divided into the following sections:

A Portal Design Vision: Two-Way Experiences

Recommendations

Metadata

Presentation Standards and Recommendations

Manage Functionality By Creating Groups

Enterprise 2.0 and the Social Portal

A Portal Design Vision: Two-Way Experiences

Portals gather and present content from a wide variety of sources, making the assembled items and streams more valuable for users by reducing the costs of content discovery and acquisition. By placing diverse content into close proximity, specialized forms of portals, such as the dashboard, support knowledge workers in creative and interpretive activities including synthesis, strategy formulation, decision making, collaboration, knowledge production, and multi-dimensional analysis.

At heart, however, aggregation is a one-way flow. In the aggregation model common to many portals, content is collected, organized, and perhaps distributed for use elsewhere, but nothing returns via the same channels. Savvy users quickly see that the greatest value of aggregative experiences and tools lies in their potential contributions to two-way flows. They understand that experiences capable of engaging direct and indirect audiences transform portal and dashboard content into a broadly useful resource for communities of much greater scope and impact. Further, business staff and IT users comfortable in the new world of Enterprise 2.0, DIY / mashups and shadow IT now often create their own information technology solutions, assembling services and tools from many sources in new ways that meet their individual needs.

Accordingly, portal designers should create experiences that support increased discussion, conversation, dialog and interaction, and allow for the potential value of remixing content in innovative ways. We might summarize a broad design vision for two-way portals that synthesizes these audiences, environmental factors and imperatives as follows:

  • Provide users with rich contextual information about the origin and nature of dashboard or portal content; context is crucial, especially in a fragmented and rapidly moving enterprise environment.
  • Improve the quality and consistency of the user experience of aggregated content.
  • Improve the portability of content, making it useful outside the boundaries of the dashboard.
  • Allow dashboard users to take advantage of other tools available outside the immediate boundaries of the portal.

Operatively, this means providing two-way channels that make it easy to share content with others or even "take it with you" in some fashion. The building block framework is ideal as a robust foundation for the many kinds of tools and functionality – participatory, social, collaborative – that support the design vision of two-way flows within and outside portal boundaries.

Recommendations

Based on this vision and my experience with the long-term evolution and usage of many portals, I recommend five ways to enhance two-way capabilities and the overall quality of user experiences designed with the building blocks framework:

  1. Define standardized Convenience functionality that could apply to all blocks. This will provide a baseline set of common capabilities for individual blocks such as export of Container content and printing.
  2. Define Utility functionality offered at the Dashboard or Dashboard Suite level. This captures common productivity capabilities for knowledge workers, linking the dashboard to other enterprise resources such as calendars and document repositories.
  3. Define common metadata attributes for all Container blocks, to support administration and management needs.
  4. Define presentation standards that appropriately balance flexibility with consistency, both within Container blocks and across the user experience.
  5. Define user roles and types of blocks or content to allow quick management of items and functionality in groups.

As with the rest of the building blocks design framework, these recommendations are deliberately neutral in terms of business components and processes, technology platforms, and development frameworks (RUBY, AIR, Silverlight, etc.), and design methods. They describe capabilities and / or functionality that design, business, and technology decision-makers can rely on as a common language when deciding together what a given portal or dashboard must accomplish, and how it should do so. (Besides allowing extension and reuse of designs, neutrality is consistent with the principles of Openness, Independence, Layering, and Portability that run throughout the building blocks system.)

Convenience Functionality

Convenience functions make it easier for users to work with the content of individual Container blocks. Good examples of Convenience functionality include printing the contents of Containers for use outside the Dashboard, or subscribing to an RSS feed that syndicates a snapshot of the contents of a block. Convenience functionality is associated with a single Container, but is not part of the content of the Container.

This collection is a suggested set of Convenience functionality meant to help establish a baseline that you can adapt to the particular needs of your users. Assign Convenience functions to individual blocks as appropriate for circumstances and as endorsed by users, business sponsors, and technologists. Some of these features make sense at all levels of the block hierarchy, and some do not (how would one print an entire Dashboard in a way that is useful or readable?).

The collection is broken into five groups:

  1. Understanding Content Sources and Context
  2. Making Dashboard Content Portable
  3. Controlling the User Experience
  4. Staying Aware of Changes / Subscriptions
  5. Social and Collaborative Tools

The illustration below shows Convenience functionality associated with a Tile.

convenience_functionality_c.jpg

Figure 1: Tile Convenience Functionality (By Group)

Group 1: Understanding Content Sources and Context

Preserving accurate indication for the source of each block’s content is critical for the effective use of heterogeneous offerings. Dashboards that syndicate Tiles from a library of shared assets may contain conflicting information from different sources, so users must have an indication of the origin and context of each block.  (Wine connoisseurs use the term "terroir.")

Show detailed source information for a block. For business intelligence and data content, the source information commonly includes the origin of the displayed data in terms of operating unit, internal or external system (from partners or licensed feeds), its status (draft, partial, production, audited, etc.), the time and date stamp of the data displayed, the update or refresh cycle, and the time and date of the next expected refresh.

For widgets, web-based applications, and content that takes the form of transactional functionality such as productivity or self-service applications delivered via an intranet or web-service, source information commonly includes the originating system or application, its operating status (up, down, relevant error messages), and identifying information about the group, operator, or vendor providing the functionality.

Send email to source system owner / data owner. This allows portal users to directly contact the "owners" of a content source. In enterprises with large numbers of internal data and functionality sources that frequently contradict or qualify one another, the ability to ask clarifying questions and obtain additional or alternative content can be critical to making effective use of the content presented within the Dashboard.

Show performance data and metrics. If standard performance data and measurements such as key performance indicators (KPIs) or balanced score cards (which have risen and then fallen out of favor in the past five years) affect or determine the contents of a block, presenting them readily at hand is good practice. 

Such performance indicators might take the form of KPIs or other formally endorsed metrics, and require:

  • Showing displayed KPIs
  • Showing supporting KPIs (rolled up or included in the summary KPI on display)
  • Showing related KPIs (parallels by process, geography, industry, customer, etc.)
  • Showing dependent KPIs (to illuminate any "downstream" impact)

For performance indicators defined by number and name—perhaps they are recognized and used across the enterprise or operating unit as a comparative baseline, or for several different measurement and assessment goals—provide this important contextual information as well.

Show related documents or assets. Whether automated via sophisticated information management solutions or collected by hand, related documents and assets increase the range and applicability of dashboard content. Bear in mind that less is often more in a world drowning in electronic assets and information.

Show source reports or assets. If the contents of a block are based on an existing report, then providing direct access to that item—bypassing document repositories, collaboration spaces, or file shares, which often have terrible user experiences and searching functions—can be very valuable for dashboard users.

Show related blocks. In large portals or Dashboards that aggregate Tiles from many different sources—perhaps several Tile Libraries—providing navigable links to related Pages or Sections of the Dashboard increases the density and quality of the connections between pieces of content. Whether mapped by hand or automated, these links can further enhance the value of the dashboard by exposing new types of relationships between informational and functional content not commonly placed in proximity in source environments.

Search for related items and assets. If individual Container blocks carry attached metadata, or metadata is available from the contents of the block, search integration could take the form of pre-generated queries using terms from local or enterprise vocabularies, directed against specifically identified data stores.

Group 2: Making Dashboard Content Portable

These capabilities enhance the portability of content, supporting the two-way communication and social flows that make content so useful outside the boundaries of the dashboard. The items below include several of the most useful and commonly requested portability measures:

  • Print contents of block
  • Email contents of block (HTML / text)
  • Email a link to block
  • Create a .pdf of block contents
  • Create a screenshot / image of block contents
  • Download contents of block (choose format)
  • Save data used in block (choose format)
  • Download source report (choose format)

Group 3: Controlling the User Experience

Individual blocks may offer users the ability to change their on-screen layout, placement, or stacking order, collapse them to smaller sizes, or possibly activate or deactivate them entirely. If designers have defined standard display states for Containers (see Presentation Standards and Recommendations below), blocks may also allow users to customize the display state:

  • Change layout or position of block on screen
  • Collapse / minimize or expand block to full size
  • Change display state of block
  • Deactivate / shut off or activate / turn on block for display

Group 4: Staying Aware of Changes / Subscriptions

Aggregation models lower information discovery and acquisition costs, but do not obviate the costs of re-finding items, and do little to help users manage flows and streams of content that change frequently. Many portals and dashboards aim to enhance users’ awareness and make monitoring the status of complex organizations and processes simpler and easier. This group includes functionality allowing users to subscribe to content through delivery channels such as RSS or to receive notices when dashboard content changes:

  • Send email on block change (it is optional to include contents)
  • Subscribe to RSS feed of block changes (it is optional to include contents)
  • Subscribe to SMS message on block change
  • Send portal Page on block change

Group 5: Social and Collaborative Tools

This group includes social features and functions that engage colleagues and others using social mechanisms. Introducing explicitly social mechanisms and capabilities into one-way dashboard and portal experiences can dramatically enhance the value and impact of dashboard content.

When designed properly and supported by adoption and usage incentives, social mechanisms can encourage rapid but nuanced and sophisticated interpretation of complex events in large distributed organizations. Social functions help preserve the insight and perspective of a diverse community of users, an intangible appreciated by many global enterprises.

Annotate block. Annotation allows contributors to add an interpretation or story to the contents of a block. Annotation is typically preserved when blocks are syndicated or shared because annotations come from the same source as the block content.

Comment on block. Commentators can provide a locally useful interpretation for a block originating from elsewhere. Comments are not always portable, or packaged with a block, as they do not necessarily originate from the same context, and their relevance will vary.

Tag blocks. Tagging with either open or predetermined tags can be very useful for discovering unrecognized audiences or purposes for block content, and quickly identifying patterns in usage that span organizational boundaries, functional roles, or social hierarchies.

Share / recommend blocks to person. Combined with presence features, sharing can speed decision-making and the growth of consensus.

Publish analysis / interpretation of block content. Analysis is a more thorough version of annotation and commenting, which could include footnoting, citations, and other scholarly mechanisms.

Publish contents of block. Publishing the contents of a block to a team or enterprise wiki, blog, collaboration site, or common destination can serve as a communication vehicle, and lower the opportunity costs of contributing to social or collaborative tools.

Rate block. Rating blocks and the ability to designate favorites is a good way to obtain quick feedback on the design / content of blocks across diverse sets of users. In environments where users can design and contribute blocks directly to a Tile Library, ratings allow collective assessment of these contributions.

Send contents of block to person (with comment). Sending the contents of a block – with or without accompanying commentary – to colleagues can increase the speed with which groups or teams reach common points of view.  This can also provide a useful shortcut to formal processes for sharing and understanding content when time is important, or individual action is sufficient.

Send link to block to person (with comment). Sending a link to a block – with or without accompanying commentary – to colleagues can increase the speed with which groups or teams reach common points of view.  This can also provide a useful shortcut to formal processes for sharing and understanding content when time is important, or individual action is sufficient.

Commenting and annotation, coupled with sharing the content that inspired the dialog as a complete package, were the most requested social capabilities among users of many of the large enterprise dashboards I have worked on.

Stacking Blocks

Some combinations of Convenience functionality will make more sense than others, depending on the contents of blocks, their purpose within the larger user experience, and the size of the blocks in the stacking hierarchy (outlined in Part 2). Figure 2 illustrates a Page composed of several sizes of Containers, each offering a distinct combination of Convenience functionality.

combinations_convenience.jpg

Figure 2: Combinations of Functionality

Convenience…or Connector Component?

Several of the Connector components (described in Part 4 of this series) – especially the Control Bar and the Geography Selector – began life as examples of Convenience functionality. Over the course of many design projects, these pieces were used so frequently that their forms standardized, and they merited independent recognition as defined building blocks. (The change is a bit like receiving a promotion.)

With sustained use of the blocks framework, it’s likely that designers will identify similar forms of Convenience functionality that deserve identification as formal building blocks, which can then be put into the library of reusable design assets. This is wholly consistent with the extensible nature of the blocks system, and I encourage you to share these extensions!

Utility Functionality

Utility functionality enhances the value of content by offering enterprise capabilities such as calendars, intranet or enterprise searching, and colleague directories, within the portal or dashboard setting. In practice, Utility functionality offers direct access to a mixed set of enterprise resources and applications commonly available outside portal boundaries in a stand-alone fashion (e.g. in MS Outlook for calendaring).

Common Utility functions include:

  • Team or colleague directories
  • Dashboard, intranet or enterprise searching
  • Dashboard personalization and customization
  • Calendars (individual, group, enterprise)
  • Alerting
  • Instant messaging
  • Corporate blogs and wikis
  • Licensed news and information feeds
  • RSS aggregators
  • Attention streams
  • Collaboration spaces and team sites
  • Profile management
  • Document repositories
  • Mapping and geolocation tools
  • Business intelligence tools
  • Supply Chain Management (SCM), Enterprise Resource Planning (ERP), and Customer Relationship Management (CRM) solutions

My Experience or Yours?

One important question designers must answer is where and how portal users will work with Utility functionality: within the portal experience itself or within the user experience of the originating tool? Or as a hybrid of these approaches?

Enterprise productivity tools and large software packages such as CRM and ERP solutions often provide consumable services via Service-Oriented Architecture (SOA) or Application Programming Interfaces (APIs), as well as their own user experiences (though they may be terrible). The needs and goals of users for your portal may clearly indicate that the best presentation of Utility functionality syndicated from elsewhere is to decompose the original experiences and then integrate these capabilities into your local portal user experience. Enterprise tools often come with design and administration teams dedicated to supporting them, teams which represent significant investments in spending and credibility. Carefully consider the wider political ramifications of local design decisions that affect branding and ownership indicators for syndicated Utility functionality.

utility_ux.jpg

Figure 3: Local vs. Source Experiences

Metadata

In portals and dashboards, aggregation often obscures origins, and content may appear far outside the boundaries of its original context and audiences. The Convenience and Utility functionality suggested above is generally much easier to implement and manage with the assistance of metadata that addresses the dashboard or portal environment.

The attributes suggested here establish a starting set of metadata for Container blocks managed locally, or as part of a Tile Library syndicated across an enterprise. The goal of this initial collection is to meet common administrative and descriptive needs, and establish a baseline for future integration metadata needs. These attributes could be populated with carefully chosen values from a series of managed vocabularies or other metadata structures, or socially applied metadata provided by users as tags, keywords, facets, etc.

Administrative Attributes:

  • Security / access level needed for content
  • System / context of origin for content
  • System / context of origin contact
  • Data lifecycle / refresh cycle for content
  • Most recent refresh time-date
  • Effective date of data
  • Block version #
  • Block release date

 Structural Attributes:

  • Container blocks stacked in this block
  • Crosswalk Connectors present within block
  • Contextual Crosswalk Connectors present within block

 Descriptive Attributes:

  • Title
  • Subtitle
  • Subject
  • Audience
  • Format
  • Displayed KPIs (defined by number / name)
  • Supporting KPIs (defined by number / name)
  • Related KPIs (defined by number / name)
  • Related Documents / Assets
  • Source Report / Assets
  • Related Blocks
  • Location

Metadata Standards

The unique needs and organizational context that drive the design of many portals often necessitates the creation of custom metadata for each Tile Library or pool of assets. However, publicly available metadata standards could serve as the basis for dashboard metadata. Dublin Core, with a firm grounding in the management of published assets, offers one useful starting point. Depending on the industry and domain for the users of the dashboard, system-level integration with enterprise vocabularies or public dictionaries may be appropriate. Enterprise taxonomies and ontologies, as well as metadata repositories or registries, could supply many of the metadata attributes and values applied to building blocks.

Presentation Standards and Recommendations

Visual Design and Style Guidelines, Page Layouts, Grid Systems

The neutrality of the building blocks framework allows architects and designers tremendous flexibility in defining the user experience of a dashboard or portal. The system does not specify any rules for laying out Pages, defining grid systems, or applying design styles or guidelines. Responsibility for these design questions should devolve to the local level and context; the architects and designers working on a given user experience must make these critical decisions.

Standards for Containers and Connectors. One of the paramount goals for the building blocks system is to minimize the presence of unneeded user experience elements (no excess chrome for designers to polish!), and maintain the primacy of the content over all secondary parts of the dashboard experience. Even so, aspects of the building blocks themselves will be a direct part of the user experience. Thus setting and maintaining standards for those aspects of Containers and connectors that are part of the user experience is essential.

The many renderings and examples of Tiles and other components seen throughout this series of articles show a common set of standards that covers:

  • Location and relationship of Tile components (Tile Body, Tile Header, Tile Footer)
  • Placement of Convenience functionality
  • Placement of Utility functionality
  • Treatment of Connector components
  • Boundary indicators for Tiles and Containers
  • Boundary indicators for mixed content (block and free-form)

Figure 4 shows one set of standards created for the Container and Connector components of an enterprise dashboard.

standards_view_border.jpg

Figure 4: Presentation Standards for Containers and Connectors

This is a starting set of elements that often require design standards. Architects and designers working with the building blocks will need to decide which block elements will be part of the user experience, and create appropriate standards. (If using lightweight and modular user experience development approaches, relying on standards and structured components, it’s possible to effect quick and easy design iteration and updates.)

Standards For Content Within Containers. Setting standards and defining best practices for layout, grid systems, and visual and information design for the contents of Container blocks will increase the perceived value of the dashboard or portal. In the long term, offering users a consistent and easy-to-understand visual language throughout the user experience helps brand and identify Tile-based assets that might be syndicated or shared widely. A strong and recognized brand reflects well on its originators. Figure 5 shows example standards for chart content in Container blocks.

standards_block_content_border.jpg

Figure 5: Presentation Standards for Chart Content in Container Blocks

Standards For Mixed Building Block and Freeform Content. Setting standards for layouts, grid systems, and information design for the freeform content that appears mixed with or between Containers makes sense when the context is known. When the eventual context of use is unknown, decisions on presentation standards should devolve to those designers responsible for managing the local user experiences.

Container States

The core principles of openness and portability that run throughout the building blocks framework mean the exact context of use and display setting for any given block is difficult for designers to predict. Defining a few (three or four at the most) different but standardized presentation states for Containers in a Tile Library can help address the expected range of situations and user experiences from the beginning, rather than on an ad-hoc basis. This approach is much cheaper over the long-term, when considered for the entire pool of managed Tiles or assets.

Since the on-screen size of any element of the user experience is often a direct proxy for its anticipated value and the amount of attention designers expect it to receive, each standard display state should offer a different combination of more or less content, tuned to an expected context. Using a combination of business rules, presentation logic, and user preferences, these different display states may be invoked manually (as with Convenience functionality) or automatically (based on the display agent or surrounding Containers), allowing adjustment to a wide range of user experience needs and settings. In practice, states are most commonly offered for Tiles and Tile Groups, but could apply to the larger Containers with greater stacking sizes, such as Views, Pages, and Sections.

One of the most commonly used approaches is to assume that a Container will appear most often in a baseline or normal state in any user experience, and that all other states cover a sliding scale of display choices ranging from the greatest possible amount of content to the least. The four states described below represent gradations along this continuum.

Normal state is the customary presentation / display for a Container, the one users encounter most often.

Comprehensive state is the most inclusive state of a Container, offering a complete set of the contents, as well as all available reference and related information or Containers, and any socially generated content such as comments, annotations, and collective analyses. Figure 6 shows a Tile in comprehensive display state.

states_comprehensive.jpg

Figure 6: Tile: Comprehensive Display

Summary state condenses the block’s contents to the most essential items, for example showing a single chart or measurement. The summary state hides any reference and related information, and places any socially generated content such as annotation or comments in the background of the information landscape. Figure 7 shows a Tile in summary display state.

states_summary.jpg

Figure 7: Tile: Summary Display

Snapshot state is the most compact form of a Container block, offering a thumbnail that might include only the block’s title and a single highly compressed metric or sparkline. Snapshot states often represent the Container in discovery and administrative settings, such as in search experiences, in catalogs of assets in a Tile Library, or in dashboard management interfaces. Figure 8 shows a Tile in snapshot display state.

states_snapshot.jpg

Figure 8: Tile: Snapshot Display

Convenience and Utility Functionality

New platforms such as Adobe Integrated Runtime (AIR) and Microsoft Silverlight, and the freedom afforded by Asynchronous Javascript and XML (AJAX) and Rich Internet Application (RIA) based experiences in general, offer too many possible display and interaction behaviors to discuss in detail here.

Accordingly, I suggest designers keep the following principles in mind when defining the interactions and presentation of Convenience and Utility functionality:

  • Convenience functionality is meant to improve the value and experience of working with individual blocks.
  • Utility functionality addresses the value and experience of the portal as a whole.
  • Convenience functionality is less important than the content it enhances.
  • Convenience functionality is always available, but may be in the background.
  • Utility functionality is always available, and is generally in the background.
  • Convenience functionality does not replace Utility functionality, though some capabilities may overlap.
  • Usability and user experience best practices strongly recommend placing Convenience functionality in association with individual blocks.
  • Usability and user experience best practices strongly recommend presenting Utility functionality in a way that does not associate it with individual Container blocks.

Manage Functionality By Creating Groups

Most users will not need the full set of Convenience and Utility functionality at all times and across all Tiles and types of Container blocks. Usage contexts, security factors, or content formats often mean smaller subsets of functionality offer the greatest benefits to users. To keep the user experience free from the visual and cognitive clutter of un-needed functionality, and to make management easier, I recommend designers define groups of functionality, users, and content. Create groups during the design process, so these constructs are available for administrative use as soon as the portal is active and available to users.

Other recommendations include:

  • Define bundles of Convenience and Utility functionality appropriate for different operating units, business roles and titles, or access levels of users.
  • Allow individual users to select from bundles of Convenience and Utility functionality. Customization commonly appears in a profile management area.
  • Create roles or personas for dashboard users based on patterns in content usage, and match roles with relevant and appropriate functionality bundles.
  • Define types of user accounts based on personas, or usage patterns and manage functionality at the level of account type.
  • Define types of Tiles or Containers based on content (informational, functional, transactional, collaborative, etc.). Apply bundles of Convenience functionality to all the Tiles or Containers of a given type.
  • Define standard levels of access for social features and functionality based on sliding scales of participation or contribution: read, rate, comment, annotate, write, edit, etc. Manage access to all social functions using these pre-defined standard levels.

Larger portals may warrant the creation of a dedicated administrative interface. The building blocks make it easy to define an administrative console accessible via a Page or Section apparent only to administrators.

Enterprise 2.0 and the Social Portal

Portals and dashboards that augment one-way aggregation of information with Convenience and Utility functionality can offer diverse and valuable content to savyy users – customers who expect Enterprise 2.0, Web 2.0, and social software capabilities from all their experiences and tools. As these recommendations demonstrate, the building blocks can serve as an effective design framework for portals that serve as two-way destinations.

Many of these recommended Convenience and Utility capabilities now come "out of the box" in portal or dashboard platforms, and the interactions that make them available to users follow standard behaviors in the resulting user experiences.When first identified as valuable for users (almost five years ago), these capabilities almost universally required teams to invest considerable amounts of time and money into custom design, development, and integration efforts. Thankfully, that is no longer the case.

Part Six of this series will explore how the Building Blocks framework solved recurring problems of growth and change for a series of business intelligence and enterprise application portals.  We will review the evolution of a suite of enterprise portals constructed for users in different countries, operating units, and managerial levels of a major global corporation.

Connectors for Dashboards and Portals

by:   |  Posted on

This article is the fourth in a series sharing a design framework for dashboards and portals.

The Building Blocks are an open system – architects and designers should introduce additional navigation models and mechanisms into the experience as needed.Part 1 of this series, “The Challenge of Dashboards and Portals,” discussed the difficulties of creating effective information architectures for portals, dashboards and tile-based information environments using only flat portlets, and introduced the idea of a system of standardized building blocks that can effectively support growth in content, functionality and users over time. In enterprise and other large scale social settings, using such standardized components allows for the creation of a library of tiles that can be shared across communities of users.

Part 2 of the series, “Building Block Definitions (Containers)” described the Container components of the Building Block system in detail.

Part 4 describes the Connector Components in detail.

Overview of the Connector Blocks

The building block system includes several types of Connectors that make it possible for designers and architects to link the different areas of a Dashboard together via a consistent, easily understandable navigation model. The system also ensures the resulting information architecture can grow in response to changing needs and content. There’s no special stacking hierarchy for the Connectors. However, they do have an official stacking size (most are size 3) in order to keep Dashboards constructed with the building blocks internally consistent.

The defined Connectors are:

  • Control Bar
  • Section Connector
  • Page Connector
  • Dashboard Connector
  • Crosswalk Connector
  • Contextual Crosswalk Connector
  • Utility Navigation
  • Geography Selector

Control Bars allow access to deeper collections of similar blocks, such as Tile Groups and Tiles offering narrowly focused content. Section, Page, and Dashboard Connectors offer hierarchically driven navigation paths between larger Containers. Crosswalk Connectors and Contextual Crosswalks extend the capabilities of the default Building Blocks navigation model to include links that express context-driven associative relationships between Containers, regardless of their location within the Dashboard or Portal structure. Combinations of Connectors provide the familiar patterns of paths from a user’s current location to higher or broader levels of the Dashboard, links to items at the same level, links to contextually related items at all levels, etc.

Container Definitions

Each Connector definition includes:

  • Mandatory components
  • Optional components
  • Stacking size
  • Detailed description
  • Example rendering (for illustrative purposes only)
  • Rendering description

Control Bar definition

Mandatory components: Controls for manipulating Container content
Optional components: None
Stacking size: special – can be attached to Tiles, Tile Groups, or Views

Control Bar description

A Control Bar increases the amount of content offered by a Tile, Tile Group, or View by giving users the ability to change the content displayed within the block. Designers attach a Control Bar to a block to increase the effective depth (or scope) of the block’s content. Control Bars allow dashboard designers to increase the depth of a new or existing Container block without increasing the on-screen size of the block or creating a large number of very similar blocks.

One common way of using Control Bars is to allow users to perform repeated tasks on one object that is a member of a group of similar objects. For example, a Tile that allows users to approve or reject purchase orders for one operating unit could be augmented with the addition of a Control Bar. The Control Bar will expand the scope of purchase order approval functionality by allowing the user to choose one or more operating units from a list of all available operating units. The approval functionality itself should appear and remain within the Tile, though the scope may expand with successive revisions of the Tile.

Another common use for Control Bars is to provide tools for choosing different combinations of data parameters for display within a block, such as selecting a single item for focus (or rendering of available data) from a list of many other items of the same type, shifting the start or end dates for a time period, changing a measurement unit or referencing an axis for comparison.

The controls – buttons, sliders, actuators, etc. – in a Control Bar are often rendered as standard form elements such as radio buttons or select lists, or hyperlinks. They could just as easily appear as custom scripted elements, applets, or AJAX / RIA delivered sliders. The types and styles of controls presented should be driven by the guidelines of good user experience design. And perhaps your budget!

A primary benefit of Control Bars is to reduce the total number of blocks necessary for a dashboard – though they do increase the complexity of individual blocks – thereby lowering overall development costs and saving valuable screen real estate. For example, consider a single product that is part of a family of fifteen related products: placing a Control Bar on a Tile that shows the inventory for one of those products allows users to change between displaying the same kind of inventory data for any product in the family, instead of simultaneously displaying fifteen separate Tiles with the same inventory data for all the different products in the family. Control Bars also work well when users need to compare metrics, items, or groups of metrics or items, in a side-by side fashion.

Control Bars attached to stacked blocks retain their functionality. Stacking Containers with attached Control Bars can lead to complex possible permutations of scope and depth for block content. Explore the potential combinations and permutations carefully, especially in regards to security and access rights. Control Bars should not replace functionality already located within a block, or serve as a means of combining wildly different sorts of content together into a single block that is incoherent or inconsistent. I recommend limiting the use of Control Bars to one per Container.

Example rendering:

control_bar.jpg
Figure 19: Example Control Bar

Rendering description

This rendering shows a Tile with attached Control Bar that allows users to shift the focus of the Tile to any of a list of fifteen individual products, chosen via the select list shown. When the user chooses a product, the contents of the Tile refresh to show weekly inventory data for the new product, as well as a reference table and associated documents and links for the same new product.

Page Connector definition

Mandatory components: links to all Pages in the parent Section
Optional components: None
Stacking size: 3

Page Connector description

The Page Connector links all the Pages stacked within a single Section of the Dashboard. The Page Connector typically appears on every Page within a Dashboard, though this is not required. As users navigate from Section to Section, the links in the Page Connector change to reflect the different Pages stacked in each Section. Of course, placing a Page Connector on any Page does not preclude creating other groups of links to other Pages located throughout the Dashboard. The Building Blocks are an open system – architects and designers should introduce additional (Free Form, within the view of the blocks) navigation models and mechanisms into the experience as needed.

Example rendering:

page_connector.jpg
Figure 20: Example Page Connector

Rendering description

This rendering shows the navigation links to Pages appearing in a Page Connector for a Section titled Products, which contains a Section summary page and four other Pages.

Section Connector definition

Mandatory components: links to all Sections in the Dashboard
Optional components: link to Dashboard Home Page
Stacking size: 3

Section Connector description

The Section Connector is a high level Connector that provides a link to each Section making up the Dashboard. The Section Connector typically appears on every Page within the Dashboard, though this is not required. The Section Selector is akin to the ubiquitous global navigation element familiar from many web sites, though its actual content when displayed to a user will vary based on security settings or access rights. The links in the Section Connector should take users either to the Section Summary Page for that Section or to the chosen default Page within the Section. Include a link to any Dashboard Home Page in the Section Connector, especially if it offers unique content not available elsewhere in the dashboard.

Example rendering:

(click on image for larger view)
section_connector_small.jpg
Figure 21: Example Section Connector

Rendering description

This rendering shows the navigation links to Section summary Pages appearing in a Section Connector for a Dashboard that includes a Home Page and five Sections. Four of the Sections are navigable via the Section Connector, the remaining fifth Section – S.5 Administration – is dedicated to administrative uses, and is not navigable or linked via the Section Connector.

Dashboard Connector definition

Mandatory components: links to each Dashboard in a Dashboard Suite
Optional components: None
Stacking size: 3

Dashboard Connector description

The Dashboard Connector allows users with access to two or more Dashboards within a Dashboard Suite to move quickly and directly amongst all the Dashboards they may access, without passing through multiple log-in or authentication interfaces. Dashboard Connectors typically appear on every Page of a Dashboard, though this is not required. The individual links in a Dashboard Connector often point to the Homepage for each listed Dashboard. A less-common linking behavior for Dashboard Connectors is to connect to the last visited Page in each linked Dashboard or to a default Page of the users choosing that is stored as a personalization preference. For administrators and maintenance staff, Dashboard Connectors can offer the same quick and direct access to the separate administrative areas of each Dashboard in a Suite.

Example Rendering:

dashboard_connector.jpg
Figure 22: Example Dashboard Connector

Rendering description

This rendering shows the Dashboard links appearing in the Dashboard Connector for the Business Intelligence Suite described above.

Crosswalk Connector definition

Mandatory components: recurring item (link origin), destination building block
Optional components: None
Stacking size: None

Crosswalk Connector description

A Crosswalk Connector is a direct navigation path between individual building blocks, regardless of origin and destination locations in the Dashboard structure. Crosswalk Connectors provide a hub and spoke style path from many locations to a single destination, rather than a uniquely occurring link between two blocks. Crosswalks often take the form of a recurring name, term, or object that consistently links to another single building block offering content related to the linked item.

Common examples of Crosswalk Connectors include:

  • product names linked to a summary Page or View of the identified product
  • topic terms linked to a news aggregator or RSS aggregator block that shows recent items related to that topic
  • competitor names linked to a profile snapshot or market intelligence block
  • market or product family names linked to sales performance blocks
  • colleague names linked to profile information blocks showing their role, responsibilities, and direct reports

Example rendering:

(click on image for larger view)
crosswalk_connector_small.jpg
Figure 23: Example Crosswalk Connector

Rendering description

This rendering shows all the appearances of a Crosswalk Connector that links the instances of a product name to a destination Page in the Products Section (S.3) titled “Product Focus” (S.3.2), in this case a Page offering detailed information and tools related to a single product.

Contextual Crosswalk definition

Mandatory components: linked term (recurring item), origin contexts associative relationship, destination building blocks
Optional components: None
Stacking size: None

Contextual Crosswalk description

Contextual Crosswalks allow dashboard architects to create a direct link between blocks that is sensitive to context, instead of simply point to point. Contextual Crosswalks typically link a recurring item, such as a product name, to a destination block that varies based on the location of the originating link within the Dashboard’s information architecture. With a Contextual Crosswalk, the destination block of each occurrence of the product name is determined by the location or context of the link within the Dashboard structure; that is, by relying on the users current location to offer insight into the things they are most interested in seeing.

For example, each occurrence of a product name throughout a Dashboard could link either to a block offering inventory information for that product, or to a block offering sales information for competing products. When the product name is located in the Supply Chain section of the Dashboard, it would connect to the inventory block: when the product name is located in the Sales section, the link would connect to the competitor sales block.

Contextual Crosswalks are useful when Dashboards offer a substantial amount of content that addresses several different facets or aspects of an important and recurring topic, term or item. Contextual Crosswalks often appear in the form of a Page showing Views for an item, both of which are chosen via Control Bar to give users ready access to the other available collections of blocks matching the other origin contexts.

Keeping the broader principles of the Building Blocks in mind, it’s perfectly logical for Contextual Crosswalks to link from one of several Dashboards or Portals within a Dashboard Suite to another destination Dashboard.

While Contextual Crosswalks can express any kind of associative relationship, in practice, it’s best to define a limited set of types of Contextual Crosswalk in advance and apply them consistently across the Dashboard or Portal Suite. We know well that complex navigation models increase the work required for designers, developers, users and administrators. Prescribing the available set of Crosswalk Connectors (Contextual and standard) in advance will make it much easier to maintain consistent and easily understood navigation models.

Example rendering:

(click on image for larger view)
contextual_crosswalk_small.jpg
Figure 24: Example Contextual Crosswalk

Rendering description

This rendering shows the navigation paths for a Contextual Crosswalk that links from a number of different origin contexts (or locations) to one of a number of similar destinations within the Products Section of a medium-size Dashboard. The legend on the map identifies the origin contexts and destinations for the Contextual Crosswalk, as well as the linked term: a Product Name. In this case, the Contextual Crosswalk directly links product names in six possible origin contexts (Marketing, Finance, Supply Chain, etc.) with six matching briefings that provide detailed information on the status of a that same product. Those briefings appear as Views available from the Branded Product Focus Page (which contains the Marketing, Supply Chain, and Competitors briefings) or the Co-brand Product Focus Page (which contains the Customers, Regulatory, and Auditing briefings). After clicking the linked product name in the Supply Chain Section, a user navigates to the Branded Product Focus Page (P.3.2), which presents them with the Supply Chain Briefing (V.3.2.2).

Utility Navigation definition

Mandatory components: links to Dashboard Utility Functionality
Optional components: None
Stacking size: 3

Utility Navigation description

This Connector gives users consistent access to the most important utility functions and features for a Dashboard or Portal, gathering ubiquitous links to these necessary tools into a single building block. Utility Navigation should include links to any Utility Function that must be accessible from most or all Dashboard Sections or Pages.

Utility Navigation is typically considered to have a stacking size of 3, meaning it is placed at the Page level of the stacking hierarchy and not within individual Tiles, Tile Groups or Views. This approach is common practice in design settings and enterprise environments where standardized functionality is often supplied by or closely connected to externally defined services supplied via SOA – situations where some sort of dependency links the Dashboard or Portal to another system or environment.

Example rendering:

utility_navigation.jpg
Figure 25: Example Utility Navigation

Rendering description

This Utility Navigation component uses icons to provide links to eight distinct Utility Functions, an enterprise directory, a news feed aggregator, managed documents (Resources), a calendar, enterprise search, KPI driven alerts, prioritized staff updates and personalization settings. As you review the illustrations and examples of Utility Navigation and the other Connectors, keep in mind that no rule from the Building Blocks system requires Utility Navigation to appear onscreen collected together in a single location (though good conceptual and practical reasons for doing so often apply). Likewise, the design decision about how to provide access and use – via icons, text, or other features – should be driven by the particulars of your project and user needs.

Recalling the example business intelligence dashboard designed with the Building Blocks system from Part 1, this illustration shows a Dashboard Page which includes several of the Connectors.

us_products_example_callouts.jpg

This Page includes a Section Connector, a Page Connector, a View and a Tile with attached Control Bars, Utility Navigation (labeled ‘Utility Functionality’ here) and Convenience Functionality (described in more detail in Part 5).

Geography Selector definition

Mandatory components: controls or links for shifting the geographic context of a Container
Optional components: None
Stacking size: special – can be attached to Tiles, Tile Groups, Views, or Pages.

Geography Selector description

The Geography Selector allows designers and architects to decouple the information architecture of a Dashboard from the shifting organizational structures based on geography that many enterprises rely on to understand the fundamentals of their activities. The Geography Selector presents users with controls or links allowing them to change the geographic reference point of a Container, while maintaining the structure of that Container. In the same way that Control Bars increase the depth of a Tile, Tile Group, or View, a Geography Selector increases the scope or depth of a Container while reducing the number of additional Containers to manage. For example, a Geography Selector might allow users the ability to change the focus of a sales activity chart located in a Tile from one US state to another.

Large enterprises often operate in or with reference to multiple states (or provinces, departments, etc.), regions, countries or even continents. These geographic concepts or schemes frequently differ from unit to unit within an enterprise. They often change dramatically from year to year to suit external environmental changes or internal reorganizations. Just as aligning a site map to an organization chart creates a brittle structure subject to disruption during reorganization, tying a Dashboard’s information architecture to an enterprise’s current geographic scheme is a recipe for frustration.

Some Geography Selectors allows users to choose from a single set of geographic units, such as states or counties, with respect to the parameters determining the data shown for a defined set of KPI’s (fixed Containers, variable scope for their content). Other Geography Selectors allow users to traverse a hierarchy of geographic units, with respect to the parameters determining the data shown for a defined set of KPI’s (fixed Containers, variable scope for their content). It’s possible to attach Geography Selectors to Containers with Control Bars. In these cases, the Geography Selector typically drives the Container contents before the Control Bar.

Example rendering:

geography_selector.jpg
Figure 26: Example Geography Selector

Rendering description

This rendering shows a Tile Group with attached Geography Selector and Control Bar. The geographic scheme represented is hierarchical, spanning three tiers, beginning with State, moving to district and concluding with territory. Of course, many businesses use non-hierarchical geographic schemes, irregular schemes, or a combination of these options; in these cases the structure and quality of the underlying data, functionality and business logic may require creative solutions to the problems spawned by unusual intersections of the various choices.

This set of Connectors provides the minimum tools necessary for the assembly of coherent Dashboards across a wide variety of circumstances. I encourage you to refine this starting set, or create additional types of Connectors to meet new challenges.

Conclusion

When combined in a fashion that meets the specific needs and context of a tile-based design effort, the Containers and Connectors can strike a good balance between cost, flexibility, and customization in terms of the user experience, systems and technology efforts and business perspective.

With proper assembly, using the stacking hierarchy and the small set of required elements, the information architect can create a consistent and scalable structure that supports a high quality user experience, lowers development costs and establishes a basis for sharing of resources across the enterprise.

Part Five of this series will describe a common set of utility and convenience functionality often used to extend the reach and relevance of dashboard content to other contexts of use, making practical suggestions for following the principles of Openness, Independence and Portability underlying the Building Block system.

Blasting the Myth of the Fold

by:   |  Posted on

iTunes     Download    Del.icio.us     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif Jeff Parks had the opportunity to speak with Milissa Tarquini on her article, “Blasting the Myth of the Fold”:http://www.boxesandarrows.com/view/blasting-the-myth-of. They talk about how this long held rule in web design is being de-bunked by web analytics and user testing, as well as how this will impact design and development processes based on screen resolution and browser compatibility.

We discuss…

*Defining the Fold*
Milissa outlines the different terms that people use for the fold. Anything that falls below that point in the screen where the user has to scroll is the fold

*Back in the day*
In the early 90’s at AOL scrolling was prohibited. Milissa talks about the need for balance in designing for the fold while being creative.

*A moving target*
She goes on to talk about the challenge of designing for the fold with different screen resolutions and browsers and how in her opinion no one should be designing for the fold.

*Content is still king*
According to Milissa it all comes down to the quality of the content. If content is engaging and the user is interested in the information, they will follow the path to what they are seeking, regardless of the medium.

*Interaction Design is everywhere*
As Derek Featherstone pointed out in his discussion with Christina about Accessibility, IXDA plays an important role when designing with how users will find content on a page.

*Not the last, but a new frontier*
Milissa addresses social media tools such as Blogs, Facebook, and MySpace and how these new web services reinforce the notion that users do scroll. As Eric Reiss commented, “…perhaps the new frontier is the bottom of the page.”