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 PolicyLesley Clark, Center for Organizational EffectivenessRachelle Feldman, Financial Aid OfficePaula Flamm, University Health ServicesGail Ford, The Library

Kati Markowitz, Neuroscience Institute

Stacey Shulman, Department of Chemical Engineering

Dan Sullivan, Haas School of Business

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, 2002Table 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 DefinitionsAppendix 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 XVCollated 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 didnt ask

Appendix XXIV Faculty perspectivesExecutive 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 Chancellors 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 portals 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 doesnt 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 Universitys 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 pros and cons) 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 universitys 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 pros and cons of various user interfaces. Determine the criteria for evaluating these options.

6) Recommend names for the student portal (including non-Bear names)

The groups 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 theres always moreSince 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: FindingsWe 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 findingsRespondents 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.

university goals a student portal might help to realize

Most of our respondents believe that an integrated student web portal would help the campus meet a variety of goals shared by students, faculty, staff and senior administrators. These include:

building community by building relationships

improving the quality of student life, thereby improving retention

aiding technological advances in teaching

fostering a consistent sense of University identity

showcasing what the University offers

improving operational effectiveness

aiding campus recruitment efforts, especially if the student portal included a prospective student variation

pros of a student portal

Provides easy access to different online systems and information sources. A portal gives students one place to enter their on-line Berkeley experience and can increase students productivity. By using a single log-on (CalNet I.D. and password), a student can do business, receive information and services organized according to their needs (rather than administrative unit), and access course and campus event information of particular interest. Students can increase their productivity, spending less time searching for information.

Enhances communication. A portal can help sustain positive contact between each stakeholder and the University and provide conduits for communications within interest groups. If all campus communications are accessible through one gateway, students are likely to check their portal often and receive messages and information in a timely and efficient manner. Students receive information tailored to their areas of interest even if these areas are outside their major or department. A learning management system integrated with a student portal would provide faculty with an easy way to communicate schedules and deadlines, set up discussion groups, send out assignments, give quizzes, and send notices. An integrated calendar system would give staff and campus groups an easy and consistent way to communicate information about deadlines and events.

Portability. Students can access their information and favorite links from anywhere they can access the World Wide Web. This gives students more flexibility in when, where, and how to conduct their student business.

Enhances sense of Berkeley community and image. Consistent look and feel in a portal can enhance the University image. The ability to connect with others with similar interests can help build a series of on-line "communities" that in turn create a sense of inclusiveness in the overall university community. A portal also signals the institutions effective use of technology in serving and educating its students.

Enhances effectiveness of in-person services. While students can get their everyday "business" done on-line, faculty, advisors, and other staff can focus on giving higher-level and more in-depth, in-person service and education. It could free up class time for less lecture, allowing more discussion and interaction.

Provides framework and motivation for development of on-line services and applications. A student portal encourages integration and standardized use of technology; it will increase efficiency and save costs otherwise associated with maintaining disparate technologies and database structures. The portal provides a campus-wide umbrella which focuses strategic development of enterprise systems. Integration of existing and new systems leads to increased efficiency.

Encourages data owners to rethink and improve web offerings. Portal developers report that portals encourage data owners to think about which audiences they want to reach, what services they want to offer, and to package information and applications accordingly. To the extent that a portal succeeds in improving internal communication, other campus and departmental websites will become focused on the external audience, helping to resolve a common dilemma faced by web designers who now struggle to address the needs of both internal and external customers.

concerns about developing a student portal

Overall, students had few concerns and considerable enthusiasm for the portal and other applications that they see as making their lives easier. There were, however, several concerns expressed by students, faculty, and/or staff, which need to be addressed:

Resources. Budgetary support needs to be in place for hardware, software, technical staffing, training, and staffing support for faculty as well as administrative units. Funding needs to be available for the development of new applications behind the portal and for connecting existing campus systems (e.g., Bearfacts, Telebears, Summer Session, Library, CARS, etc.) Funding is not a one-time investment portals are iterative and their potential evolves over time and funding needs to be stable and available for the life span of the project. Robust and scalable. Technical infrastructures must be able to support heavy traffic. Integrated. The more systems that can be integrated behind the student portal, the more useful (and used) it will become. Governance. There is a perception that nobody currently owns or is responsible for establishing and maintaining internal campus communications. Clear guidelines and authority need to be established. (See Management Models section, below, for potential models.) There is consensus that students shouldnt be overwhelmed with information, and there needs to be a structure in place to ensure this outcome.what capabilities / features should portal software have?

Easy for students to use and customize. Students, staff, faculty, and portal providers report that a portal should be easy to use; it should support a single logon and password for users to access all campus functions provided by the portal. It must be accessible and useful for disabled students. Other features specifically named include: clean design with a consistent look and feel; fast, even over a phone line; easy subscription tool; search tool; easy navigation, without recourse to the back button; feedback/help desk/how-to pop-ups when necessary.

Be developed in conjunction with a roles database. There is considerable interest in the possibilities that an extensive roles database would support. In this context, faculty, staff, and administrators hope that a roles database could be filled system-to-system; by staff wanting to distinguish among clienteles; and by students self-selecting communities/topics of interest.

Easy for data owners (content providers) to use. Portal providers as well as UCB staff and faculty recommend an easy-to-use content management tool that would not require high levels of technical knowledge, and that can support a large number of data owners.

Notification to students personalized, generic, requisite. Some students and staff are opposed, in principle, to requisite information but as shown in the following table, over half of the students surveyed expressed a desire to receive important information from their colleges and the Registrars Office, with another 42% expressing an interest in receiving unsolicited general campus news. Some portal providers from other campuses as well as UCB staff, administrators, and faculty suggest that the portal should allow the campus to provide information to students that they could not remove.

Allow for integration of existing systems, growth of future systems, and communication between systems. The portal must be developed so that the integration of existing systems and addition of future systems is supported. Not too expensive, but not underfunded. (For more on costs, see below.) Secure and private.

how does the portal rank on peoples wish-list for near- or long-term development of applications?

Students ranked applications as follows, in descending order:

1. academic administrative transactions (e.g., enrolling in classes, requesting majors and minors, electronic advising, requesting transcripts and diplomas, etc.)

2. an integrated calendar system (including course schedule, deadlines, daily appointments, etc.)

3. campus financial transactions online

4. a learning management system

5. a student web portal

Faculty and staff who provide services to students ranked applications, as follows:

1. academic administrative transactions

2. learning management (course-specific)

3. financial

4. an integrated calendar system

