Improving portal usability

The experience of using a portal can be an excruciating one for end-users. By paying attention to usability issues at the start of a project, development teams can ensure that portal investments pay off.

By Janus Boye

IN ORGANISATIONS worldwide, the enterprise portal is increasingly becoming the default user interface that both employees and business partners use to interact digitally with each other. Many useful applications – such as employee directories, management information and document sharing – are readily available for access by portals and, as a result, many organisations are investing heavily in this young (and still somewhat immature) technology.

Unfortunately, the experience of using a portal is often an excruciating one for employees, thanks to considerable usability challenges. Too often, enterprises wait until the very end of a portal project to address key interface and process concerns, and even then, they rarely pay sufficient attention to usability considerations. It is time to put that right if their portal investments are to pay off.

Reasonable requirements

Before embarking on a portal project, most organisations 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 us take a step back for a moment and look at how you can identify the reasonable user interface requirements. First and foremost, it is important to understand the intended audience of a planned portal. Is the audience companywide? Is it senior management only? Is it the organisation’s customers?

Depending on audience demographics, companies should try to focus on the tasks users are trying to perform. The trick to this is defining the task in a brief and crisp sentence and then focusing on how the task can most easily be solved. The best advice is to try to think less about technology and features, and more on simply ‘getting the work done’.

In the requirements process, portal developers should strive to remove features that may be nice to have, but will end up cluttering the interface. It has been demonstrated time and time again, that less is better and simple is good (think iPod, for example). Once a company starts talking to vendors, it is important that they tell you in detail how they will meet stated requirements – not just if they meet them or not.

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

Be accessible through any browser

Remember that support for industrywide standards will help a portal be more accessible for employees that have sight or hearing impairments. It will also help to future-proof it and reduce support requirements later on.

Be accessible through standard monitor sizes

Horizontal – left-right – scrolling is painful for users, but vertical scrolling is just as bad. I’ll touch on this later, but let us just say for now that the portal should not require a company to invest in larger monitors for its users and administrators.

Use short, meaningful and user-friendly uniform resource locators (URLs)

The actual URL (for example, www.cmswatch.com/portal) is an important element of the user experience. Avoid long, complicated URLs that are system and technology dependent. However impressive the system and technology 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 does not end up with dead links and broken bookmarks.

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 is very important. Avoid additional expensive hardware spending in a rush for quick fixes, while frustrating those users struggling hard just to do their job.

Provide a robust and easy customisable interface

To satisfy corporate branding requirements, portal design needs to be easily changeable, ideally by nontechnical business users. Basic changes like adding a company logo to the interface will make a great impact on user adoption, while further improvements 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, few portals on the market today handle these basic requirements very well.

Handling information overload

Most enterprises blindly adopt the default layout which comes with today’s enterprise portals. This portal layout consists of building blocks, typically under the moniker of ‘portlets’ or ‘web parts’, resulting in a card-deck or dashboard-like interface. Historically, this ‘building block’ approach to page layouts is a leftover from the days of dot-com web portals, such as AOL, Lycos or myYahoo!, where the user could create a personal profile and then tailor the interface to fit.

Most software vendors active in the portal space today launched the first versions of their software 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 startups to create their own portals using the ‘portal builder product’ available from vendors.

Today, this de facto standard might in fact be what is holding usability progress back. Portals can be used for many different business scenarios, but a dashboard may actually never be the ideal portal interface. It is turning out to be the lowest-commondenominator among vendors but, as a result, users are hurting. While vendors may remember to say that this is simply nothing more than a default layout – a sample site – fewer than 5% of licensees plan for the comprehensive changes that are required to create a more meaningful user interface.

In my view, the current approach with a dashboard interface only makessense in exceedingly few and very specific cases. What is needed are new solutions – call this Web 2.0, if you like – that can offer improvements to the user experience and move the subject higher up the project agenda. The impact is becoming clearer to many enterprises, but often too late in the process.

Untangling the user experience

Those involved in a portal project – developers, project managers, editors, business users – often work in an environment where the user interface is ‘assumed’ or they choose to simply accept whatever comes out of the box with the portal product. But effective presentations are critical to portal adoption, and therefore business success. At the most basic level, the user interface renders web pages using standard protocols, including XHTML, Java Server Pages (JSP), Microsoft Active Server Pages (ASP) and Cascading Style Sheets (CSS). This layer manages page templates that are used for consistent layout, portlets that provide specific services to users, and presentation services for portal developers.

An important aspect of the user interface from an architectural perspective is to manage the input and output of multiple applications that function together within a portal. For example, a portal might provide an interface to business intelligence, a list of the latest project files, a sorted listing of recent news, as well as an updated view of important 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 a program and provide a common interface for integrating those applications into the portal. The components consist of two parts: one that functions in the user-interface layer and another that functions in the application-services layer.

As such, the components bridge those two tiers in the portal architecture. The application services layer typically provides the core functionality of a service, such as querying a database, retrieving a document, or authenticating a user through a single sign-on server. 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 portal components 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.

You end up with a template, or ‘skin’ that really just comprises a motley collection of different portlets. 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 (GUI) early in your project. Aim to be done with information architecture and have a usable interface ready to test before signing the contract with the vendor.

To get a better understanding of the implementation consequences and how much effort will be involved in customisation, one approach is a proof-of-concept or prototype as a part of the vendor evaluation. This will require effort on both sides, but investing two days on this process will provide very valuable information for the further planning of the project. It will also give the organisation a welcome opportunity to involve its users. Set them loose with the prototype, let them play around and let them come with comments before it is too late for the development to adapt the project accordingly.

What you find may surprise you. Our own tests and research, for example, found some portal products dependent 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 make improvements to the user experience. Much can be learned from exchanging information with other licensees. These need not use exactly the same portal product and same version in order to provide the inspiration for practical improvements. It may be that a company can win some cheap points with its portal users by simply disabling unused or rarely used features.

If you do go down the route of making significant changes, make sure to adhere to standards and listen carefully to vendor advice, to reduce the chances of losing modifications when the vendor releases a new upgrade.

To become more popular, the portal user-experience needs to be improved. There is still a long way to go before portals become intuitive, but we cannot blame the vendors. It is the practitioners – the buyers – who need to become more demanding and remember to ask themselves: Is a confused and frustrated user a productive one? Of course not. But in the present portal software marketplace there are many choices and, ultimately, the burden falls to those that deploy portals to address usability issues.

Janus Boye is lead analyst at IT market researcher CMS Watch and author of ‘The Enterprise Portals Report’. The report, from which this article is excerpted, evaluates 13 leading portal packages and is available at: www.cmswatch.com/portal