VPBL/10/01
VLE/Portal Review
Draft Report, Feb 2011
VLE/Portal Review
Contents
Background/context .......................................................................................................................................... 2
Review methodology.......................................................................................................................................... 3
What is a Portal? What is a VLE? ...................................................................................................................... 3
Current status .................................................................................................................................................... 4
Table 1 Summary of current VLE and Portal usage and functionality .......................................................... 5
Figure 1 Leeds Portal/VLE integration diagram - user perspective .............................................................. 7
Figure 2 Leeds Portal/VLE integration diagram – architecture/data perspective ........................................ 8
VLE/Portal models.............................................................................................................................................. 9
Table 2 Summary of approaches taken at different HEIs ............................................................................. 9
University A (very large Russell Group university) ........................................................................................ 9
University B (Russell Group university) ....................................................................................................... 10
University C (London-based Russell Group University College) .................................................................. 11
University D (small university, in ‘University Alliance’ group) .................................................................... 11
University E (Russell Group university) ....................................................................................................... 12
Review Findings ............................................................................................................................................... 13
Product Landscape - Portal products .......................................................................................................... 13
Product Landscape - VLE products .............................................................................................................. 13
Feedback from users ................................................................................................................................... 14
Summary of lessons learned ....................................................................................................................... 15
Options and scenarios for future Portal and VLE functionality ........................................................................ 17
Portal options .............................................................................................................................................. 17
VLE options.................................................................................................................................................. 17
Table 3 Summary of future scenarios and implications for Leeds ............................................................. 18
Next stage ........................................................................................................................................................ 19
Issues ........................................................................................................................................................... 19
Draft/possible recommendations ............................................................................................................... 19
1
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
Background/context
VLESG and SPSG have confirmed agreement with a proposal (SPSG-36-02 and VLESG/09/10) to
undertake a ‘review’ of the Student Portal and the VLE.
“It is proposed that the Portal and VLE Services should undertake an initial evaluation of Portal and
VLE options (including current/future versions of the currently implemented solutions) – to identify
possibilities for separate and combined web interfaces, and to jointly report to VLESG and SPSG....”.
The roadmap for both the Student Portal and the VLE currently allows for an evaluation of the
applications as part of the hardware replacement cycle, i.e. every 5 years the hardware
infrastructure for each application will need to be replaced – providing an obvious point at which to
consider whether the applications should be offered in the same way/using the same software and
what functionality they should provide.
Recent and ongoing developments in web technology mean that we should consider why the
University has and/or needs both of these two virtual environments, and joint working on an initial
evaluation of Portal/VLE approaches allows us to highlight common and distinct requirements for
the two systems.
The review is not intended to revisit the work undertaken for the 2005 VERG report, nor the
business cases for the Portal and for the VLE; its overall intention is to consider whether Leeds is
undertaking the correct approach by providing two systems as per the current setup.
The VLE/Portal review was proposed, in part, to address the question "why do we have two" but also
to address the medium/long term planning for the VLE and Portal Services. Both services have
teams which are based in the Library and the Library has overall responsibility for the two services.
The Library based teams provide specialist functional development/ support (whilst ISS provide
infrastructure development/support and, in the case of the VLE, SDDU provide training and
pedagogic support). The Library’s planning is based on the assumption that the University should
continue to offer both a Portal (i.e. a web interface which offers students access to university
communications, information and web-based ‘services’, with targeting and single-sign-on) and also a
VLE (i.e. a web interface which offers students access to course materials & e-learning tools and
allows staff to manage the course areas). Whilst it is safe to assume that students need web access
to this functionality, the mechanisms used for such access need to be regularly evaluated, and
consideration given to the potential for delivering the VLE and Portal services differently. Defining a
medium-term roadmap for the applications will enable the Library to understand how best to
optimise the current teams.
2
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
Review methodology
As previously agreed by VLES and SPSG, the VLE/Portal review included the following activities:

Define and describe the present situation: - including areas of similarity for the two systems,
areas of uniqueness, and how the two systems work together.

Scope and describe different models for offering Portal/VLE functionality.

Investigate the benefits and problems of different models in practice, through visits to other
universities, assessments by HE bodies (e.g. JISC, Educause, ALT-C), attendance at relevant
events and discussion within appropriate HE networks.
In addition, the review included

Consideration of the development roadmap of the present Portal and VLE software

Focus groups with students and a small survey of academic staff– to identify user
perceptions and usability issues

Further literature review – including internal documents related to virtual environments and
system architecture.
What is a Portal? What is a VLE?
The term ‘portal’ has been used to describe many different types of web functionality. The
University of Leeds’ Portal fits well with the JISC definition for an ‘institutional portal’1:
“An institutional portal provides a personalised, single point of access to the online resources
that support members of an institution in all aspects of their learning, teaching, research and
other activities. The resources may be internal or external and include local and remote
'information resources' (books, journals, databases, Web-sites, learning objects, images,
student information systems etc.), 'transaction-based services' (room bookings, finance,
registration, assignment submission, assessment, etc.) and 'collaborative tools' (calendars,
email, chat, etc.).”
The VLE at Leeds also fits well with the JISC definition2:
“A VLE provides an online framework that supports the end-user in their learning activities
within a particular pedagogic context. Typically, the VLE will provide support for the delivery
of learning materials, learner assessment, collaborative tools, course registration, etc. A VLE
will normally also provide access to information resources that support the learner in their
activities.”
In both cases, the definitions describe an online environment, a point of access to resources and a
suite of collaborative tools. A more in-depth look at what these two systems offer at Leeds is useful
to highlight similarities and differences.
1
2
3
http://www.jisc.ac.uk/whatwedo/programmes/portals/faq.aspx
http://www.jisc.ac.uk/whatwedo/programmes/portals/faq.aspx
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
Current status
Portal software is currently Luminis 4. This product is supplied by SunGard – who also supply
Banner. Luminis is designed to work closely with Banner but, at the last Luminis upgrade, Leeds took
a strategic approach to data integration – creating a data feed which can be used by both Portal and
VLE systems (i.e. effectively removed the tight integration with Banner). VLE software is currently
Blackboard 7.x moving to 9.x in 2011.
VLESG and SPSG have previously considered the functionality of the Portal and the VLE in terms of
their similarities and in terms of their integration; in order to define how best to support users that
need to use both interfaces. As the two systems have been implemented and then further
developed, we have tailored the systems in order to exploit particular features of each.
Table 1 below gives a summary of current usage and functionality of the Portal and VLE systems at
Leeds.
Figures 1 and 2 below illustrate how the Portal and VLE systems at Leeds are integrated – in terms of
the user experience and in terms of the underlying data which is consumed by the two systems.
To summarise:


