VLE/Portal Review - University of Leeds

convertingtownSoftware and s/w Development

Nov 4, 2013 (3 years and 7 months ago)

251 views

VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

1


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 Land
scape
-

Portal products

................................
................................
................................
..........

13

Product Landscape
-

VLE products

................................
................................
................................
..............

13

Feedback from users

................................
................................
................................
................................
...

14

Summary of lessons learned

................................
................................
................................
.......................

15

Op
tions 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




VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

2


Background/
co
ntext

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 an
d 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
wh
y the
University has

and/or
needs both of these two virtual environments
, and joint working on an initial
evaluation of Portal/VLE approaches allow
s

us to highlight common and distinct requirements for
the two systems.

The review is not intended to rev
isit 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 re
sponsibility for the

two services.
T
he

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 als
o 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 mechanism
s

used for such a
ccess

need to be regularly evaluated, and
consideration given
to
the

potential for delivering the VLE and Portal services differently
. D
efining a
medium
-
term roadmap for the applications will enable the Library to understand how best to
optimise the curre
nt teams.



VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

3


Review methodology

As previously agreed by VLES and SPSG, the VLE/Portal review included the following activities:



D
efine and describe

the present situation
:
-

including areas of similarity

for

the two systems
,
areas of uniqueness, and
how the

two systems work together
.



S
cope and describe

different models for off
ering 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, Educaus
e, ALT
-
C
), attendance at relevant
events and discussion within appropriate HE networks
.

In addition, the review included



C
onsideration of
the development roadmap of the present Porta
l and VLE software



F
ocus 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 su
pport 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 obje
cts, 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 definition
2
:

“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, colla
borative 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
s
uite of collaborative tools
.
A

more in
-
depth look at what these two systems offer at Leeds is useful
to highlight similarities and differences.







1

http://www.jisc.ac.uk/whatwedo/programmes/portals/faq.aspx


2

http://www
.jisc.ac.uk/whatwedo/programmes/portals/faq.aspx


VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

4


Current status

Portal software is currently Luminis 4. This product is supplied by SunGard


who also suppl
y
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 int
egration 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 defi
ne 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
system
s

in order to exploit particular features of each.

Table 1

below
gives a summary of current usag
e and functionality

of the Portal and VLE systems at
Leeds
.


Figure
s

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:



The key differences reflect the purpose of the two systems:

o

The Portal can target
communicati
ons

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 boar
ds, 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, w
hereas providing single sign on

in the VLE requires custom
d
evelopment 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).

VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

5


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 ‘g
roupings’ 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 als
o 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 boa
rds, test, questionnaires,
electronic submission areas and more.

T
hese t
ools 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 aggrega
ted 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 b
e
targeted to different groups.

VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

6


Functionality

VLE

Portal

Similarities

Differences

appear in a group area.

