Portals Will Forever Suck for Usability

In the past few years I've spent a lot of time working with portal software. I was involved for half a year with the design of Sakai, which you may know as Oncourse CL. For those of you who want to flail me about its usability flaws, be assured that we refugees from the Tools Team, who were the usability voices, are not too happy about them either. I've since become even more deeply involved in Websphere Portal and its evil little sidekick LWCM, the web content management part of the team. In between, I've been a user of one or two other portal packages. Believe me, they all stink from a usability perspective.

First let's get together on terminology. A "portal" in the old sense is just a website with a bunch of collected links that send you elsewhere. Yahoo pioneered this interface. The newer sense of "portal" is actually a software package that specializes in showing various systems to a user all at once, and supposedly giving the user the ability to customize his own interface (although no one ever does). Portal pages can have different "windows" on a page. For example, one place on the page permits Google searching, another one gives the weather, another one shows your stock market portfolio, and yet another has corporate news from your employer's PR machine. These various "windows" are actually known as "portlets", "applets", "gadgets", or "tools". Oncourse CL is an example. There, it's "tools". You can write a tool. Anybody can. It's completely open, and that's what Sakai's creators are most happy about.

But that's Sakai's Achilles heel, too. Tools don't talk well with one another, because they're designed to be secure and happy living alone. Navigation and other usability factors vary from tool to tool, so you can never just settle down to one consistent interface.

Major portal makers, like IBM and its Websphere Portal, suffer similar problems, except in greater profusion. A typical Websphere portal page may have a dozen "portlets" on a single page, all doing something different, and all potentially with a different "skin". If nothing else, they don't always fit thematically together. They're like jet cockpits. Over there is the flaps indicator, while over here is the oil pressure indicator. Just a flock of barely connected different things. There's no flow to the page, few cues, and little uniformity. And it's designed to be just that way, as if the business and computer science communities conspired in smoke-filled rooms to stick it to both users and usability professionals. Portal proponents claim that users can overcome this madness by customizing their pages, but that's just crazy talk. Users won't do it. They suffer in silence instead. In a portal, there's almost no room for conventional user testing or interface design. There is no "interface" as such, merely pages with things that do stuff. This is great for developers and business types, because portal architecture makes it much, much easier to incorporate in one place functions as diverse as weather announcements, time reporting, and CRM applications.

If you want to see examples, check out the NCAA (www.ncaa.org/wps/portal) or IBM (www.ibm.com).