4
The key differences reflect the purpose of the two systems:
o The Portal can target communications in a way which is not achievable in the VLE –
that is, it can customise what a user sees depending on which groups they are a
member of.
o The VLE offers access to tools which support L&T activity – announcements,
documents, blogs, wikis, discussion boards, test, questionnaires, electronic
submission areas, timed release of module materials and more.
o Single sign on to other systems (e.g. email) is part of the Portal system’s base
functionality, whereas providing single sign on in the VLE requires custom
development and ongoing maintenance of that.
Whilst the Portal focuses on giving access to all web content and applications, the VLE
focuses on supporting learning and teaching activity. The two systems have been optimised
to ensure that the student experience is as seamless as possible:
o They exploit the same data feed – to ensure they offer consistent information to
users such as lists of their modules (and to reduce ‘integration costs’).
o The Portal offers links into the VLE (in the same way that it offers links into other
systems and web content). This includes module-specific links for ease of access and
VLE announcements (next to ‘Portal’ announcements).
VPBL/10/01
VLE/Portal Review
Draft Report, Feb 2011
Table 1 Summary of current VLE and Portal usage and functionality
Functionality
VLE
Portal
Similarities
Differences
Groups
Has a number of grouping mechanisms –
module areas and ‘organisations’ for non
module based groups such as programmes
and schools that require an area similar to
modules.
There are also system roles that can be
assigned to users. These roles can be used
to target content.
Has ‘groupings’ for each module, and
targeted groupings for numerous other
purposes (halls of residence, all first years,
all postgraduate students, etc).
‘Community groups’ can be requested by
staff and students for any university-related
purpose.
There are also system roles which are
assigned to users. These roles are used
extensively to target content, including
layout, wording, links and announcements.
Currently being used
differently but,
theoretically, each system
can be used to create any
kind of ‘group’.
Portal has a wider range of
grouping mechanisms which
are used extensively for
communications and
personalisation.
Group areas
Each ‘module/organisation’ has a group
area – which can offer access to
announcements, documents, blogs, wikis,
discussion boards, test, questionnaires,
electronic submission areas and more.
These tools can be distributed in nature,
e.g. the Turnitin electronic submission and
plagiarism detection is a hosted service
that is integrated into the VLE.
Group areas are not created for modules or
targeted groupings.
Community groups have group areas with a
basic set of collaboration tools such as
discussion boards.
Currently being used
differently but each can be
used to create ‘group
areas’.
Tools available in the VLE are
focussed on those which
support L&T. Those in the
Portal are less sophisticated
– designed to support group
collaboration.
It is possible to add
new/different ‘tools’ to the
group areas of the VLE.
Targeted
announceme
nts
Can target announcements to modules and
organisations.
Announcements appear aggregated on a
user’s homepage but also in a group area.
Can target announcements to any kind of
Portal group (roles such as UG, groupings for
admin purposes, modules, community
groups etc).
Announcements appear aggregated on a
user’s homepage.
Announcements to community groups also
Currently being used
differently but each can be
used to create and send
announcements.
The Portal has a more
refined communication
feature set –
announcements can be
targeted to different groups.
5
VPBL/10/01
VLE/Portal Review
Draft Report, Feb 2011
Functionality
VLE
Portal
Similarities
Differences
appear in a group area.
Single signon (SSO)
Custom development work is required to
create an SSO connection.
A few custom SSO connectors have been
built (Library reading list and Leeds for
Life).
SSO connections are part of Portal’s base
functionality, although some development
work is required to create each..
Connectors to many University systems have
been created and are maintained as systems
change.
Development work
Larger development and
required to create
maintenance overhead in
connectors in either system the VLE.
(double the costs though –
better tactic would be to
implement authentication
mechanism such as
university-wide usage of
Shibboleth or CAS).
Aggregation
Offers access to L&T resources related to
each user.
Acts as a one-stop-shop – i.e. brings together
access to all resources/ services/
applications that the particular user needs
access to. Different aggregations can be
provided for different roles, thus avoiding
users seeing irrelevant content.
Currently being used
differently but both can act
as an aggregator, i.e. can
bring together links to
various content and
applications.
The Portal has a more
refined communication
feature set, whereas the VLE
is somewhat limited (e.g.
cannot target
announcements).
Personalisati
on
Currently little personalisation.
Shows users the modules and
organisations relating to them, and
announcements from these areas.
Users have a ‘My tab; which allows a small
amount of personalisation.
The Portal personalises the content it shows
according to user role (e.g. taught and
research students see different channels).
Users can add their own newsfeeds and
bookmarks, and can also rearrange their
own layout to some extent.
Some personalisation (i.e.
the user’s ability to tailor
what is viewed) available in
both systems.
Limited customisation (i.e.
the ability for the content
provider to tailor what is
viewed) in the VLE, whereas
the Portal is designed to
offer all content according to
a user’s role.
6
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
Figure 1 Leeds Portal/VLE integration diagram - user perspective
Students access the VLE via the Portal, in the same way as they access a myriad of other systems via
the Portal. They can either click the VLE ‘Quick Link’ on their Homepage tab, which single signs them
on to their homepage in the VLE, or they can access module areas directly, via a ‘deep link’ for each
module in their ‘My Modules’ list.
The VLE announcements for each person are also shown on the Portal’s Homepage tab, next to their
Portal announcements. This is done to ensure students have their attention drawn to VLE
announcements, since they visit the Portal frequently for a range of purposes such as checking their
email.
7
VPBL/10/01
VLE/Portal Review
Draft Report, Feb 2011
SAP
Authoritative data
source for HR/Staff
information
SAP supplies HR
data to Banner
Banner 1
Authoritative data
source for module
and enrolment
information.
SAP supplies
HR data to
LURCID
LURCIS 2
Identity Management
system, tied data from
Banner and SAP
together.
Authoritative source
for Authentication
system.
Banner &
LURCIS
exchange
data
Data feed draws
relevant data from
Banner & LURCIS
Authoritative Data Sources
Figure 2 Leeds Portal/VLE integration diagram – architecture/data perspective
LURCIS provides data
to Active Directory
Data Feed
It has a number of purposes:
1) Brings data together from 1,2
2) Filters data
3) Output XML data files
XML data files loaded
into systems
VLE
8
Portal
Active Directory
Current authentication
mechanism for the
majority of the university
systems including the
VLE and Portal.
VPBL/10/01
VLE/Portal Review
Draft Report, Feb 2011
VLE/Portal models
Although there has been widespread adoption of the VLE throughout Higher Education, in recent
years there has been a recognition that a seamless student experience involves more than access to
online learning, so there needs to be another ‘system’ (such as a portal) to provide a way-in to the
range of systems and information which a user needs access to.
The functionality within a VLE is, in some respects, limited and restrictive – it being designed for the
purpose of supporting learning and teaching activity, and previous research in this area has
considered different models for achieving an extended virtual environment. Initially the MLE
(Managed Leaning Environment) concept was explored, combining VLE and other functionality.
Subsequently portal technology was adopted, in many HEIs, to build a web environment that
supports users in navigating through the various content and systems that they need access to.
More recently, the rise of social media has suggested that a possible alternative scenario could be to
construct a virtual environment out of various existing web tools, brought together by some sort of
framework.
Some very recent research describes distributed learning environments ranging from the traditional
VLE, augmented with a selection of add-on tools, to learning environments that are effectively
entirely composed of separate tools. There has also been discussion within HE about future
possibility of providing outsourced Portal or VLE functionality ‘in the cloud’.
Table 2 Summary of approaches taken at different HEIs
University VLE
Portal
Approach
A
Blackboard 9
uPortal
Need functionality from more than one system
Use Blackboard as primary interface, use Portal as
underlying layer to provide what Blackboard can’t do
B
Web CT Vista
moving to
Blackboard 9
Luminis 3
Need functionality from more than one system
Need collaboration tools separate to VLE
Use Portal as primary interface (i.e. as the way-in)
C
Moodle
Home-grown
portal
Need functionality from more than one system
Use Portal as way-in to services (not to content)
No strategy for collaboration outside of the VLE
D
Blackboard 8
None – use
static web
pages
Don’t need/want to target content or communications
VLE not widely adopted – under review
E
In-house
development
(based on inhouse CMS)
In-house
development
Need functionality from a number of different tools – best
to have a framework to plug these ‘tools’ into
Some difficulties in taking this approach, and user
experience is fragmented because of these difficulties
University A (very large Russell Group university)
This HEI is currently upgrading its VLE from Blackboard WebCT to Blackboard 9 and uses uPortal (this
is the portal technology which the Luminis system used by Leeds is based on).
They have recently defined a vision for how their Portal and VLE should work together – they have
identified that they need the functionality of two different systems and have prioritised access to
9
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
module information (university communications, admin applications and other resources being
secondary). The user environment will be the ‘University A Learning Environment’ (using Blackboard
9) for students and the ‘University A Working Environment’ (using SharePoint) for staff. Their Portal
will disappear as far as users are concerned, although it will still be needed as part of an integration
layer between underlying systems and the user environment. Their overall aim is to provide
seamlessness to backend systems but for students to focus on learning and for staff to focus on
collaboration.
They have outsourced their VLE infrastructure through a hosting arrangement with Blackboard, to
improve reliability and round-the-clock support, although at considerable cost both financially and in
terms of their ability to tailor their VLE differently for different parts of the university.
They have a strategic objective to communicate via mobile devices and this is included in the
strategic plans of both Library and IT Service, but they do not have a long-term or all encompassing
strategy for mobile ‘infrastructure. They have just launched Bb Mobile Central (they started with
CampusM and will decommission this when they move to Bb Mobile Central), although this took
several months longer than intended. Their mobile approach is largely technology driven but the
platform was agreed between Head of IT Service and PVC for L&T, and the business owner is
corporate communications. Content includes: staff directory, corporate communications (news),
maps & travel, and some VLE content. They also have plans to offer a mobile app for recruitment &
admissions – for use at Open Days etc.
University B (Russell Group university)
This HEI is currently migrating from WebCT to Blackboard 9, and uses Luminis as their Portal. They
have widely adapted Luminis to include, in their opinion, better communication and collaboration
tools which can be accessed separately (i.e. not through the Portal). They are using Portal and VLE
as two separate systems with minimal integration – with the focus of the Portal being a way-in to
everything but also providing access to a comprehensive suite of communication and collaboration
tools.
They recently undertook a VLE review, which resulted in the decision to upgrade to Blackboard 9.1.
The review considered Moodle, Sakai and DesireToLearn along with Blackboard. They had wide
consultation during the review and the decision to go for Blackboard was unanimous. Their longer
term plans involve migrating the Portal to the next version of Luminis (Luminis 5), or LifeRay which is
the portal technology which underlies Luminis 5. Their strategy is that students access everything via
the Portal, whilst researchers use the collaboration tools which they have integrated with the Portal
to collaborate and communicate (the collaboration tools offer access for external users – essential
for research groups).
This HEI has been using their Portal to provide single-sign-on access to other systems but their
authentication strategy is to move to Shibboleth 2 and CAS.
They have been running a CampusM mobile app for a year and they’ve had 3,500 downloads. It
doesn’t communicate with the Portal and provides access to basic web content. The university’s
mobile strategy is simply that all mobile content should exist in standard web format (in order to
ensure that users without smart-phones aren’t disadvantaged).
There are no plans to undertake further development of CampusM, although it is likely that they will
continue with current content (impressive native iPhone app). They have been concerned about
delays (from Campus M suppliers) in providing native apps on other platforms, and also concerned
about the stability of these apps.
Their new portal will be based on LifeRay – which provides a mobile ‘theme’ out of the box, using
browser client detection, although unfortunately at the moment it only detects WAP phones.
10
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
They have also considered Bb Learn mobile app but thought the functionality very limited and there
is currently no great call for this in the university.
University C (London-based Russell Group University College)
This HEI currently uses a home grown Portal and Moodle.
The aim of their Portal is self-service (originally fee payment, now covers many more things). Other
parts of the university implement self service, by developing for the Portal framework. The Portal
isn’t used for communications or displaying content which could be on a static website i.e. it is not
used as an aggregator. They have a ‘Students and Staff’ website which is essentially an intranet with
3 lists of links (headed ‘Staff’, ‘Staff and students’, ‘Students’), maintained by their Web Services
Group using a CMS, and their authentication strategy (they use CAS) handles web pages where a
user needs to login. News goes onto this site also, but isn’t targeted. RSS news feeds exist but you
have to look for them. There is no integration between the Portal and Moodle, other than a singlesign-on link. Outlook Web Access is offered but separately, not through the Portal. They use email
lists for communicating targeted information. So users have multiple places to go, multiple places to
look for things, i.e. their approach to communication is ‘pull’ rather than ‘push’.
Their VLE strategy is centred around Moodle They previously used WebCT 4 but a review, as this
version was coming to the end of its life, considered all options and shortlisted two, Moodle and
WebCT 6 (with watching brief on Sakai which they didn’t consider mature enough then). They ran
two pilots (approx 10 courses each for a year) and Moodle was selected for roll-out (WebCT6 was
missing a key feature and they were disappointed with support from Blackboard during the pilots).
They have been very happy with Moodle – their perception is that the Moodle community is very
supportive.
They have CampusM – which they believe is improving. It just offers content (push feeds – so user
can view content but not actually interact with any systems). They survey their students each year
to find out what ICT equipment they have/use, and are now asking about mobile devices. Last year
about 45% had smart-phones. They are expecting the number of smart-phones to double next year
and are expecting complaints from students about the lack of interaction in their current mobile
app.
University D (small university, in ‘University Alliance’ group)
This HEI has implemented Blackboard 8 and uses web pages as a ‘Portal’.
They are currently undertaking a VLE review. They have used PebblePad (e-portfolio tool) as a VLE,
and then moved to Blackboard 8, but use of Blackboard is not yet widespread. They use a page of
links as their ‘Portal’ – plus they have one student newsfeed and one staff newsfeed. Some local
communication is done in schools via Blackboard groups.
One opinion put forward by staff from this HEI is that VLEs are a transitory technology and will fade
away, and using a VLE encourages dependence, whereas we should be trying to create independent
learners. ‘Dynamic Learning Maps’ (that students can take away when they leave) as pioneered at
Newcastle are a possible way forward, maybe providing a VLE in first year as security blanket then
gradually take it away.
Their vision is centred around providing a next generation learning environment with no focus on
aggregating or targeting access to wider content and applications.
They have just implemented CampusM ‘mobile Portal’ which is offering access to web content and
some data. Their mobile Portal is uncovering a lot of data issues, connection problems etc (similar
data issues to those encountered at other universities with widespread adoption of Portal and/or
VLE). Mobile Portal is largely seen as recruitment and reputation tool.
11
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
University E (Russell Group university)
This HEI currently uses a combination of home-grown tools to support L&T and wider
communication/collaboration.
They develop in-house systems to support learning and teaching, and to support wider
collaboration, which, they believe, serve the academic mission of the university better than
commercial alternatives. They are not averse to the idea of buying a ‘best of breed’ system for a
particular purpose, e.g. student records or finance system – but they are not convinced by
commercial VLE, Portal or collaboration systems as being ‘best of breed’ and meeting their needs.
They have developed their own Web Content Management System for their external and internal
websites, which they have further developed over the years and which is now very widely used.
They do not integrate commercial tools with it but have developed/integrated a number of tools to
support teaching content and to support student records. Lecturers can create forms where
students can upload work and lecturers can download it to mark. But this doesn’t integrate with
their student record – lecturers have to upload marks manually. Feedback is managed individually.
They have another home-built app for creating and managing groups, which are used for emailing
and also for granting access to websites (so that only the correct people can access e.g. the teaching
materials for a course). The groups are mostly based on data from the student record system (years,
levels, modules etc) but can also be done on an ad-hoc manual basis using a list of userIDs.
Academic staff can email any groups but NOT the whole university.
They ran Blackboard for 12 months as a pilot, which was not entirely well-received. They found that
it was difficult to tailor and felt that adoption would be low if rolled out. They felt that they would
have to undertake in-house development to integrate Blackboard with other systems and their own
bespoke development – resulting in additional costs (i.e. the cost of the commercial product plus the
cost of local developments).
They have just launched a Portal for students and staff based on the OpenSocial gadget container as
in iGoogle, using Java and Apache Shindig. Users can use iGoogle gadgets and also (at least in theory)
use the university gadgets in iGoogle and other compatible OpenSocial portals. They have been able
to develop gadgets for in-house apps but had difficulties doing so for commercial systems (student
records, library system, etc). The only gadget related to VLE functionality is a link to the student’s
year’s modules in their dept.
They have a ‘distributed sign-on’ authentication based on Shibboleth, but tweaked to support web2
apps. Once you’ve signed on to one thing you are automatically signed on for all. Authentication is
multiple – users can authenticate against the central directory or a local directory (e.g. business
school) or alumni system etc.
They have a mobile version of the university homepage (html optimised for non-smart phones)
which is just web content, no mobile enhancements. Their new Portal has a mobile interface – they
have selected particular bits of the Portal functionality in order to optimise this mobile view. They
do not want to adopt a commercial app – their experience is that users rarely update apps – and
thus they quickly get out of date (so as the university develops more content, users don’t get to see
the updates). Their approach is to have a mobile (web) Portal and to add content to the Portal, but
no mobile apps for this L&T/student admin content.
Their Communications Office wants to have iPhone apps for specific PR purposes which are domainspecific and reputational e.g. writer’s archive, anatomy videos. The campus map already has GPS
location-awareness built in – it uses Microsoft mapping and added overlays for buildings.
12
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
Review Findings
Product Landscape - Portal products
The term ‘portal’ is used extensively across HE to mean many different things, ranging from a page
of links to the full portal functionality described above, which can cause confusion. Some HEIs refer
to the web interface to their Student system as a portal for example, although this only gives access
to the one system plus a few links, and some call their VLE a ‘portal’, although it focuses on learning
and teaching and doesn’t have the full portal functionality.
A few universities have developed their own in-house portal solutions from scratch, and there are
small numbers using non-HE-specific commercial products. However, the majority of full portals in
UK HE are based on uPortal, the open source HE-oriented portal software co-operatively developed
originally by a group of US universities (e.g. Rutgers, Yale, and Wisconsin-Madison) and now
available via the Jasig group and contributed to worldwide. Some universities such as Manchester
and Edinburgh use uPortal itself, and others like Leeds use the Luminis system from SunGard which
adds key HE functionality on top of uPortal. Leeds was one of the first UK universities to upgrade to
Luminis v4 in 2009, and, together with Nottingham, is viewed as something of a sector leader
amongst UK Luminis sites.
SunGard have now decided to move away from uPortal as the base system for their product, and
have chosen LifeRay instead, a fairly new product which has more of a social networking emphasis
but which doesn’t offer some of the functionality we use at present. This is a concern for two
reasons – upgrading to Luminis 5 would be more like implementing a new product, and some key
features are missingso far, e.g. our current single sign on mechanism.
The latest versions of portal products (including Luminis, LifeRay, uPortal) now almost all use
portlets to provide much of their functionality. There are international standards for portlets so it
should be possible for any portlet to work on any portal framework. The current version of Luminis
accepts both ‘channels’ (which were used in previous versions) and portlets, and most of the Leeds
functionality is still currently provided via channels. Channels are not supported in any other portal
products. It would therefore seem prudent to plan to redevelop the Leeds channels as portlets, in
advance of whatever decision is taken about which Portal system Leeds wishes to use in future. This
will be a major piece of work, and should be scheduled for 2011/12.
OpenSocial is a set of common application programming interfaces (APIs) for web-based social
network applications, developed by Google along with MySpace and a number of other social
networks. Applications implementing the OpenSocial APIs are interoperable with any social network
system that supports them. The OpenSocial framework is being considered by some universities
(and being implemented by University E (above)) as a next-generation portal platform which allows
the university to develop applications which can be ‘plugged in’ to Google by users, and allows users
to ‘plug in’ Google applications to the university portal. However it doesn’t (yet) have extensive
targeting ability, as currently used extensively at Leeds.
Product Landscape - VLE products
There are a number of products within the VLE landscape at present; these fall into three categories
commercial, open source & in-house. Within the commercial market there are three market
leaders, these being Blackboard, Desire2Learn and the recent Blackboard acquisition Angel. Three
years ago, Blackboard also bought another leading competitor, Web CT, in doing so they took the
market share of the UK HEI market (this included most of the Russell Group Universities).
Between 2006-2009 Desire2Learn and Blackboard launched a number of lawsuits, with the main
lawsuit being launched by Blackboard over their patent related to VLE technology in general.
Desire2learn won the key lawsuit relating to the VLE patent, though both companies ended up cross13
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
licensing each other’s patents (terms are unknown for this agreement). The main question left from
the Desire2Learn v Blackboard lawsuit is what role patents will play in software and higher education
(a question for both vendors and universities).
Those UK HEIs that were Web CT customers have all faced a decision as Blackboard have slowly
removed support and development for Web CT. These HEIs have had to choose to move to
Blackboard or another product. This sparked a number of VLE reviews across the sector and
produced some interesting results. In the London area a number of high profile Web CT customers
moved to Moodle3, examples are London School Economics, City University and University College
London.
The open source landscape has several products ranging from school to FE and HE, with Moodle
being the leading open source offering in the UK HE. The other product of note in this area is Sakai4.
Sakai offers two products; the first is a centred around collaboration and learning, the second being
closer to a framework to embed tools (including L&T) into a more social structure. Product support
for Moodle and Sakai (both commercial and community) seems to be growing; this is linked to the
increased use across the sector. Both Oxford and Cambridge Universities use Sakai.
There are a few institutions still running in-house locally developed products that are not available
to reuse, not a great deal is know about these as they tend to remain isolated, since institutions
concentrate on delivering needs locally.
Finally, there is an interesting concept developing around cloud solutions such as Google apps for
education, some institutions have integrated cloud products into their VLE (i.e. Bboogle project for
Blackboard). This fits with the JISC Cetis distributed learning environment paper5. There are a few
examples of this moving a step further with a cloud based learning environment, though this isn’t
widely used at present6.
Feedback from users
Student opinions about how the Portal and VLE work together, and about the importance of
different aspects of Portal and VLE functionality, were canvassed in a focus group.
The students canvassed can be broken down as follows:
 69% UG, 31% TPG, all studying fulltime
 Schools: 2 ICS, 2 Modern Languages, 2 LUBS, 1 SPEME, 3 Joint Honours, 1 Medicine, 1
