Academic Services Portal Project

Academic Services Portal Project Requirements Specification Report

June 2004 Version 1.1

This document outlines requirements for a portal at the University of Leeds. It draws on work undertaken by the Academic Services Portal Project Manager (ASPPM) – and on the following reports: Portal Project Brief, September 2003, Bo Middleton [1] Portal Project Interim Report, March 2004, Bo Middleton [2] Portal Project User Requirements Report, April 2004, Bo Middleton [3] Familiarity with these reports is not necessary but readers who are familiar with these documents can focus on sections 3, 4 and 5 of this report. Intended audience: to inform ISS Information Architecture strategy. May also be used with advisory bodies in order to refine the specification.

Bo Middleton Academic Services Portal Project Manager

i A summary of the requirements specified in this report

Functional and content requirements detailed in this report are listed here:

Functional requirements for a portal:

FR1) System will allow administrator to define custom user types. There is no limit to the number of roles which can be defined. FR2) There is no limit to the number of roles a user can have in the system. FR3) A guest role is possible. FR4) Each role can offer a tailored view of all the information relevant to user-specific needs and preferences. FR5) System can dynamically access profiling information for a user in order to determine the user’s role(s) and thus tailor their portal view. FR6) System will allow administrator to define custom information channels. No limit to number of information channels. FR7) Channels are written using standards and can be easily transferred to another framework using those standards. FR8) Off-the-shelf channels for HE available or being developed. FR9) Access to channels can be restricted to specific roles. FR10) System supports established standards and communication protocols. (JMS, XML, IMS, HTTP/HTTPS, LDAP, IMAP, POP, SMTP). FR11) System allows multiple authentication methods that can use existing databases (for example, can authenticate using an existing LDAP server, or using Active Directory via Kerberos). FR12) System offers GUI web enablement tool – that is a GUI which connects to a remote application’s database and allows a developer to create a web-form (based on fields in the DB) which can then be used to interrogate/update the application’s database. FR13) Forms routing available - paper documents can be replaced by web-based forms. In addition, forms tracking software built in. FR14) Secure connection can be specified using standard method (e.g. system handles initial authentication of users by encrypting the channel between the client and web server via Secure Sockets Layer (SSL).) FR15) System offers a web accessible GUI for carrying out administrative functions. Administrative functions can be delegated. FR16) System provides system monitoring tools through a web interface - for a variety of logging and reporting functions. FR17) Intuitive interface, requiring little or no user training. FR18) Administrator has full control of (initial) look and feel and changes can be made quickly. FR19) Good set of tools provided to ensure that site meets WAI accessibility guidelines. FR20) Portal user has access to editing tool for customising tabs, colours, and fonts. FR21) Several online help features, for example tutorials and FAQs. FR22) Electronic balloting and polling are fully supported.

The following requirements may be provided by a portal product or may be provided by other means.

FR23) The system draws on content from a web content management system. FR24) The system offers a search engine which can search web content across campus. FR25) The system includes collaborative/community building tools (group creation/joining with associated file store, discussion board, calendar). FR26) Single sign-on for multiple functions from one central database. FR27) (desirable?) Portal API can pass information to other applications, seamlessly integrating multiple sources of information, and ability to write own interface, for example passing user preferences between applications.

ii Content requirements for a portal:

Stage 1 – undergraduate student role pilot portal  One broad undergraduate student role.  Content as per recommendations in User Requirements Report: o communication/collaboration functionality, o library services, o VLE integration, o functionality which is new or exclusively accessed through the portal.  Campusweb content migrated into CMS.  Access to web enabled applications and other web functionality is via links (application opens in separate window).  Users do not need to logon again in order to access web mail, library account, Bodington, web-enabled Banner functionality.

CR1) Campusweb content, university web sites and internet accessible and searchable. CR2) (Authenticated) link to student webmail. CR3) E-tools for collaboration/community building. Ability for user to create groups. CR4) Link to library web catalogue. CR5) (Authenticated) link to user account on Library Management System. CR6) (Authenticated) link to Bodington. CR7) (Authenticated) links to currently web-enabled functionality: o Update personal details o Re-enrolment/module selection o View module catalogue o Fee payment CR8) One or more of the following new functionality possibilities: o Access exam paper database o Up-to-date (searchable) contact information o Alerts o Message board/small ads o External news feeds

Stage 2 - postgraduate role and finer ‘grouping’  Postgraduate role.  Further profile information available for all students so finer roles or ‘grouping’ can be used to offer school/dept content.  Additional content focussing on research resources.

CR9) (Authenticated) link to library e-resources – library portal. CR10) ResearchResearch feed. CR11) Access other research related resources. CR12) All other content/functionality available in the pilot portal.

Stage 3 – staff role  One broad staff role.  Additional content focussing on staff self-service.

CR13) (Authenticated) link to Outlook account. CR14) (Authenticated) link to Bodington. CR15) (Authenticated) link to user account on Library Management System. CR16) (Authenticated) link to SIPR. CR17) (Authenticated) link to Banner for Faculty. CR18) (Authenticated) links other web-enabled applications (as per ISS plans for self- service). CR19) Link to VKP. CR20) All other content available in student portal (as appropriate).