5. a student web portalFrom the perspective of the e-Berkeley vision, a student web portal provides students with a single doorway through which they may easily access other applications. The low ranking accorded to a portal by respondents implies that they feel a student portal would not make much of an impact on their lives unless the campus builds other integrated enterprise applications either concurrently with or prior to a web portal. Portal developers from other institutions report that by initiating a portal project, they were able to use it to focus and encourage development and integration of legacy and new enterprise systems.

top 21 links

A student portal will likely connect students to two levels of content: transactional and informational. Transactional applications are those which enable students to conduct campus business via the web. Informational links would connect students to campus and external websites of interest, but do not offer interactive capabilities.

Based on our student survey data and on our understanding of whether or not various campus offices currently allow students to conduct business transactions via the web, the top 21 links follow:transactional linksinformational links

1. Library1. UC Events

2. Black Lightning notes 2. Bay Area entertainment

3. Office of the Registrars transactional systems (e.g., course enrollment, ordering transcripts, etc. via BearFacts and Telebears)3. Weather

4. Bookstore 4. Book price comparison engine(s)

5. Financial Aid Office5. Daily Cal

6. Campus Career Services6. Political news

7. Web-based email7. Regional news

8. External career services

9. Student associations and clubs

10. Recreation

11. University Health Services

12. Departmental Advising and news

13. Central campus advising and news

14. Parking & Transportation office

In addition to those cited above, respondents urged us to include resources for affinity groups within the larger campus community (e.g., student parents; disabled students; transfer students; etc.) and to the Office of Student Life.

As campus applications come on line allowing offices to begin delivering services through the web in the transactional sense, they could move from the Informational list to the Transactional list.

who should be involved in design (navigation, look, and feel)?

The staff, faculty, and administrator groups view design as an iterative process and feel that the Student Portal should be developed, deployed and changed as necessary. They suggested that the following individuals/groups be included in design:

professional web designer

communications professional

technical representative

University branding/marketing professional

students

Our survey of portal developers surfaced three approaches to design:

IT group that implements/develops the portal together with a steering committee of stakeholders including students, service providers (from central/outlying units/departments, faculty, administrative systems) and executives.

IT group responsible for implementation only.

A subgroup of the e-initiative (in our case e-Berkeley) committee specifically charged with this task.Our charge suggests that design should include those units with whom students interact most, and should include representatives from student groups that speak for the student body. The following table represents results to questions we asked in this regard:

Our student survey revealed that students interact mostly with the Library (64%) and the Registrars Office (62%). The Graduate Assembly and the ASUC represent UCBs students, but in seeking respondents for our student survey we discovered that neither group currently has an officer charged with issues of technology.

WHAT MANAGEMENT MODELS DID WE DISCOVER?

Whatever management model is selected, it must effectively guide and coordinate issues raised regarding policy, standards, technology, content, security, training, support, and administrative procedures. UCB staff and administrators underlined the importance of a student portal focusing on internal rather than external communications and commented that responsibility for this kind of focus is not currently clearly assigned.At UCB, most of those surveyed believed that technology issues should be delegated to IS&T and that responsibility for content and granting authority to access the content should reside with data owners. Both technological and content decisions should conform to existing and developing standards, as well as to campus-wide policies for security, trademark, etc.Management models of successful portals include:

Steering committee of stakeholders

IT group guiding content in the process of integrating services

E-initiative committee (e-Berkeley)

Executive nominated for this purpose

Implementation work group

University Relations/ Communications / Public Affairs

Combination of steering committee and small (3 to 5 member) executive decision-making group.

There is a general belief that high-level executive support (e.g., Provost, Chancellor, Cabinet) is instrumental in the success of the project.

Section III: Portal Development, Current Practices

During extended interviews with portal providers at nine universities, we found different processes leading to the successful development and deployment of portals. It is clear that the functionality of a portal develops over time. The variety of experiences we encountered provides us with no clear sense of best practices at this point in portal history. Rather, we present here a summary of trends and management models, as well as our conclusions. Some intriguing and illustrative examples are provided in an Appendix.

general information

IT professionals, from web developers to executives, were interviewed at the following institutions:

University of Texas

University of British Columbia

University of Minnesota

UC Davis

UCBs Haas School of Business

University of Washington

Stanford

UCLA

UC Irvine

Portal continues to mean different things to different people. At the core, however, is the desire to enhance community, help students organize, save time and resources by streamlining institutional processes, and provide services that focus on stakeholder needs and desires, not those of the unit providing services. In its simplest form, a portal provides, as Randy Ebeling from University of Texas calls it, a mobile bookmark facility that can be accessed anytime, anywhere in the world. Its hidden power lies in the opportunity to integrate discrete business processes that will render information to better serve students.

identifying need for a portalOther academic institutions identified their need for a student portal in a variety of ways:

IT professionals from systems development groups saw the portal as the next step in the series of electronic services provided to their stakeholders;

IT professionals from the central unit reacted to threat of campus departments developing or purchasing systems based on a wide variety of architectures and standards, and difficult to integrate into a campus-wide system;

IT professionals realized that a portal mechanism would enable the entire institution to restructure its relationships with the stakeholders as well as its web presence;

Students, through their governing bodies, pushed specifically for a student portal.

After preliminary identification of the need, in all cases except one, corroboration was provided by a mixture of stakeholder groups (students, faculty, and staff) through:

Surveys

Public meetings Interviews

Focus groups

Success, before implementation, was defined by all as being a function of usage: if people use it, then its a success.

design processStudents at most surveyed institutions were not directly involved in format and functionality design (IT mostly decided these issues).

Format

Level of customization (not necessarily unlimited, just several options)

Consistency of design throughout

Simple, clean, uncluttered look

Functionality

Single log-on

Role-based authentication/authorization

On-line student systems, as available

Learning management system, if available Webmail

Search engine

Calendar, if available

General ease of use

Other concerns in the design phase revolved around:

Scalability of system to high usage

Speed

Costs

Engaging sponsorship and partnerships for content provision Integration of background systems

Desire to organize by subject area, instead of institutions organizational structure

A desire to foster communications

Most developers reviewed institutional portals, if available at the time of their projects start. The decision to choose one over another depended on:

Familiarity to user (similarity to previous system, existing other systems)

Alignment with institutional, and/or system-wide, e-architecture standards

Building community and proficiency within IT group by deciding to do it internally Costs

Match between available technical expertise and the system

Alignment with electronic/software standards

While students or other stakeholder groups might not have been involved in the design, beta releases or prototypes were tested with student/stakeholder representatives, and necessary and appropriate changes were implemented before production.