Healthcare, 1 Theology & Religious Studies, 1 Computing, 1 English, 1 Earth & Environment
 63% UK, 13% EU, 25% international
Students indicated the frequency with which they used each system:
 Portal login frequency: 50% several times a day, 44% daily, 6% weekly, 0% occasionally.
 VLE login frequency: 19% several times a day, 63% daily, 19% weekly, 0% occasionally.
After discussion about the type of functionality that the Portal and VLE offer, students were asked to
rate the importance of specific functionality:
 Portal single sign on: 75% very impt, 19% quite impt, 6% slightly impt, 0% not impt
3
http://moodle.org/
http://sakaiproject.org/
5 http://wiki.cetis.ac.uk/images/6/6c/Distributed_Learning.pdf
6 One example http://www.smartassess.com/
4
14
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
 Portal aggregation links/info/resources: 75% very impt, 25% quite impt, 0% slightly impt, 0%
not impt
 VLE aggregation links/info/resources: 69% very impt, 19% quite impt, 13% slightly impt, 0%
not impt
 Portal targeting: 69% very impt, 19% quite impt, 13% slightly impt, 0% not impt
In addition students were asked to give any other comments arising from the focus group
discussions. Key points arising from these comments are:
 Generally students appreciate and use the VLE single sign link from the Portal, and
