Contents: What is a portal, anyway? Methodology is the basis for action Working with the different parts of the puzzle Tools for the job Case study Resources About the author Rate this article Related content: Web content usability Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Thomas Myer (tom@myerman.com)
Independent consultant and writer
01 Jun 2002

Usability is key when building a portal, because all of the components have to work together. And the key to good usability for component-based portals is a solid methodology grounded by the proper tools. This article covers methodology, the different aspects of a portal, tools, and a case study.

It seems that every other day another company is offering software to help build a portal, integrate a portal with back-end databases, link a portal to back-office supply chain infrastructure, and so on. They're known as enterprise portals, knowledge portals, and sometimes just plain portals.

What is a portal? What makes them so important? And what can usability professionals do to keep them from being a nightmare for users?

What is a portal, anyway?
A portal can be defined as a single access point to applications, information, and services to a group of users (consumers, employees, customers, or partners) who can personalize their user experience. The emphasis is on single point of access and personalized user experience. With one portal, a company, organization, or person can get the right information to the right people.

Portals are typically made up of components, each of which is highly specialized. One component may list latest breaking news; another one might be a search widget; still another component may list data from a partner's database. In many cases, these components fit into a unified visual design and interaction flow, making the user experience seamless.

When they're done right, a portal can act as a front door to an organization and all it has to offer. Users can access all kinds of information, interact in community areas, and accomplish tasks using custom applications. When information and services change, all users get access to the latest and greatest material-which simplifies content management and application deployment. The common user interface, when implemented correctly, provides consistency.

The My Yahoo page, shown below, is a leading consumer portal. Yahoo allows users to customize layout and appearance (including background color, link colors, and more) as well as the kind of news and applications modules present on the page. News sources include local news, specialized information (such as fitness features), and national news (such as the New York Times). Applications range from weather forecasts to lottery results and access to e-mail. The news and applications modules, plus the wide array of personalization options, are a perfect match for the needs and requirements of the consumer audience.

Figure 1. The My Yahoo page

There's practically no better way to offer so much value in so small a space. All the work put in to designing and building the portal pays off handsomely when new content or applications are rolled out to users, which can sometimes be as easy as dropping new templates or back-end logic onto the server.

Done wrong, a portal can be nothing more than a hodge-podge of little boxes with data and links in them. Each screen could have different interaction models. Each interaction could have different outcomes in different contexts. And the entire thing could be a nightmare to navigate. Search functionality, critical when a portal's information architecture is impenetrable, may not provide visibility into all information and services represented.

In other words, a portal, if done wrong, could be more trouble than it's worth, and certainly a waste of time and money to build.

That's why usability is key when building a portal, because all of the components have to work together. And the key to good usability for component-based portals is a solid methodology grounded by the proper tools.

Methodology is the basis for action
The first thing to realize is that measuring the usability of a portal is precisely like measuring the usability of any kind of site. Although some of the steps in the following methodology may be more akin to an information architecture engagement, they should be familiar to anyone with a usability background.

Step 1: Discovery
The starting point is always discovery. Specifically, you want to understand the audience, the portal's goal, and the portal's breadth.

Understanding your audience is always a critical step in any communication effort. Who makes up your audience, and what kinds of tasks are they involved in? The answers to these two questions form the backbone of your understanding of the audience.

Finding out who makes up your audience can be straightforward or not, depending on how much due diligence the organization that's launching the portal has done. The organization's marketing and sales groups should understand both the demographics and psychographics of the audience.

You can use demographics, psychographics, focus groups, surveys, and other methods to figure out who your audience is and what information they want. The goal is to understand your audience such that you can reduce them to actors in user scenarios. It's O.K. if you have more than one or even dozens of user scenarios involving different segments of your audience. Ostensibly, each of the different users you identify will have different information needs and have different tasks to complete on your portal.

Next, try to figure out the goal of the portal. All portals have an overarching goal, which is to offer centralized access to widespread information sources and services. However, all portals also have unique goals. For example, a corporation may want to cut the cost of managing HR information in half. Putting all HR information in one centralized area and allowing employees to manage their own 401(k) programs via the intranet would certainly help to achieve this goal.

As with audience analysis, the goal is to create a list of specific, measurable goals for the portal. The more specific and measurable, the easier it is to test for usability.

Next, try to understand the breadth of the portal. How many databases and information sources are going to be represented on the portal? How many departments and/or companies will be involved in creating, editing, filtering, publishing, and managing this information? Who has final say-so over various elements like design, editorial content, and access to data? Obviously, these questions run the gamut of technical and organizational issues, but they all impact usability at some point.

