RIIL Small Projects 2019/20 – Mobile Learning Summer Project Summary Report

Project Lead: Dr Layal Hakim

Project Team: Sarah Henderson

Our Aims: (Taken from application for funding)

The project aims to create a mobile application to initially use to build a platform for student to learn and revise “on the go”. Mobile learning (M-learning) is not a virtual library, nor is it a means to replace lectures. It is intended to complement lectures/seminars and harmonises learning techniques by using mobile applications (e.g. using phones, PDAs, tablets). As students become increasingly technophilic, the digital revolution becomes an integral part of education. M-learning is not shifting from PCs to phones, it is a way of extending the hierarchy of learning facilities. M-learning offers new ways for lecturers to deliver material, new ways for students to revise independently and with their peers, and integrates learning into their daily lives. After creating a mobile application, we will integrate various components such as module/chapter summaries, flashcards, personal photo storage (such as photos taken in lectures), peer-to-peer interaction, upcoming lecture plans, feedback tool, as well as other ways to improve student engagement. Initially, we will incorporate material for the Stage 1 modules, and depending on time, we will expand it to other stage modules too. We will continuously monitor engagement and success, and seek ways to improve the application according to student responses.

Summary of Progress:

Before we started creating the application, we spend roughly 4-5 days looking into different platforms we could use to build it, as well as creating a rough outline of what we wanted the initial app to do. We were aware that we had a limited amount of time, and so wanted to get something up and running that demonstrated how it fulfilled an otherwise unexplored niche in student’s learning, whilst being mindful that we would not have enough time to do everything we would ideally want to accomplish.

The first decision we made was which language we wanted to write the program in. As this project needed to serve all those within the college, we settled on using the language ‘dart’, which we ran via flutter. This is a newer language and is serviced by google. It bears similarities to java and is object orientated, and so was easy enough for me to quickly pick up and learn to a level where I could start programming with it the following week. The main benefit however, is that using flutter allowed us to write one code which would run on both android and IOS, and so we would not need to replicate or rewrite the code in order for it to work on different operating systems, and so different phones. Flutter also allows you to run a simulated phone which you can use on your computer as you go to test out the app, and allows you to make changes to the aesthetics as you run it, reloading it very quickly.

Now we had decided on using flutter, we wanted to look at the general layout of the app, allowing us to build a framework which we could adapt and work off of as we progressed.

Our first thoughts were about splitting the app up into modules, but we were aware that we would potentially want to expand beyond just maths modules, and eventually incorporate modules from other areas of CEMPS, so instead we opted to list topics, as there is overlap between courses, with some engineering courses using maths topics etc… This also allows the user to scroll through by topic:

Once we had this, we could then start adding in function to the app, so we decided that each topic button would take the user to another page, where we would list options of how they could revise the topic. We started with definitions as this is what is often deemed most important when it comes to revising mathematics, as you can’t do much if you don’t know what the words mean. We considered just taking the user straight to the definitions, but by implementing this intermediary page, it will allow us to add more possible functions of the app, such as multiple choice questions where students can identify the correct definition, or even FAQs which can be submitted by lecturers on common questions they are asked about the topic.

Upon pressing the definitions button, we are then taken to another page which lists all the relevant definitions for that topic, as provided by the lecture material. When you click on the term you want, it will show a screen, giving the term and the definition. We made this screen have a non-white background colour as it is often said to help people learn and retain information, and it is also in contrast to the rest of the app, so it is clear that it is the definition. This also means it should be slightly easier for those with Dyslexia to read the definition, as it is not black text on a white background.

In terms of storing the definitions, we looked into different types of database, as well as coding it directly into the app, and we settled on the latter for the following reasons:

  • Using a server database would mean that while we could update definitions on the database, and it would be automatically updated in the app, it is unlikely there will need to be much updating, as the definitions will not be changing much. If the definitions of standard terms are drastically changing, mathematics as a whole has a bigger problem than this app.
  • We are not asking the user to input their own data, so we do not need to store anything
  • Having the definitions inside the app means that a Wi-Fi signal will not be necessary to use the app, which means students will have access to the material wherever they are, including on public transport or if their phone is having problems connecting.

Once we had settled on this, we then started writing the text into the code. Flutter reads Unicode, so I made a sheet with the symbols that might be used and their associated Unicode numbers (which uses hexadecimal), and wrote the definitions in the following way:

Inputting the definitions and creating the UI took some time as it was a new language, and so there were of course a few times where I had to research how to do something or try and fix a bug that was throwing the code. I also tried a few different methods of laying out the app to try and work out which was the best method. I did however store all the definitions in separate functions, so they can be called from wherever they are needed in the code.

We also wanted to consider putting some sort of password on the app, as it would be available on the app store, but we would want to try and limit it to only Exeter students that can use it. We considered using individual logins, but this would require potentially huge amounts of storage and could also raise more data privacy concerns, plus it would lose the aspect of being readily available on the go. Therefore, our idea was that we would have one password for the whole app, that could be changed each term that the college would be notified of, for example, by email or a notice in the Harrison building. This way there is one password that is kept in the app, and which is easily changed each term. The password is set in the first few lines of code in the main file in the program, and is clearly labelled, with a comment explicitly stating what it is. Once we set the password, we then created a password page that opens upon launching the app. It prompts the user to enter a password, and if it is not correct, just wipes the textbox, and if it is correct, loads the topics page:

I set the password to ‘mathsisfun’ to start with, but that was just for my own entertainment. It is a string, and so can take other forms.

Short Summary:

As it currently stands, after a 4 week project, the app has a working user interface and the definitions for 2 topics entered into it, plus a password page and standard code which can be used to replicate and adapt current definition pages to new pages to enter more definitions. It is not connected to a database because is a relatively small app and we wanted it to be self-contained. There is one password for the app, and so no user logins. Our aim for the app development was for it to be primarily based on revision, without replicating already available resources on VLE, which is what we feel we have begun to create.

Ideas for Potential Expansion:

  • Adding more definitions to cover all the remaining year 1 maths topics, and eventually to cover all the maths topics and potentially topics in other disciplines in CEMPS
  • Multiple choice questions to test student’s knowledge of the definitions. These can be made to be more difficult and though provoking, such as:

Question: What is the definition of an exponential function?

  1. An exponential function is one of the form f: ℝ → ℝ such that f(x) = ax where a is a strictly non-negative constant.
  2. An exponential function is one of the form f: ℝ → ℝ such that f(x) = ax where a is a strictly positive constant.
  3. FAQs from lecturers who teach the topic, so that common questions are explained in the app, so students can check there first if they want to know something and are shy / afraid of asking.
  4. Tagging the topics with associated modules, and then adding a search function, so students can search for all the topics in a particular module.
  5. Mind-map summary of what the student needs to know about a topic.

Incubator RIIL

uoeeduinc View All →

The University of Exeter’s Education Incubator scheme. Promoting pedagogic innovation and collaboration with an aim to enhance learning across the University and beyond.

1 Comment Leave a comment

Leave a Reply to Dr Karen KennyCancel reply

Discover more from The Education Incubator Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading