LDP Project Student Portal Report Notes
LDP Student Portal Project, May 22, 2002
Leadership Development Program 2001/2002
Student Portal Project
May 22, 2002
Cecille Cabacungan, Goldman School of Public Policy
Lesley Clark, Center for Organizational Effectiveness
Rachelle Feldman, Financial Aid Office
Paula Flamm, University Health Services
Gail Ford, The Library
Kati Markowitz, Neuroscience Institute
Stacey Shulman, Department of Chemical Engineering
Dan Sullivan, Haas School of Business
11
LDP Student Portal Project, May 22, 2002
Imagine a single Website personalized to meet all your cyberneeds – one that would keep you up-to-date on campus events and academic information and would be accessible from any computer.
-- The Daily Californian, April 15, 2002
11
LDP Student Portal Project, May 22, 2002
Table of Contents
Executive Summary
Main Report
I. Charge and Methodology
II. Findings
III. Portal Development, Current Practices
IV. Costs and Phased Implementation
V. Conclusions and Recommendations; Criteria for Measuring Portal Success
VI. Three Portal Interface Options for Look and Feel; Criteria for Evaluating Options
VII. Portal Names
Appendices
Introduction, Charge, and Methodology
Appendix I – Definitions
Appendix II – Respondents
Appendix III – Student Survey Instrument
Appendix IV – Staff, Faculty, Administrator One-on-One Interview Questions
Appendix V – Staff Focus Group Questions
Appendix VI – Staff, Faculty, and Administrator Survey Instrument
Appendix VII – Portal Developer Questionnaire
UCB Student Response
Appendix VIII – Undergraduate Affairs Focus Groups, Raw Data, 2001
Appendix IX – Undergraduate Affairs Focus Groups, Draft Summary, 2001
Appendix X – UCB Student Survey Data, LDP, 2002
Appendix XI – Summary of Student Perspective
UCB Staff, Faculty and Administrator Response
Appendix XII – One-on-one Interviews, Content
Appendix XIII – Responses, UCB Staff, Faculty, and Administrator Survey
Appendix XIV – Responses, Staff Focus Groups
Portal Providers
Appendix XV–Collated Responses to Non-Statistical Interview Questions
Appendix XVI– Portal Developer Basic Data
Appendix XVII – Illustrative Examples of Portal Development
Literature
Appendix XVIII– Literature Review
Appendix XIX – Bibliography
Options – Sample Portals
Appendix XX – Portal Option 1
Appendix XXI – Portal Option 2
Appendix XXII – Portal Option 3
Portal Names
Appendix XXIII – Suggested Portal Names
Things you didn’t ask
Appendix XXIV – Faculty perspectives
Executive Summary
A student web portal would allow UC Berkeley students to access online campus services, websites, and course information from one convenient location, using a single user ID and password. They would be able to customize the portal to their own liking, adding or deleting links to internal websites, internal news channels aimed at particular groups of students, and external information such as sports, weather, entertainment, etc.
Our project team was asked to report on why the University should develop such a student web portal; interview Berkeley students, staff, and faculty to assess their level of interest in a portal and ensure that those who develop the portal understand the features these stakeholders feel a portal should have; investigate best practices at other Universities that have already deployed student web portals; and suggest management models for the portal project. We were also charged with presenting three possible user interfaces, and recommend names for the Berkeley student web portal.
The central goal of the Chancellor’s e-Berkeley Initiative is to transform the day-to-day operations of the University by reducing paperwork; putting more information services and transactions online; and streamlining access to course information and content. A student web portal would collect these campus services and functions into a single website, making it easy for students to find and use online services, and thus increasing the likelihood that the University can attain the strategic goals laid out in the e-Berkeley Initiative.
We used a combination of surveys, focus groups, and one-on-one interviews to gather information from Berkeley students, faculty, and staff, and from key personnel at other institutions that have operational student portals.
Berkeley students, and the staff who deliver services to them, are very excited by the possibilities a student web portal offers. Roughly 70 percent of student respondents said a portal would make their lives easier. However, when forced to rank-order a portal amongst a list of other applications that would need to be built in order to deliver campus services through the web, both groups put the portal at the very bottom of their list. A portal would not make much of an impact on their lives unless the University builds these other applications either concurrently with or prior to a web portal.
These groups want a portal that is easy to use; that is secure and protects student privacy; and that is linked to a roles database so that information can be targeted to particular groups of students. The roles database is crucial to the success of a portal, as it will allow students, staff and faculty with similar interests to identify each other. Students, faculty and staff expressed several concerns about a portal, including the need for the project to be sufficiently funded; the need for a campus infrastructure robust enough to handle increased web traffic as a result of a successful portal; and that as many systems as possible be integrated into the portal, since the portal’s usefulness to them will largely be a function of how much campus business students can conduct online.
Other institutions that have successfully deployed student web portals reported that their portal development project encouraged the development and integration of existing and new systems, and pushed data owners to think about which audiences they want to reach, what services they want to offer, and how to best package information and applications. Students immediately began using these portals in high numbers, even though the portals were still works in progress at the time of launch. Students are satisfied with the ways that portals make it easier to conduct campus business, and portals heighten student expectations of other campus online services.
We found no common model for managing the development process as a whole. For example, some schools set up a steering committee of stakeholders from across campus; some let the campus information technology group guide all aspects of the development process; and others gave ownership to a campus-wide “E-initiative” committee similar to the e-Berkeley group at UC. And there was no common model for the management of content once the portal was deployed. Some gave this responsibility to the university public information office, others to the campus “E-initiative” group or a special steering committee established for this purpose.
The amount of time it took to develop these portals ranged from five days to one year. The number of staff FTE involved varied from two to 45 people. Funding levels also varied widely, from less than $100,000 to $2.5 million. There was no correlation between level of funding and the length of time it took to complete the project. However, there was a direct correlation between the level of satisfaction with the portal and the length of time the portal had been in production.
We did find some common experiences. All institutions report that the technical management of the portal resides in an information technology unit. All believe that high-level executive support was key to the success of their portal development project.
Based on our research we have come to a number of conclusions:
Build it and they will come. The Berkeley student web portal will develop over time; it will not realize its full potential until existing systems are integrated into the portal framework and new systems for delivering services through the web come on line. However, students will begin using it immediately, and there is no reason to delay the development process.
The portal will support multiple campus goals. These include the e-Berkeley vision of transforming the way campus business is conducted; improving the undergraduate experience; and building community by allowing people with similar interests to find and connect with each other.
The portal doesn’t have to be expensive. However, it does need support at the highest level of administration, and it needs steady and ongoing funding throughout its life. Content providers (both staff and faculty) need training, consultation, and acknowledgment and reward for doing their jobs in new ways.
Set up clear lines of authority before beginning development and implementation. Technical management for the Berkeley student web portal should belong to the campus Information Systems & Technology group. However, no single campus entity seems to have overall responsibility for managing internal campus communications. The first steps in developing a student portal are to assign this responsibility and to support this assignment by establishing a management team to bring together the many aspects of student portal development and deployment (e.g., technology, content, training and support, design, policy, procedures, etc.).
A tab-based user interface provides the greatest flexibility for users and developers. Tabs allow students to toggle quickly between different types of information. As more online content becomes available over time, it is a simple matter for developers to add new tabs to accommodate and organize the new content. Allowing students to create and name some or all of the tabs on their personal portal pages wound give them the maximum flexibility in choosing how to organize information to suit their own needs.
Names for the Berkeley student web portal. In descending order of preference, we suggest the following names for the portal: MyCal, Bear Essentials, Sather Gateway, CalWeb and Oski Online.
Section I: Charge and Methodology
UC Berkeley is discussing the topic of portal technology. Whom might a student web portal serve? What content would it contain? What would it look like? Should the campus invest in a student portal? If so, where would this rank with other technological proposals under consideration?
charge
To further this discussion, five campus leaders (Susie Castillo-Robson, Registrar; Lisa Chow, Business Manager, Student Information Systems; Tim Heidinger, Manager, UGA Computing; Christina Maslach, Vice Provost, Undergraduate Education; and J.R. Schulden, Director, IST, Student Information Systems) have sponsored a Leadership Development Program project to
1) Investigate and report on the reasons for doing a student portal. What would be the University’s goal(s) in providing such a portal? How will the campus know if the portal realizes these goals?
2) Summarize best practice research on student portals (on-campus and/or at other institutions.) Report on the gains portal designers seek and what their actual experience has been (both the pro’s and con’s) when putting a portal in place. Collect information on who was involved in development, design, and ongoing management of the portal and its content.
3) Interview UCB students, student service providers, faculty and administrators, and report on the benefits they would seek from a student portal, as well as concerns they may have about authorizing development of one. Question users and providers as to where they would rank development of a student portal compared to other web-based student-oriented services.
4) Suggest campus groups that should be involved in developing and designing a UCB student portal. Identify these groups by answering: a) whom do the students interact with the most? b) what student groups exist that speak for the student body? c) what high level administrators are most responsible for the university’s image? d) who might be involved in managing the technology, e) who might be responsible for managing the content.
5) Present three options of what a student portal might look like and what might be its top twenty enterprise applications (e.g., calendar, course information, news, services, sporting events, etc.) Demonstrate and discuss the pro’s and con’s of various user interfaces. Determine the criteria for evaluating these options.
6) Recommend names for the student portal (including non-Bear names)
The group’s work spanned five months, from January through May 2002. Our findings, observations, and conclusions follow.
what is a student web portal? and other definitions
There are almost as many definitions of a student web portal as there are people talking about them. A portal and the information that it helps to organize are two sides of the same coin – great portal software without good information is not useful. Neither is usable without a network infrastructure that supports fast access by thousands of simultaneous users. In talking with our colleagues we learned a great deal about the larger world of portal development – look and feel, content, the need for integration, management models, etc.
We discovered a wide range of sophistication among students, faculty, and staff, in their knowledge about portals. This is the working definition we took to the lay campus community:
The portal would provide students with access to online campus services, websites, and course information from one convenient location, using a single user ID and password. Students would be able to customize the portal to their own liking, adding or deleting links to internal web sties, internal news channels aimed at particular groups of students, and external information such as sports, weather, entertainment, etc.
We also found that there is a world of portal-related terminology that is not common knowledge. For purposes of this report, we try to avoid jargon, but may not have been totally successful in doing so. See Appendix I for a list of terms.
methodology
We used a combination of surveys, focus groups, and one-on-one interviews to gather information from students, faculty, staff, and portal developers. The on-campus respondents come from a variety of academic disciplines and administrative departments.
The student survey focused on what content and features students would find most useful in a student web portal. The staff / faculty / administrator interviews and focus groups expanded the inquiry to include questions on management structures and portal design. Portal provider questions focused on the processes undertaken to conceive, design, implement and manage their portals, as well as their opinions on whether their portals were meeting expectations. We also took an introductory look at the literature on portals, and at how academic institutions are trying to use the web to improve their business applications. Survey instruments and responses can be found in the Appendices.
and there’s always more
Since we did many one-on-one interviews, we heard ideas, suggestions, frustrations, and wish-lists that are slightly outside our scope. Nonetheless, these asides can prove useful, and have been included as an Appendix.
Section II: Findings
We include responses from 328 students, eighty-five staff and administrators, nine faculty, and nine institutions that have operational portals. Not surprisingly, we did not receive unanimity of response on any topic, although there are trends.
caveat on findings
Respondents on campus could not easily distinguish between the portal (as framework, connector, gateway) and the back-end systems (sources for the actual information/services). Our findings, therefore, reflect responses from populations with varying degrees of familiarity and understanding of portal and interactive system technology.