For example, if the content featured in critical components doesn't match the needs of the audience, then understanding how that content is created will help when the time comes to give the creators of the content feedback.

Step 2: Analysis and artifact creation
Once discovery is nearing completion (on some projects, discovery may truly never end), start analyzing the data. Make sure that the audience is well-understood and represented by the portal's services and information, for example.

The goal of this step is to create certain artifacts that can be reviewed and approved. For example:

• User scenarios for each user you identify
• A usability specification that identifies each of the components of the portal, what each of those components does, and how users interact with the component
• A site blueprint that shows how each component in the portal flows

The artifacts are the only tangible evidence of usability work, so make them clean, crisp, and professional.

Step 3: Assist the developers
At some point, development of the portal will begin. Depending on the kind of organization, usability information will either be integrated into the process or ignored. Regardless, it's part of each usability expert's mandate to remain a steadfast user advocate.

This doesn't give anyone license to be an annoyance -- remember, most developers haven't been trained in usability techniques. They know how to build software, and this usually means building it efficiently but not necessarily with the end user's needs in mind. The role of the usability expert is to offer guidance, provide pointers, and refer them back to the artifacts that pinpoint users, their needs, and the services offered by the portal.

In many cases, developers will need clarification of what they've read in the artifacts. Developers always appreciate others who communicate with them on their level (that is, in precise language free of ambiguity), and this is a good chance to advance the user's cause while being a true asset to the development team.

Step 4: Testing
At some point, testing begins, and this marks a clear line between being helpful and being adversarial in the process of developing a portal. Although testing can begin at any stage, it might be helpful to wait until the portal software is in Quality Assurance (QA) before embarking on usability testing.

Usability testing can imply a lot of things, but for the purposes of this article, precise methods don't matter. What does matter is what you test: specifically, that your users can access needed information and perform necessary tasks on the portal.

The results of testing and recommendations stemming from the testing should be rolled into the portal and make it better.

Step 5: Deployment and further measurement
Eventually, the portal will launch and users will start using it. This isn't the time to rest, it's time for further measurement. This is especially true for portals, because they are constantly being renewed with new services, applications, widgets, and content items.

Working with the different parts of the puzzle
Portals are complex. They can have an arbitrary number of components, and allow users to access an arbitrary number of data sources and applications.

However, regardless of a portal's size and complexity, each consists of the following layers:

• GUI framework
• Business logic
• Backend

Each of these layers has its own set of problems from a usability standpoint.

GUI framework
The GUI, also known as the presentation layer, contains branding elements, content displays, navigational items, and application widgets. In most cases, the GUI elements are kept separate from the other layers, which makes it easier to roll out changes in look and feel or add new application components.

Issues of importance for the GUI framework are:

• Is the visual design pleasing to the user?
• Is the visual design consistent from page to page?
• Are interactions intuitive and consistent from page to page?
• Do GUI elements load onto the page quickly?

In other words, the GUI must support everyone's goals -- the users' as well as the portal's owners.

Business logic
Business logic is just a fancy term for all the processes that occur on the portal. For example, when a user logs in to the portal, there's an underlying piece of business logic that checks the user's identity and password against values stored in a database. The business logic section of a portal might be stored in Java Beans or in centrally located templates.

Business logic lies at the heart of interaction, and if interaction is faulty, then the user experience will likewise be faulty.

Issues of importance for business logic are:

• Does the business logic foster interaction that the user expects? (For example, does the logic retrieve or display information that the user wants? Is the retrieval fast and efficient?)
• Is the logic driven by user requirements?
• Are all components of the business logic consistent?
• Does the business logic provide visibility into the different data presented by the different components? (For example, can users search multiple databases with one widget?)

Backend
The backend is where most information is stored. The backend can consist of flat files, XML repositories, databases, data warehouses, and back office tools like supply-chain management systems. The backend systems can be on the same system with the portal, or situated across the globe.

A good design for backend systems takes care of the most pressing usability issue (namely, delivery speed) but there are other issues, too, involving:

• Linkage between different data
• Types of data being stored (e.g., ASCII, multimedia files, XML)
• Metadata

Linkage between data can mean the difference between a usable and unusable site. For example, each content item may be linked to a category hierarchy. When a user reads an article about how to create a search engine in Java, the article might be categorized under Programming Languages>Java and Widgets>Search Engines in the hierarchy. The portal's business logic may list other articles in the Java and Search Engine categories to allow the user to read similar articles.