iii Table of Contents A summary of the requirements specified in this report Functional requirements for a portal:...... ii Content requirements for a portal:...... iii 1. What is a portal?...... 1 1.1. Defining the term ‘portal’...... 1 1.2. Portal functionality...... 2 1.3. Portal scenarios and their benefits...... 4 2. Business and user requirements...... 6 2.1. Business requirements...... 6 2.2. Portal roles...... 7 2.3. User requirements...... 7 2.4. Portal scenario...... 11 3. Functional requirements of a portal...... 12 3.1. Roles...... 12 3.2. Channels...... 12 3.3. Infrastructure...... 12 3.4. Portal front-end...... 13 3.5. Additional functional requirements which may be provided by a portal product...... 13 4. Content requirements for an institutional portal...... 14 4.1. Stage 1 – undergraduate student role pilot portal...... 14 4.2. Stage 2 - postgraduate role and finer ‘grouping’...... 15 4.3. Stage 3 – staff role...... 16 4.4. Stage 4 – refinement of student role functionality...... 17 4.5. Stage 5 – refinement of staff role functionality...... 17 5. Refining the specification...... 18 5.1. Required functionality for a portal product...... 18 5.2. Weighting functional requirements and determining criteria for portal product selection...... 18 5.3. Specifying the interface...... 18 5.4. Finalising and prioritising content for a portal pilot/Specifying portal roles and a portal scenario (for level of integration)...... 19 References...... 20

Appendices

Appendix 1 Web-based interfaces – an attempt to clarify overlapping functionality with a portal...22 Appendix 2 Portal scenarios and their benefits…23 Appendix 3 Mapping portal features against University strategy documents…26 Appendix 4 Recommendations from user requirements analysis report…32 Appendix 5 Criteria for portal product selection…34

iv 1. What is a portal?

The term portal has been used to describe a range of web-based functionality. In order to scope and specify requirements for an institutional portal at the University of Leeds, it is necessary to fully understand: what is meant by the term ‘portal’, what functionality could be included as part of a portal product, what possible portal scenarios are available to the University, and what are the benefits of implementing a portal.

1.1. Defining the term ‘portal’

There is no one definition of a portal which can be considered to be definitive since the term ‘portal’ has been used to describe a range of functionality. (Clarification of how other web-based interfaces have functionality which overlaps with a portal is given in Appendix 1). It is possible to identify common characteristics of a portal from a range of portal definitions:

‘An [sic] network service that provides a personalised, single point of access to a range of heterogeneous network services, local and remote, structured and unstructured. Portal functionality often includes resource discovery, email access and online discussion fora. Portals are intended for (human) end-users using common Web 'standards' such as HTTP, HTML, Java and JavaScript. In the context of the JISC IE, portals interact with brokers, aggregators and content providers using Z39.50, the OAI-PMH and RSS/HTTP.’ [4]

‘… a layer which aggregates, integrates, personalises and presents information, transactions and applications to the user according to their role and preferences.’ [5]

‘… a portal is an online service that provides a personalised, single point of access to resources that support the end-user in one or more tasks (resource discovery, learning, research etc). The resources made available via a portal are typically brought together from more than one source.’ [6]

‘The portal … is more than a gateway. It is … a unifying principle that may enable organizations – including colleges and universities – to leverage their investments in enterprise systems, in data warehouses, in reengineered institutional processes, and in staff talent.’ [7]

The common characteristics of a portal may therefore be summarised as:

 A portal provides a single point of access to all communication, learning and administrative systems and resources

 A portal user is assigned a role (or roles) and each role has a tailored portal ‘view’

1 1.2. Portal functionality

Applying these two common characteristics of a portal to the ‘systems’ landscape at the University of Leeds, figure 1 illustrates a simple information architecture.

Figure 1 Portal architecture for the University of Leeds

Figure 1 shows that a portal (shaded areas) provides an interface to systems and information, and that the interface is customised for each role. The term ‘thin portal’ is sometimes used to describe a portal which only provides these 2 common characteristics.

Relating this simple architecture to actual portal products is perhaps the most revealing exercise since different portal products include functionality other than the 2 common portal characteristics. In order to deliver a single access point which is customised for each user, a portal needs to draw on other functionality:

 Authentication mechanism. Though a portal may give a generic ‘guest view’, its primary function is to deliver content and access to systems which is tailored to the user, thus a portal needs links to a directory service against which the portal user can be authenticated.

 User information. A portal needs information about a user in order to assign a role and tailor content. This information may come from the directory service if very simple roles are adopted, or may need to draw on further databases in order to get more specific user information.

 Authorisation mechanism. Since a portal user has already been authenticated, it may be appropriate to allow access to the various systems available to the user without the user having to authenticate to each separate system, i.e. a portal may need a mechanism for single- sign-on (or simplified-sign-on).

Some portal products provide this functionality, or provide means of drawing on this functionality from elsewhere. In addition, portal products may offer functionality which aids the integration and aggregation of systems and information:

 Integration tools. Since a core portal feature is to aggregate access to a variety of systems, some portal products include a set of ‘tools’ to 2 support this. These tools vary according to the portal product – the two most common being:

 Integration with external systems and applications – presentation level. A GUI which connects to an application’s database and allows a developer to create a web-form (based on fields in the DB) – the web form can then link directly to the data in the application’s database.

 Integration with external systems and applications – data level. Essentially an identity management system, a portal product may include a messaging server which can link disparate systems (covering some of the functionality of LURCIS) – such that when a portal user updates, for example, their address in one application, the messaging server will then update their address in every application that holds that information.

 Content management system. Seen by many portal software suppliers and many HE portal implementers to be a fundamental part of an effective institutional portal, a web content management system (which may also be useable by web content which is primarily accessed outside the portal) may be included as part of a portal product.

