Campus Web portals are nothing new. Emerging over ten years ago, they have been widely adopted by institutions of higher learning as a means to provide convenient, single sign-on access to campus services such as webmail, financial aid, course management systems, and more. The portal replaces the college website — which in many cases is turned into an “enterprise” or marketing site — and is the primary means of accessing campus information for students, faculty, and staff.
In principal, portals are the ideal place for students and faculty to discover library resources. They operate on a dynamic “push” concept, where chunks of highly personalized information can be “pushed” to just the people who need it. For example, a nursing major might see the CINAHL database on her library resources “channel,” while a history major would not. Circulation information, such as fines, checkouts, and holds, can also be displayed on a student’s portal page. The potential of the campus portal for library resources was recognized by EDUCAUSE as early as 2001 in a report that encouraged libraries to actively engage in campus portal development.
In my experience, that potential has yet to be realized. I have worked at two institutions with campus web portals: one used CampusEAI’s portal product, and one was built on Microsoft’s Sharepoint server. In both cases, the library has found it challenging, to say the least, to develop truly dynamic, customized links to library resources. These are some of the difficulties I’ve experienced being behind the portal:
- Technical glitches: The secure (https) nature of portals necessarily convolute EZProxy access to library subscription resources. For several weeks after my library migrated to the portal, EZProxy access was almost entirely inhibited, and we had many frustrated users. Those problems have been somewhat remedied, but off-campus users still frequently have difficulty getting through. Access is worse on certain browsers — Internet Explorer in particular is notorious for their security messages that many patrons do not know how to bypass or disable. Linking to non-https external resources (i.e. LibGuides) can also be problematic, as users are taken out of the portal environment and often cannot easily find their way back.
Having the library on a secure site can cause problems
- Not managed by the library: when the library’s website migrates to the portal, site administration often moves to the institution’s centralized IT department. This makes sense since the portal is an institution-wide interface and should be centrally managed. But with library resources and services living primarily in virtual spaces, librarians need to be centrally involved in their development and maintenance. Institutions that adopt portals need to ensure that the library-IT relationship is closely integrated and collaborative if we are to provide relevant and useful services. In my experience, this has not been the case.
- Inhibits knowledge sharing: I’m concerned about how portals are increasingly inhibiting knowledge sharing in the LIS community. With more and more of our web pages, documentation, and innovations hidden behind password-restricted sites, we are less able to learn from each other. There may be colleges and universities out there who are doing an amazing job of embedding their services into portals — but because I can’t see them, i can’t learn from their example. We thus are becoming more silo-ized and isolated from each other. My open-access-loving librarian nature rebels at this state of affairs.
- Duplication of interfaces: Library web sites are already far too complex, offering users a bewildering choice of access points. The discovery layer, the catalog, the A-Z list, the database list, the intitutional repository …. no wonder our users give up and flee to Google. Complicating things further, many libraries that have migrated to portals simultaneously maintain a presence on the public-facing institution website. We do this because we don’t want to entirely disappear behind a password: we want prospective students and faculty, as well as our library colleagues, to be able to find us. But this inevitably leads to complications. For example, since the OPAC resides outside the portal, how do we maintain links from within the catalog? How do we link to library hours or even library home, when we have two library homes depending on where the user began?
The Portal at SNHU
Conclusion: Because the portal is “where students live,” it follows that it is also where library resources should reside. But ten years into this experiment, how are we doing at getting library resources into the portal? In my experience, we have not done a very good job. This is not always our fault: we are stymied by limitations and restrictions that are often at the institutional level. I haven’t yet given up on the promise of the campus Web portal, but until library staff have truly collaborative and equal relationships with IT, we will not be able to provide the best service to our patrons. We still have a long ways to go.
the cloudy librarian 