Improving portal usability

By Janus Boye at 2006-09-07 11:59:00 |

In organizations worldwide, the enterprise portal has increasingly become the default interface for employees and business partners to interact digitally with each other. Many useful services -- such as employee directories, management information, and document sharing -- are readily available for access by portals and, as a result, enterprises are investing heavily in this young (and still immature) technology.

Unfortunately, the experience of using a portal often becomes excruciating for employees, owing to considerable usability shortcomings. Too often, enterprises wait until the end of a portal project to address key interface and process concerns, and even then, they rarely pay sufficient attention to usability considerations. It's time to put that right if portal investments are to truly pay off.

Reasonable user interface requirements

Before embarking on a portal project, most organizations commit serious time to gathering and documenting their requirements. This exercise typically involves creating lengthy documents covering everything from business plans to technical details, but these seldom include much about the intended portal interface.

Let's take a step back for a moment to look at how to identify reasonable usability requirements. First and foremost, it's important to understand the intended audience of a planned portal. Is the audience company-wide? Senior management only? Primarily customers? Depending on audience types, enterprises should try to focus on the tasks users are trying to perform. The trick to this sort of scenario-based analysis is defining specific tasks in brief and crisp sentences and then focusing on how work can most easily be supported.

Remember that less is better and simple is good (think iPod or Legos). So focus less on technology and features, and more on simply "getting the work done." In particular, portal developers should strive to remove features that may be nice to have, but end up cluttering the interface.

In order to meet basic reasonable user interface requirements, a portal should:

Employ standards-based mark-up and be accessible through any browser

Remember that support for industry-wide standards will help a portal be more accessible for employees that have sight or hearing impairments.

Be functional across standard monitor sizes

Vertical scrolling is painful for users, but horizontal scrolling is even worse. The portal should not require a company to invest in larger monitors for its users and administrators.

Use short, meaningful and user-friendly URLs

The actual URL (for example, www.cmswatch.com/portal) is an underappreciated element of any user experience. Avoid long, complicated URLs that are perishable or technology-dependent. However impressive the system may be, chances are slim that a company will still be using the same portal in five or ten years' time. As a result, it is necessary to ensure that the company doesn't end up with dead links, broken bookmarks, and URLs that can't be e-mailed.

Provide speedy performance, even under heavy usage

Due to the dynamic nature of portals -- all the building blocks needs to be assembled in the right way on-the-fly -- performance becomes a ubiquitous challenge. And an important one: employees will judge portals in some measure by their speed. Avoid a last minute scramble for additional expensive infrastructure, or other quick fixes, by stress and load testing early and often.

Provide a robust and easy customizable interface

To satisfy branding requirements and the diverse needs of multiple personas across an enterprise, portal design needs to be easily changeable, ideally by non-technical business users. Basic changes like adding a company logo to the interface can certainly impact user adoption, while further adaptations will provide even more value. Should a part of the user interface fail, it is a reasonable requirement that the user is presented with a clear message, and not a cryptic technical error message.

Unfortunately, our comparative evaluations in The Enterprise Portals Report found that few portals on the market today handle these basic requirements very well.

Reconsidering the dashboard

Most enterprises blindly adopt the default layout that comes with today's enterprise portals. This layout consists of building blocks, typically under the moniker of "portlets" or "web parts," resulting in a card-deck or dashboard-like interface.

This building block approach to page layouts is a leftover from the early days of public portals, such as AOL, Lycos, or myYahoo!, where the visitor could create a personal profile and then tailor the interface to fit. Most software vendors active in the portal space today launched version 1 of their solutions at the height of the Internet bubble around 1999/2000. Using building blocks in the layout seemed -- at that time -- valid, enabling the many Internet start-ups to create their own portals using the "portal builder module" available from vendors.

Today, this de-facto standard might in fact mitigate against usability progress in the enterprise. Portals can be used for many different business scenarios, and the current dashboard approach only makes sense in exceedingly few and very specific cases revolving around business intelligence and reporting. What we need are new solutions -- call this Portal 2.0 if you like -- that can offer a better user experience, or at least move the subject higher and sooner on the project agenda.