appreciate seeing VLE announcements in the Portal.
 The most requested new feature was direct link to assignment submission areas at the times
assignments are due.
 No suggestions for VLE to become tab in Portal (though Portal feedback exercise had
students suggesting this in 2010).
 In the Portal Feedback exercise 2010, some students complained about VLE announcements
in the Portal being slow to load or not working, indicating that they use them (or want to)
A small survey of academic staff (conducted at the Learning and Teaching conference 2011) showed
that there is a large variation amongst staff about their understanding and use of the Portal and the
VLE. This tallies with informal feedback received by the VLE and Portal teams. Most staff used the
VLE but some were clearly unsure about or confused about how the Portal and VLE integrate, since
they did not use the Portal themselves. So, for example, an academic writing an announcement
within a module area in the VLE might entitle it ‘Important information’, but when a student sees
that announcement in the Portal aggregated with all their module announcements the title would
not help them understand its purpose. However, a significant percentage of staff ( around 2,500
different staff in any month, about a third of the total staff numbers) already use the Portal, some
using the module-specific links to the VLE. Some staff have raised concerns that students may be
confused by there being two systems. However, our research indicates that this is not common, and
perhaps any confusion exists more amongst staff. It would seem sensible to have both staff and
students using both systems in the same kind of way, which reinforces the longstanding proposal for
a Staff Portal to be essentially a differently customised view of the same Portal system.
Summary of lessons learned
(Based on findings from users, other HEIs, and literature search)
15