And finally, some portal products include functionality which is usually provided by other applications:

 Email  Calendaring  Collaborative e-tools (notice boards, discussion boards, shared calendars, shared file-stores for collaborative authoring)

If a ‘thin portal’ is one which only provides a web front end (with associated administration tools), the term ‘thick portal’ can be used to describe a portal which includes other functionality. Figure 2 illustrates functionality which may be provided by a portal product.

Figure 2 Portal architecture for University of Leeds showing portal product functionality

3 1.3. Portal scenarios and their benefits

Portal software suppliers frequently bundle a portal front-end with the underlying functionality required in order to provide a single interface which integrates access to administrative systems, communication and collaboration applications, and a diverse range of web resources. This serves to make the purchase of a portal product a far-reaching decision. In order to consider the options available to the University of Leeds, it may be useful to consider several portal scenarios. These scenarios are not meant to be exhaustive, nor mutually exclusive; they are merely a means by which the portal project can focus on the benefits which result from including various bits of underlying functionality as part of the portal (though not necessarily as part of a portal product).

Further details about potential portal scenarios and their benefits are included in appendix 2.

Re-vamp Campusweb It is possible to provide the two common characteristics of a portal (single point of access and tailored view) by updating Campusweb and simplifying sign on to disparate systems. Campusweb could offer role based views of its content (as the University web site does) and include a tab which lists short-cuts to web-enabled applications. Simplified sign on could be achieved by encouraging the ‘owners’ of the various applications to authenticate users against Active Directory (i.e. users have a reduced number of usernames/passwords).

Advantages: relatively quick, relatively simple and cheap to implement. Disadvantages: doesn’t reap any of the benefits of a portal normally associated with a portal (improving ease of access to information and resources, increased productivity, off-campus access to restricted web- content); all the current problems remain (users difficulty in distinguishing between Campusweb and University internet sites, poor Campusweb search engine, lack of confidence by users in Campusweb).

Favourites portal This scenario differs from the Campusweb revamp in that it can offer a truly customised view since users are required to logon.

Advantages: user reduced time to find relevant content and applications.

Front door portal This scenario has the additional functionality of authentication to remote applications, i.e. the user is not required to login (single-sign on rather than simplified sign on).

Advantages: reduced time to access applications (improved satisfaction and productivity), improved security, reduction in password queries to help desk, supports remote working.

Community portal (CP) This scenario emphasises creating an environment for sharing resources. It offers tools for community building (group discussion lists, group notice boards, shared calendars, shared file store).

4 Advantages: promotes collaborative working, alternative to VLE functionality (under utilised by some areas of the University, fosters campus community.

Information portal (IP) This scenario has an underlying content in order to deliver timely and current news and documents along with ability to find resources easily.

Advantages: improved access to information, improved control over Campusweb.

Service oriented portal (SOP) An emphasis on delivering services rather than access to applications.

 Channels offer ‘services’ rather than access to full functionality of an application.  True channels – i.e. services offered in portal channels and portal infrastructure does web enablement.

Advantages: common and consistent user interface, improved productivity and reduced overload in introduction of new services; allows channels which aggregate data from more than one source, allows delivery of services to match business processes;, provides a presentation for all current and future applications, saves costs in purchasing web-enabled applications/saves development effort.

Unified campus portal (UCP) This scenario can include all the functionality described for the other scenarios but adds integration (at the data level) functionality. That is, a messaging server is used to pass/update information between disparate systems. An example might be - when a student drops a module, the change is reflected in the portal, in the student records system and in the VLE.

Advantages: improved data quality, reduced manual processes in updating data, replacement for (though does more than) LURCIS?

5 2. Business and user requirements

The definition of common portal characteristics along with details of portal product functionality, and an overview of the benefits of a portal, together demonstrate that the first stage of a requirements specification for an institutional portal should include:

 Identifying business requirements  Identifying portal roles  Specifying user requirements for each role  Identifying a portal scenario

2.1. Business requirements

There are several strands within the University's general strategy, the University's IT/IS strategy, the Library strategy and the ISS strategy which point towards the need for portal implementation. Both the University IT/IS strategy and the ISS strategy explicitly state that the University/ISS need to work towards integrating web-enabled facilities in a portal environment. The following is from the University IT/IS strategy:

Strategy priority Strategy rationale Strategic action points 5.2  Improve efficiency of teaching  Virtual Learning Environments (VLEs) Develop an integrated processes. will integrate with the University’s other Managed Learning  Improve efficiency of administrative corporate systems and processes, processes. particularly student administration. Environment (MLE) in  Improve student experience.  Allow staff and student access to line with HEFCE/JISC  Improve cross-education links. information over the Web by integrating guidelines  Maximise Return on Investment of data sources and information systems corporate systems. and incorporating infrastructure and  University strategy points 1.3, 1.4, 3.2, authentication mechanisms: the 5.1, 7.2 “enterprise portal”. 6.2  Need to adapt teaching and working  24/7 support wherever possible. Information provision styles to suit the individual.  Personally configurable systems and tailored to personal need  University strategy points 1.2, 1.3, 3.2, user interfaces (such as on a Web- 3.3, 5.2, 6.1, 7.2 portal). and ways of working.

Clearly, an overarching business requirement is to fulfil the University’s strategic aims but the strategy rationale leads us to specific business requirements for a portal:

 Improve efficiency of teaching processes.  Improve efficiency of administrative processes.  Improve student experience.  Improve cross-education links.  Maximise Return On Investment of corporate systems.  Need to adapt teaching and working styles to suit the individual.

In addition, there are further points within the strategy documents which point to functionality which could be provided by a portal product, for example “Design and deliver collaborative systems and tools”. Most importantly however, more than a dozen strategic action points specifically mention web-enabling applications. This together with a specific strategic action “Wherever possible, software and hardware should interface with the WWW or be accessible over it” point to a clear need to implement a web interface that can aggregate all the web-enabled services that will develop

6 over the next few years. In order to maximise return on investment on corporate systems then a portal product should provide the tools required to web enable applications.

Appendix 3, Mapping portal features against University strategy documents, gives more detail of business requirements

2.2. Portal roles

A portal can offer very broad roles such as students, staff, alumni or prospective students, or it can tailor content further offering finer roles for students and staff. The finer the role, the more profiling information is required about the user. The focus of the Academic Services project has been on analysing requirements for a broad student role with the intention of launching a student portal first, but limited requirements analysis for a staff portal has also been undertaken in order to ensure that the requirements specification encompasses any future needs.

Since students and staff can have more than one role, the portal should have the ability to aggregate content to deliver a multi-role interface. In addition, if the portal is to be used as a vehicle for delivering the web content which currently exists as Campusweb then it should be able to offer access to the freely available part of that content without a user needing to login, or via an easily accessible guest role.

2.3. User requirements

This section draws on the User Requirements Report [3] produced as part of the Academic Services Institutional Portal Project. Appendix 4 lists the recommendations resulting from the user requirements analysis. Briefly, the portal should:

 focus on communication/collaboration functionality, library services and VLE integration  offer functionality which is new or exclusively accessed through the portal  offer admin functionality which is simple to use, directed, well- supported, and based on accurate information (i.e. give user the ability to update info in student record)  focus on delivering customised content and services  authorise users to access some applications (i.e. not prompt for the user to login to the application)  contain generic content which is accurate, current and easily searchable (particularly up-to-date contact information).

The most popular functionality is listed here:

Communication and collaboration applications All focus group attendees reported that they used their University email account frequently – in many cases it being essential for receiving emails from their departments, and the ability to access University email was the most important feature for inclusion in a portal for students. Access to calendar information was more important for staff than students, whilst use of collaborative tools was important to the majority of staff and was often commented on in the survey and meetings with staff.

Related survey ratings: 7 ‘Access University email account’ - rated 1st by students and 2nd by staff. ‘Access shared calendars - keep track of other staff and/or departmental events’ - rated 20th by students and 7th by staff. ‘Access personal calendar’ - rated 37th by students and 6th by staff. ‘Access your personal email account’ - rated 15th by students and 28th by staff.

Library services All the separate library services mentioned in the survey were rated highly by both students and staff. During focus groups, students thought that only viewing their personal library record was not that useful – they generally wanted to be able to carry out some interaction such as renewing books. In addition, the postgraduate students and 3rd/4th year students in particular were keen on the idea of a library portal.

Related survey ratings: ‘Search the library catalogue’ - rated 2nd by students and 8th by staff. ‘Check your library account (view reservations/books on loan etc)’ - rated 4th by students and 11th by staff. ‘Renew library books’ - rated 3rd by students and 15th by staff. ‘Place/remove library book 'holds' (reserving an item)’ - rated 7th by students and 19th by staff. ‘Search your favourite library e-resources or web sites’ - rated 14th by students and 20th staff.

Access up-to-date contact information ‘Access up-to-date telephone/email directory for University staff’ was rated 1st by staff - perhaps a reflection of the fact that the current online directory is inaccurate and incomplete. When discussing email in meetings with staff this feature was frequently mentioned in conjunction with the desire for easily accessible institutional email distribution lists.

Related survey ratings: ‘Access up-to-date telephone/email directory for University staff’ - rated 13th by students and 1st by staff.

Access teaching/learning materials for courses Students rated access to academic related information highly in both the survey and focus groups. In particular online exam papers were highly rated by almost all attendees and a staff focus group with academic related library staff considered online exam papers to be an essential key feature for an institutional portal. Access to Nathan Bodington was specifically mentioned in focus groups and single sign on to this application was considered important. (A number of students (5) commented on Bodington stating that it was “too convoluted”, “scary”, “and intimidating” but that the logon should be removed to make it easier to get at resources. Other students (4) were more positive about Bodington but again would like to improve the ease of accessing it).

Related survey ratings: ‘Access teaching/learning materials for your course/modules’ - rated 5th by students and 42nd by staff. ‘Access reading lists’ - rated 9th by students and 41st by staff. ‘Access (previous years') online exam papers’ - rated 12th by students and 44th by staff.

8 Search/Information In addition to those library related searches rated in the survey, the University web site, Campusweb and Google searching was rated highly by both students and staff. The relationship between the University website and the portal was frequently mentioned in meetings with staff – in connection with news, events and searching. Generally views about the University web site and Campusweb varied, students being more positive than staff. In particular, concerns were expressed about the search engine available on Campusweb.

Related survey ratings: ‘Search the library catalogue’ - rated 2nd by students and 8th by staff. ‘Search University web pages/intranet’ - rated 11th by students and 3rd by staff. ‘Perform an internet search - using the Google search engine or similar’ - rated 10th by students and 16th by staff. ’Access course/department/University handbook’ - rated 17th by students and 10th by staff. ‘Search your favourite library e-resources or web sites’ - rated 14th by students and 20th staff. ‘Access institutional calendar keep track of University events’ - rated 20th by students and 9th by staff. ‘Access shared calendars - keep track of other staff and/or departmental events’ - rated 20th by students and 7th by staff. ‘Access University related news and information about University events’ - rated 27th by students and 12th by staff. ‘Access campus maps/directions’ - rated 29th by students and 5th by staff.

Administration features Other than accessing timetabling information (for students) survey items relating to ‘administration’ were not rated particularly highly by students and raised no survey comments from staff or students. A few focus group attendees did mention queues for registration and thought the ability to register online was desirable. Some students had paid their accommodation fees online. For some who didn't pay fees themselves, this facility was not applicable. Some were not confident that the security provided by a portal would be sufficient for them to confidently do online transactions, unlike online banking. Many had previously done online financial transactions. Though ‘administration’ is not particularly desirable for students, it could be perceived to be important for the University since integration of this functionality in a portal would lead to an increased use of the various services. That is, as students are already using the portal to access the functionality which they consider desirable, they will be more likely to carry out web enabled ‘administration’ such as registration, fee payment and update of personal details.

Related survey ratings: ‘View all the marks for your course/modules’ - rated 16th by students and 44th by staff. ‘Enter marks’ was rated 50th by staff ‘Check the availability of rooms and make room bookings’ - rated 14th by staff. ‘View/update your University annual leave record - rated’ 18th by staff.

9 ‘Check/buy printer credits’ - rated 18th by students. ‘Change your personal details e.g. Leeds address, email etc’ - rated 19th by students. ‘Access exam timetables’ - rated 6th by students and 39th by staff. ‘Access course timetables’ - rated 8th by students and 38th by staff.

Personalisation and customisation Two personalisation features were specifically mentioned in the survey - these were poorly rated by students and given a fairly high rating by staff. These results do not particularly reflect focus group and meeting feedback when students were more keen than staff on being able to personalise their own screens. In addition, students were strongly in favour of customisation (i.e. the system/’University’ tailoring functionality according to the user role) – this being seen as the key to avoiding information overload. The issue of multiple ‘roles’ for staff and joint honours students were also raised.

Related survey ratings: ‘Ability to control what information is displayed in your portal screen displayed and where it appears’ - rated 41st by students and 17th by staff. Ability to change the look and feel of your portal screen - rated 47th by students and 24th by staff.

News News was rated highly in student focus groups – it being the most popular external resource for undergraduates and rated second (after e-resources) for postgraduates.

Related survey ratings: ‘Have local or national news delivered or accessible’ - rated 43rd by students and 35th by staff.

File storage This feature was not included on the survey but was raised by students and staff – it being particularly important for staff who work from home and students who have a PC at home. Having a 'briefcase', i.e. storage on the network which was accessible from off campus was seen as desirable highly desirable by students. One focus group attendee used the current network space allocated, but found it insufficient and made use of CD- Writers which some cluster machines have.

Off-campus access and simplified sign-on This feature was not explicitly mentioned in the survey but was discussed in all focus groups and meetings. Four students admitted that it was difficult to remember many different usernames and passwords that were required currently to access various services/resources. To have a simplified sign-on for e-resources was seen as desirable by most though some students cited security concerns as a draw back for giving single-sign on to administrative functions. Off campus access was mentioned in connection with many portal features – file storage, access to self-service functionality, and simplifying sign on. Generally, both staff and students were keen to have access to applications from home – Bodington being mentioned by a few students. In particular, a

10 number of comments were received from staff and students at Bretton or Wakefield and also from part-time and postgraduate students.

Coursework Submission Online submission of coursework was not included on the survey but was raised by both academic and academic support staff in meetings. Related to this was the need to ensure that the work did originate from the declared sender, and some staff who expressed an interest in this functionality had already started to research how this could be done at a departmental level.

Instant messaging Though not rated highly in the survey, the ability to send ‘instant messages’ was mentioned by 6 focus group attendees. Indirectly related - it is worth mentioning that a number of focus group attendees and a number of survey comments from students indicate that students are frustrated by non- academic use of cluster PCs. Though instant messaging (IM) may be a ‘sticky’ application for some students, (i.e. one that attracts them to use the portal), it may also be a source of discontent from students – and the discontent may well be directed at the portal itself rather than at the IM application.

Related survey ratings: ‘Send instant messages to friends or colleagues’ - rated 32nd by students and 27th by staff.

Alerts The only survey item related to ‘alerts’ was that for staff events (which was rated quite highly) but alerts for coursework deadlines, library overdue notices and library fine reminders were all commented on in focus groups and on the survey.

Related survey ratings: ‘Receive alerts for staff development events’ - rated 13th by staff.

2.4. Portal scenario

Business requirements and user requirements point towards a portal which offers the following standard portal features as a minimum:  personalisation,  customisation (at a fairly fine level, i.e. offer department of course based content to students rather than a generic ‘student’ role),  off-campus access to all parts of Campusweb,  authentication to remote applications.

It is not necessary to pick one scenario from those suggested, but a portal specification needs an understanding of the type of ‘integration’ that will be offered in a portal. It is likely that in the first instance, a portal will offer links to some remote applications (which users will ideally not have to login to) but future work in web-enabling applications is likely to adopt a more service-oriented approach to application integration. A current example would be offering SIPR – allowing web-based purchase requisition, as opposed to web enabling (or buying a web front end to) the whole purchasing application. The functional specification which follows assumes that a portal should have the potential to offer services rather than links to applications.

11 3. Functional requirements of a portal

In this section, business and user requirements have been refined in order to identify functional requirements for a portal. Content requirements are covered in section 4.

3.1. Roles

FR1) System will allow administrator to define custom user types. There is no limit to the number of roles which can be defined.

FR2) There is no limit to the number of roles a user can have in the system.

FR3) A guest role is possible.

FR4) Each role can offer a tailored view of all the information relevant to user-specific needs and preferences.

FR5) System can dynamically access profiling information for a user in order to determine the user’s role(s) and thus tailor their portal view.

3.2. Channels

FR6) System will allow administrator to define custom information channels. No limit to number of information channels.

FR7) Channels are written using standards and can be easily transferred to another framework using those standards.

FR8) Off-the-shelf channels for HE available or being developed.

FR9) Access to channels can be restricted to specific roles.

3.3. Infrastructure

FR10) System supports established standards and communication protocols. (JMS, XML, IMS, HTTP/HTTPS, LDAP, IMAP, POP, SMTP).

FR11) System allows multiple authentication methods that can use existing databases (for example, can authenticate using an existing LDAP server, or using Active Directory via Kerberos).

FR12) System offers GUI web enablement tool – that is a GUI which connects to a remote application’s database and allows a developer to create a web-form (based on fields in the DB) which can then be used to interrogate/update the application’s database.

FR13) Forms routing available - paper documents can be replaced by web- based forms. In addition, forms tracking software built in.

FR14) Secure connection can be specified using standard method (e.g. system handles initial authentication of users by encrypting the channel between the client and web server via Secure Sockets Layer (SSL).)

12 FR15) System offers a web accessible GUI for carrying out administrative functions. Administrative functions can be delegated.