vendors, implementation timeline, fte, costsMost respondents chose either to build portal software in-house, or to use a freeware product like uPortal or Metadot. Time of portal development (between end-of-design phase to first production release) varied between five days to one year. FTE numbers involved in the development also varied widely, from two to 15-45 people. Funding ranged from less than $100k to $2.5 million over two years of development (in most cases FTE costs not included.) There was, however, no direct correlation between levels of funding, numbers of FTE, and timeline to completion.

functionality and customizationAll outside institutions surveyed have multi-customer portals of which students are only one of the served populations. The majority offer:

Services at the interactive level, and some transactional features (added as they become available)

Customization feature a spectrum of templates, not completely free choice Single log-on (although not always as a one-stop-shop feature) and role-based authorization

Access to non-campus information

The real substance of portal functionality is in its access to enterprise applications. Most portal providers report that the portal spurred an increase in the development of enterprise applications, and though unsubstantiated by hard statistics, they think that all available applications are more heavily used since the portal has gone live. Moreover, they report that the portal pinpointed the need for development of other specific enterprise applications to provide enhanced services to stakeholders.

An interesting feature of some portals is the cameo, a window within a channel that displays small but important pieces of information. This information (e.g., how much money is left on a students meal card) updates every time the user logs on and can be drawn from data, application, or web sources.

The question of locked-down (non-removable) information channels is handled differently at different institutions. Models we found include:

No locked-down channels

One locked-down channel (for urgent university news, or portal-specific news) that appears on the log-in page but not on the students customized page(s)

One or more locked-down channels that appears on the students customized page(s)

In lieu of locked-down channels, some institutions have a notifications section which appears on a students page only when the information applies to the individual and is time-sensitive or otherwise of critical importance.

usageUsage patterns vary according to the length of time from the systems release date. Most established portals report between 60 and 99% usage by students; those that are brand new or limited in scope have lower usage rates. Although several institutions had elaborate public relations campaigns before the portal release flyers, public forums, meetings, presentations, inclusion in student orientation sessions, demos, newspaper articles, banners, video clips, give-aways, etc. most institutions report that students found out about the portal immediately, whether they invested in marketing or not. Moreover, usage started immediately. Feedback mechanisms range from email links on the portal, help desk, input/feedback solicitations, public forums, other university review mechanisms, to a designated official for student affairs (including portal affairs).

technical management All institutions report that the technical management of the portal resides in an information technology unit. The technical staff involved in maintaining and further developing the system ranges from two to seven FTE, ranging in job duties: web architect/administrators/editors, programmers, and students (probably from computing sciences).

content management Institutional portals we surveyed used the following models of content management:

University Relations/Communications/Public Affairs

E-University steering committee Technology group

Technology executive in charge of portal/e-affairs

Steering committees in conjunction with executive decision-making group

We found that standards for content providers are spotty and not necessarily enforced:

Developers guide through integration process

Published guidelines for content providers

Template for content provision Existing general electronic information policies/procedures

Elaborate set of step by step procedures according to content type

None

Content ownership includes:

Systems for interactive/transactional links Schools, departments, various offices

IT group

problem Identification

Technical difficulties encountered by portal developers include:

System technical complexity (JAVA)

Technology is still new, doesnt always scale and can be unstable

Refining a roles database

Ensuring functionality for disabled students Integration of existing services

Browser/specific application dependence

Length of time for development

Note: portal developers reported no security problems.

Content management difficulties include:

Learning curve for content providers

Content providers requesting right to mandatory information channels Keeping content current

Ability to update stakeholders on new features in timely manner

Most portal providers encountered political difficulties to some extent, but no clear picture emerges. Some of these difficulties revolve around:

Gaining sponsorship and buy-ins

Content ownership issues

Describing services appropriately on tabs/headers/labels/links Changing peoples perceptions

Changing existing organizational culture

Informing people of new services/features/functions

Getting people on campus to trust each other

evaluation of portals

Most portal developers (with the exception of University of Texas) reported no formal, systematic evaluation of the portals success. Nevertheless, most providers consider that the portal meet their expectations and goals at least somewhat. Four out of nine respondents are completely satisfied with the results. The difference in satisfaction levels correlate directly with the length of time the portals have been in production. The more stable the portal, the higher the level of satisfaction.

Stakeholders, including students, at these institutions reported:

Decrease in spam email

Ease of doing business with the institution Ease of access to needed information

Pleasure at level of services

Note: portal developers report that there is a certain level of expectation among students, and the sense of why wouldnt this be available? They also report that the portal heightens user expectations of other on-line services.

Elements that helped portal developers meet their goals include:

Synergy among stakeholders

Ease of creating content

Robust, scalable system

Good design

Reorganization of entire institutional web Strong executive support

Compatibility with technical staff

Professional expertise

Fast pace of users adoption of the portal

Firm deadlines

Elements that impeded achievement of goals include:

Lengthy process of development

Some software is still not user friendly or developed enough. Stakeholders do not immediately understand full potential

Lack of robust content management tools

Portal developers were altogether very positive about their respective experiences with the project as a whole. Some changes, if one could start over, include:

Get buy-in from executives and stakeholders earlier in the process

Use uPortal and not go at it alone (one of the first portals developed, JAVA-SIG did not yet exist)

Search ability of databases

More time for design phase

Have more applications available for integration from the get-go More staff and funding to cut development time

More usability testing

More focus on re-engineering discrete business practices to a more integrated system

Compatibility with wireless systems from the outset

conclusions

As seen from the above compilation of major themes covered by our portal provider survey, as well as after reviewing documents and other institutional portals sites, it becomes clear that successful portal projects have been developed and deployed using a variety of means and ways. Several common trends, however, do stand out:

a. All portals have been successful in attracting users. If you build it, they will come!b. All portals are going through step-by-step processes of continual refinement.

c. The main technical focus of portal providers has been on performance: ensuring robustness, stability, and scalability of the portal system.

d. Design, while important, has not been the driving force making-or-breaking the portal projects. The iterative nature of such an undertaking ensures opportunities for changes in design after beta-testing, usability studies, feedback from users, etc.

e. Single log-on is a major feature of portals.

f. Role-based authentication and authorization, also major features and highly desirable, can become a component of later iterations without compromising the attraction of the initial portal.

While we outlined the different models for resources in our findings, we would like to add the following:

a. The portal should be viewed as a strategic investment, and as such, should be funded at consistent levels throughout initial design, deployment, and subsequent development.

b. Planning for resource allocation should take into consideration training and the work-load of content providers.

c. Resources should be planned for and allocated to ongoing and future back-end student systems which need to be integrated with the portal, as well as the integration of existing legacy systems. The portal, which is only a gateway, depends on the back-end systems it links and will ultimately be as successful as these other systems.