The Portal and VLE product landscape is still evolving largely due to the fact that the web
landscape is fast-moving. There are no indications however that the products will merge
such that VLE vendors will include true Portal like functionality in their product suite.

Open-source and home-grown solutions are being used where an HEI wants to create a truly
seamless environment – but it is likely to be some time before there is a mature opensource web interface offering both VLE and Portal functionality.

With the exception of one HEI, each university visited has adopted both VLE and Portal
technology – since the current range of products available do not offer all the functionality
that can be provided by two separate systems. They largely use a VLE as a Learning
Management System and they use a Portal to aggregate access to (and, in some cases,
target) content.

Many large universities have a clear strategy to offer Portal and VLE systems separately – it
helps to define the activities that users do in each system (converging the 2 could cause
greater confusion).
VLE/Portal Review
Draft Report, Feb 2011
16
VPBL/10/01

Most major universities have both a Portal and a VLE, but there is minimal integration –
generally a single sign on but not much more. Leeds provides the best integration we saw –
it offers deep links to VLE modules, and displays VLE announcements in the Portal. Some
universities aspire to improve integration – in a similar way to the Leeds’ set-up – and some
aspire to further improvements such as notifications of new content in VLE being highlighted
in Portal

The Leeds Portal places great emphasis on providing aggregation of content (a one-stopshop) and targeting of content/communications – providing an excellent student experience.
Other HEIs have not placed such an emphasis on this (though some aspire to), leading to a
poorer student experience and/or confusion/fragmentation.

