Alternative Access Project: Mobile Scoping Study Final Report
Download 6.11 Mb.
|
- Navigate this page:
- Table of Contents Executive Summary
- 1. Background and Context 1.1 Why do we need Digimap mobile
- 1.2 Methods and Deliverables We organized the Digimap mobile scoping study into three strands as below: (I) User engagement
- (ii) Technical evaluation
- (iii) Digimap Mobile Prototype
- 1.3 Technical requirements
- 1.4 Technical approaches
- 1.4.3 Hybrid Applications
- 2 Technical Evaluation Strand
- 2.1 Summary of technical evaluation experiments conducted
- Experiment name Detailed in Section
- 2.1.1 Testing OpenLayers with iPhone and Android
|
Alternative Access Project: Mobile Scoping Study Final Report
Acknowledgements Edina would like to thank the following people and groups who gave up some of their time to talk to us about their work and experiences in using mobile in educational settings. We learnt a great deal from the conversations we had and we are sure that our analysis and recommendations are much closer to genuine needs and expectations as a result. Mike Sharples /Professor/ of Learning Sciences and Director of the Learning Sciences Research Institute at the University of Nottingham Anthony Steed - Professor of Virtual Environments & Computer Graphics Department of Computer Science, UCL David Mountain - Lecturer - City University London Claire Jarvis, Lecturer in Geographic Information, University of Leicester Jen Dickie, Research Associate - University of Leicester Gemma Polmear, Researcher University of Nottingham Gary Priestnall, Associate Professor - University of Nottingham Chris Kray, Lecturer at the School of Computing Science and the Digital Institute at Newcastle University. James Goulding, Research Associate, University of Nottingham Liz Brown, Research Associate, University of Nottingham The CGS Postgrads at Nottingham Phil Stenton, Managing Director, Calvium Jon Trinder, Researcher, University of Glasgow Chris Speed, Lecturer/Reader, Edinburgh College of Art Chris Lowry, Lecturer, Edinburgh College of Art Mark Wright, Research Fellow, University of Edinburgh Simon King, Reader, EPSRC Advanced Research Fellow, Centre For Speech Technology Research, University of Edinburgh Kevin McDonagh, Executive Director, Novoda Table of Contents Executive Summary As part of the Digimap Service Enhancement programme for 2009-2010, JISC funded EDINA to undertake a scoping study to investigate the potential for delivering Digimap data and services to mobile platforms. Within EDINA we needed to develop skills and competence in relevant mobile technologies and get a feeling for what skill sets and technology infrastructure would be necessary to achieve a sustainable mobile delivery platform. We organized the project into three separate strands to cover the goals above. A technical evaluation comprised a series of experiments using different technologies to help us understand the tradeoffs and merits of different technical approaches, code libraries and frameworks available to mobile application developers. To understand our users’ needs better we undertook a user engagement exercise in which we researched extensively how people in HE/FE are currently using our data and services for mobile applications and organized a series of interviews with research groups and academics across the country to gain feedback on what EDINA could do to facilitate their activities. Finally we designed and implemented a Digimap4Mobile pilot application. The main conclusion from the technical evaluation is that the Mobile Web approach is the best medium term option for rolling out the Digimap service for mobile. Our work optimizing the OpenLayers web mapping framework for mobile has demonstrated that this approach is feasible, although some technical issues arose that still need some investigation before committing fully to this approach. Where a sustainability model requires end users to make payment to use the service we suggest the higher speed and usability afforded by a native application is a necessary to meet users’ expectations. Another outcome of the technical evaluation was the “geomobile” blog which has attracted 600 hits a week with technical posts covering our work on integrating OpenLayers with HTML5 particularly popular. This suggests there is some outside interest in our approach. We therefore recommend the EDINA take a leading role in providing an Open Source browser based mapping solution for mobile and continue to promote this through our blog and other channels to maximize the impact of our ongoing activity. The user engagement strand of the project led us to understand our users much better. A key finding was that in areas such as fieldwork and augmented reality, where we expected Digimap data to be in great demand, only teachers and researchers highly skilled in GIS and 3d visualization were making any significant use of our data for mobile. Therefore we only found very sophisticated applications of Digimap data (such as 3d visualizations of retreating glaciers) while much simpler applications (such as displaying the name and height of a mountain) were notable by their absence. Based on discussions with various people working in HE/FE we believe that there may be a skills mismatch preventing more widespread use of our data in mobile devices. For the people who want to exploit our data for simple field applications the technical barriers are too high, while for those who have the necessary skills the barriers are too low, that is, they cannot justify standard technical work against research goals. We believe EDINA could play a role in bridging this gap by providing easy to use authoring and publishing tools which will enable educators to add content that can be deployed far more easily on mobile devices. To support field exercises we suggest a tool similar to HP’s MScape ( now spun off into Calvium) that has already proved very popular in the mLearning community and schools sector. Similarly we recommend investment in tools that make it easier to publish content that can be consumed by emerging augmented reality browsers such as Layar and Wikitude. For users aiming to create sophisticated 3d models to drive their mobile applications, we recommend that a new tool is developed to facilitate the process of creating these models and automating much of the laborious manual work currently involved - possibly hosting these models in virtual world servers and 3d engines. Talking to several users in different fields of study we discovered that our existing tools do not always make life easy for those wanting to use Digimap data in fieldwork contexts and therefore we suggest some enhancement to existing downloader facilities to allow multiple products to be downloaded at the same time in a mobile friendly format. Further we recommend a facility that allows users to cache their favourite maps on the mobile device so that a small area can be viewed without any data connection. The main output from our work on the Digimap pilot is a new security model based on a long lasting token, rather than a short lived login session used in desktop applications. We recommend that EDINA follow up the Digimap pilot with a short service transition project that will allow us to rollout a new Digimap4Mobile product as soon as possible. Data providers such as Ordnance Survey will need to be consulted to ensure they are comfortable with the new security model we have developed. The main offering will be a web based application (for HTML5 compliant mobile browsers) that incorporate features such as Ordnance Survey , Historic and BGS mapping, cacheable “MyMaps”, and “Unlock” feature search. We may also consider rolling out the iPhone version of the pilot but a sustainability model is required for this as it is not certain that EDINA will be able to retain the skill set needed for this and other native applications. At the end of this project EDINA is in a much stronger position both in its technical capability and in its links to the academic community to invest in delivering mobile based content in a way that will address the community’s needs. The study has revealed some gaps in our current offerings and opportunities for new services. We have gained experience and expertise allowing us to make judgements on a sustainable approach for future development and have generated several new ideas for research projects and collaborations with educators and researchers across the academic community. 1. Background and Context 1.1 Why do we need Digimap mobile? There are already many mapping products readily available on mobile devices so delivering yet another one might seem unnecessary. But the kinds of map offered by Digimap go beyond simple road navigation and “knife and fork” features to include historic maps, geology maps, terrain and landscape, as well as political and administrative boundaries. The level of detail and coverage is consistent across the country, covering remote areas as well as densely populated towns and cities. For educational uses this level of detail of coverage is crucial as the remote, inaccessible places are often those of most interest to academic study. The Digimap service offers comprehensive information about places, not just through maps, but through access to rich feature sets. As this report will demonstrate, there is great potential for Digimap services to offer a unique mobile educational experience ranging from fieldtrips to augmented reality. This scoping study explores in detail ways in which Digimap is already and could be further used to develop location based services for learning and teaching within the HE/FE sector. We review the various technical approaches and frameworks that could be employed to deliver these services and report our prototype Digimap mobile service, indicating the technical and sustainability issues that need to be resolved to roll out a fully featured service. 1.2 Methods and Deliverables We organized the Digimap mobile scoping study into three strands as below: (I) User engagement The aim of the user engagement activity was to find out how people are using Digimap already for creating location based services, what they would like to do in future and what we could do better to support their activities. We held interviews with people working in a range of academic and teaching disciplines to ask them about their experience and expectations. The feedback from these interviews is provided throughout this report and many of our recommendations came directly from the people we spoke to. (ii) Technical evaluation The purpose of the technical evaluation was to review frameworks and emerging standards that enable delivery of maps and other geographic data to mobile devices. In particular, we targeted location aware smart phone devices such as iPhone. The challenge is for EDINA to provide a service that will work on a range of devices without having to develop in depth expertise in all the different native operating systems and platforms, as this would not be easy to sustain. Frameworks / standards such as Google geo-location API, PhoneGap, Layar and HTML5 were evaluated to give an overview of how web services can be delivered in a portable way. While semi portable frameworks such as those mentioned above may be sufficient for some applications it is important to understand what the limitations are. So a comparison with what can be achieved using a pure native approach (such as a Android or Objective-C ) application was also undertaken. Another issue to overcome is offline access to data - are there solutions to serving maps from a local cache - again finding ways to port the solution across different platforms, browsers? The main criteria for evaluation will be:
portability access to sensors ( geo-location, camera, compass, accelerometer) usability ( touch screen controls / gestures ) sustainability speed offline access Drawing on this work we summarize the current state of technology and make recommendations on how to proceed with a future service implementation. Also a blog will provide comment and analysis in a more informal way as we go along. (iii) Digimap Mobile Prototype As an extension to the general technical evaluation described above we implemented a prototype mobile application to serve OS maps to a smart phone platform. We tried two approaches: the first implementing the map application on a mobile web browser; the second using a native iPhone application framework. We report on the usability and sustainability of each approach and make recommendations for future rollout of a service considering different sustainability models. 1.3 Technical requirements Without specifying any formal requirements or use cases we have kept in mind the overall objective of delivering a map to a smart phone device within a range of educational contexts including field trips in remote areas, where network connectivity may be limited. It was also anticipated that the application might assist data collection, for example, taking pictures of rocks during a field study. The general functional and non functional requirements for such a client are shown below. Must be able to obtain a location fix through GPS. Must be able to take advantage of touch screen user gestures (e.g. pinch to zoom in and out) Should be able to access sensors and gadgets such as the camera, accelerometer and compass. Should be able to cache data so that application can be used in remote areas with limited connectivity. Should work on a range of devices. 1.4 Technical approaches In the technical evaluation strand of the mobile scoping project we investigated three general approaches to developing location based services for mobile devices, native applications, mobile web applications and hybrid applications. These categories are explained below: 1.4.1 Native Apps A native application is developed using the programming language and APIs for a specific platform. The app developer has full access to the device operating system, sensors and user interface primitives. For example a native application for the Apple iPhone uses the Objective-C language and Cocoa Touch API to create rich internet applications such as mapping clients. A developer programming a native application for Android based devices will typically use the Java language; for Blackberry PDAs the native language is RIM, while for Symbian, programming is done in a specialized version of C++. While native applications offer the best outcomes in terms of speed and usability, the fragmented technology base makes it hard (and expensive) for small organizations to obtain the necessary skills to support such a heterogeneous range of platforms. 1.4.2 Mobile Web Mobile Web applications make use of the mobile phone web browser to deliver applications. Before the current generation of smart phones came to market, most mobile web browsers were limited in their functionality compared to desktop equivalents and did not support technologies such as JavaScript or Flash which are used to create rich internet applications such as mapping clients. But the current generation of smart phones do support standards such as JavaScript and HTML5 [1] opening up the possibility of creating rich applications for mobile web. Many of these new generation mobile browsers support HTML5 Cache and HTML5 Storage, enabling access to the application even when network coverage is not available. Because the browser built in security prevents developers from accessing the native operating system it is not possible to get programmatic access to some parts of the device equipment, such as camera, accelerometer and phone. Crucially though, access to location sensors such as GPS and compass can be achieved using the Geolocation API [2], which most browsers support. This means that rich location based services can now be developed for mobile web browser with fairly good compatibility across devices and platforms. However, the speed and usability of these applications is not always as good as native equivalents. Also, the application can not be sold in this format on popular app stores such as the Apple App Store or Android marketplace. This means that developer has to find another mechanism to allow the user to make payments for the service or find other ways to monetize the application. 1.4.3 Hybrid Applications A hybrid application is a native application with an embedded web browser so that the advantages of both a web and native approach are combined. Most of the code is implemented in the web browser using standards such as JavaScript and HTML5, which means most of the code is still portable across platforms. Where access is needed to devices such as the camera or accelerometer, this can be achieved through a framework such as PhoneGap [3], which provides a single JavaScript API for accessing sensors and devices that is the same across platforms. Using an application with an embedded web browser or a framework such as PhoneGap requires relatively little knowledge of the native language and APIs - so it is much easier to develop cross platform applications without having to develop expertise in a plethora of low level languages. However, developers will still require basic familiarity with the native development environment and knowledge of how to package, deploy and publish the applications. You can also market the application on the App Store, although sometimes the App Store review process may impose restrictions on the use of frameworks, for example, mandating a particular stable version. The table below shows how each of the approaches above meet the overall requirements.
The diagram below shows how we see functions fall into each of the three approaches. In cases where the feature (e.g. “developer happiness”) could fall into more than one category we choose the one we felt matched the feature best based on our experience, but it a subjective decision and is meant to inform rather than dictate decision making, 
One approach that does not feature in the diagram above is outsourcing. We do not have any direct experience of outsourcing code development but we are certainly open minded about this option. As part of the project we attended several “Mobile Monday” events in Edinburgh and it clear that many dynamic small firms have sprung up over the last year specializing in mobile app development for a range of platforms. Given the market is so competitive it may well prove cost effective to outsource development and maintenance of mobile delivery to such firms, at least until the rapid rate of change and increasing fragmentation in the mobile app market subsides. 2 Technical Evaluation Strand There is a lot of debate and hype surrounding the different approaches to developing mobile applications and the situation is constantly changing making it difficult to reach an objective decision on which approach best suits your organizational needs. We were determined in this study to find out for ourselves which technologies and frameworks worked best for our needs by actually trying out each technology in a series of small experiments designed to tease out the pros and cons of each approach and particular issues related to delivery of maps and geographic data. To evaluate the native application approach we used an open source mapping client framework called Route-me [4]. For the Mobile Web evaluation we used the popular OpenLayers [5] AJAX framework and the Layar [6] and Wikitude [7] augmented reality frameworks for testing Augmented Reality. For investigation into hybrid application we experimented with the PhoneGap [3] framework and our own purpose built hybrid application. 2.1 Summary of technical evaluation experiments conducted The technical experiments conducted as part of the technical Evaluation Strand of the work are summarised in the table below. Fuller explanation of each follows in the narrative.
2.1.1 Testing OpenLayers with iPhone and Android Summary - A web browser based mapping client using the OpenLayers mapping API. Modifications made to the OpenLayers event handling so that iPhone and Android touch screen gestures can be used for panning and zooming on the map. In this evaluation we looked at how we could best deliver Digimap content to a mobile web browser on touch screen device such as iPhone or Android. As these devices have built-in mapping applications such as Google Maps the device owners will expect a similar level of user experience, in particular fast panning and zooming and a touch screen controls. Most web based mapping clients such as Google maps use a JavaScript (AJAX) codebase to create a rich user experience on a web browser, where a “slippy map” effect is achieved by caching many surrounding tiles in the browser to reduce calls to the server as the user pans and zooms around the map. The Digimap service does not use the Google API as the terms and conditions are too restrictive. Therefore Digimap ROAM uses an open source JavaScript (AJAX) library called OpenLayers [5] instead. This popular API provides a similar rich user experience on desktop browser to the Google offering but does not impose restrictions. Crucially, the current version of OpenLayers does not support touch screen events and is not optimized for much smaller smartphone screens. So to provide a version of Digimap on mobile web browser we needed to investigate how the OpenLayers mapping API could be adapted to provide touch screen support and improved performance on mobile device such as iPhone. Searching through the OpenLayers mailing lists we soon found a way of applying touch gestures to panning and zooming and posted a blog on this technique. There is no doubt that the OS Mastermap product is ideally suited for the smartphone touch screen display, with details such as house numbers rendering very crisply and adding greatly to the user experience ( see screenshot below). Freely available applications such as Google Maps look barren in comparison and it is clear that providing such a level of detail will greatly enhance the potential for mobile mapping in an educational setting. We were disappointed though with the responsiveness of the panning. The Goggle API achieves a highly responsive drag effect where the map moves with your finger just like pressing down and shifting a piece of paper on a table. The OpenLayers pan method in comparison is slow and jittery with a significant delay between the finger movement and image shift. Interestingly this problem only becomes apparent when OpenLayers is running on an iPhone type device. On a desktop the responsiveness of OpenLayers seems to be more than adequate, presumably due to the much greater CPU power. Given many other mapping applications based on Google’s API have raised user expectation this is a problem we need to redress if we are going to deliver a browser based mobile map application. As we already use OpenLayers API as the core mapping technology in other products such as Digimap ROAM, some investment in contributing to the project is justified. Our blog on this topic was one of the popular we posted (over 1000 views) suggesting there is a wider interest in using OpenLayers on mobile. Therefore we will work on improving the OpenLayers API panning and zooming functionality to provide the same experience as Google API offers, but without restrictions imposed by Google. Based on this evaluation, we recommend the EDINA take a leading role in providing an Open Source unrestricted browser based mapping solution for mobile. 
Screen shot of OS Mastermap on iPhone Safari browser. 
Blog stats for Open-Layers with iPhone. Total views by 18 May 2010 is 1,201. Average views per day 13; Average per month 350. Directory: 2010 2010 -> Through the Roof 2010 -> 2004 ieee international topical meeting on microwave photonics technical digest 2010 -> The petition and case system 2010 -> Hr 116 Application for Employment with Hills and Dales 2010 -> Polimaster ltd V. Rae systems inc polimaster ltd.; Na&se trading co., Limited, Plaintiffs-Appellants 2010 -> The tandem project 2010 -> Cape Lookout National Seashore Historic Resource Study By 2010 -> Cape Lookout National Seashore Historic Resource Study By 2010 -> Ap u. S. History presidents list the Young Republic, 1788-1815 George Washington, 1789-1797 Download 6.11 Mb. Share with your friends:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||