Why Are Portalized University Home Pages Rare?

• By Joe St Sauver
• 02/27/04

In fact, out of the 172 sites studied, only about three dozen schools (about 20 percent) even had a link to a local Web portal from their home page, often from a none-too-prominent location. Given the substantial interest in university portals we’ve seen in recent years, we found that rather surprising. In retrospect, we probably shouldn’t have been surprised.

The Competition Is Tough

To begin to understand why university portal projects have largely failed to thrive, just think about the commercial competition. This is an important consideration because by definition, a user can have only one default start page. That page could be your school’s home page, or it could be some other Web page, but it can’t be both. Who are your top competitors? According to comScore [www.comscore.com], as of December 2003 the top three U.S. Internet properties are Yahoo!, Time Warner (AOL/Netscape), and MSN-Microsoft.

Yes, those are all very big, well-funded, professionally run sites, with enormous support staffs. Given their volume, they enjoy tremendous economies of scale, and as advertising-supported sites, they have the cash flow to underwrite their operations.

Those three sites also enjoy some profound structural competitive advantages. For example, many novice Internet users routinely leave their Web browser start page set to the default home page chosen by the browser vendor. In the case of Microsoft IE, with an estimated market share of nearly 95 percent [www.onestat.com], that default home page is www.msn.com, not your university’s Web page. Similarly, when AOL distributes millions of CDs, the software on those disks starts up pointing at AOL’s site, not yours.

Yahoo! is a little different. Its draw is partially a function of having the world’s most popular topical directory of Web sites, but that, in and of itself, is not enough. As anyone who has visited Yahoo! knows, they’ve substantially diversified their audience appeal by offering free Web e-mail, instant messaging, discussion groups, online auctions, shopping, news summaries, calendaring, bill paying services, Web hosting and domain registration, and foreign language and geospecific versions of their sites.

So the bottom line is, if you want to compete to be your users’ default start page, ask yourself, “Can I be a better portal than Yahoo! or AOL or MSN?” If not, your local portal project will always be secondary or tertiary to a bigger, better, slicker commercial portal site, and will never be your user’s default start page. That may be okay, or it may make you want to reconsider the substantial investment a portal represents.

Portal Logins, Customization, and Tracking

The second major stumbling block a higher education portal faces is the portal login issue. Specifically, in order to be able to tailor a portal’s display for a specific user, the portal needs to know who that user is. For virtually all non-trivial cases, that implies creation and use of a username and password for each visitor.

In the case of local faculty, students, and staff, there may already be a username and password currrently in use that might be leveraged for purposes of authentication. For example, perhaps there’s an institutional e-mail server that could run a RADIUS daemon, or maybe you have an institutional LDAP server that could do authentication for your portal.

But what about everyone else, such as the tens or even hundreds of thousands of prospective students and casual visitors to your site? Will you try to get all those people to create an account just to use your site?

I don’t know about you, but when I run into a Web site that requires me to register for an account in order to get at content, I tend to run away. Part of that resistance is sheer password overload—most everyone already has way too many accounts and usernames and passwords, and we really don’t want even one more, thanks.

Like many users, I also don’t want to be tracked, not so much because I’m obsessed with privacy as because I am prone to irritation at the poor inferences and aggressive salesmanship associated with that tracking. Heaven forbid that I should buy a book online about bowling as a gift for a relative—as far as many online sites are concerned, that single purchase forever will tag me as someone who should be subjected to a barrage of bowling-related promotional suggestions. Sorry, I’m not a bowler, I’m not interested in bowling paraphernalia, and I don’t want to be tracked and harassed as if I were a bowler.

At least, like most users, I don’t want to have to login to a site so that site can try to know me and track my online activities in order to “customize my experience” and tailor what I’m shown. Sites that try that are being too dang helpful, and for many people it’s irritating, somewhat aggressive, and a little bit creepy.

E-Mail and Group Discussions

Another key area where university portal deployments tend to get derailed is e-mail. Traditional portals such as Yahoo! or Hotmail have always been tightly coupled to e-mail (and possibly other messaging technologies), in part because that insures the user will actually register and then access the portal on a frequent or near-daily basis in order to get their messages.

But consider the university environment: most of us in academia already have an institutional e-mail account, and most of us who are high-volume mail users do not access their mail via a Web e-mail interface—we use POP, IMAP, or perhaps a shell e-mail client like Pine instead. What will happen if you suddenly tell all those users that they will have to use a new portal-based Web e-mail account instead of the e-mail address and interface they prefer?

Yet if you aren’t able to capture e-mail as a foundation portal application, you will experience substantial erosion in portal relevance and functionality, or at best you will have yet one more perversely complex external application that will need to be grafted onto the portal in some way or another.

One-to-many communication channels have similar potential displacement and disgruntlement issues. At most schools, the default paradigm will often be use of majordomo-type mailing lists, which work well for both local and non-local participants, and which are mail client agnostic. Now substitute the typical portal’s Web-based discussion boards, and watch participation drop, in large measure because we’re all too busy to remember to login to some Web discussion site to check to see what (if anything) is getting discussed.

Too busy, sorry.

Other Issues

A host of other issues may inhibit university portal project success.
Web site segmentation. Customization for various audiences may be handled by a comparatively small number of pre-constructed pages, e.g., one for current faculty and staff, one for prospective students, one for current students, another for sports fans, and so on. Such segmentation tends to undercut the need and utility of customizable portals.

In our study, nearly 80 percent of site home pages had deployed some sort of explicit segmentation. If you segment, do you really need a customizable portal?

Complexity of integration. By their very nature, academic portals tend to need to be tightly integrated with administrative systems (such as Banner), and teaching and learning systems (such as Blackboard or WebCT), not just via periodic snapshots but by tightly coupled direct programmatic APIs. The integration is not trivial and requires a team of talented local programmers as well as cooperation from all the vendors involved.

Lack of cooperation, collaboration, and buy-in. Because of the resources they require and the systems they integrate, portal projects tend to cross and blur traditional organizational boundaries. Is a portal an administrative project? Or is it an academic project? Is it something that should be controlled by the folks who do the institutional home page?

Security limitations. Beyond the problem of a single sign-on, those deploying portals face additional questions about security. Many portals require (or perform best) when scripting and cookies are enabled, and portal applications may or may not fully support end-to-end encryption. Can you live with such security limitations? And what about something as mundane as insuring that easy-to-remember and user-friendly portal passwords don’t undercut the more stringent password standards normally associated with single sign-on environments?

A long list of other problems and questions adds to the likelihood that institutions will delay or avoid a portalized home page. Is your portal designed to be fully accessible by disabled users? Insuring an accessible portal site can be tricky, but it is required by law. Will a portalized Web site index satisfactorily in Google and other major search engines?

Most universities have been loathe to commercialize their Web sites, but it is tempting to use advertising to help pay for the cost of your portal. Those who try to deploy portals in an academic environment face a daunting task, and it may not be surprising, after all, that the portalization of university home pages has, at least to date, been rare.