Library Portals: A Minority Report

With the growing acceptance of web portals on university campuses, many librarians are considering building library portals to make their collections accessible to users who expect all knowledge to be obtainable with just a few clicks from inside a web browser. After all, the World Wide Web has become the marketplace for documents, goods, services, and ideas. For many people, especially students, if something is not on the web, it does not exist.

This trend is especially challenging for libraries, which are the traditional keepers of knowledge but whose knowledge is largely kept in many millions of books and journals—not on the web. The idea of a library portal is misdirected. While it is vital that libraries have a presence on university enterprise portals, libraries should build portal pages, portal channels, and portal cameos rather than entire library portals.

We need a portal because it should make every user more efficient and more effective. Portals deliver to every user, in a few clicks, all of the electronic information and services they commonly use in the way they work best. Homepages, by contrast, give users general information, most of which no one ever wants. After all, library users want to get their work done, not spend hours following hypertext web links or doing web searches.

Many universities have or are considering more than one portal. The mistaken reasoning is that faculty can have a portal that addresses faculty issues, students can have a student portal for student issues, and when people need to do library work they can start up the library portal. But of course everyone at the university needs to access the university calendar, wants to look at medical plans, to buy tickets to events, and so forth. In which portal should shared features be placed? Any one we choose makes the others less useful. If we replicate the features—it would be nice to see the library hours in the library and the student portal—it is difficult and expensive to keep all the replicated parts synchronized, even if we could. Different portals often use quite different technology, making it impossible, for example, to use the same electronic calendar in two different portals.

Another problem with multiple portals is that a person often has multiple roles. Many students are part-time faculty. Do they use the faculty portal, student portal, or both? And everyone would use the library portal if there were one. In addition, instead of personalizing just one portal, every user would have to personalize them all.

Most important, if there is more than one portal, a portal cannot replace your desktop. It cannot be the place where you access all the information and services you commonly use. If it is not those things, then many of the benefits of having a portal will not be realized. If there is to be a library portal it should be the only portal, but that choice is inappropriate for colleges and universities. Library information needs to make its critical appearance in campus portals in some other way.

There is great confusion even among the technical cognoscenti on the definition of a portal. Add to that the existence of many kinds of portals.

A web site such as www.millstones.com, for example, is a vertical niche portal. It aggregates all the important information and web pointers on a particular topic in a single web site. There is a vertical niche portal for almost every imaginable interest. Should librarians build a library portal, it is likely that it would be a vertical niche library portal, which would be used only by those with a very strong interest in libraries, a tiny part of a potential audience.

Traditional homepages are institution-centric, providing the same view to all users. Every user who keys in the URL of an institutional homepage sees exactly the same thing: a page that says wonderful things about the organization, some general information, and links and search capabilities so that users can attempt to navigate the complex tangle of institutional web pages. These pages are usually built by a web design group that is part of an IT department.

Universities and corporations are building enterprise portals. These are portals that use all of the information known by a particular institution to build automatically a customized web site for each member of the institution. Enterprise portals are a radical departure from traditional homepages. They dramatically change the way people use the web and the way web pages are built. To build them successfully, as many universities have, requires planning, money, commitment from senior management, data sharing across the institution, and usually a change in IT culture.

An enterprise portal is a user-centric web site that provides users with access to all of the electronic information and services they commonly need. That access includes data and services on their own computer, local networks, and the web. Every user of an enterprise portal sees a unique web site customized for him or her. Users of such a portal identify themselves to the portal, often by entering an ID and password.

Once the portal knows who the user is, it accesses all the institutional information about that person and displays it on a web site customized for that person. Among other things, it may know a user's job function, manager, subordinates, insurance plans, benefits, library books borrowed, vacation schedule, authorized applications (can she buy $5000 worth of office furniture?), address, marital status, and much more.

Every portal page the portal system builds is specific for each person. The creation of user-specific web pages by the system is called customization. Another area of customization is the portal's ability to recognize the device that is being used to view it. It must format web pages quite differently for a palm top PDA, web appliance, or web cell phone than for a desktop computer.

Even the cleverest portal system cannot make the ideal web site for each user. What web search engine, for example, should it place on the portal? My favorite is AltaVista; yours might be Google. Where should access to library information appear? I'd like it at the top of the far right column. You might like it at the bottom of the middle column. Someone else might wonder why he or she needs access to the library at all. To make a portal most effective, once the system has been customized, users need to be able to personalize it to make it fit the way they work.

As we use our customized, personalized portal it needs to be able to adapt to how we work and how our lives change. A freshman is focused on trying to stay at a university while a senior is most concerned with getting out. A portal needs to change its appearance as our job, marital status, location, benefits, and so forth change. It must always present us with the most appropriate user-centric portal possible. It also needs to change and make suggestions as it detects ways that it can better support the peculiar way each of us does things.

A customized, personalized, adaptive portal replaces the electronic desktop that we see when we start our PCs, Macs, Linux machines, or whatever else we use to access the web. The operating system (e.g., Windows) or hardware we use becomes irrelevant; our portal becomes our electronic desktop. It should make all of us efficient by giving each of us ready access to all of the information we need most in the format that we can use best.

A portal changes the way we use the web. The web portal becomes the tool we use to access information and services. It is the first thing—and often the only thing—we see when we turn on our computers. It is ours, not the institution's. Building such a portal requires that data and services across the institution be shared and that all data be exposed to the scrutiny of having it online.