Leeds’ approach is distinctive, the targeting and communications functionality minimises
time spent on mundane tasks – allowing students to focus on their learning and research
activities.

If communications are prioritised then it is important to aggregate communications –
students want to know that they have received all important information. A Facebook-like
summary is attractive to students, e.g.”You have 5 new emails, 3 discussion posts in VLE, 23
blog posts, 1 new assignment”.

Students value aggregating and targeting functionality.

The current Portal platform is changing with the next release of software, and there are
currently limited plans to include a single-sign-on mechanism with the next release.
Students do value this functionality in the current Portal. Many universities have an
authentication strategy based on CAS/Shibboleth (some are considering Microsoft options),
which improves usability across all systems and enables single-sign-on to be continued
whatever Portal approach is taken.

Two universities have reported problems with the Blackboard mobile product Bb Learn
(serious security issues) and haven’t deployed yet for this reason, they are actively working
with Blackboard to resolve these issues (i.e. this should not be considered to be a long-term
issue). Luminis 5 has a mobile skin, and some universities are creating their own mobile
versions of Luminis 4.

Users would like to access some content and applications from a mobile device. Currently,
viewing the Portal and VLE on smart-phones via a web browser works, but users find them
difficult to use (because of the need to zoom and scroll all the time).

Many universities have not take a strategic approach to mobile content and services – some
have adopted a mobile platform quickly, under pressure to offer a mobile app, but these
interfaces are largely to web content only, and mobile versions of ‘systems’ have not been
integrated with the app. Currently, it is more costly to offer mobile apps to content and
systems because of difficulties and capital costs in creating mobile versions of systems but
also because of need to create different apps for different mobile devices.

Some universities have a mobile strategy which defines mobile web as a baseline (i.e.
accessible to all), but have not yet defined a strategic approach to mobile apps. (Too many
questions - if ‘apps’, which clients should be supported and how will the range of apps be
brought together so there aren’t lots of different bits to download? Easier if a standard
client is defined, e.g. by giving all incoming students an iPad).
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
Options and scenarios for future Portal and VLE functionality
Options for both Portal and VLE software are given below, whilst Table 3 is used to summarise some
scenarios which may be used to model a roadmap for the Portal and the VLE.
Portal options

Remove the Portal entirely. Have a web page of links for students, and links in the VLE. This
is the cheapest option but would likely damage student experience, and be detrimental to
university communications. Possible to replicate some Portal functionality in the VLE to
mitigate against damage to student experience, but this would require large-scale
development work and ongoing maintenance which would severely impact on cost savings.

Continue with Luminis 4 for the time being and plan for a major change in 2012/3 which has
three options:
o
upgrade to Luminis 5,
o
change to different Portal framework, to be decided – possibilities include LifeRay,
uPortal, OpenSocial, or a non-HE commercial product,
o
change to a next-generation web framework (designed to be able to offer
collaboration and VLE web environment), e.g. Sakai OAE (Open Academic
Environment), or similar.
Note that whichever option is chosen, authentication needs to be addressed to continue
providing single sign on. The present mechanism in Luminis 4 may not be supported in
Luminis 5.
VLE options
17

Continue to use Blackboard. Ongoing licensing costs.

Adopt Moodle, or similar, open source VLE solution. Open source is becoming increasingly
widespread in HE. Possible small savings in the longer term – no licensing costs offset by
increased staffing (development) costs.

