Mobile Presence for Small Liberal Arts Colleges (and others?) April 15, 2011Posted by ficial in brain dump, mobile, techy.
Williams is looking to break into the mobile world, and despite my resistance to / disinclination for cell phones and such I find myself heading up this effort. I don’t think the latter issue is actually a serious problem since, for the moment, I’m working on larger organizational aspects rather than particular services/applications. By the time I get around to dealing with implementation I’ll have a device of some sort.
I’ve examined at a number of different approaches to building a mobile presence. I’ve looked at over 40 different colleges and universities to see how they’ve done it (or not done it, as the case may be). Outside that I’ve also found various companies that will develop mobile solutions for a college or university (or other institution). I’ve installed several open source packages for creation of mobile web apps, and at least skimmed the documentation for several more. For all of these I am struck by their tactical focus. That is, if you have a particular service / app you wish to implement/provide, they are many good approaches available, BUT I’ve been able to find little discussion of what services to provide, and basically none about how to put those services in a larger context. I’ll give a high-level overview of what’s out there, and then spend some time talking about what’s missing.
From my research it looks like there’s some de facto consensus about what the core services are:
- campus map
- emergency contact info
- school calendar/events
- visitors info (including directions to campus)
- library catalog/database searching
- athletic schedule
- for large campuses some sort of bus schedule thing also seems to be quite common
There seem to be three main approaches to developing a mobile presence: building native applications (either in house or via a 3rd party like Boopsie or Axess), building mobile web applications (usually using some kind of framework), and making lists of relevant applications that other’s have created (e.g. rather than creating a local weather app, reviewing a number of existing weather apps and choosing one or two to recommend). These approaches are non-exclusive. Native apps are generally considered to provide a superior user experience, but also to be the most difficult and expensive to create and maintain – among other things, any particular service needs to be re-created on at least three platforms – iphone, android, and blackberry – to be fully available (though, realistically speaking, iphone alone gets to a large majority of the audience). Mobile web apps are web applications with a user interface and experience designed for a mobile device. They have the advantages of being relatively fast and easy to create, being platform independent, and usually leveraging skills that already exist in the institution. They also can offer graceful degradation to support a text-only interface for older and/or simpler devices. They come at the cost of some usability, and of being unable to access some device-specific features (e.g. camera, accelerometers; they CAN access GPS info). Creating a collection of apps created by other people is fast, cheap, and easy. However, you get no institutional branding, no sense of coherence, and you are limited to what’s there (no customization).
Most places use a mix of these approaches. For example, a university might use native apps for complex and high-profile services (e.g. campus map integrated with a bus schedule), mobile web apps for things that need graceful degradation (e.g. emergency contact info), and 3rd party apps for very general services (e.g. weather) or very specific ones (e.g. access to a library database, with the app provided by the database vendor). Native and mobile web apps might be created in-house, or might be contracted out.
I haven’t looked into too much in the way of prices offered by vendors. Of the ones I know about a per-year price is the model they use. Prices vary widely – one vendor includes in their free package an app for which another would charge $15K/year. This is very reminiscent of early web years when developer quotes could easily be different by 2 orders of magnitude, and many places spent an awful lot for not much.
Another way this reminds me of early web years is that mobile development/presence seems to completely lack a larger context. That is, each service and need is treated essentially in isolation. Certainly services may be grouped together in a larger package, but there’s little in the way of coherent framework. At Williams we got ourselves into a pretty sticky mess with the web because early on there wasn’t much coherence among all the various departmental and program sites. This meant that in short order our maintenance was a nightmare, our costs were way too high, lots of important information was hard or impossible to get, and our combined web presence was much less useful to our users than it could have been.
Ideally we’d avoid that same problem in the mobile world. This means that beyond just choosing and implementing a bunch of services, we need to figure out a larger structure in which they can be placed. As the number of services available and useful on a mobile platform grows over time to the many tens or even hundreds our users still need to find what they want and need quickly and easily. Related to that, ‘our users’ are highly segmented, and people may quickly switch from one segment to another. This is true of audiences in general, but I think it’s an especially important consideration for mobile users of interest to an academic institution.
There are two parts to that. First, the ‘mobile users’ part- people with mobile devices move around, and the services in which they’re interested depend on where they are. For example, a alum on campus would need a different set of services than that same person at home on the other side of the country. Second, the ‘academic institution’ part- academic institutions by their nature deal with people moving through different phases, from prospective student to matriculated student to various classes to alumni, not to mention faculty, staff, and visitors (e.g. parents, conference attendees, etc.). These two factors mean there are at least 10 distinct audience segments (local and remote for each of prospective, student, alum, faculty/staff, and visitor), not even counting special events like a reunion for a particular class, or a schedule of events for a particular conference, nor small-but-important audience segments like the trustees. These various audience segments need particular sets of services available to them, with a fair amount of overlap. For example, everyone local to campus might need athletic facility hours, and all students, local or not, might need access to course information.
Our mobile framework needs to support:
- adding and removing mobile services (native apps, mobile web apps, and app recommendations)
- with control distributed across various campus groups
- easy integration of 3rd party work
- creating selections of mobile services tuned for a particular audience segment
- with control distributed across various campus groups
- make it fast and easy for a user to get the service they need
- automatic and self directed segment determination
- un-cluttered presentation
- excellent search and browse capabilities
- access/use for all major mobile platforms
- phones and small mobile devices (e.g. itouch)
- larger mobile devices (tablets)
Creating mobile services without such a framework leads to a number of very serious problems:
- as development continues users are overloaded by the number of services available
- the specific services a user needs are hard to find
- the overall experience is unpleasant and so users avoid it
- the institution’s mobile presence ends up diluted, scattered, and disorganized
- user experience is poor
- maintenance is a nightmare
- bad use of institutional resources
The biggest challenge we face in developing a mobile presence is not in implementing particular services – there are many options for that, with choices depending how much of what resources are available. Nor is it in choosing which services to provide – we have a good idea of the core services to offer, and many ideas for additional services once those are done. By convening a cross-departmental group to discuss mobile issues we’ve already taken the single most important step in letting us figuring out what services want to offer. The real obstacle is finding, or more likely creating, a framework that allows us move forward as soon as possible without making our lives and our users lives too difficult a few years down the line.