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