Week beginning 18th November 2013

With the big relaunches of the Historical Thesaurus and SCOTS out of the way last week, I returned to some of the other outstanding items on my long-term ‘to do’ list and decided specifically to focus on updating the Grammar app.  A few weeks ago Marc’s Course 20 students tested out the three STELLA apps that I have created and posted their feedback on the course’s Moodle page.  There was some very useful feedback, and a recurring theme was that navigation between the exercises and the ‘book’ pages could be better.  I was aware myself that this was something of a weak spot in the app – if you are midway through answering an exercise but need help and go to the book pages then your progress in the exercise (and all previous exercises) is lost when you navigate away from the exercise page.

As I mentioned in a previous post, I have been investigating HTML5’s ‘Local Storage’ facilities – basically the next generation of client-side storage that replaces cookies.  Local Storage allows a web page to store any number of ‘key/value’ pairs on the user’s computer (or phone) that can then be reloaded whenever the user returns to the page.  This very simple mechanism greatly enhances client-side applications by essentially allowing client-side scripts to have a client-side database.

My plan was to use HTML5 Local Storage to store a user’s exercise answers so that these could be reloaded and used to repopulate the exercise whenever the user returned to the exercise in question – either after navigating to the ‘book’ part of the app or after closing the app and opening it another time.  Firstly I added a very simple local storage check – storing the name of the exercise page the user is currently viewing and then checking for this when a ‘book’ page is loaded, adding a link to the exercise page if the variable is set and thus providing a better navigation pathway between exercises and book pages.

After that was in place I started tackling the first exercise – ‘Unit 2: Parts of Speech 1’.  I had hoped to be able to store a user’s answers as an associative array (an array where the ‘key’ is text) in local storage, but I ran into some problems with this approach.  Firstly, unbeknownst to me, Javascript doesn’t actually support associative arrays as such – e.g. answers[‘answer-id-1’] = ‘Aj’ doesn’t actually give you an array that you can use array functions on.  You have to use objects instead – e.g. answers{“answer-id-1”:”Aj”}.

Secondly, HTML5 Local Storage only allows you to store key/value pairs and the value can only be a string – i.e. plain text rather than a Javascript array or object.  However, once I discovered this it turned out to not be such a problem – my Javascript objects (by their very nature) were stored in the JSON format and the JSON functions of Javascript include a handy function called ‘stringify’ which turns any JSON object into a string, which can then be stored using local storage.  This can then be retrieved using the ‘JSON.parse’ function, converting the string to proper Javascript objects for reuse in a script again.

I managed to get the first exercise working with local storage as a proof of concept.  Whenever a user selected a part of speech this saved the selected value.  Whenever the page was reloaded the script then checked for any saved values and used these to populate the answer boxes.  It worked pretty nicely.  However, I began to realise just what a mess the code for the exercises was.  When previously developing the exercises I was really just getting to grips with using Javascript for such a relatively complicated task, and I approached each exercise individually, tailoring the code for the specific exercise and saving it as a separate file.  This meant that there was a lot of code repetition, which is never a good thing.  I was also storing a lot of HTML snippets for the answer boxes etc within Javascript variables, which was also not so good as these could instead be generated.  The data for each exercise was also spread across a variety of different variables and structures – sentences here, answers there, notes somewhere else etc.  I decided I should really rationalise things so I went back to the drawing board and started designing the exercise Javascript afresh.

Each exercise would be stored as a Javascript object and loaded from a JSON file.  Each object would contain all of the required data about the exercise – its words, the type of answer boxes required, their positions, the answers, notes, multiple stage information etc.  There would also be only one Javascript file that would process every exercise rather than individual files for each exercise and a single set of functions that would handle the common tasks of every exercise – e.g. load sentence, show answers, clear, load next sentence etc.

I spent the rest of the week developing the JSON structure and the Javascript code for handling the exercises, including the local storage discussed earlier.  By the end of the week I had the structures in place for handling all but the more complex exercises – specifically those that are not just multiple sentences but multiple stages within each sentence.  I hope to be able to finish off the redevelopment of all of the exercises early next week.