Another issue at hand is the types of data being stored in a database. Most databases handle ASCII data (including HTML documents) with great ease, but other types of data become problematic. For example, XML documents, although stored in ASCII format, will need to be processed by the business logic for display in a Web browser. And although databases can store and retrieve video and audio files, it may be best to only store a pointer to these resources --again, for speed.

Metadata, by and large, is what makes or breaks any effort at publishing huge amounts of disparate content on a portal. For example, if a database contains tables that store articles and white papers, then effective metadata would include author name, author e-mail, and keywords. Each of these metadata can then be accessed by business logic that could, for example, display all articles by a certain author or that contain certain keywords.

Tools for the job
Tools and languages exist for usability professionals that can help make life much easier. For example:

• Visio is known as a flowchart tool, but it can be used to create site maps and page flows. It's the perfect tool for visualizing a process and understanding how components and layers talk to each other.
• Photoshop isn't just an image-manipulation tool. It can be used to create low-, medium-, and high-fidelity mockups and prototypes of GUIs, which can be used as artifacts to illustrate specifications, or as part of user testing.
• SQL, or Structured Query Language, is the lingua franca of many database systems. Learning even the basics will provide insight into how data are organized, retrieved, and updated -- and this, in turn, will make it easier to visualize business logic.

Case study
XYZ Corporation wants to build a portal for its customers and partners. XYZ Corporation is the leading manufacturer of solar panels and other alternative energy/fuel sources, and it wants to cut down on the cost of marketing its products.

From a usability standpoint, there are two major user groups that are uncovered in discovery:

• The company's partners, who need access to company information to help them move forward with business deals. They also want to participate in discussions about the company's products and current news about the industry.
• The company's customers, who primarily want information about product lines, but also want to read about the company's technology in action (case studies) and understand the technology better (white papers). They also want to participate in discussions and receive access to FAQs and product update patches.

Obviously, these are fairly broad strokes, and a more thorough assessment would drill down into specific cases for each grouping, such as:

• The partner development analyst needing access to early field test information on new solar panels to help her work a deal.
• The customer who is a homeowner in an isolated rural environment needing product descriptions and specs for each solar panel.

Of course, all needs should be prioritized on a list, and some may not make the first cut of the release, but at least they've been recorded and considered.

The company's goal for the portal is to foster an open environment for sharing information -- to grow the economy for their products and services. They don't just want a place to pump information out to people, they want a space in which all constituents can interact.

The breadth of the portal is small at first, bringing in data sources from only three departments (all internal to the company). Because each user will have to log in to the portal, the company plans to make this a personalized portal, where users can mix and match the components that are important to them.

The first step is to put all of this together, and to create artifacts that record discovery and analysis outcomes. Each user gets his or her own user scenario, complete with tasks and demographic/psychographic information. How the site flows, how the components interact, what they look like, should all be recorded in a site map or blueprint. Even if this document has already been created by another group, make sure to procure it and include it with the other artifacts.

After development begins, the different components will start materializing. So, too, will the backend systems and business logic that ties everything together. At some point, the portal will enter QA, and that's a good opportunity to perform some usability testing.

Find users (or suitable user proxies) to test whether the portal serves the needs of the different user groups. Can the partner get access to pre-release information on products? Can the rural customer easily figure out which solar panel to buy?

Is the GUI easy to use, or does it confuse users? Are the components built such that they mesh with each other, or does each stick out like a sore thumb? Does the business logic operate in ways that support tasks? Does the search functionality work across all data, or does it stick to predetermined silos of data?

The answers to these (and other) questions determine the usability, and ultimately, the success of XYZ Corporation's portal.

Resources

• Read "Application Framework for e-business: Portals" here on developerWorks to get a good overview of the topic.
  
  
• "Open Wide the Portal" here on developerWorks discusses the use of IBM WebSphere to deliver personalized portal applications.
  
  
• The "Portlet Development for WebSphere Portal Server 1.2 Tutorial, Part 1" goes into a lot of technical detail, but it provides a good sense of what's involved in the effort.
  
  
• "Patterns for e-business and the evolution of business-to-business over the Web" offers an historical overview of the importance of enterprise portals.
  
  
• The Content Management Technical Conference (June 17-19 in San Diego) offers information on content management and portal applications.
  

Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments?

developerWorks > Web architecture >