Taking a fresh look at portals

One of my current projects is to pull together a student portal for Loughborough.  For a variety of reasons we missed the boat and failed to develop such a system back in the Noughties, but I think this is something we can turn to our advantage by learning from other people's experiences.

My view is that our portal (see left for portal concept poster from Ben Spencer in our Web design team) will be mostly about giving people a handy preview of information that's relevant to them, and linking through to systems and services that we already run - rather than imposing a whole new IT system on everyone.  One convenient side-effect of this not being a direct replacement for an existing system is that we will be able to introduce it as and when it's ready, thereby avoiding the traditional mad rush to get everything ready for the start of the academic year.

The initial system will be very tightly scoped, and is mostly about us identifying a sensible underlying architecture that we can continue to build on.  On launch day we are aiming for something along like this:



  • Information providers able to update their content via our Terminal Four Site Manager CMS, with the portal pulling in material from specified CMS nodes as they are updated 
  • Widget framework allowing for:
    • Admin defined default widgets (of which some may be "sticky" and cannot be moved or removed)
    • User selected widgets from a catalogue
    • Users able to move, remove and ideally resize widgets
  • Alerts and notifications framework:
    • Information providers and IT systems can send targeted alerts to specific users or groups of users, e.g library book is due back, careers fair for finalists
    • Alerts are aggregated and presented together in the manner of an RSS aggregator (this may well be the underlying technology)
    • Some alerts may be so important (e.g. emergency messages from the University) that they are displayed in a modal pop-up
  • Embedded email widget, linking to Google Mail
  • Embedded calendar widget, linking to Google Calendar
  • Enterprise search via our Google Search Appliance
  • News feed widgets with University and Students Union news and events
  • Modules widget showing active module selections and linking through to Learn, our Moodle based VLE
  • Library widget, current loans and reservations, making use of the X Server API from Ex Libris and linking through to our Aleph library catalogue
  • Student finances widget, including printer credits and account balance, and linking through to online payments service for (e.g.) topping up printer credits
Over time I expect that the portal will come to encompass widgets for many other areas particularly around student self service - at present we don't have a system to link people through to carry out many common tasks such as a change of address.  This probably won't make it into the initial launch later this year, though.

There are a number of widely used pieces of software that could form the underpinnings of our portal, such as uPortal, Liferay and Sakai.  However, I'm conscious that some in the developer community feel that the JSR-168 and JSR-286 "portlet" standards on which these packages are based are no longer the way to go.  Consequently I'll be spending some time looking at alternatives.

At the recent TransferSummit conference I had some interesting discussions around this area with Sakai architect Charles Severance, the W3C working group chair Steven Pemberton, and Scott Wilson from JISC CETIS.  The Apache Wookie project (instigated by Scott) is particularly interesting in this context.  Wookie provides a mechanism for hosting W3C Widgets, with integration into existing platforms including Sakai, Moodle and Elgg.  W3C Widgets are simply Zip files containing HTML, CSS, images etc, and driven by JavaScript.  Wookie's integration with platforms like Sakai means that we could potentially hedge our bets and be in a position to take advantage of full-blown JSR-168 portlets where these are available, whilst taking a more pragmatic approach for our own development work.

However, it should be noted that there are caveats around authentication in particular with W3C Widgets - at present there is no general agreement as to how to pass on login credentials to widgets from the parent platform.  There is some interest in OAuth or IMS Basic LTI (itself built on OAuth) as the solution to this problem.  The W3C specification also has some serious competition from OpenSocial, which includes a "gadget" mechanism derived from Google Gadgets.  More to come on this topic as we start to build our prototype portal...

2 comments:

  1. At the University of York we also missed the boat and are finally looking seriously at a portal. My preference is for Google Gadgets that can be embedded in lots of places, including but not limited to a portal. This shifts the emphasis from the portal dashboard itself - which may or may not be used or configured much by users - to creating the gadgets with the key content. Then (in theory) these can be added to existing well established portals around your institution, like your VLE or your library portal and so on.

    I'm on shaky ground as this is all theory and I know very little about good containers of Google Gadgets to use an a portal in practice. One recent entrant that may be worth a look is eurekastreams. (http://www.eurekastreams.org/) The WS02 Gadget server is a commercial alternative (http://wso2.com/products/gadget-server/). I think there are others.

    I like Wookie, but I think there's far more activity behind OpenSocial and gadgets IMO.

    ReplyDelete
  2. Cool - thanks for the pointer to Eureka Streams. Reminiscent in many ways of Elgg, which in its own way is probably another contender. Like the dashboard in Eureka Streams a lot :-)

    In a purely Google universe, something else worth taking note of is the Google Secure Data connector - http://code.google.com/securedataconnector/

    ReplyDelete