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