This blog post describes some work that Garry Booth and I have been doing at Loughborough to prototype a Mobile Web site as part of our student portal project. It expands on the themes I raised in my talk at the recent Developing for the Mobile Web workshop hosted by UKOLN and the ILRT. My slides can be viewed below via slideshare.net...
Mobile Web at Loughborough
(if the rationale doesn't interest you - skip on for screenshots!)
Mandate for Mobile Access
Focus group feedback from our students indicates a clear demand for on-the-go access to timely information. Examples have been cited in focus group meetings of mobile access to view lecture timetables and find room locations, book and renew resources (books, rooms, tickets for events, sports facilities etc), and in general to provide the same types of personalised service that we have been developing for our student portal site. I am expecting that we will be able to go one better and provide the same information in both mobile and desktop paradigms (albeit with different presentation). I will also note that a great many of the things students are asking us for are also directly relevant to staff. My feeling is that developments such as ours, the Molly (Mobile Oxford) project and Bristol's Mobile Campus Assistant will lead to a new wave of "portals" focussed more on the data feeds than the portal software - but more of that later.
However, it is also evident that we cannot assume everyone will own an iPhone, or more generally a high end smartphone running a browser based on a recent version of WebKit. At the DevCSI Mobile Web workshop Tim Fernando and Stuart Lee both made persuasive cases for "progessive enhancement" rather than "graceful degradation" (which on reflection sounds a little too much like a dodgy goth band in any case). By taking a progressive enhancement approach, your primary goal is to provide information to lowest common denominator devices, then moving beyond this to take advantage of higher end features (such as sensors, geo-location and UI gloss) where available. Similar considerations apply to data plans, with an increasing move to tiered pricing by mobile operators - and we cannot assume WiFi support as a given on students' mobile phones.
Why Mobile Web?
I contend that whilst native apps offer the best user experience, this comes with a steep learning curve for each platform being taken on. Consider that true cross platform development for the iPhone has yet to take off, in spite of Apple's recent relaxation of their policy over intermediate tools. There are also some questions around which platforms to tackle - iOS (essentially still Objective C) and Android (Java) are clearly in the ascendent, but there are a huge number of "feature phones" (typically supporting Java Midlets) and legacy smartphones (e.g. Nokia Series 40 and 60) kicking around. To add insult to injury, some vendors are working on radical changes to their offerings which will result in them offering multiple operating systems and development environments for a period - notably Nokia's planned move to MeeGo, and Microsoft's move to Windows Phone 7 (which may well become the only place where Silverlight is used). At least Nokia are evolving a common approach across their operating systems using QT for portability. [As an aside, it's interesting as a long time Unix hacker to see that BSD and Linux will shortly be in pretty much everyone's pockets via the proliferation of iOS, Android, and either or both of WebOS and MeeGo :-]
Doing justice to this plurality of environments is clearly difficult to do. We could say "hang it, this stuff is iOS only" as some other institutions have done, or "sorry, it's high end smartphone only". The problem with this is that it disenfranchises people who are not in a position to afford the latest and greatest device, and there is also the implication that at some point a high end smartphone might become a requirement for study at our institution. [Playing Devil's Advocate - there is a certain logic in ensuring that everyone is handed out standard kit, and in a world of annual tuition fees of as much as £9,000, this sort of thing might turn out to be line noise :-]
So what this boils down to for me is that by taking a Mobile Web based approach rather than an App based approach we can potentially develop once (for the Web) and then (with a small amount of buffing and polishing) provide the same underlying information with varying degrees of sophistication depending on your device's capabilities.
Let's see if this holds true...
MIT Mobile Web and Mobile Web OSP
MIT were pioneers of mobile information provision through their Mobile Web application. This was written in PHP, with interfaces to various MIT back end services. Here's a nice presentation that outlines this early work:
The MIT Mobile Web software was released as open source, but this essentially consisted of two code dumps and little else. Following on from this, an active community has coalesced around a fork of this code known as Mobile Web OSP (OSP == Open Source Project), led by Dave Olsen from West Virginia University.
This code base is particularly interesting to us because it is built on top of PHP, which we are using as the foundation for our student portal. If we had been writing the student portal in Python, then I suspect Oxford's Molly project would have been a more natural choice. Similarly, if we had been ace Java coders, then the ILRT's Mobile Campus Assistant would have been a cinch. However, there is a particular concern with PHP - the ease with which the underlying code and the presentation layer (HTML and CSS) can be muddled. Care needs to be taken to ensure that the two are kept at arm's length from each other.
Mobile Web OSP builds on MIT Mobile Web using the jQTouch library to provide "iOS style" behaviour, with the sorts of visuals and transition effects that high end smartphone users will be familiar with. When we first started looking at Mobile Web, my feeling had been that we could avoid having a "system" or a particular software package (in the same way that there will be no overarching portal "system"), but the nuances of providing content in slightly different ways to different devices mean that a small layer of presentational logic is necessary somewhere.
First Look - The Home Grid
This screenshot shows a prototype Loughborough Mobile Web site constructed using Mobile Web OSP.
Whilst it might appear otherwise, please note no graphic designers were harmed in its construction! I think it's safe to say that the production version of this site will look very different :-) Focussing on the content, we have a mixture of general University news and information, and personalised content. I'll go into more detail below.
Personalised Mobile Services
Here we have data drawn from central systems including Learn, our Moodle based VLE, our Aleph library system from Ex Libris, and our cashless payment system from VMC.
It's important to note that the underlying code that populates these pages is the same code which populates the widgets on the desktop version of our portal site. No redevelopment was necessary to produce a Mobile Web interface. This for me is a key benefit of the Mobile Web approach.
General Information
Here we have existing public data feeds such as our student noticeboard and YouTube channel, plus content scraped from web pages such as Washer/Dryer status in the campus laundrettes, and IT service status including "lab" PC availability.
Whilst the information shown above is not personalised per se, we know from focus group feedback that "public information" such as this of great interest. Some of the data feeds that we have identified will be useful in other contexts, e.g. lab PC availability via our digital signage.
Location Based Services
This is an area where I think there will be a real differentiation between what we can offer on entry level and high end devices - made possible by features such as GPS and interactive maps. There is a question here about the degree to which we can achieve progressive enhancement for low end devices without WiFi or for those without a generous data plan.
The examples above show a prototype interactive campus map based on OpenStreetMap (via touchMapLite), and another based on Google Maps (using proprietary code developed for us by Rock Kitchen Harris for our interactive campus map). You may be able to spot that the Google Maps base layer has a mistake which means that a small section of the main road route through the University is missing - this has unfortunate consequences for route mapping, as you might imagine. It will be interesting to see whether we are able to exploit our connections within Google to get this corrected. In theory this is possible through the Base Map Partner Program.
Like Exeter we are in the fortunate position of having already geo-located all our buildings - for our desktop oriented interactive campus map. We have also added numerous points of interest, which should make it relatively easy to create a "Near Me" type feature in future. I'm interested in people's feedback on this sort of proximity based information, e.g. the following seem fairly obvious:
Loose Ends and Next Steps
As we put the finishing touches to our desktop student portal site prior to piloting it in the run up to Christmas I have been demonstrating the prototype Mobile Web site to people to gauge the general level of interest. Initial feedback has been very encouraging, and indeed most of the people I have spoken to have been very keen for us to release a Mobile Web site in conjunction with the main portal site. Clearly there is much to do in the way of web design before we can let this one out ;-) Interestingly most of the features are already up and running through code re-use from the desktop site.
If we do go down the Mobile Web OSP route, it will be interesting to see whether we are able to preserve compatibility with the core code base. This would let us pick up on (say) a future move from jQTouch to jQuery Mobile or Sencha Touch with a minimum of recoding. However, we may find that we have made so many changes to the code base that this is simply impossible. For me this is one of the perils of building upon open source software rather than simply using it off the shelf (you become the maintainer of a system that is unique to your site), and a bear trap that can be difficult to avoid. Only time will tell...
Finally, at the head of this post I allude to the idea that some of these Mobile Web implementations will grow into the next generation of portals. If you consider that presentation logic and politics are perhaps the main obstacles to this, then it may be interesting to compare and contrast the facilities typically offered by institutional portals with the information being provided on Mobile Web sites. That's one for another day :-)
(if the rationale doesn't interest you - skip on for screenshots!)
Mandate for Mobile Access
Focus group feedback from our students indicates a clear demand for on-the-go access to timely information. Examples have been cited in focus group meetings of mobile access to view lecture timetables and find room locations, book and renew resources (books, rooms, tickets for events, sports facilities etc), and in general to provide the same types of personalised service that we have been developing for our student portal site. I am expecting that we will be able to go one better and provide the same information in both mobile and desktop paradigms (albeit with different presentation). I will also note that a great many of the things students are asking us for are also directly relevant to staff. My feeling is that developments such as ours, the Molly (Mobile Oxford) project and Bristol's Mobile Campus Assistant will lead to a new wave of "portals" focussed more on the data feeds than the portal software - but more of that later.
However, it is also evident that we cannot assume everyone will own an iPhone, or more generally a high end smartphone running a browser based on a recent version of WebKit. At the DevCSI Mobile Web workshop Tim Fernando and Stuart Lee both made persuasive cases for "progessive enhancement" rather than "graceful degradation" (which on reflection sounds a little too much like a dodgy goth band in any case). By taking a progressive enhancement approach, your primary goal is to provide information to lowest common denominator devices, then moving beyond this to take advantage of higher end features (such as sensors, geo-location and UI gloss) where available. Similar considerations apply to data plans, with an increasing move to tiered pricing by mobile operators - and we cannot assume WiFi support as a given on students' mobile phones.
Why Mobile Web?
I contend that whilst native apps offer the best user experience, this comes with a steep learning curve for each platform being taken on. Consider that true cross platform development for the iPhone has yet to take off, in spite of Apple's recent relaxation of their policy over intermediate tools. There are also some questions around which platforms to tackle - iOS (essentially still Objective C) and Android (Java) are clearly in the ascendent, but there are a huge number of "feature phones" (typically supporting Java Midlets) and legacy smartphones (e.g. Nokia Series 40 and 60) kicking around. To add insult to injury, some vendors are working on radical changes to their offerings which will result in them offering multiple operating systems and development environments for a period - notably Nokia's planned move to MeeGo, and Microsoft's move to Windows Phone 7 (which may well become the only place where Silverlight is used). At least Nokia are evolving a common approach across their operating systems using QT for portability. [As an aside, it's interesting as a long time Unix hacker to see that BSD and Linux will shortly be in pretty much everyone's pockets via the proliferation of iOS, Android, and either or both of WebOS and MeeGo :-]
Doing justice to this plurality of environments is clearly difficult to do. We could say "hang it, this stuff is iOS only" as some other institutions have done, or "sorry, it's high end smartphone only". The problem with this is that it disenfranchises people who are not in a position to afford the latest and greatest device, and there is also the implication that at some point a high end smartphone might become a requirement for study at our institution. [Playing Devil's Advocate - there is a certain logic in ensuring that everyone is handed out standard kit, and in a world of annual tuition fees of as much as £9,000, this sort of thing might turn out to be line noise :-]
So what this boils down to for me is that by taking a Mobile Web based approach rather than an App based approach we can potentially develop once (for the Web) and then (with a small amount of buffing and polishing) provide the same underlying information with varying degrees of sophistication depending on your device's capabilities.
Let's see if this holds true...
MIT Mobile Web and Mobile Web OSP
MIT were pioneers of mobile information provision through their Mobile Web application. This was written in PHP, with interfaces to various MIT back end services. Here's a nice presentation that outlines this early work:
The MIT Mobile Web software was released as open source, but this essentially consisted of two code dumps and little else. Following on from this, an active community has coalesced around a fork of this code known as Mobile Web OSP (OSP == Open Source Project), led by Dave Olsen from West Virginia University.
This code base is particularly interesting to us because it is built on top of PHP, which we are using as the foundation for our student portal. If we had been writing the student portal in Python, then I suspect Oxford's Molly project would have been a more natural choice. Similarly, if we had been ace Java coders, then the ILRT's Mobile Campus Assistant would have been a cinch. However, there is a particular concern with PHP - the ease with which the underlying code and the presentation layer (HTML and CSS) can be muddled. Care needs to be taken to ensure that the two are kept at arm's length from each other.
Mobile Web OSP builds on MIT Mobile Web using the jQTouch library to provide "iOS style" behaviour, with the sorts of visuals and transition effects that high end smartphone users will be familiar with. When we first started looking at Mobile Web, my feeling had been that we could avoid having a "system" or a particular software package (in the same way that there will be no overarching portal "system"), but the nuances of providing content in slightly different ways to different devices mean that a small layer of presentational logic is necessary somewhere.
First Look - The Home Grid
Whilst it might appear otherwise, please note no graphic designers were harmed in its construction! I think it's safe to say that the production version of this site will look very different :-) Focussing on the content, we have a mixture of general University news and information, and personalised content. I'll go into more detail below.
Personalised Mobile Services
Here we have data drawn from central systems including Learn, our Moodle based VLE, our Aleph library system from Ex Libris, and our cashless payment system from VMC.
It's important to note that the underlying code that populates these pages is the same code which populates the widgets on the desktop version of our portal site. No redevelopment was necessary to produce a Mobile Web interface. This for me is a key benefit of the Mobile Web approach.
General Information
Here we have existing public data feeds such as our student noticeboard and YouTube channel, plus content scraped from web pages such as Washer/Dryer status in the campus laundrettes, and IT service status including "lab" PC availability.
Whilst the information shown above is not personalised per se, we know from focus group feedback that "public information" such as this of great interest. Some of the data feeds that we have identified will be useful in other contexts, e.g. lab PC availability via our digital signage.
Location Based Services
This is an area where I think there will be a real differentiation between what we can offer on entry level and high end devices - made possible by features such as GPS and interactive maps. There is a question here about the degree to which we can achieve progressive enhancement for low end devices without WiFi or for those without a generous data plan.
The examples above show a prototype interactive campus map based on OpenStreetMap (via touchMapLite), and another based on Google Maps (using proprietary code developed for us by Rock Kitchen Harris for our interactive campus map). You may be able to spot that the Google Maps base layer has a mistake which means that a small section of the main road route through the University is missing - this has unfortunate consequences for route mapping, as you might imagine. It will be interesting to see whether we are able to exploit our connections within Google to get this corrected. In theory this is possible through the Base Map Partner Program.
Like Exeter we are in the fortunate position of having already geo-located all our buildings - for our desktop oriented interactive campus map. We have also added numerous points of interest, which should make it relatively easy to create a "Near Me" type feature in future. I'm interested in people's feedback on this sort of proximity based information, e.g. the following seem fairly obvious:
- "Lab" PCs - with feedback on availability
- Bus stops - with live running information
- Cycle racks and car parks
- Shops/Cafes/Bars(!) - with opening hours
- Accessible toilets
- Toilets available 24x7
Loose Ends and Next Steps
As we put the finishing touches to our desktop student portal site prior to piloting it in the run up to Christmas I have been demonstrating the prototype Mobile Web site to people to gauge the general level of interest. Initial feedback has been very encouraging, and indeed most of the people I have spoken to have been very keen for us to release a Mobile Web site in conjunction with the main portal site. Clearly there is much to do in the way of web design before we can let this one out ;-) Interestingly most of the features are already up and running through code re-use from the desktop site.
If we do go down the Mobile Web OSP route, it will be interesting to see whether we are able to preserve compatibility with the core code base. This would let us pick up on (say) a future move from jQTouch to jQuery Mobile or Sencha Touch with a minimum of recoding. However, we may find that we have made so many changes to the code base that this is simply impossible. For me this is one of the perils of building upon open source software rather than simply using it off the shelf (you become the maintainer of a system that is unique to your site), and a bear trap that can be difficult to avoid. Only time will tell...
Finally, at the head of this post I allude to the idea that some of these Mobile Web implementations will grow into the next generation of portals. If you consider that presentation logic and politics are perhaps the main obstacles to this, then it may be interesting to compare and contrast the facilities typically offered by institutional portals with the information being provided on Mobile Web sites. That's one for another day :-)
Excellent post, Martin. Really informative - thanks!
ReplyDeleteWhat with the much-talked-about use of mobile devices amongst learners now and the options available to institutions; from vendor driven native apps to web apps to mobile web, I think this post is fantastically helpful.
I'll be seeing you next week at the CETIS conference. I'll have to talk to you about presenting at my 2nd (as yet unplanned) CETIS event round Mobile Technologies methinks :)
Martin-
ReplyDeleteOne area of concern that I have for Mobile Web OSP is that notion of "upgradeability". I'm hoping that version 2 (which it appears you're using) has separated enough of the core logic and presentation from modules that for the most part code is re-usable when/if I make, for example, a move to jQuery Mobile. I think at this point jQTouch is on the way out. Hopefully as I release new versions folks like yourself can give feedback on what works or doesn't in terms of making your lives as simple as possible on upgrades. That is one of the positives to using open source... you can always bug me ;)
Please let me know if/when you go live with the project. It looks like you're providing some really cool information. It's definitely one of the more ambitious sites I've seen developed with Mobile Web OSP.
Really great post by the way.
Martin-
ReplyDeleteJust as an FYI I posted a "State of Mobile Web OSP" today in case you're curious where the project is heading outside of that jQTouch/jQuery Mobile issue.
http://www.dmolsen.com/mobile-in-higher-ed/?p=149
Hi Martin!
ReplyDeleteI've been meaning to google about Loughborough and Webosp for a few months since seeing you guys were giving a paper at the UKOLN Mobile Web Event back in October...just got round to it now!
Here at Stirling Uni we are currently starting to slowly implement Webosp and are so far in a definite prototype stage with a few things missing due to lack of usable data feeds. It's available here, although it's just on a development server so may collapse if more than a few people access it! http://m.stir.ac.uk
As Dave says some of the things you are implementing are pretty awesome and way more advanced than most other instances of his platform I've seen...I've been petitioning for networked washing machines for years! Going by the screenshots, your moodle implementation and library catalogue look great too. We unfortunately use webct and millenium for our VLE and OPAC which means we have to pretty much pay through the nose for any type of API to be able to do mobile stuff with them(although I do have a semi working Z39.50 client working on the mobile app with our opac).
I do share your worries about upgrading. My current version is a pretty bastardised version 2 as it is and I just noticed Dave has committed some new bits n pieces to github in preparation for a 2.5 launch. Looking through some of the changes I can see myself breaking it totally if I try to upgrade some of it, although simplerss and proper mysql support would be really helpful!
As probably two of the only UK places that are currently trying to implement webosp, it would be great to share some ideas and catch up properly at some point (andrew.wilson@stir.ac.uk).
Keep up the good work!
A bit late to the party, but at Bath we're currently doing some investigation into Mobileweb OSP. It plugged in quite nicely on top of many of our existing services! Did you end up going this route, or pursuing something else?
ReplyDeleteYou're right, the maps stuff is a differentiator, so it's annoying to see you've done some great work here; we've previously geo-located our buildings and computer labs (and PC availability) but not worked the display to such a high level. It'll be interesting to see what changes MWOSP 2.5 brings on this front.
http://blogs.bath.ac.uk/webservices/