Something I have realized about university services

October 24, 2009

There's a lot of services that people build around the university, both large and small. The general habit is to make them self-contained services that run on your own web site or whatever, or perhaps ones that integrate with other on-campus systems.

I have come to believe that this is a mistake. These days, university services should be assuming that students (both undergraduates and especially graduate students) will show up to the university with already established online identities and habits, which means that services should be designed so that they primarily integrate with these. People aren't going to abandon the services that they're already using, and generally they aren't going to be enthused to add more things to their online life (more websites, more programs, more whatever).

Or, in short and as an example, if you're going to make a new calendaring service, the thing to do is to make it export calendaring information so that people can integrate it with their existing Google Calendars or Yahoo Calendars or whatever online calendaring system they're already using. And you should expect that most people will use it that way.

This doesn't mean that you can't have your own self-contained service (eg, a calendar section on your website). But such a thing should be viewed as a backup that most people only use when something goes wrong with the data export to their regular services, not as something that very many people will ever use regularly.

(Yes, there are some practical issues; you'll have to figure out which outside services to support, for example, and make sure that you don't require people to join any particular one. These are not insurmountable, just potentially hard.)

This implies a number of things about how you design the services and what parts of them you focus most of your efforts on, of course. If the version on your own website is effectively a minor sideline, it doesn't make sense for it to consume lots of the project's efforts; they're better spent making sure that you integrate very well with the outside services that most people will use your service through.

Written on 24 October 2009.
« The limits of some anti-spam precautions
Some thoughts on a 'modern' university email system »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Oct 24 02:21:08 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.