d. Throwing money into this project will not guarantee success. The $1 million per year University of Michigan experiment shows that funds only do not a portal make. Money alone does not seem to ensure speed either. The Stanford Enterprise System Portal Project is a two-year, $2.5 million project.

e. Whatever management model is selected, it must effectively guide and coordinate issues raised regarding policy, standards, technology, content, security, training, support, and administrative procedures. Responsibility and authority lines for internal communications need to be clearly defined and assigned.

Section IV: Costs and Phased Implementation

costs

Development and deployment of a portal involve both direct and indirect costs:

Set-up of technological framework for the user interface, including hardware and software Conversion of campus systems to use CalNet ID and password Development of a roles database that can be populated system-to-system; via staff interface (e.g., to flag a student as a member of a particular sub-group for tailoring communication); via student self-identification (e.g., allowing students to sign-up for subject-based interests) Upgrade of legacy systems Programming of individual channels as systems become portal-ready Purchase and implementation of a content management system Consultation, contract help and/or technical training for staff and faculty who want to create content Departmental / unit assignment of staff time to rethink packaging their information for delivery via a portal Development or purchase of applications of particular appeal (e.g., a calendar system that can be automatically populated; can have entries input by the student; with results that can be displayed via the portal.)Different institutions include different elements when speaking about costs, resulting in quite a range of answers to our interview questions:

InstitutionsUniversity of MinnesotaUCLAUniversity of TexasUC DavisU of British ColumbiaU of WashingtonUC Irvine-admin portalStanfordUCB Haas Business School

Institution-wide portalYesYesYesYesYesYesYesYesNo

Outside vendorNoNoNoNoNoNoNoYesNo

What softwareMETADOT (freeware)

as of Fall 2002Site-developedSite-developedSite-developedUPortal (freeware)Site-developeduPortal (freeware)Blue MartiniMETADOT (freeware)

# of staff implementingn/an/a45/~14 FTE742.5112-15 various % time4

# of staff maintaining1.5n/a541/10 FTE4.5152

# of staff further developingn/an/a185 campus-wide42.520.7554

Costs$105K+1.5 ongoing FTE

as of Fall 20027 additional FTE~$30K$100-250K4 FTE+ 1/10 FTE ongoingn/a$15K (hardware)$2.5 mil./2 yearsLess than $100K

Berkeley has made some estimates of costs for a basic infrastructure and programming support:

ProjectEstimated cost/timeComments

e-Berkeley SIS proposal for pilot/prototype (2002)$95,000/1 yearSet up prototype of student portal using JA-SIGs uPortal freeware

Portal production$250,000/yearly$50,000 for server first year; hardware updates/maintenance onward

2 FTEs: for system administration/maintenance, and setting up channels (building connectors) to existing systems

Time estimates for building connectors:

for Web-based CalNet ID authenticated systems (such as, BearFacts, TeleBears, Graduate Admissions, e-Grades, etc.) , connector building/deployment will take anywhere from one to three months

one to two weeks for informational links, two to four weeks for operational (update) systems.

some legacy systems, such as CARS, entail major work (migration to new systems which allow CalNet authentication, and then connection to the portal framework; the former is beyond the purview of the portal enterprise as such).

implementation

Implementation can occur in phases, providing access to information and systems that are now portal-ready, then adding new systems as they become available. The student survey gives us an idea of how students would rank existing and future applications. We have added to the student list other already-existing student systems and websites of interest, and have organized them below:

Table 1: existing student systems that are CalNet ready (need only connector to be linked to portal), together with informational links according to student choices available for first portal iteration

Table 2: existing systems which need to be migrated/upgraded to CalNet, together with systems now in development through e-Berkeley initiative available for integration after migration/development

Table 3: List of desirable systems that are not currently under development, together with informational links which need refining longer term options

Table 1

SystemCurrently exists?Uses CalNet?Currently transactional?Student Rank (Trans/ Info/Appl)urlComments

Library (Pathfinder)YesYesyesT1http://sunsite2.

berkeley.edu:8000/

Black Lightning notesYesLinkyesT2https://blln.securesites.com/home/newhome.shtmlOutside (auxillary) service; Okay for campus image to "promote" this service?

Bear FactsYesYesyesT3http://bearfacts.

berkeley.edu/students would like to see current CARS balance on-line

Degree Audit Report System (DARS)yes(Bear Facts)yes T3http://bearfacts.

berkeley.edu/; Currently on-line info request only

Cal Student Store (bookstore)YesLinkyesT4http://shop.efollett.com/htmlroot/storehome/universityofcalifornia-berkeley554.htmlCan order books online through outside vendor

Financial Aid Office -- on-line offer letteryes(Bear Facts)YesnoT5http://bearfacts.

berkeley.edu/; Transactional Functionality in Development

Bay Area EntertainmentOutside linkLinknoI2Need to allow outside custom links; should the campus suggest a particular site?

WeatherOutside linkLinknoI3Need to allow outside custom links; should the campus suggest a particular site?

Book Price Comparisonoutside linkLinknoI4Contract Implications with Cal Student Store; allow custom outside links

Daily CalYesLinknoI5http://www.dailycal

.org/Outside link

Political Newsoutside linkLinknoI6Need to allow outside custom links; should the campus suggest a particular site?

Regional Newsoutside linkLinknoI7Need to allow outside custom links; should the campus suggest a particular site?

External Career Servicesoutside linkLinknoI8Need to allow outside custom links; should the campus suggest a particular site? Competition with our own career services?

Student Associations and clubsUnevenLinknoI9variousStudents want through calendar/roles database

Recreationoutside linkLinknoI10Need to allow outside custom links; should the campus suggest a particular site?

Parking and TransportationYesYesyesI14http://public-safety.berkeley.edu

/p&t/

ASUC Student Referendums On-LineYes?yesn/aStudents would also like to vote for candidates on-line

Class Pass Online Distribution SystemYesYesyesn/ahttps://classpass.

berkeley.edu:6204/

Table 2

SystemCurrently exists?Uses CalNet?Currently transactional?Student Rank Trans/ Info/ApplurlComments

Online degree verificationYesno T3http://infobears.berkeley.edu:3400/degver/uses Telebears PIN number

Summer TelebearsYesno yesT3http://www-telebears.berkeley.edu:3400/summer/uses Telebears PIN number and Advisor Code

TelebearsYesNoyesT3http://www-telebears.berkeley.edu:3400/telebears/uses Telebears PIN number and Advisor Code

Campus Career ServicesYesNoyesT6http://career.berkeley.eduUses outside vendor for online resume bank; uses its own userid/password

Web-based emailYesNoT7http://bearmail.berkeley.eduStudents/staff interested in having more than their in-box available via web

