Mobile Learning infokit / Technical considerations
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.


Technical considerations

Page history last edited by Doug Belshaw 8 years, 9 months ago

"People... don’t like going out of their way to report problems."

Tim Fernando,
University of Oxford

Mobile Learning is a fast-moving field with device lifecycles becoming ever shorter. This section looks at some of the general principles behind the technical roll-out of a platform or ‘ecosystem’ for mobile learning.


Important decisions

There are two main decisions when deciding on the approach for institution-centric mobile learning experiences. These decisions should flow not from technical possibility but from some of the considerations mentioned in the Strategy and Pedagogy sections of this infoKit. The first decision is whether the mobile devices used will be provided by the institution or by the students. As we will discover in the Cost/benefit section it is increasingly the case that going down the road of institutionally-provided devices is undesirable in all but the most specialised of cases.


The second technical decision to be made is on the type of interface that is presented to the audience for the mobile learning initiative. This, of course, needs to take into account whether the audience is closely identified (e.g. a particular group of students) or diverse (e.g. the whole staff and student population). These considerations do not map one-to-one onto the following options but should nevertheless guide implementation.


JISC CETIS has a useful briefing paper on mobile web apps.


There are broadly three options for mobile learning ‘apps’:


  • Native
  • Web
  • Hybrid


The native app is delivered via the app store pertaining to the particular device. This means, for example, that to cover the bases of the main types of smartphones that are currently on campuses, native apps would have to be developed for iOS, Android and BlackBerry devices. The cost in terms of financial outlay and time commitment to do this is prohibitive for all but the largest of institutions. CampusM from Ombiel is an example of a popular native app available across various smartphone devices.


The web app can be accessed via any device that can connect to the internet. There are many ways to do this, including providing an alternative mobile-friendly CSS file for existing content, or building a new portal. If the latter is chosen it is important that it is standards-compliant, using the guidance of the World Wide Web Consortium to ensure cross-platform, and future, compatibility. Bradford University’s site is a good example of a standards-compliant, mobile-friendly portal.


The advantages of native apps include tighter integration with the various specific features mobile devices as well as offline caching of content. The advantages of web apps, on the other hand, include instant updating of content and lower costs. Hybrid apps, therefore, promise to be the best of both worlds. The native app is a ‘shell’ which is available through the various app stores and is updated when functional improvements are necessary. However, the content - the information, links, resources and communication opportunities - are web-based and can be updated without updating the whole app. An example of this innovative approach would be JISC Regional Support Centre South East’s iOS and Android apps which give access to the latest news, events and funding opportunities from the service.


The Basics

Before building apps and rolling out services to staff and students it is important to have in place those things that will enable a mobile learning ecosystem to flourish. There are three such basics which any institutions should consider as ‘standard’:


  1. Wifi coverage
  2. Open data streams
  3. A problem-solving system


Our network team have taken a measured approach with the wireless roll out, providing hot spots in all the main areas where staff and students gather or work rather than blanket coverage everywhere. This enables us to provide a cost effective wifi service and minimise the number of access points that are installed in areas where there is no wireless requirement."

John Fairhall,
University of Bradford

The received wisdom up until recently has been to ‘flood’ campuses with wifi access. In other words, an institution could never have too many access points to provide network and internet access to staff, students and, on occasion, the general public. That position is changing, however. Not only have financial constraints meant a re-evalutation of this approach but evolutionary improvements in wifi technologies, along with a more nuanced understanding of when and where students use wifi-enabled devices, mean that such a blanket policy looks outdated.

Opening data streams, or more precisely exposing systems through web services, is also important as it allows any apps that are developed to easily ‘hook into’ information available to the institution. Examples of these include RSS feeds, the source XML for which can be used on a variety of platforms including web pages, apps and information screens around campus.

Finally, as Tim Fernando points out in the video at the top of this page, people do not like going out of their way to report problems. A lightweight but context-relevant problem-reporting system may not capture every detail about a particular problem but it would, at least, identify the problem and (often) the affected user. Having partial information about a problem that could be frustrating many users of a service is better than having no information on it at all.

Some guiding principles

Whilst strategic and pedagogical decisions should always guide technical deployment of hardware and software for mobile learning there are, nevertheless, some guiding principles that may help guide those looking after the technical considerations. Upside Learning has suggest five key mobile learning implementation tips:


  1. KISS (Keep It Short and Simple)
  2. Aim for low information density
  3. Use multimedia sparingly
  4. Make use of built-in features for collaboration
  5. Provide tools as well as content


Their checklists focus on usability as well as the technical and functional aspects of the mobile learning experience - something that, as explained in the section on the importance of context, it is vital to bear in mind. The Open University do a good job of providing support to users of their mobile learning offerings through their mobile portal, learner support blog and apps page (see box to the right). Such a ‘joined up’ approach requires buy-in from across the institution, as set out in the Strategy section


The Open University's Mobile Portal, Apps page and Mobile Learner Support blog may interest and inspire those institutions getting to grips with the technical side of mobile learning.