Getting the necessary groups to work together cooperatively to build an effective web portal is a much more formidable task than the considerable technical challenges involved in building a portal. A portal is an information system. While it requires excellent applications, its success primarily rests on its ability to deliver information to users.

A portal is displayed as one or more web pages accessible by any web browser. In most cases a user has so much information that it would be inconvenient to put it all on one page. In fact, since a web page can be any size, all the information could be put on a single page, but then there would be lots of vertical and horizontal scrolling. A portal page is a collection of related information. For a student, for example, one portal page might contain course information, another information on organizations, and yet another reference tools including, of course, those from the library. During customization, the portal system decides what pages to build and how to organize the information across those pages.

A user needs some way to navigate from page to page. The most common is to have a tab for each page and to allow a user to click on a tab to display a particular page. When the portal is first displayed, it will show the page having the leftmost tab. The order of the tabs, their text, and the contents of each page may be personalized by each user. While the portal might set the Courses tab first for students (and not include it at all for staff), a student could make it the last tab and call it Great Lectures.

Each portal page may be divided into columns of information. For some unknown reason, three columns have become the standard for portals, often with the middle column wider than the other two. But many portals allow this attribute to be personalized, too. If two columns or one work better for you, that format is just a few clicks away.

There is room at the top of the columns for the navigation tabs and for portalwide alerts. Alerts are messages targeted to a subset of portal users. Portalwide alerts are very general. There may also be alerts at the channel level, which are just for subscribers to the channel in which the alert occurs.

Each column of a portal page is populated with text, links, images, multimedia, form controls, and cameos— small amounts of data. These are usually grouped into channels, which are small windowlike areas containing related information. It is tempting to think of channels as applications and to map applications into them. One might have a human resources channel, a purchasing system channel, and a library channel. While this might work, it is far better to define channels functionally. A student might have a degree audit channel, for example. This might include parts of the transcript application, a list of the courses one still needs to take for graduation, links to the law school she plans to apply to, and the rules for taking pass/fail courses.

Users may subscribe and unsubscribe to any channel they are authorized to use. The channels may come from within the institution or may be offered by outside vendors and institutions. They may contain public or licensed content, and subscriptions may or may not be free.

The text areas in channels may be static or created on the fly. Of course text can usually be personalized by choosing fonts, font sizes, colors, and so forth. Links, which should be used sparingly so that the portal is not turned into a big list of bookmarked web pages, may point to external or internal web pages and services. Images and multimedia include static images, animated images, images that one can interact with, movies, 3-D images, sounds, and the whole menagerie of digital graphics and audio.

Form controls include pull-down menus, list boxes, buttons, and text boxes in which data may be entered. Most importantly, channels can include data cameos, data from an application, database, or web page. There are also application cameos, areas into which a portal user can enter information that is used to run a small part of an application or to run it in a particular way.

To see one great advantage cameos have over links, consider a link to www.noaa.gov—the federal web site for weather. This will provide the weather for one's local area as well as for the rest of the world. It will also tell all about tornadoes and hurricanes and explain everything from advection to zonal flow. But this is far more information than anyone would want for local weather in a portal. A portal user would just like to know today's weather in a quick glance without using much area on the screen. A cameo allows one to display only the tiny pieces of data that are pertinent, such as the high and low temperature and maybe an icon showing if it will rain. By displaying a cameo instead of a link, the actual information one needs is right on the portal screen—no clicks away.

Suppose you constantly need to track the current value of an unspent capital budget. Why link to the report and check that number when it could appear as a cameo in the upper-left-hand corner of your screen—or wherever you decide it should appear—and be automatically updated as money is spent and encumbered.

Any library portal would either have to be a vertical niche portal, a university's top-level portal, or one of many university portals, were a university misguided enough to have more than one. None of these options will serve the library or, more importantly, its users well.

Most portal users want library information, such as the catalog, access to electronic journals and licensed databases, the books they need to return, library floor plans, e-reserves, and maybe even lists of new acquisitions that match their profile. Personally, I'd like an application cameo that would allow me to search the Oxford English Dictionary, another that would let me search quotations, and yet another for searching the music library's CD collection.

Libraries would best serve their users by building portal pages, channels, and cameos rather than portals themselves. A portal page would be much easier to build than a channel since it is just a regular web page, but the library should at least create a variety of pages for different constituencies: freshmen, seniors, graduate students, faculty, office administrators, and as many more as can be defined. The IT folks should also be encouraged to allow personalization of the library pages.

One effort, initiated in 1995 by OCLC, that every library portal content builder should examine closely is the Dublin Core project (dublincore.org). Dublin Core addresses many key issues involving the creation of web-searchable documents and making them available via networks and in portal channels.

Library portal channels would provide the most value and would work best within portals. All the features and facilities of channels would be available, and the library could offer a rich variety of channels that portal users everywhere could subscribe to.

Today distance education is growing rapidly. Nontraditional and part-time students outnumber full-time students. Traditional students on campus wonder why there are all those books in the building that houses their favorite coffee shop. How can we get information to students who spend little or no time on campus and, when they do, rarely set foot in the library?

Portals will become an increasingly important information delivery system, and libraries have to be part of that. They represent an opportunity for libraries to turn around their traditional paradigm: instead of building libraries—real or virtual—for users to come to, the library can now more easily come to the user. The best way to do this is to get involved immediately with—or lead—campus portal projects and to create compelling library portal pages and channels—not library portals.