FR16) System provides system monitoring tools through a web interface - for a variety of logging and reporting functions.

3.4. Portal front-end

FR17) Intuitive interface, requiring little or no user training.

FR18) Administrator has full control of (initial) look and feel and changes can be made quickly.

FR19) Good set of tools provided to ensure that site meets WAI accessibility guidelines.

FR20) Portal user has access to editing tool for customising tabs, colours, and fonts.

FR21) Several online help features, for example tutorials and FAQs.

FR22) Electronic balloting and polling are fully supported.

3.5. Additional functional requirements which may be provided by a portal product

The following requirements may be provided by a portal product or may be provided by other means.

FR23) The system draws on content from a web content management system.

FR24) The system offers a search engine which can search web content across campus.

FR25) The system includes collaborative/community building tools (group creation/joining with associated file store, discussion board, calendar).

FR26) Single sign-on for multiple functions from one central database.

FR27) (desirable?) Portal API can pass information to other applications, seamlessly integrating multiple sources of information, and ability to write own interface, for example passing user preferences between applications.

13 4. Content requirements for an institutional portal

Content requirements focus on a student portal but details for further stages and a staff portal are outlined. Details of the stages are given below – they may not necessarily be consecutive.

o Stage 1 – undergraduate student role pilot Launch student portal pilot - Easter 05 o Stage 2 – postgraduate role and finer ‘grouping’ Launch student portal - Oct 05 o Stage 3 – staff role Launch staff portal o Stage 4 – refinement of student role functionality o Stage 5 – refinement of staff role functionality

4.1. Stage 1 – undergraduate student role pilot portal

Assumptions:

 One broad undergraduate student role.

 Content as per recommendations in User Requirements Report: o communication/collaboration functionality, o library services, o VLE integration, o functionality which is new or exclusively accessed through the portal.

 Campusweb content migrated into CMS.

 Access to web enabled applications and other web functionality is via links (application opens in separate window).

 Users do not need to logon again in order to access web mail, library account, Bodington, web-enabled Banner functionality.

Issues:

 How will authentication to web-enabled applications (from within the portal) be achieved? In the first instance, it may be necessary to offer an SSO service which caches usernames and passwords (i.e. users must logon once to each application).

(Note for Information Architecture away day - see Nigel Bruce’s report on which applications currently use/have plans to use AD).

 How will CMS functionality be provided?

 How will collaborative tools functionality be provided? Both Bodington and VKP offer some ‘e-tools’ such as discussion lists and shared file-store. Is Bodington the only collaborative tool functionality to be offered to students?

 What “new or exclusively accessed through the portal” content/functionality will be offered?

o Currency of contact information

14 o Create exam paper database o Alerts o Message board/small ads

Content:

CR1) Campusweb content, university web sites and internet accessible and searchable.

CR2) (Authenticated) link to student webmail.

CR3) E-tools for collaboration/community building. Ability for user to create groups.

CR4) Link to library web catalogue.

CR5) (Authenticated) link to user account on Library Management System.

CR6) (Authenticated) link to Bodington.

CR7) (Authenticated) links to currently web-enabled functionality:

o Update personal details o Re-enrolment/module selection o View module catalogue o Fee payment

CR8) One or more of the following new functionality possibilities:

o Access exam paper database o Up-to-date (searchable) contact information o Alerts o Message board/small ads o External news feeds

4.2. Stage 2 - postgraduate role and finer ‘grouping’

