Alternative Access Project: Mobile Scoping Study Final Report

Download 6.06 Mb.

Page	1/17
Date	26.04.2018
Size	6.06 Mb.
	#46904
Type	Report

1 2 3 4 5 6 7 8 9 ... 17

Version	Date	Comment	Author(s)
1.0	18^th June 2010		Ben Butchart Murray King Addy Pope Joe Vernon James Crone Jennie Fletcher
1.1	07^th July	Minor Changes	Ben Butchart
1.2	16^th July	Minor format changes	Ben Butchart
1.3	3^rd August	Reformat, readability changes and section numbering; minor edits	James Reid

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 4

1. Background and Context 6

1.1 Why do we need Digimap mobile? 6

1.2 Methods and Deliverables 6

(I) User engagement 6

(ii) Technical evaluation 7

(iii)Digimap Mobile Prototype 7

1.3 Technical requirements 7

1.4 Technical approaches 8

1.4.1 Native Apps 8

1.4.2 Mobile Web 8

1.4.3 Hybrid Applications 9

2 Technical Evaluation Strand 11

2.1 Summary of technical evaluation experiments conducted 11

2.1.1 Testing OpenLayers with iPhone and Android 12

2.1.2 Integrating OpenLayers and HTML5 Canvas 13

2.1.3 HTML5 local database SQL database and OpenLayers 16

2.1.4 GeoLocation API first impressions 17

2.1.5 3d objects for AR browsers 18

2.1.6 Building a native mapping app with Route-me 21

2.1.7 Automatic geo tagging of photos 22

2.1.8 A Phone Gap for a Map App 23

2.1.9 HTML5 Cache 25

2.2 Summary of Technical Evaluation Strand Key Recommendations 25

3 User engagement 26

3.1 Field study 26

3.1.1 Field Study User Engagement Recommendations 31

3.2 Augmented Reality 32

3.2.1 Augmented Reality User Engagement Recommendations 35

3.3 Virtual reality 36

3.3.1 Virtual World User Engagement Recommendations 38

3.4 Campus applications 38

3.4.1 Campus Apps Engagement Recommendations 40

4 Digimap Pilot 41

4.1 Security 41

4.2 Sustainability 43

4.3 Deployment 43

4.4 Digimap Pilot Recommendations 44

References 44

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.

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.

Requirement	Native	Mobile Web	Hybrid
Location sensors	yes	Yes (via HTML5 geo location API)	Yes (via HTML5 geo location API)
Touch gestures	yes	Yes (partial)	Yes (partial)
Sensors and gadgets	yes	No	Yes (usually via framework API)
Local storage	yes	Yes (via HTML5 Cache and Storage API)	Yes (via HTML5 Cache and Storage API)
Portable	no	Yes	Yes (partial)

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.

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.06 Mb.

Share with your friends:

1 2 3 4 5 6 7 8 9 ... 17