Educause '09: Portals
Writing about web page http://www.ithaca.edu/myhome
At a session about building a portal, I was struck by the similarities between the presenters’ institution – Ithaca College – and our own setup. They have three groups governing their web presence:
- Their web strategy group has oversight. This is a high level group with VPs, Marketing, Admissions, Provost’s office, etc.
- IT Services has technical leadership and hosts the institutional web site(s)
- Marketing & Comms shares responsibility with ITS for brand, high level content, UX, etc.
They have a richly functional and well populated CMS which they built themselves, and a year or so ago, decided that they would build a portal to accomplish the following:-
- Provide a home for a person’s (not the institution’s) activities. User has complete control over portlets, tabs, etc. – except for the “message center” portlet which is mandatory. The Comms Office control what appears in the Message Center.
- Provide a single entry point leading to other resources
- Improve communications between institution and students
- Make transactions easier and information easier to find
- Make a lightweight system that reuses as much as possible of existing web services & content.
A fairly similar set of circumstances to our own. What they built was a PHP / mySQL based application which uses the iGoogle portlet standard to deliver the following:-
- Drag & drop UI for selecting & arranging content. (Choosing a background colour for each portlet turns out to be surprisingly popular and well used.)
- The portal is a single sign-on participant, so starting in the portal means you won’t need to sign in to move on to other apps, and data can be pulled from other apps without needing to reauthenticate.
- Webmail & calendar views in the portal (in fact, the only access to webmail is via the portal, to drive traffic)
- Access to third party email accounts (Yahoo, Gmail, IMAP)
- Lots of portlets for non-institutional data – Facebook, Digg, Reddit, Twitter, RSS Feeds, etc.
- Search portlet shows results inline for people, web pages, blogs, etc.
- “Service tabs” are whole-page applications (eg. change your password, see your calendar).
- Users can publish and share their tabs with others if they’ve made a useful combination of things.
- There’s a very Facebook-like gadget which shows you who else is online, their status updates, comments on other peoples’ statuses, their photos, etc. You can define who your friends are just like Facebook.
- Mobile-optimised rendition (webkit optimised) – mobile home page is a list of portlets, then each portlet gets its own mobile-optimised screen. Similarly, an accessibilty-optimised rendition of the portal.
What’s striking about this to me is that they reached a different conclusion to the thinking we’ve so far been doing. Their portal at present doesn’t have access to much institutional information about the individual. So there’s no gadgets for “My modules” or “My timetable” or “My coursework”. The gadgets are fundamentally just news, email and external. They hope to add gadgets which can display institutional data, but there’s back-end plumbing which needs to happen first (again, sounds kind of familiar). Until I saw this presentation, my take was that you absolutely had to have those institutional data gadgets to succeed. But the Ithaca portal has achieved the astonishingly high take up rate of 80% of the members of the university visiting it at least once per day. Without institutional data. It’s given me pause for thought.
Ithaca have an excellent micro-site intended for people who are interested in their portal but who aren’t members of the university. See for instance the home page, some video tutorials, the presentation from today, and some usage stats