UC EventsYesNonoI1http://www.berkeley.edu/calendar/Ideally populate a calendar rather than current informational link

University Health ServiceYesNonoI13Http://www.uhs.berkeley

.eduPlans for on-line appointment scheduling development

Request transcripts, enroll in classes(Academic Transactions online)YesSee commentyesA1See commentdone through Bear Facts or Telebears -- see below

Learning Management SystemIn developmentYesA4

Table 3

SystemCurrently exists?Uses CalNet?Currently transactional?Student Rank (Trans/ Info/Appl)urlComments

Departmental Advising and NewsVariesnonoI11variousVarious department homepages; some departments have interactive sites

Central Campus Advising and NewsVariesnonoI12variousCentral Campus news on UCB homepage; information on central campus pages (e.g. Registrar, Graduate Division.)

Declare major, intent to graduate(Academic Transactions online)NoA1involves development of electronic signatures

Calendaring system Populated by Other Systems/StudentNoA2

Calendaring system Populated by Studentfor staff noyesA2http://calagenda.berkeley.eduCal Agenda

Online payment of CARS bills (reg fees, housing)NoA3Transaction fee cost issue

For all existing, newly purchased or developed applications, it will be important to ask, Will it scale? and How easy is it to integrate? For the student web portal to be optimally functional, it will also be important for the campus to commit to a purchase or development of a content management system; developing an integrated roles database populated (by systems, by staff, and/or by students themselves) with meaningful data about students; a business process for departments and central units to supply and refresh content; a business process and guidance for delivering all-campus or targeted notices to students; and training or consulting support for content providers, be they staff or faculty.

Section V: Conclusions and Recommendations;

Criteria for Measuring Portal Success

While compiling and analyzing survey and interview data, we have come to the following conclusions, and have formulated a few recommendations. These follow.

build it and they will come; reap multiple benefits

Although students and staff on campus ranked development of associated applications above the portal itself, 70% of students welcome any technology which helps make their life easier. All other institutions surveyed reported positive experiences and major benefits from the portal as well as considerable customer satisfaction with the results. It is our belief that launching the portal early will reap multiple benefits:

Allow students to organize applications and information. Reports of instant high use of the student portal at other institutions leads us to believe that Berkeley students will use a portal as well. There are already a number of web-based applications at UCB, but not all students know about them, nor are they easy to find. Early launch of a student portal would give all students a menu of whats available thereby informing them of possibilities, as well as allowing them to include, exclude, and organize options in a way that makes sense to them.

Encourage development of standards, enabling integration of new applications as they develop. Portal developers at other institutions report that the student portal engendered standards which made future integration of new applications easier, and provided the impetus for upgrading legacy systems to fit into the new web-based environment. There is considerable interest on campus in portal technology (evidenced by the MyHaas student portal, the Alumni portal and the staff portal being rolled out with the Human Resources Management System). It is important to make sure that independent efforts will be easy to include in a campus-wide system.

Focus campus-wide discussion and provide opportunity to engage in innovative work. There are several innovative efforts underway on campus to do business online and to leverage technology to revolutionize teaching. A campus-wide commitment to a student portal would lend a Chancellor-level imprimatur to these efforts. The portal itself would make it easier to showcase new initiatives, and for students to use new applications as they become available.

Build efficiency, synergy, and clear purpose. Creation of a student portal and a roles database would not only free staff from repetitive and inefficient tasks, but could restructure the way business is conducted. This is particularly important in a time when we expect increased enrollment without increases in staffing. Advising staff welcome the idea of being able to send tailored messages to select populations (with a high probability of the recipients being interested in the content because of their affiliations) and thus free up time for more in-depth, personal contact with students. This same kind of synergy could play itself out in other arenas: if faculty teaching an interdisciplinary course could invite students from many disciplines to participate, the class would be significantly enriched on the basis of a diverse membership. Research collaborations might be fostered by being able to identify others on campus having similar interests and like minds. Deploying a portal would also lend support to an integrated, streamlined, collaboration between IT professionals on campus by providing them a clear framework and consolidated goals.

support campus goalsWe believe that a student portal, with a roles database and integrated back-end systems, would further the following campus goals:

Improve the undergraduate experience.

Build community.

Improve organizational effectiveness.

These goals overlap to a high degree and in provocative ways.

If by looking at the same student portal, a prospective student can learn about programs, professors, housing, and health benefits; an entering student can enroll, pay for parking, and subscribe to student groups; a lower-division student can make an appointment with the health service and review the slides from his/her Classics course; and an upper-division student can see what to take in order to graduate in the time remaining, and make an appointment with his/her advisor; all of the above goals would be furthered.

Staff could tailor messages to the right subset of students at the right time, and undergraduates would benefit they would feel seen; receive timely and pertinent information; avoid standing in the wrong and/or long lines; use their time more productively. Staff could use their in-person time with students to provide in-depth information and assistance; reduce paper use; and rethink how their own work might be packaged most efficiently for sub-groups within their student customer base.

If students and faculty can find other students and faculty having similar interests, irrespective of their school or department, new communities can be built. A student portal has the potential to provide a way for scientists and humanists, emeriti and undergraduates, commuters and residents, to find each other and talk.

elements of success development, design, management

Content. The more students can manage their academic life and do business (academic, administrative, and financial) on the portal, the more likely they are to use it. The portal is an entry point to the world of information behind it. A student portal will be most effective in meeting campus goals if it is developed in conjunction with a comprehensive roles database, an easy-to-use content management system, and an ever-increasing number of web-based student information systems. Technology. The portal needs to be easy for students to use and to customize; easy for content providers to fill; and fast, without compromising bandwidth for other campus endeavors. Security and privacy need to be maintained; however, other institutions report that while crucial, security was not particularly difficult to ensure. A work-in-progress. Building a portal isnt done just once. It needs to be put up, tried, and changed as new applications come online and as the campus changes. Resources and support. A portal doesnt have to be expensive. It does have to be supported in concept by 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/reward for doing their jobs in new ways. Note: Its very important to have a content management tool in place before the portal goes live. Design. Technical expertise needs to be paired with expertise in communication and web design. Students, as the primary users of a student portal, should be involved in discussions on content, look and feel, and navigation. As one staff member notes, Whats attractive and useful to middle-aged me, might not be the best design for someone in their 20s. Management. In contact with other institutions, we did not discover that any one management model worked better than others to the contrary, each management model seemed to reflect the culture of the organization more than the nature of the project. It seems obvious to us, however, that the first step in developing a student portal is to assign responsibility for internal campus communications 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.) Decision-making authority needs to be assigned, and the process of implementation needs overall coordination.