Investigate use of Sakai as replacement VLE. Possible small savings in the longer term – no
licensing costs offset by increased staffing (development) costs.
VPBL/10/01
VLE/Portal Review
Draft Report, Feb 2011
Table 3 Summary of future scenarios and implications for Leeds
Scenario
Portal
VLE
Notes
1
2 system and 2 web
interfaces (as now)
Use Portal as primary
interface – as a way-in
to all other systems
Use Luminis 4.x until next hardware replacement cycle
(2 years)
Then migrate to Luminis 5, or alternative Portal solution
such as uPortal or LifeRay.
Use Blackboard 9.x (optional, we
could change VLE and still
progress this option)
Could consider enhancement of
existing integration (improved user
experience) although this is not
essential.
2
2 systems and 1 web
interface
Use VLE as only web
interface with Portal
underneath
Use Luminis 4.x until next hardware replacement cycle
(2 years)
Then implement Portal technology which will support
targeted communications and content – and allow such
to be surfaced in Blackboard (uPortal or LifeRay)
Use Blackboard 9.x (optional, we
could change VLE and still
progress this option)
Large-scale development to
implement this scenario
Different user experience – focus on
L&T (dilutes communications?)
3
1 system
Use VLE as only web
interface
Stop using Luminis – no Portal provided.
Use Blackboard 9.x (optional, we
could change VLE and still
progress this option)
Lose targeted communications
(detrimental to user experience)
Small-scale development to create
access to resources in the VLE - links
to systems and content, or large-scale
development to surface data/content
from other systems in the VLE
4
1 (or 2) systems and 1
web interface
Adopt framework which
allow both Portal and
VLE functionality to be
surfaced in 1 web
interface
Use Luminis 4.x until next hardware replacement cycle
(2 years)
Replace Portal with web framework which will support
targeted communications and content, and plug-in VLE
tools ( Such a framework doesn’t yet exist but may be
developed e.g. out of Sakai OAE or a combination of
products)
Use Blackboard 9.x, only renew
Blackboard contract on annual
basis at end of current 5 year
contract (18 months)
Investigate use of web framework
as a next-generation VLE/Portal
Large-scale development to
implement this scenario
Ultimately - 1 user interface, 1 set of
integration costs, next-generation
Portal/VLE
18
VLE/Portal Review
Draft Report, Feb 2011
VPBL/10/01
Next stage
A further stage of review consultation is needed. In particular, findings will be discussed with staff in
the Library and ISS.
The next stage of the VLE/Portal review should involve circulation of findings and draft
recommendations, and meetings with the following staff/groups: wider Portal team, wider VLE
team, VLE Board and steering group, SPSG, BLFG, Library/ISS senior management teams. The
following issues and recommendations are given in order to facilitate and focus discussion – the
intention being to firm up recommendations after the consultation round.
Issues
Resourcing – any upgrade or change in hardware/software incurs both capital and staffing costs.
Hardware capital costs are currently part of Library and ISS projections – but other costs are not
projected (previous assumption being that software would remain the same and only hardware is an
essential cost). It may be possible to upgrade or change software using existing staffing but this will
lengthen the implementation project and may also impact on current provision. In addition, any
change to software may change the recurrent costs for an application, e.g. implementing Blackboard
Learn Mobile or a mobile portal. Both the Portal and VLE teams are already working at capacity, so
new developments would require additional resourcing.
Data – data issues were not investigated as part of the review – but they continue to have a large
impact on the ability of the two services to provide ongoing support and development of the two
applications. Whilst it is clear that data issues are surfaced in the Portal and the VLE applications,
the teams themselves cannot actually resolve the problems. E.g. since users report a problem as ‘I
cannot see my modules in the VLE’, the VLE team ends up acting as first line support, channelling the
call to various sections in ISS and/or faculties – and, very often, explaining how to resolve the
problem. Both teams have become experts in data issues out of necessity – there are no other
central units that own the issues which arise. Although these issues are the same regardless of the
Portal or VLE options which are implemented in the future,
Draft/possible recommendations
19

Continue to prioritise aggregation and targeting of content and communications, i.e.
continue to offer Portal functionality.

Portal – stay with Luminis 4 until next hardware replacement cycle. Prepare for a major
upgrade/transfer project in 2012/13 by transferring functionality to portlets as much as
possible in the meantime (major work proposal for 2011/12). Further investigation in
2011/12 to inform about maturity of options at that stage (Luminis 5, other commercial
product, Sakai/uPortal or other open source).

VLE – move to 1 year contract renewal on Blackboard (at end of current 5 year contract).
From 12-13, undertake small projects to investigate Sakai and various tools (this is linked to
Portal framework decision). This allows us to investigate use of a different approach to
offering VLE functionality whilst still leaving the option to retain Blackboard.

A mobile interface should be an essential requirement for any system selected to deliver the
Portal going forward. The Portal should become the focus for accessing mobile content and
services.
VLE/Portal Review
Draft Report, Feb 2011
20
VPBL/10/01

Select and implement a University wide authentication approach in order to improve
usability across all systems and to enable single-sign-on to be continued whichever choices
of Portal and VLE systems were made in future

Each of the scenarios described would benefit from closer working of the Portal and VLE
teams – the two teams should therefore be co-located (in order to improve the ability of the
two teams to deal with similar support issues and thus lead to more time spent on
improvement and development of the 2 systems).

A further recommendation about data issues may be appropriate – although not related to
VLE/Portal functionality, data issues do affect the 2 teams and their ability to enhance the
two services. Consider ownership of data issues lying with central IT Helpdesk?