Single sign
-
on (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
晵n捴
楯n慬a瑹Ⱐ慬瑨ougU⁳潭攠T敶敬epm敮琠
睯牫⁩猠r敱e楲敤⁴o⁣r敡ee 敡捨e
.

䍯nn散eo牳r瑯慮y⁕湩v敲獩瑹⁳y獴敭猠桡V攠
b敥n⁣牥r瑥T

慮T⁡ 攠m慩a瑡楮敤⁡猠ey獴敭猠
捨cng攮

Mev敬opm敮琠eo牫
牥煵楲敤⁴o⁣牥慴a
捯nn散eo牳⁩渠敩瑨敲e獹獴Vm
⡤(ub汥⁴U攠co獴V⁴UougU


b
整瑥r⁴慣瑩挠wou汤⁢攠瑯
業p汥m敮琠慵瑨敮瑩捡瑩Wn
m散桡e楳m⁳ 捨⁡猠
un楶i牳楴y
-
睩摥⁵獡w攠o映
卨楢bo汥瑨r⁃䅓⤮

Larger development and
maintenance overhead in
the VLE.

Aggregation

Offers access to L&T resources

related to
each user
.


Acts as a one
-
stop
-
shop


椮攮⁢物ng猠Vog整U敲e
慣捥獳⁴o⁡汬⁲ 獯u牣敳e⁳ rv楣敳I
慰p汩捡瑩cn猠VUa琠瑨W⁰慲瑩 u污l⁵獥爠湥 TV
慣捥獳⁴o.†
M楦i敲敮e⁡杧牥r慴楯n猠V慮⁢攠
p牯v楤敤⁦o爠摩晦敲敮琠牯l敳ⰠHUu猠慶o楤楮g
u獥牳V獥敩eg⁩牲敬 v慮W⁣on瑥n琮

䍵牲敮瑬W⁢
敩eg⁵獥搠
T楦i敲敮瑬e⁢ 琠bo瑨⁣慮⁡WW
慳⁡渠慧g牥条Wo爬⁩
.
e
.

捡c
b物rg⁴og整Ue爠汩r歳k瑯
v慲aouV⁣on瑥n琠慮T
慰p汩捡瑩cn献V

周攠Po牴慬⁨慳⁡amo牥
牥晩r敤⁣ommun楣慴ion
晥慴畲攠f整H⁷U敲敡猠瑨攠VL䔠
楳⁳ime睨慴wm楴敤
e⹧⸠
捡cno琠瑡牧整
慮noun捥浥c瑳W.

P
敲eon慬a獡瑩


䍵牲敮瑬W 瑴汥⁰敲獯n慬a
V
慴楯n⸠

卨o睳wuV敲猠瑨攠moTu汥l⁡nT
o牧慮楳慴ion猠
牥污瑩Wg⁴o⁴U敭
H⁡湤
慮noun捥浥c瑳W晲om⁴U敳攠慲敡献

Users have a ‘My tab; which allows a small
慭oun琠of⁰敲 on慬a獡瑩on.

周攠Po牴慬⁰敲eon慬a獥V⁴Ue⁣onW敮琠楴
獨V睳w
慣捯牤楮g⁴o⁵ 敲ero汥
攮e⸠瑡畧U琠慮T
牥獥慲捨 獴畤敮瑳e獥V⁤楦晥牥湴⁣桡rn敬猩e

啳敲猠捡c⁡摤⁴U敩爠o睮w睳晥敤e⁡湤
bookm慲歳Ⱐ慮T 捡c⁡汳o⁲ 慲a慮g攠瑨敩爠
o睮wyou琠Wo⁳om攠數W敮e.

卯m攠
p敲eon慬a獡瑩on
椮攮e
the user’s ability to tailor
睨慴⁩
猠v楥睥T⤠慶慩a慢汥⁩渠
bo瑨⁳y獴Vm献

L業楴敤⁣畳eom楳慴ion
椮攮
瑨攠慢楬楴i⁦ r⁴U攠捯nW敮琠
p牯v楤敲⁴o⁴慩ao爠睨慴⁩猠
v楥i敤⤠楮⁴e攠噌䔬N睨敲敡猠
瑨攠Wo牴慬⁩猠摥獩an敤⁴o
o晦敲⁡汬⁣on瑥nW⁡捣o牤楮g 瑯
a user’s role.

VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

7


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.



VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

8







Active Directory

Current authentication
mechanism for the
majority of the university
systems including the
VLE and Portal.


Banner &
LURCIS
exchange
data

SAP supplies
HR data to
LURCID

Banner
1

Authoritative data
source for module
and enrolment
information.

SAP

Authoritative data
source for HR/Staff
information

LURCIS
2

Identity Management
system, tied data from
Banner and SAP
together.
Authoritative source
for Authentication
system.

Data Feed

It has a number of purposes:

1)

Brings data together from
1,2

2)

Filters data

3)

Output XML data files

VLE


Portal


SAP supplies HR
data to Banner

Data feed draws
relevant data from
Banner & LURCIS

XML data files loaded
into systems

LURCIS provides data
to Active Directory

Authoritative Data Sources

Figure
2

Leeds Port
al/VLE integration diagram


architecture/data perspective


VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

9


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.


T
he f
unctionality within
a

VLE
is,

in som
e 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
(Mana
ged Leaning Environment)
concept was
explored, combining VLE and other functionality
.
S
ubsequently
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,
t
he 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

distrib
uted 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 fu
ture
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

u
P
ortal

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 w
eb
pages

Don’t need
/want

to tar
get content or communications

VLE not widely adopted


under review

E

In
-
house
development
(based on in
-
house CMS)

In
-
house
development

Need functionality from a number of different tools


best
to have a framew
ork 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
uP
ortal (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
VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

10


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 s
tudents and the ‘
University A
Working Environment’ (using SharePoint) for staff.

The
ir

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 environmen
t.
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 rel
iability 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.

The
y

ha
ve

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 th
is when they move to Bb Mobile Central)
, although this took
several months longer than intended
.
Their mobile approach is l
argely technology driven

but
the
platform was agreed between Head of IT Service

and
PVC for L&T
, and the b
usiness owner is
corporate

communications. Content includes:

staff directory, corporate communications (news),
maps & travel, and
some
VLE content
.

They also have plans to offer a mo
bile 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. no
t through the Portal)
.

They are using
Portal and VLE
as two separate systems with
minimal

integration



with the focus of the
P
ortal
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. The
y

had wide
consultation during the review and the decision to go for Blackboard was unanimous. Their longer
term plans involve migrating the
P
ortal
to the next version of Luminis

(
Luminis 5
),

or Life
R
ay which is
the portal technology which underlies
Lumini
s 5.

Their s
trategy is that students access everything via
the
P
ortal
, whilst r
esearchers use
the collaboration tools which they have integrated with the
P
ortal
to collaborate and communicate (the collaboration tools offer a
ccess for external users


essen
tial
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 ar
en’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 Life
R
ay


which provides a mobile ‘theme’ out of the box, using
browser client detection, althou
gh unfortunately at the moment it only detects WAP phones.

VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

11


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
Porta
l

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 ‘S
taff’, ‘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 feed
s exist but you
have to look for them. There is no integration between the
Portal

and Moodle, other than a single
-
sign
-
on link. Outlook Web Access is offered but separately, not through the
Portal
. They use email
lists for communicating targeted informa
tion. 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 c
oming to the end of its life, considered all options and short
listed 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 t
he Moodle community is very
supportive.


They have CampusM


which th
ey 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 ‘Universit
y Alliance’ group
)

This HEI
has implemented Blackboard 8 and use
s

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 p
ut forward by staff from this HEI is
that VLEs are a transitory

technology and will fade
away, and u
sing a VLE encourages dependence, whereas we should be trying to create independent
learners. ‘Dynamic Learning Maps’ (that students c
an take away when th
ey leave)
as pioneered at
Newcastle are
a possible

way forward
, m
aybe provid
ing 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
aggregat
ing 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 m
obile
Portal

is uncovering a lot of data issues, connection problems etc (
similar

d
ata 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.

VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

12


University
E
(
Russell Group university
)

This HEI currently uses a combination of hom
e
-
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 bette
r 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


b
ut they are not convinced by
commercial
VLE
,
Portal

or
c
ollaboration

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 rec
ord


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)
.

The
y have just launched

a Portal

for students and staff based on the OpenSocial gadget container as
in iGoogle, using Java and Apache Shindig.
U
sers 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 ha
ve 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


the
y
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 O
ffice wants to have iPhone

apps for specific PR purposes which are domain
-
specific 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.




VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

13


Review Findings