Vendors counter that dashboards simply represent a default layout -- a sample site -- but our research suggests that fewer than 5% of licensees plan for the comprehensive changes required to create a more meaningful user interface. This is because portal developers, project managers, and business users typically work in an environment where the UI is "assumed," or they choose to simply accept whatever comes out of the box.

But effective presentations are critical to portal adoption, and therefore business success. So let's look at how portals create user interfaces.

Untangling the user experience

At the most basic level, the portal user interface renders web pages using standard protocols, including (X)HTML, JSP, ASP, CSS, and others. This layer of the portal software stack manages:

• page templates that are used for consistent layout,
• portlets that provide specific services to users, and
• presentation services for portal developers.

From an architectural perspective, the user interface manages the input and output of multiple applications that function together within a portal. For example a portal might provide an interface to a business intelligence service, a list of the latest project files, a sorted listing of recent news, as well as an updated view of important business transactions. Each of these views may be based on existing applications that have their own requirements, interfaces, and levels of complexity.

The building blocks mentioned earlier -- portlets or web parts -- are the components that encapsulate the application-specific features of an underlying application and provide a common interface for integrating those services into the portal. These components consist of two parts: one that functions in the user interface layer and another that functions in the application services layer. As such, portlets bridge those two tiers in the portal architecture.

The application services layer typically provides the core functionality, such as querying a database, retrieving a document, formulating a list, or authenticating a user. The user interface layer is responsible for accepting user input, such as search terms, and presenting results, like the list of hits from a search.

To the extent that portlets / web parts typically provide both user interface and application services, it becomes easy to fall into the trap of focusing on one to the exclusion of the other. In particular, development teams tend to focus on application services to the detriment of user interface suitability. The result? You end up with a template, or "skin" that really comprises a motley collection of different portlets -- each working properly against a particular functional spec, but on the whole leaving portal users alternately overwhelmed by the layout and underwhelmed by the capabilities at their fingertips to complete a particular task.

Not a website?

It is hardly surprising, then, that most portals operate as separate islands from a website or intranet. Technically this may make sense, but for the user it is tough to understand the loss of traditional navigation when skipping between the portal and the website or intranet.

Based on my interviews with early adopters, I would recommend spending time on the graphical user interface early in your project, just as you would in a website overhaul. Aim to be done with scenario / persona analysis and information architecture, and have a usable interface ready to test, before signing the contract with any portal software vendor.

To get a better understanding of the implementation consequences and how much effort will be involved in customization, undertake a proof-of-concept or prototype as a part of the vendor evaluation. This will require effort on both sides, but investing weeks on this process will usually save your months or years later. It will also give the organization a welcome opportunity to involve its users. Set them loose with the prototype, let them play around and make practical suggestions before it is too late for the development team to adapt the technology accordingly.

What you find may surprise you. Our own tests and research, for example, found some portal products depend on tables for layout, while others circumscribed where and when you could use CSS.

Never too late

If your company has already launched a portal, it is not too late to improve the user experience. Much can be learned from exchanging information with other licensees. These need not employ exactly the same portal product and same version in order to provide the inspiration for practical improvements.

Indeed, you might be able win points with portal users by simply disabling rarely used features. If you do go down the route of making significant changes, however, make sure to adhere to standards and check in with your suppliers, to reduce the chances of losing modifications when the vendor releases a new upgrade.

To become more popular -- and effective -- the portal user experience needs to improve. There is still a long way to go before portals become intuitive, but we cannot blame the vendors. In the present portal marketplace there are many choices, but ultimately the burden falls to those deploying portals within the enterprise to address usability issues. It is the practitioners -- the buyers -- who need to become more demanding of suppliers and themselves.

This article was adapted from an original version that ran in the July/August, 2006 edition of Knowledge Management Review.