I’ve blogged in the past about our project to create a student portal at Loughborough this Autumn. This post is intended to provide a quick update and also to explore some of the architectural issues that have arisen.

In a previous post I introduced the concept that a portal did not necessarily equate to “a portal system”, i.e. a dedicated piece of software. This is a theme that I want to pick up on here. If we had been putting a portal in a few years ago, then we would almost certainly have surveyed the market and looked at packages like uPortal, Sakai and Liferay. Why not simply put one of these systems in now?

Here's why...


The world has changed sufficiently through the evolution of HTML, CSS and Javascript that I contend these now provide most of the underpinnings that we need to construct an engaging portal site. Whilst a full blown portal system would in theory offer us benefits through standardization and re-usability, the reality is that Java JSR-168 portlets are not readily available from our suppliers (I checked!), and we have a number of bespoke systems or databases that would require custom development in any case.  It's also the case that our skills are more in PHP and Perl than Java. So my overall conclusion was that a “traditional” portal system would be a huge distraction and probably slow the whole project down considerably.

I’d also have to echo some of the comments from IWMW10 delegates about the perceived “clunkiness” of these systems (see Owen Stephens' summary) to people who are used to fluid Web 2.0 interfaces that make heavy use of jQuery based effects. Of course we could retrofit this stuff, but my feeling is that this would be misdirected effort which would be better spent on opening up more systems to the portal, providing open data feeds etc.

That said, there is a question in my mind around the degree to which people expect to be able to customize a portal site. Our students presently have iGoogle as their landing page, and I expect to effectively supplant this with the portal site. Will students expect to be able to theme the portal site to the Nth degree, embed their own choice of widgets, and so on? I don’t plan to take iGoogle away, but equally I don’t (yet) intend for us to offer our widgets as iGoogle gadgets and offer a huge choice of themes - think online banking rather than Yahoo or iGoogle.  Student focus group feedback will be invaluable on this one.

After an intensive development period, we now have a portal prototype that can be demonstrated to people. It clearly needs a bit more spit and polish, but we now have most of the phase 1 features implemented. After the remaining snags are sorted out I will be sharing the URL with a few people for feedback. It will be very interesting to see if there is a viral spread in usage. This approach proved invaluable in our wireless network rollout and the move to Google Apps, and provided much in the way of useful feedback that enabled the services to be tuned prior to formal launch.

So, without further ado - here's how it's looking at the moment!

Loughborough student portal prototype

You will see that we have email and calendar feeds from Google, module information from our student information system, with click through to our Moodle VLE, library loan information from Aleph and balances for our VMC cashless card payment system and Safecom charged printing.  Clicking on the Printing History link brings up your recent print jobs in a "lightbox" (using the excellent ColorBox), which is a trick that I expect us to make more use of.

However, one bit of this isn't working yet - the Notifications box on the top left of the page is still static HTML.  I'll blog in the next few weeks about how we plan to fill that with targeted alerts and notifications.

Personalisation

This is done by embedding a small PHP fragment in any page that will have personalised content.  The conceit here is that any page on our website can potentially have personalised content and that the widgets being created for the portal can be reused all over the place rather than being orphaned on a site which you have to visit in its own right.

Behind the scenes a library routine is called which looks up your user name (you will have authenticated by this point) in our Active Directory via LDAP and caches the attributes returned by the directory for later use by widgets.  At the moment we are doing this on a page by page basis, but I expect that we will move to storing the attributes (probably as an encrypted cookie) to improve performance.

The conceit behind this project is that the portal is simply a regular website that has embedded widgets, which in turn can take advantage of information about the user’s identity to personalize the information that they display.

Widgets

The “widgets” themselves are not formally specified in the sense of JSR-168 Java portlets – they are simply calls out to embed additional content. Widgets could be written in PHP and embedded using something like PHP’s require_once() mechanism. Equally a PHP callout such as system() or an IFRAME can be used for this. This approach is well suited material being included as library items in a  Content Management System such as our Terminal Four Site Manager CMS, or authoring software such as Dreamweaver.

I was keen that the initial selection of widgets that we committed to develop would be written in a range of languages and take a range of different approaches behind the scenes. This proves the concept that the portal site is essentially technology neutral.  At present the prototype is written in a mixture of PHP, Perl and Python.  For best performance (this will have to perform smoothly with in excess of 30,000 sessions/day) we will want to avoid calling out to external interpreters to keep the page render time down to a minimum.  I think this means that the default widgets people see will end up being entirely PHP based.

University API

We are close to having everything we need for the initial student portal launch, but I expect us to develop further RESTful APIs as the requirements for the next phase of the portal firm up - perhaps eventually culminating in the much discussed but as yet apocryphal “University API”.  Our portal effort will begin with a read only view of key data, but as time goes by I expect us to start providing interactive widgets that update back end systems, and to experiment with mashing up multiple data feeds for visualisation purposes.

My view is that the portal (and there will be only one, just displaying different widgets depending on your role) will use the following technologies, in preference order:

• APIs where they exist, e.g. Google ATOM feeds and 2-legged OAuth mechanism, SOAP API for our Mifare based card system, our library's home grown RESTful API, and so on
• Direct database connections where an API is not available (still surprisingly common with bought-in packages) - presently we have a mixture of MySQL and ODBC for MS SQL Server
• IFRAMEs to embed the results of code that executes on other systems - probably the solution for most of our Oracle Web Reports and Apex code
• Screen scraping as a last resort, i.e. pull the results of fetching a URL then massage them for presentation

Time for a REST

As the portal becomes established I see us moving more and more towards RESTful APIs and away from the other approaches, which are fine for bootstrapping but not really sustainable. Here's a great example of constructing a RESTful API around the del.icio.us social bookmarking site. More on this topic anon...