criteria for measuring success of a student portalWhile the portal could influence the campus in any number of positive ways, the primary criteria for measuring success include:

Usage both the number of sessions and the number of hits on different channels

Student satisfaction measured using surveys or focus groups System stability minimal down time, is reasonably fast, and does not impede existing network traffic.

Number of integrated systems number of back-end systems developed or integrated into the portal.

Other long-term markers of success include:

Students spending less time waiting in line.

Better quality in-person advising due to decreased in-person advising on basic issues.

Reduced staff burnout.

Section VI: Three Portal Interface Options for Look and Feel;

Criteria for Evaluating Options

We have mocked up three options for how a student portal might look. Each of these options illustrates a combination of two major themes: how a student might organize their portal page, and how the portal software might structure content.All options show several general features:

administrative systems, ranked number one on the student survey: CourseWeb, TeleBears, BearFacts, Library, Office of the Registrar, Parking & Transportation;

a personalized calendar, ranked number two by students;

a cameo, to illustrate the potential of a notification box showing personalized and updated information;

links to UCB home, Help, WebMail, Campus Directory, Search, and Customize, and no back button per student request;

general subject headings within mini-screens to sort together like information.

The three options show

different links, to illustrate that different students will have different interests;

similar information positioned differently between options, demonstrating that different students will prioritize information differently;

different navigation schemes (e.g., tab, columnar, etc.);

different decisions on the existence of locked-down channels.

option 1 (see next page) Jane Bear is here for fun. Her personal links include rock climbing and parties. She has chosen to put these links and todays weather at the top of her page, and put the links to her classes further down.

This option is modeled on the University of Washingtons student portal. The information on the portal is organized using tabs for navigation; there are no mandatory channels; channels appear in boxes organized in columnar format. Note: some user interfaces pre-set the tabs, while others allow each tabbed page to be customizable by the user.

Pros of Option 1 Tabs allow users to see a series of compact screens, rather than one long screen. Some users will prefer this compactness.

Interface scalability: as more online content becomes available, it is relatively simple to add new tabs to accommodate and organize new content.

If students can name the tabbed screens and customize their content, students would have maximum flexibility to organize information as they see fit. For instance, some might create tabs by type of information; others by how frequently they need access to information; or by some other principle of their own choosing.

Even if all of the tabbed screens are created and named by the institution, tabs would still allow students to toggle quickly between different types of information.

There could be a mixture of user-defined and mandatory (locked-down) tabs. The latter give the University another way of delivering mandatory information to students.

Cons of Option 1

A tab-based interface necessitates that students use a separate customization tool to create and/or manage content. This is arguably less convenient than a static menu bar, which allows the user to see all content options on the same screen as the content itself at all times.

If the separate customization tool is not easy to use, students may not take full advantage of all that the portal has to offer, since they may overlook some options.

Portal Option 1

option 2 (see next page)

This Jane Bear is homesick. She has put the links to her courses at the top of her page, together with access points to Black Lightning Notes, the Bookstore, and the Library. Janet is also homesick. Her daily calendar reminds her to call Mom and shows weather information for her hometown, Wichita Kansas.

Option 2 is modeled on the MyHaas student portal. There are no tabs for navigation; information is organized into columns and students use the Customize link at the top of the page to determine which channels will appear, and to select their order. There are no mandatory channels.

Pros of Option 2

High level of customization for the user, who can determine what elements to put on their personal portal page, and where on the page they should be displayed.

Users who prefer a very busy web page can choose to display a lot of channels, whereas those who prefer a very uncluttered web page can choose to display fewer.

Cons of Option 2

Users must choose between less information or a more cluttered look.

Users who want to display a large number of channels and links will also have a very long page to scroll through in order to see all of the items.

This interface requires students to use a separate customization tool to create and/or manage content on their pages. This is less convenient than a static menu bar which allows the user to see all of the content options on the same screen as the content itself.

If a separate customization tool is not easy to use, students may not take full advantage of all that the portal has to offer, since they may overlook some options.

Portal Option 2

option 3 (see next page)

This Jane Bear is focused on course work and her career prospects. CourseWeb, Library, and Bookstore appear near the top of her page, together with the Career Center and various student groups and associations such as Leaders in Training.

Option 3 is modeled on the UCLA student portal. The left-hand navigation column is static it displays all the options available to students via the portal, organized in categories. The right-hand column changes to reflect the students selections from the navigation column. The Campus Alert box at the top of the screen is an example of a locked-down channel it would appear on every students portal.

Pros of Option 3

This model does not require a separate customization tool. Rather, all content options are displayed at all times and the student can get to a not-often used item without looking into a background document.

Since all options are displayed at all times, students might be more likely to take full advantage of all that the portal has to offer.

Content providers can be assured that their content category exists as they will see it on the static menu bar.

The static menu bar makes it easy to explain to users how and where to find specific information.

Cons of Option 3

Makes the screen very long; many students do not like to have to scroll down. Users cannot change the menu bar, which may contain links and channels of no interest to them.criteria for evaluating options

Ease of use: How intuitive is each possible user interface for the average user?

Level of customization: How easily does each user interface lend itself to customization? In general, we believe developers should strive for the highest possible level of customization.

Accessibility: How well does each user interface lend itself to meeting the needs of those with disabilities?

Performance: Do some of the different user interfaces offer a higher level of performance than the others, either from a system bandwidth perspective, or from the perspective of users with slower, older computers?

Information: Does the customization tool provide easy access to all potential sources of information in an easy and comprehensive way?

Portal Option 3

Section VII: Portal NamesWhen we raised the issue of name with on-campus interviewees, many of them advised us to duck. Taking this counsel to heart, we provide here our top five favorite names. A compiled list of ideas we heard from students, faculty, and staff is included in Appendix XXII.

MyCal

BearEssentials

Sather Gateway

CalWeb

OskiOnline

Appendices

Appendix I Definitions

Applications, application programsA complete, self-contained program that performs a specific function directly for the user. This is in contrast to system software such as the operating system, server software, etc. which exists to support application programs. See Enterprise Application, below.

AuthenticationThe verification of the identity of a person or process. In a communication system, authentication verifies that messages really come from their stated source, like the signature on a (paper) letter.

AuthorizationAllows a person access to a particular system or process, after their identity has been authenticated.

Back end systemsEnterprise applications transparent to the customer, who connects to them via the web portal. For example, a student web portal would provide a front end system through which students could connect to a back end system, such as Telebears.

CalNet IDA unique identifier (currently student or employee ID number), associated with a secret passphrase, which provides for authentication, authorization and information lookup.