P
roduct 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 interfa
ce 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 so
ftware 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 lea
der
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 pr
oducts (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 o
f 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
a
pplication 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
syste
m 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 G
oogle 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. Thre
e
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 cross
-
VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

14


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 a
ll 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 Moodle
3
, 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 Moo
dle
being the leading open source offering in the UK HE. The other product of note in this area is Sakai
4
.
Sakai offers two products; the first is a centred around collaboration and learning, the second being
closer to a framework to embed tools (includi
ng 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 ins
titutions 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 paper
5
. There are a few
examples of this moving a step further with a cloud based learning environment, though this isn’t
widely used at present
6
.


Feedback from users

Student opinions about how the Portal and VLE work togethe
r,
and ab
out 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% severa
l 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 imp
ortance of specific functionality:



Portal single sign on: 75% very impt, 19% quite impt, 6% slightly impt, 0% not impt




3

http://moodle.org/

4

http://sakaiproject.org/

5

http://wiki
.cetis.ac.uk/images/6/6c/Distributed_Learning.pdf


6

One example

http://www.smartassess.com/

VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

15




Portal aggregation links/info/resources: 75% very impt, 25% quite impt, 0% slightly impt, 0%
not impt



VLE aggregation links/info/resour
ces: 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 p
oints 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 t
he 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 an
d 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 aggregate
d with all their module announcements the title woul
d
not help them understand its purpose. Howev
er, 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 l
essons learned


(
Based

on findings from
users,
other HEIs,
and
literature search)



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 th
e 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 open
-
source 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 a
ll the functionality
that can be provided by two separate systems.

They
largely
use a VLE as a Learning
Managem
e
nt System and the
y use a
Portal

to aggregate access to (and, in some cases
,

target)

content.



Many large universities have a clear strategy to o
ffer
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


VPBL
/10/01

Draft Report, Feb 2011

16




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


an
d 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
-
stop
-
shop) and targeting of content/communications


providing a
n excellent student experience.
Other HEIs have not placed such an emphasis on this (though some aspire to)
, leading to a
poor
er

student experience and/or confusion/fragmentation.



Leeds’ approach
is distinctive, the targeting and communications function
ality
minimis
e
s

time spent on mundane tasks


allowing students to focus on their learning and research
activities.



If communicat
ions are prioritised then it is important to
aggregat
e

communications


students want to know that they have received all imp
ortant 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 changin
g 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

uni
versities have a
n
authentication
strategy based on

CAS/Shibboleth

(some are considering Microsoft options)
,
whi
ch improves usability across all systems

and enable
s

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)
.

L
uminis 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,
v
i
ewing the Portal and VLE on s
mart
-
phones via
a
web browser works,
but users find them
difficult to use (
beca
use 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 m
obile versions of systems but
also because of need to create different ap
ps 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 appro
ach 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 incom
ing students an iPad).


VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

17


Options and s
cenarios for future Portal and VLE functional
i
ty

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 p
lan 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
providi
ng single sign on. The present mechanism in Luminis 4 may not be supported in
Luminis 5
.


VLE options



Continue to use
Blackboard
.


Ongoing

licensing

costs.



Adopt Moodle, or similar, open source VLE solution. Open source is becoming increasingly
widesprea
d 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 sta
ffing
(development) costs.


VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

18


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 m
igrate 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

U
se 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 develop
ment 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
, o
r
l
arge
-
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
targete
d 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
co
ntract (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

VLE/Portal Review


VPBL
/10/01

Draft Report, Feb 2011

19


Next stage

A

fu
rther stage of review consultation is
needed
. In particular, findings
will

be discussed with staff in
the L
ibrary and ISS.

The next stage of the VLE/Portal review should involve circulation of find
ing
s and draft
recommendations, and meetings with the fo
llowing staff/groups:

wider
Portal team
, wider
VLE
team
,
VLE Board and steering group
,
SPSG
,
BLF
G, Library/ISS senior management teams
.

The
following
issues and
recommendations are given in order to facilitate and focus discussion


the
intention being t
o 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 i
mpact 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
application
s. 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 th
e issues which arise. Although these issues are the same regardless of the
Portal or VLE options which are implemented in the future,


Draft/possible r
ecommendations



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
B
lackboard

(at end of curr
ent 5 year contract)
.
From 1
2
-
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


VPBL
/10/01

Draft Report, Feb 2011

20




Select and implement a

Univer
sity 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 workin
g of the Portal and VLE
teams


the two t
eams 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?