Assumptions:

 Postgraduate role.

 Further profile information available for all students so finer roles or ‘grouping’ can be used to offer school/dept content.

 Additional content focussing on research resources.

Issues:

 How will be profile information be provided? In order to provide the user profile information required for offering finer roles there must be a match point between the database that the portal authenticates against and the database containing user profile information.

 How will authentication to library portal (and other web-enabled research resources) be achieved?

 What additional research related content will be offered? Access to research databases was not related very highly in the user

15 requirements analysis undertaken. Further work on analysing the postgraduate role is required.

Content:

CR9) (Authenticated) link to library e-resources – library portal.

CR10) ResearchResearch feed.

CR11) Access other research related resources.

CR12) All other content/functionality available in the pilot portal.

4.3. Stage 3 – staff role

Assumptions:

 One broad staff role.

 Additional content focussing on staff self-service.

Issues:

 How will authentication to the portal be achieved? (Dependent on all staff being on AD?)

 How is access to staff Outlook account to be achieved? (Dependent on all staff being on Exchange). Via Outlook web interface?

 How will authentication to web-enabled applications (from within the portal) be achieved?

(Note for Information Architecture away day - see Nigel Bruce’s report on which applications currently use/have plans to use AD. In addition, SSO access for staff to Bodington and Library Management System may prove difficult since they each create staff accounts manually).

 What additional staff content will be offered? Further work on analysing the staff role is required. This content will be finalised after further requirements analysis (and as per ISS plans for self- service).

Content:

CR13) (Authenticated) link to Outlook account.

CR14) (Authenticated) link to Bodington.

CR15) (Authenticated) link to user account on Library Management System.

CR16) (Authenticated) link to SIPR.

CR17) (Authenticated) link to Banner for Faculty.

CR18) (Authenticated) links other web-enabled applications (as per ISS plans for self-service).

CR19) Link to VKP. 16 CR20) All other content available in student portal (as appropriate).

4.4. Stage 4 – refinement of student role functionality

Refinement of the student roles may involve:

 Development of method for offering SSO?

 Additional functionality as it is web-enabled. Content favoured in the user requirements work so far:

o View marks o Financial statement o Access reading lists o Access timetables (course/exams)

 Offering library services as channels rather than via link to application.

4.5. Stage 5 – refinement of staff role functionality

Refinement of the staff roles may include:

 Finer roles for staff – in order to provide the user profile information required for offering finer roles there must be a match point between the database that the portal authenticates staff against and the database containing user profile information.

 (Authenticated) link to VKP (from within the portal)

17 5. Refining the specification

For the purposes of this report, the ASPPM attempted to refine the functional specification further but found that additional input (from the Information Systems Architecture and from advisory bodies) was required before the functionality could be refined and rudimentary costings could be identified. This section outlines the additional input required before the portal project can move into the tender and pilot planning stages.

5.1. Required functionality for a portal product

Section 3.5 of this report identifies additional functional requirements for a portal which may be provided by a portal product or may be provided by other means. The Information Systems Architecture currently being developed within ISS will inform the refinement of this functional specification – allowing the ASSPM to finalise requirements for portal product tender documentation.

5.2. Weighting functional requirements and determining criteria for portal product selection

In order to assess how well a range of portal products fulfil the functional requirements, a list of criteria has been drawn up (based on work undertaken by other universities). This list needs to be refined further (based on the Information Architecture strategy) and the criteria then checked/approved by a technical advisory body. It will be appropriate to identify a small group of technical staff (from ISS but including some input from faculty based technical staff) in order to form a Technical Advisory Board. This refinement and scoring exercise should be carried out prior to the tender exercise since the criteria may preclude some products, identify that an open source solution is preferred, or perhaps identify a single product which fulfil the criteria.

Appendix 5 shows the current list of criteria for portal product selection.

5.3. Specifying the interface

A portal usability study [8] has been undertaken by a postgraduate student at the University of Leeds. The study tested the University of Nottingham’s (SCT Luminis-based) portal and identified more than 50 areas of concern – both in terms of ease of use and accessibility. This functional specification states, in very general terms, that the portal should have an intuitive interface but does not identify what exactly is required in order to provide an intuitive interface. A detailed functional specification for the portal ‘front- end’, looking at ease of use, accessibility and, in particular, content classification, needs to be drawn up as part of the pilot planning phase. This specification could be informed by further usability testing. A small team of staff with a particular interest in usability and/or accessibility could drive and approve this specification. (The School of Psychology at the University of Leeds has proved helpful in this work so far and would be willing to advise future testing).

18 5.4. Finalising and prioritising content for a portal pilot/Specifying portal roles and a portal scenario (for level of integration)

The focus of the portal project so far has primarily been on scoping requirements for a student portal. The recommendations in the User Requirements Report [3] have been used, in conjunction with other research undertaken by the ASSPM, in order to derive a list of functional requirements and identify content requirements for various stages of portal development. A number of assumptions have been made regarding the type of portal which should be developed, but neither the assumptions nor the requirements have been endorsed by the various stakeholders in the portal project. A user advisory body needs to be formed, including students but also faculty based staff, in order to approve/refine the content specification and the following recommendations/assumptions:

 Campusweb should be migrated to a web content management system and subsequently accessed via the portal (with a ‘guest’ role to preclude the need to login for all but the currently restricted content of Campusweb).  Initial ‘integration’ involves providing links to web enabled applications (with some mechanism for authentication) but consideration should be given to developing channels to services in further phases of the portal project.  A broad student role should be the focus of the portal pilot but faculty/ course/ module content should be included as part of the second phase of the portal project (i.e. after the pilot phase but before university-wide launch).  The focus of the content on collaborative tools/library services and VLE integration

