February 2000
Volume 15
Number 11
Web Portals - A Home Page Doth Not a Portal Make
Howard Strauss, Princeton University
What will replace the web? It may be hard to imagine that anything will
replace the web, but nothing lasts forever. However, so far nothing has replaced
the web because it has managed to reinvent itself several times and is about to
do it again, this time with web portals.
In its original incarnation, the web was an online tool for sharing scientific work that included text and images. This read-only version of the web was soon replaced by a more interactive version that offered simple services, and then later, advanced web-based services, generally within the context of a university or company home page. While this was a major advance for the web, the focus of a home page was still the entity, the person, company, institution, or organization, offering it. Every person viewing a particular home page saw exactly the same thing, the entity=s view of itself.
What=s a portal?
A portal is a fundamental departure from the old entity-centric nature of
the web to a user-centric web experience. Portals represent a basic change in
the way we present web information to users and the way in which users use the
web. Unfortunately, the word Aportal@
is commonly being used to refer to a variety of web sites that include simple
home pages with the word Aportal@
on them, horizontal portals such as Netcenter or Excite, and a few vertical
portals that are the type that will have the most impact for colleges,
universities, and corporations.
At this year=s Detroit Auto Show, Ford=s CEO Jacques Nasser said, AWe will do nothing short of transforming our cars and trucks into a portal for the Internet.@ Cars cannot be a web portal. They might access a portal, but Mr. Nasser is using Aportal@ to mean any place where you can access the web. Peter Granoff of wine.com says that they will become the wine portal. I suppose Mr. Granoff means that everything you=ll want to do with wine will be at wine.com and it will remember your preferences. That=s at least somewhat portal-like. CampusPipeline.com wants to build the student web portal for your university, and dozens of companies, including IBM (Enterprise Information Portal) and Oracle (Enterprise Portal) offer portal products. Almost any software company who doesn=t offer one now, will do so in the next two years.
Definitions
People have defined portals as gateways, as hubs from which users can locate
all of the web content they commonly use, as personal web pocket guides, and as
homepages that can be personalized. All of these have some truth to them.
The Gartner Group defines four levels of portals that cover the entire landscape, from level 1, Internet Entry Point portals which are just gussied up home pages, to level 4, Market Place Integration portals which include supply chain management and other features.
Horizontal portals
Portals can be classified as horizontal portals or vertical portals.
Horizontal portals are often called mega portals or HEPs (Horizontal Enterprise
Portals) and are like the web portals offered by Yahoo, AltaVista, MSN, Excite,
and others. These web sites attempt to provide on a single web page all the
services any user might need. All of them include shopping, weather, stock
prices, news, search engines, chat groups, horoscopes, and so forth, and all
urge you to make their page the first page you see when you use the web. They
allow you to personalize the page you see by selecting the cities for which you=d
like the weather, choosing the stocks and news sources you=d
like to display, altering the appearance of the web page, and much more.
Some HEPs let you do extensive personalization, allowing you to build multiple stock portfolios and see frequently updated valuations. Typically, but not always, the personalization is held in web cookies that are stored on your local computer. Accessing a HEP from another computer loses all of your personalization. HEPs almost always include advertising and their goal is to attract as many eyeballs as possible.
HEPs are very useful web sites, but they don=t give academic or corporate employees access to everything they really need on the web. Much of what an employee of any kind needs on the web is specific to the place they work and their role in that organization. Employees need calendars that include university holidays and events, access to financial reports, the status of the tasks they are working on, organization charts, benefits information, and much more. Depending upon their role, different people need quite different information. Students, for example, need to see their course and exam schedules, the books they=ve borrowed from the library, their grades and GPA, their financial aid status, information about their extracurricular activities, and much more. Prospective students, their parents, the parents of enrolled students, alumni, faculty, scholars from other institutions, and vendors to the university all have very different needs for web information from the same organization. Horizontal portals have no way of offering that kind of organization-specific information because they are not connected to any organization=s data sources except their own. Only your own organization or organizations can really deliver access to all the web information you need, and even then, much of the information you need will be outside your university.
Vertical portals
A portal that delivers organization-specific information in a user-centric
way is called a vertical portal or vertical enterprise portal (VEP). A VEP can
also deliver all the information a HEP delivers. While a HEP looks the same to
all who first enter it, a VEP looks quite different. How does a VEP know it
needs to look different for you than for someone else? Unlike a HEP, a VEP
requires authentication for access. When a user logs on to a VEP, it produces a
customized page, tailored to the user who logged on. It knows a great deal about
the user who logged on because the user is a member of the organization that
produced the VEP. It knows, for example, what cohort a user belongs to (e.g.,
student, faculty, staff), what role a user plays (e.g., help desk manager,
department chair, lacrosse team member), what projects a user is involved with,
how many vacation days a user has taken this year, and much more.
This information that no HEP could possibly know can be used to customize a portal page so that even for a first approximation it contains all the web information a user would normally use. Naturally that would look quite different for different users, and of course, as with HEPs, the user can personalize the initial portal page.
Inside the vertical portal
A VEP requires customization and personalization accessible from any
computer, advanced search, single sign on, links, and channels. Many more things
can also be added to VEPs such as workflow and ERP (Enterprise Resource
Planning) that are very desirable. In all likelihood any portal that is built
will evolve, adding additional features and channels, as your organization
better understands user needs and portal technology.
The portal software customizes the initial web portal page every time a user connects and is authenticated. It creates a portal page based on all the information it can obtain about a user. For example, while everyone who enters a university portal might find a calendar there, students should see exam schedules for their courses, while faculty might see exams schedules for all departments, and staff might see no exam schedules, but see university holidays. This initial customization must be kept on a server so that a user can enter a portal from any computer anywhere in the world and get access to his or her own information.
Personalize it...
A user can personalize a customized portal page. The personalization
information needs to be kept on a server or other place where it can be accessed
from any computer anywhere. Cookies are not an acceptable place to store this
information for a VEP. More extensive customization and personalization makes
for a better portal if the format of the portal and the personalization
interface are done well.
Since a VEP should be the place for a user to obtain web information it must include an advanced search capability. The search should include the ability to search all of the web, only the web pages of the user=s organization, the information on the actual portal page the user is viewing, or only information related to specific channels on the portal. The first two of these are pretty standard search capabilities and will be easy to implement. The last two will add a great deal to the effectiveness of the portal but will be more challenging to implement.
A vertical portal accesses many applications and different information sources both inside and outside a university. Many of these applications and information sources, like the portal itself, require authentication. A portal could require a user to authenticate to use each new application and data source, but that would make the use of a portal so cumbersome as to deter many users from using it. Since a user authenticates to a portal, the portal can determine which services within the organization a user is authorized to use and should be able to authenticate the users to those services as necessary. For services outside the university, the portal should also contain enough information to authenticate a user to those services as well. A user sees a single sign on to a portal, obtaining all the information accessible from the portal. While this is an essential feature of a VEP, it creates an environment that requires careful attention to security on the part of the portal builders. An abandoned computer with a logged-on portal, for example, would give anyone walking by access to everything that the owner of the computer could access.
Channels
While a portal is much more than a dynamic list of links, it will definitely
contain many links. Most, if not all, of the links will be contained in
channels. Channels are small window-like areas that contain specific information
and/or applications, such as stocks, weather, benefits, search, calendars and so
forth. A portal page consists largely of channels.
Often the channels are arranged newspaper style in columns, with several channels appearing in each column. When a portal first appears it subscribes a user to the most appropriate channels. A channel that is subscribed to appears on a portal page, though it may appear in a variety of sizes including iconified. The contents of a channel can be personalized and its size, appearance, and position within the portal page can also be personalized. In addition, a user can subscribe and unsubscribe to any channel he or she is authorized to access. Not all such channels will necessarily appear when the portal is first viewed.
Cameos
A channel gives a user access to specific information. One way to do that is
with links, which channels do use, but filling a channel totally with links
turns it into little more than a dynamic bookmark or favorites list. The goal of
a portal is get the information a user needs at his or her fingertips.
Traversing hypertext links for commonly needed information makes for a poorly designed portal. A channel needs to display the actual data or part of the actual application a user needs, not a link to it. Suppose a departmental manager needs to track very closely the amount of money left in her capital budget. She=d like the budget channel on her portal to display that amount, and other amounts she needs to track, right on the portal page. These tiny data windows within a channel, display small but important parts of critical data which I call Data (or Database) Cameos. A channel can also display Application Cameos. These are small but important parts of an application. An application Cameo enables a portal user to run a small bit of an application within a portal channel. This is how part of a searching portal channel might work. There would be no link to the search engine. Instead there would be a text box into which a user would type his search request. Depending upon the results, they might be displayed within the portal channel or on a new web page.
We need portals because the web is now being used to access all the information and applications we use via our computers. Our users need to do that much more efficiently and effectively than they can do it today. Even information such as voice mail, faxes, legacy applications, TV, radio, newspapers, journals, books, and other information sources which today are accessed in other ways, will soon be available via the web. To give all of our users the same home page will either not give them all the data and applications they need or will overwhelm them with all the data and applications everyone needs. The same home page also assumes that all of our users work the same way, which is obviously false.
How do we get started?
To get started you need to start at the beginning, which is planning, not
building. Building or buying a portal will take an enormous amount of careful
planning. Since it will be used by all people who access information and
applications that your institution controls, and since a portal must be
user-centric to be effective, you must include a wide cross-section of users
even in your earliest planning. The two worst things you can do is to start
implementation too early and to exclude potential developers and users from the
planning process.
Building a portal will be an evolutionary task, but your planning should extend far beyond your first attempts at implementation. You=ll need to work with users to determine their needs, both the information and applications they must have access to, and the customization and personalization they need. You=ll need a high level commitment to do this and a good leader whose vision and commitment can make this happen.
A portal will change the way a university treats data and applications. Building it will require cooperation between every department related to the use and ownership of data and applications. Your web development group, if you are lucky enough to have one, will not be able to build this alone. A portal cuts across many IT groups. You=ll need to have them all cooperate. A high level determination of the division of labor will help to avoid the turf wars that might otherwise result.
When you are well into your planning and determination of user needs you=ll need to make a build or buy decision. If you build your own portal, should you use Java, XML, RSS, CGI, EJBs, or ESP? While your technical folks might push to make this decision and start coding ASAP, these are issues that can only be answered when you understand what you are really building.
Different again...
And what of your venerable home page? Corporations are replacing their
internal homepages with portals. Ford Motor Company, for example, has replaced
its supplier extranet (FSN B Ford
Supplier Network) with a business portal. This portal might appear as a channel
on a supplier provided portal. It will take some time, but home pages for large
institutions are an endangered species. And they should be. We have the
technology and the hardware to build user-centric portals. Once your users see
what they can do, even the fanciest home page will never seem very useful
anymore. The web is about to look very different. Again.
Howard Strauss is manager of advanced applications at Princeton
University and is a frequent contributor to this publication.
The Edutech Report is a monthly publication of Magna Publications
The EDUTECH REPORT is published each month by Magna Publications www.magnapubs.com, 2718 Dryden Drive, Madison, WI 53704; 800-433-0499. President:William Haight whaight@magnapubs.com; Publisher: David Burns dburns@magnapubs.com; Managing internal editor: Rob Kelly robkelly@magnapubs.com. Content provided by contributing editors Linda Fleit lfleit@edutech-int.com and Thomas Warger twarger@edutech-int.com. Subscription Customer Service custserv@magnapubs.com. Copyright 2004. All rights reserved. Authorization to photocopy items for specific clients is granted by Magna Publications for users registered with the Copyright Clearance Center (CCC) Transactional Reporting Service, provided that 50 cents per page is paid directly to CCC, 222 Rosewood Drive, Danvers, MA 09123. Phone: 978-750-8400; www.copyright.com. For those organizations that have been granted a photocopy license by CCC, a separate system of payment has been arranged. One-year subscriptions: $199. Discounts available for multiple subscriptions.