Why Are Portalized University Home Pages Rare?
During Summer 2003, a team at the University of Oregon did a comparative study of university home pages. Among the questions we examined was this one:
How many universities have 'portalized' their institutional home page?
At least in the case of our study sample, we were surprised to find no portalized institutional home pages.
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.
