WHY DID WE WANT ONE?

The sister-site of City University's legal portal Lawbore, is Learnmore and this resource acts as a support tool for students new to law who need guidance on legal skills. Split into 6 categories (Mooting, Legal Writing, Exams, Newbies, Research and Careers) Learnmore contains a range of different multimedia from basic text-based articles to talking slideshows and videos.

Whilst Learnmore has been extremely well received by studentsFootnote ⁴, it has always been a frustration that we couldn't embed any real interaction opportunities within the site. Yes, students can read, listen and watch the materials found within but the ‘doing’ part of learning is missing. Apps give us a real opportunity to change this. We were really excited about the manner in which we would be able to get students to connect with the materials more, and the possible quiz-type activities we'd be able to incorporate.

There are other commercial reasons of course; there is substantial marketing potential in creating something unique, and higher visibility would mean more attention for what we're doing, more users of our materials and more students aware of what City University does. For our existing students it would also be beneficial to demonstrate we're doing something that no-one else is and to demonstrate our unique style of getting the students to learn basic legal skills.

An app isn't the only option of course; creating a version of the website specifically for mobile devices was one alternative solution. However we weren't as keen on this for a variety of reasons: users would still need to download content, you couldn't access materials without an internet signal and the potential ‘buzz’ around the product would be less easy to generate. We wanted students to be able to access Learnmore via their mobile device wherever they were. Traxler (2010)Footnote ⁵ muses on the differences in education between accessing materials on a fixed computer and via devices: ‘using desktop technology takes place in a bubble – in dedicated times and places’…whereas interaction with mobile technologies is ‘woven into all times and places and students’ lives'.

HOW DID WE GET STARTED?

We thought about how to make our vision of interactive resources come to life by thinking about what we could do if there were no technical limitations to our design. We spent some time researching different apps and thinking about how developers have employed the various functions available to them to make their app work. We considered how we could use functions like swiping, pinching and tapping and incorporate them into our app ensuring it is engaging to the users. This research led to us to locking ourselves away for a few days and mind mapping how we would like to develop each sub-category in each of the six areas, as well as thinking about how we would make the resources interactive, taking examples from our research of apps. We then developed these mind maps into our storyboards. We drew up each frame and illustrated how each frame would develop into the next, what interactive functions would be employed in each section and what we were hoping the user would achieve. We had the very difficult task of explaining our hand drawn storyboards to our developer who was tasked with making this app come to life.

Conveying our designs and our ideas to a developer was not an easy task as we began to realise that some of our ideas, as good as they were, simply were not suitable or adaptable for an app. We learnt and maintained the golden rule to app building which is ‘keep it simple’. Initially, we had thought about developing the Learnmore website into an app for mobile phones but through discussions with our developer, we came to understand that when dealing with resources which may be text heavy or require a high level of interaction, a larger screen such as that on an iPad, would be far more suitable, simpler and user-friendly than smart phone like an iPhone.

Figure 1: Learnmore

SECURING THE FUNDING

With Dr George Buchanan from City's Department of Human Computer Interaction and Design (part of the School of Informatics), we submitted an application for some JISC grant funding under the Mobile Library stream – Mobile Library C1 – Developing mobile library content Footnote ⁶, with an application deadline of September 2011. This call asked for projects to undertake the development of prototypes for the delivery of scholarly content suitable for delivery to a range of mobile devices. Two additional things were made clear by the call; that they were interested in multimedia resources within any resource and that no new content should be created as part of the project, but existing content should be re-purposed.

We were very excited to be awarded the grant; which would pay for a developer's time for 5 months and various other bits of equipment.

WHO WAS INVOLVED?

We were fortunate enough to secure the services of Sam Muscroft to develop our app. Sam came recommended by our colleague George Buchanan who had some experience of working with him in the past. Sam patiently listened to our ideas and took the time to get to know the Learnmore website before he began the development process. It was crucial for us to be on the same page about how the app should and could develop. What is more, regular communication between us and Sam was crucial to ensure that time was used efficiently and each area for each category was developing how we had envisaged whilst making necessary compromises along the way; George was directly responsible for managing Sam.

DEVELOPMENT PROCESS

In terms of how the app developed this was a little of a surprise to us. We realized that something that made perfect sense in our storyboards perhaps did not make sense to others including our developer! This was an important wake-up call to us. If something that we thought was well-designed, at least on paper, could not be understood by our developer, how will the students use it? We then decided to tackle developing the app into its component parts. On the advice of Sam, we viewed the project in three stages. The first was the media content and how that needed to be prepared. The second was the functions that we intended to use, how they might be used and where. The third was how each of the six categories would come together and flow.

At its most detailed we worked on the different type of media that needed to be developed and attempted to overcome any obstacles that this threw up, such as video having originally been developed with Flash payer or needing to improve the quality of voice recordings. We had originally worked on planning the app according to each of the different six categories that we had developed rather than different types of media across the apps although now we understand why working on the media content was a more efficient way of working. Once all of the media aspects of the app were prepared we went back to looking at the different functions that we wanted to use on the app.

Sam developed a prototype of the swipe function and demonstrated how each of the six sections would integrate. Using this prototype we were able to evaluate and confirm the design and move forward with the development of the rest of the app.

CHALLENGES

As with any project involving more than one person, difficulties can arise and some of these cannot be put into writing. However here are a few of the issues we had to find solutions for over the course of development:

• Team – What was difficult is that Professor Buchanan managed the developer; this meant that although we would have occasional meetings and ad hoc ‘let's discuss this issue’ drop-ins, we had no power to be able to influence work direction. We initiated all meetings, which was also difficult.

• Other demands on time – Clearly December to June is not the quietest time of the year and Sanmeet found juggling her teaching, marking, research and role as Assessments Officer with the development of the app, challenging. Emily had to move her entire library over Easter to another location (prior to a final move in December 2012 to our new Law building), and the preparation for this temporary 9-month decant was massively time-consuming. Our new temporary home was substantially smaller, and had the added complication of a swimming pool under the floor which meant any shelves could only be placed round the outside of the room. We both found it very difficult to keep on track with the app when so much else was going on.

• Drawing on the new and old – Learnmore on the web has a very distinctive ‘look’ thanks to a series of hand-drawn images custom-made for us by an American illustrator. One of the biggest decisions we had to make was to stray away from this design. Sam, the developer, felt that the slickness and simplicity required from an app meant these were too fussy for the platform. This was hard to accept at first as we felt that these illustrations were part of what defined the Learnmore brand. However we did come around to his way of thinking and Emily set about finding new photographic images from flickr to work as the new navigation. We ended up using some of the old images as a watermark in the background of the screen.

• Information architecture – The Learnmore website had become unwieldy; the existing wiki structure meant that we were tied to just the six categories and then no sub-categorisation within these. The larger the number of resources within them, the less easy it was to find what you needed. We didn't want this to be the case within the app, and so needed to re-categorise all content into new areas. Another issue was that the website had videos on only three separate pages (Top tips, Mooting Video Guide and Hear it from the students) simply as a result of when we recorded them, we needed to split every single video clip into more meaningful categories and link them together.

• Design – The biggest issue here has already been covered in the New v Old section. We had to take a new approach with the app; it needed to be paired down and uncluttered.

• Formats – The resources on the Learnmore website were in a variety of formats: text-based articles with accompanying images, video clips in .flv, documents in pdf and talking slideshows made in Adobe Presenter (Flash-based). As is widely recognised, Flash and Apple are not happy bedfellows: we needed to come up with a non-proprietary alternative for the slideshows.

  Our developer created a custom solution where we could add the PowerPoint presentation as separate jpgs of the slides and the audio (which we had to re-record). Notes of the audio were provided separately as a text file.

  All the video material needed to be converted into mp4 format and any accompanying commentary to the clip written within a simple text file.

  Articles needed to be coded up in simple html.

• Transition – Ultra important was how our users would move about the app: how would the slides move from one to the next? How could you skip from one video to another related clip? The iPad swipe would be exploited here; we wanted to be able to navigate both through content on the right with an easy swipe as well as down the left-hand navigation.

• Conflicting visions and recognition of differences between app and web – We have already hinted at this in previous challenges, but it was a mindset that we had to shift. Where a site has a character it is very difficult to put this to one side and opt for a less visually exciting design. We took on board the research of Jones and Marsden (2005)Footnote ⁷ who warn of transferring what's on the web onto a ‘mobile device with a revised interface’, demonstrating that low usability usually follows.

Figure 2: Lawbore

Figure 3: An emphasis on interactivity…

INTERACTIVITY

This emphasis on interactivity goes from the smallest detail to the more obvious interaction tools such as quizzes. Exploiting the swiping and pinching elements of the iOS functionality was important, and we've been able to make all content work together in a dynamic way via these simple gestures. It means that the user isn't limited to using a menu structure but can move between different types of content (videos, articles, quizzes) via the swipe. Slideshows can just be swiped to move between slides, tapping for the accompanying notes. Videos can be pinched apart to enlarge to full screen.

The quizzes are the more complex part of this; what was lacking on the site was any way for students to test their knowledge and this was an obvious way to ensure self-assessment and activity, as well as increasing the interaction. Quizzes in the first version of the app will largely involve a question being asked and a selection of responses flagged up for the user to choose from by dragging and dropping into a certain area of the screen. These will range from simple text-based styles to examples using audio or images.

Figure 4: Moot Quiz

Examples we have up and running in the pilot include a Moot Glossary (definition at top of screen and various related words at the bottom, user selects the matching word and drags it into the answer box), and a Dealing with Moot Judges quiz (Advice for dealing with particular moot judge at top of screen and the picture/label of judge at bottom, again the user selects the right judge and drags into answer box).

There is silly content too – not everything is deathly serious. We have a quiz in development around what items a student can take into exams, something which everyone panics about at a particular time of year. On the screen students will see a desk and a bin as well as a variety of objects which they must drag into the right location.

WHAT'S NEXT?

We need to work on further activity-based content – the app needs to offer something different to the website. We see the app as somewhere students can gain familiarity with legal resources, and make even more use of different types of media to learn. We're looking at using drag and drop to get students learning anatomy of the case, as well as to highlight errors within skeleton arguments. We're hoping to use various audio recordings to get students identifying the best way to refer to an authority in court.

A big improvement for the future will be simplification of the content management. At present any updating is quite a fiddly process and cannot be done remotely.

We would like to pay more attention to the content types too in later development; this would involve flagging up both the types of media via use of an icon, but also the type of interaction involved.

Making versions of the app for other platforms would be desirable but expensive. Clearly having an app that worked for both iPhone and Android/Blackberry would be the ideal, but at present we can't see where the money for this development would come from.

Developing this app has really made us think hard about the resources we create and the value we seek to add. Simplicity is our new guiding principle, though I doubt we shall be morphing into minimalists any day soon.