Endorsement of these recommendations, together with the Information Architecture strategy will enable the ASPPM to outline costings, staffing and hardware requirements.

19 References

Reports and project documentation for the AS Portal Project are generally held on VKP. If you are unable to access the documents using the links quoted below, contact Bo Middleton ([email protected]).

1. Middleton, B. Academic Services Institutional Portal Project – Project Brief, version 1.5. Available from: http://vkp.leeds.ac.uk/Drive/gotodoc.jsp? doc=176311 [Accessed 14/6/04]

2. Middleton, B. Academic Services Institutional Portal Project – Interim Report. Available from: http://vkp.leeds.ac.uk/Drive/gotodoc.jsp?doc=319447 [Accessed 14/6/04]

3. Middleton, B. Academic Services Institutional Portal Project – User Requirements Report. Available from: http://vkp.leeds.ac.uk/Drive/gotodoc.jsp? doc=319452 [Accessed 14/6/04]

4. JISC. 2002 Information Environment Development Strategy. Available from: http://www.jisc.ac.uk/dner/development/IEstrategy.html [Accessed 14/6/04]

5. Dolphin, I., Miller, P., & Sherratt, R., 2002. Portals, PORTALs everywhere. Ariadne. 33. Available from: http://www.ariadne.ac.uk/issue 33/portals/ [Accessed 14/6/04]

6. Stuckes, J., 2002. Avoiding portal wars: a JISC view. Available from: http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2002/ [Accessed 14/6/04]

7. Katz, R.N. It’s a bird! It’s a plane! It’s a …portal? In: Katz, R.N. et al. Web Portals in Higher Education: Technologies to Make IT Personal. 2002. Available from: http://www.educause.edu/ir/library/pdf/EQM0038.pdf [Accessed 14/6/04]

8. Bye, R. Portal Project Usability Report. 2004 Available at: http://vkp.leeds.ac.uk/Drive/gotodoc.jsp?doc=319526 [Accessed 14/6/04]

9. Daigle, S. L. & Cuocco, P. M. Portal Technology Opportunities, Obstacles, and Options: A View from the California State University. In: Katz, R.N. et al. Web Portals in Higher Education: Technologies to Make IT Personal. Jossey-Bass, San Francisco. 2002. Available from: http://www.educause.edu/ir/library/pdf/pub5006f.pdf [Accessed 14/6/04]

10. JISC 2001. Briefing paper no.1: MLEs and VLEs explained. Available from http://www.jisc.ac.uk/mle/reps/briefings/bp1.html [Accessed 14/6/04]

11. Kemp, C. Portals - a report for the Director of Educational Strategy. QMUC 2002. (Quote from personal communication with Toole). Available at:

(I have a printed copy of this report but I can no longer find it on the web)

12. Phillips, T and Browning, P. University of Bristol Portal Project Proposal. 2002. Available from: http://www.bris.ac.uk/is/projects/portal/docs/ppp5.pdf [Accessed 14/6/04]

13. Frazee, J. SDSU Rubric for Rating Commercial Portal Vendors. 2001. Available from: http://its.sdsu.edu/portal_rubric.pdf [Accessed 14/6/04] 20 Bibliography

Awre, C. Portals and the JISC Information Environment Strategy. 2002 www.nottingham.ac.uk/portals2002/ChrisAwre.ppt

Dovey, M. JISC Technology Watch Report: Java Portals. 2001. http://www.jisc.ac.uk/index.cfm?name=techwatch_report_0103

Eisler, D. Gilbert, S. & Mehaffy, G. Provosts on Portals. 2000. http://old.weber.edu/portals/

Gleason, B. Portal Technology Opportunities, Obstacles, and Options: A View from Boston College. In: Katz, R.N. et al. Web Portals in Higher Education: Technologies to Make IT Personal. http://www.educause.edu/ir/library/pdf/pub5006j.pdf. 2002.

JISC Information Environment Architecture Portal FAQ. 2002 http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/faq/portal/

Lightfoot, E & Ihrig, W. Customer-Centered Resources. In: Katz, R.N. et al. Web Portals in Higher Education: Technologies to Make IT Personal. 2002 http://www.educause.edu/ir/library/pdf/pub5006e.pdf

Lorenzo, G. Web Services Enabling Technology for Application Integration and Assembly. HEKATE. 2002. http://www.hekate.org/HEKATEwebserviceswhitepaper.pdf

McDonald 2003 McDonald D, Web Services Technologies Report, JISC, 2003, Technology Watch Report TSW 03-04. http://www.jisc.ac.uk/index.cfm? name=techwatch_report_0304

Robiette, A., 2002. The future of authentication for JISC services. Available from http://www.jisc.ac.uk/pub02/ar1/future_auth.html

Strauss, H. All About Web Portals: A Home Page Doth Not a Portal Make. In: Katz, R.N. et al. Web Portals in Higher Education: Technologies to Make IT Personal. 2002. http://www.educause.edu/ir/library/pdf/pub5006g.pdf

Walsh, J .F. & Thomas, J. The Enterprise Portal as a Service Delivery Framework, Educause 2002 Atlanta, Georgia. http://www.educause.edu/asp/doclib/abstract.asp? ID=EDU0295