CameoA channel which provides a user with a real-time snapshot of a particularly useful or time-sensitive piece of information or data from an external application or system, without having to go directly to the external application or system. For example, a cameo might display how much money a student has on their meal debit card.

Channel, locked down channelsA means of organizing similar types of information for purposes of delivering them through a web portal. For example, a Financial Aid channel might consist of links to all transactional systems associated with the process of applying for and receiving financial aid (internal campus applications as well as external ones, such as the online application to complete the Free Application for Federal Student Aid form), plus links to purely informational websites (eg. Scholarship search engines).

A locked down channel is any channel which all users, or all users of a given type, are required to see, and which they cannot remove from their personal portal page.

Enterprise applicationAn application is a complete, self-contained program that performs a specific function directly for the user. An enterprise application is a program which performs functions central to the business of an organization. An example at UC Berkeley is Telebears, which students use to register for their courses.

FERPAFamily Educational Rights and Privacy Act, the federal statute governing the disclosure of information from student records.

FreewareSoftware, often written by enthusiasts and distributed at no charge by users' groups. Freeware should not be confused with free software (roughly, software with unrestricted redistribution) or shareware (software distributed without charge for which users can pay voluntarily). The uPortal framework (see below) is being developed by a consortium of universities, and is thus freeware.

JA-SIGJava in Administration Special Interest Group, a consortium of universities working together to develop a common portal reference platform. See freeware, above, and uPortal, below.

J2EE

Java 2 Platform, Enterprise Edition. Sun Microsystems Java-language platform for server-oriented enterprise applications, ie. applications (servers) which provide some service to other applications (clients) by passing messages over a network, using a protocol to encode the clients requests and the servers responses.

Kerberos

Kerberos is an authentication system, developed at MIT, whose main purpose is to allow people and processes to prove their identity in a reliable manner over an insecure network, without transmitting secret passwords in the clear, where they may be intercepted and read by unauthorized parties. Kerberos is the established authentication standard for UC Berkeley enterprise applications.

LDAP

Lightweight Directory Access Protocol. A protocol for accessing on-line directory services. LDAP defines a relatively simple protocol for updating and searching directories over the internet.

Legacy systemAn existing enterprise application that would need to be made compatible with a student web portal. This bit of industry jargon often carries a negative connotation, implying that the existing system continues to be used because of the high cost of replacing or redesigning it, despite its poor performance and incompatibility with modern equivalents. However we have used the term in a less pejorative fashion, to refer to pre-existing campus enterprise applications, regardless of whether they have performance or compatibility issues associated with them.

PortalA website which provides clients with a single, intuitive, and personalized gateway to information stored in local databases and systems, as well as externally stored information. See Student web portal, below.

Roles databaseA database containing user-specific information. Various attributes are associated with each user name. In the context of a portal, these attributes can in turn be used to determine whether an authenticated user will be allowed to access specific enterprise applications, or subscribe to specific channels. They can also be used to identify students of like type, in order to push information to a specific set of students (eg., all entering undergraduate community college transfer students, or all second-year law students).

SharewareSoftware for which the author requests some form of voluntary payment. Such payment may buy additional support, documentation or functionality.

Student web portalThe Berkeley student portal would provide students with access to external websites, as well as 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 websites, internal news channels aimed at particular groups of students, and external information such as sports, weather, entertainment, etc.

uPortalPortal development software created by a consortium of universities developing a common portal platform. See freeware and JA-SIG, above.

User interface (i.e., UI)The aspects of a computer system or program which can be seen (or heard or otherwise perceived) by the human user, and the commands and mechanisms the user uses to control its operation and input data.

Appendix II Respondents

students

This report reflects input from students collected at two different times

1. student focus groups conducted in the Spring of 2001 by the UGA Divisional Computing Resources office, with responses from 44 participants representing all levels and colleges and a wide variety of majors, and

2. our survey conducted in Spring 2002, with responses from 284 students reached through the following groups:

The March 2002 meeting of the Graduate Assembly (ca. 30 attendees)

Three discussion sections for the course BA 10 (ca. 120 students)

A lecture of the course PH 103 (ca. 120 students)

A discussion section for the course ED 198 (ca. 12 students)

Sexual health peer educators at University Health Service (ca. 20 students)

Student health advisory group at University Health Service (ca. 10 students)

Residence Halls health worker coordinator team (ca. 10 students)

Residence Halls advisors group (ca. 27 students)

Letters & Science peer advisors group (ca. 8 students)

ASUC interns group (ca. 18 students)

For survey results, see the Appendices.

faculty / administrators / staff

We conducted one-on-one interviews with administrators, staff, and faculty; conducted focus groups at the 11th Annual Conference on Advising, Counseling & Mentoring; and provided surveys to the Advising Conference and some of our interviewees. Altogether we collected ninety-four responses. Responses have been compiled in separate Appendices.

Faculty we spoke with:

Leonard Duhl, Professor, Public Health and Urban Planning

Mark G. Kubinec, Director of Digital Chem1A, and Lecturer of Chemistry

Stephen Miller, Professor, Classics

Panayiotis Papadopoulos, Associate Professor, Mechanical Engineering

Philip Stark, Professor of Statistics and Faculty Assistant to Vice Provost Christina Maslach

Garrison Sposito, Director, Kearney Foundation of Soil Science

Elaine Tennant, Professor, German

Ruth Tringham, Professor, Anthropology

Alan Weinstein, Professor, Mathematics

Colleagues on campus recommended that the following faculty would be good to include in future discussions on this topic:

Rutie Adler, Lecturer, Near Eastern Studies

Ani Adhikari, Visiting Lecturer, Statistics

Americ Azevedo, Lecturer, Engineering

George Chang, Associate Professor, Nutritional Sciences

Mike Clancy, Senior Lecturer, Electrical Engineering & Computer Science

Margaret Conkey, Professor, Anthropology

Deborah Nolan, Professor, Statistics

Alex Pines, Professor, Chemistry and Principal Investigator, LBNL

Kris Pister, Electrical Engineering & Computer Science

Paul Ruud, Professor, Economics

Francoise Sorgen-Goldschmidt, Lecturer, French

Paul Wright, Professor, Mechanical Engineering

Staff and Administrators we spoke with:

Renato Almanzor, Associate Director, Office of Student Life

Doug Au, Web Communication Coordinator, Summer Sessions

Richard Black, Assistant Vice Chancellor, Admissions and Enrollment

Pamela Burnett, Director, Office of Undergraduate Admissions

Greg Brown, Assistant Vice Chancellor of Finance, and Controller

Susanna Castillo-Robson, Registrar

Lisa Chow, Business Manager, Student Information Systems

Jon Conhaim, Director, e-Berkeley

Russ Connacher, Information Systems, L&S Undergrad Advising

Tom Devlin, Director, Career Center

Victor Edmonds, Director, Educational Technology

Glenda Freberg, Assistant Manager, Business Services Payroll

Elizabeth Gillis, Campus Community Project Coordinator

Tim Heidinger, Manager, Undergraduate Affairs Computing

Chris Hoffman, Computer Resource Manager, Graduate Division

Tom Holub, Director of Computing Services, L&S

Bernard Hurley, Director, Library Technologies

Gail Kaufman, Director, School & University Partnerships

Karen Kenney, Dean of Students, Office of Student Life

Leslie Leonard, Assistant Dean, Letters & Science

Kimberly Longwell, Business Services Loans and Receivables

Mindy Lopez, Business Services Loans and Receivables

Steve Lustig, Assistant Vice Chancellor, University Health and Counseling Services

Jack McCredie, Associate Vice Chancellor, IS&T

Ralph Moon, Director of Library Systems

Barbara Morgan, Director of Strategic Planning Technology

Je Nell Padilla, Research Analyst, Residential & Student Services

Gary Penders, Director, Summer Sessions

Nad Permaul, Director, Transportation

Jeffrey A. Reimer, Professor and Associate Dean, Graduate Division

Cheryl Resh, Director, Financial Aid Office

Maria Rubinshteyn, Director, Office of Marketing & Management of Trademarks

J.R. Schulden, Director, Student Information Systems

Genevieve Shiffrar, Web Manager, L&S

Joyce Sturm, Manager, Business Services Cashiers Office

The following units were also named as important stakeholders, and might be considered for future input:

Alumni Association

Athletics & Recreational Sports

Business Services (Director)

Cal Performances

CALSO especially to hear their input re student orientation

Disabled Students Program

Housing & Dining Services, Manger for Systems Development

Police Department, Chief of Police

Re-entry Program

Student Research, Director

UC Extension

portal developers

A detailed questionnaire was developed to investigate the process portal providers at other institutions have undergone in the conception, design, implementation and management of their portals. Responses were gathered either by email return of the questionnaire or by phone interview, from the following nine academic institutions:

Stanford Universitys Stanford Enterprise Portal

Susan Empey , Information Technology Systems and Services and

Ross Davisson, CEO, Stanford Student Enterprises

University of British Columbias MyUBC

Ted Dodds and Dave Frazer, Information Technology

UC Berkeley, HAAS School of Business MyHaas

Teresa Costantinidis & Zane Cooper

UC Daviss MyUCDavis

Joyce Johnstone and Brian Alexander

Information & Educational Technology Information Resources

UC Irvines SNAP (Simple Navigational Administrative Portal)

Marina Arseniev, AdCom Services

University of California, Los Angeles

Eric Splaver, IT Director

University of Minnesota

Bob Kvavik, Office of Exec VP

Kari Branjord, Director of Web Development

University of Texas at Austin

Randy Ebeling and Shan Evans, Information Systems Technology

University of Washingtons MyUW

Ed Lightfoot, Director, Information Systems

Appendix III Student Survey Instrument

Berkeley is considering building a web portal for students. 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 also 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.

As part of that effort we are interested in knowing what you would like to see the portal look like. We will pass your input on to the campus portal development team. Thank you for taking the time to complete this survey.

1. Are you a/n: ( Undergraduate (( Lower-division; (Upper-division)( Graduate Student

2. What college/school are you enrolled in?

3. Have you ever used a web portal before? (e.g.. My Yahoo [http://my.yahoo.com/];My Netscape [http://my.netscape.com/index2.psp])( Yes ( No ( I dont know

4. Which of the following campus offices do you interact with on a regular basis? (Please check all that apply):( Registrar (class registration, fees, class schedules, etc.)

( Financial Aid (grants, loans, fellowships, scholarships)

( Central academic advising (at the College/School/Graduate Division level)

( Academic advising in your home department

( University Health Services

( Library

( Housing & Dining

( Book store

( Transportation/Parking

( Student Government

( Student Associations/Clubs

( Campus Career Services( Recreation (Intercollegiate Athletics, Rec Sports, Cal performances, etc.)( Other (please list):

5. Which of the following links would you like to access through your portal? (Please check all that apply):( Sports

( Political news

( Financial news

( Regional news (by country or world region)

( Consumer news (fashion, travel, health, etc.)

( Weather

( Bay Area entertainment (art, theater, concerts)

( UC events (public lectures, concerts, Cal sports)

( Daily Cal

( Comics

( On-line stores

( Bay Area rentals( Travel

( Black Lightning Notes

( On-line Campus Chat Groups

( External Career Services (e.g.. Monster.com [http://monster.com/], hotjobs [www.hotjobs.com],

Craigs List [http://www.craigslist.org/])

( Book Price Comparison Engines (e.g.Best Book Buys [http://www.bestwebbuys.com/books/])

( Groupware (software designed for users to collaborate via the Internet and/or a local intranet)

( Other (please list):

6. Which of the following services would you most like the campus to provide through the web? (Please check all that apply):

( Calendaring (ability to keep track of your academic and financial deadlines, class schedule, appointments etc. through a single website)

( Financial transactions on-line (payment of fees, parking fees & tickets, bookstore

transactions, etc.)

( Academic transactions on-line (requests for major/minor, request for transcripts/diplomas, check up on required courses for college/major/minor, electronic advising options, enrollment in classes, etc.)

( This Student Web Portal( Learning Management System (not simply websites with instructor biographies, etc, but also timed release of assignments, archives of past exams, course notes, discussion boards, etc.)

( Other (please describe):

7. Web portals typically include a few required items or links that a user cannot remove from their portal page. Which of the following do you think should be required? (Please check all that apply):

( News from the Registrars office

( News from the Financial Aid office

( News from your College, School or Department

( News from the Cashiers office

( General Campus News

( None of the above

( Other: _________________________________

8. If the Berkeley student web portal offered a mix of the features listed in questions 4-7, would it make your campus life easier?

( Yes( No( Not sure

9. Assume the campus has a limited budget that allows the implementation of one system each year. Please rank order the following systems in order of importance to you.

a. ______ Calendaring (ability to keep track of your academic and financial deadlines, class schedule, appointments, etc. through a single website)

b. ______ Financial transactions on-line (payment of fees, parking fees & tickets, bookstore transactions, etc.)

c. ______ Academic transactions on-line (requests for major/minor, request for transcripts/diplomas, check up on required courses for college/major/minor, electronic advising options, enrollment in classes, etc.)

d. ______ This Student Web Portale. ______ Learning Management System (not simply websites with instructor biographies, etc, but also t