I was working on Monday the 23rd of December and then returned to work on Monday the 6th of January. I spent my final day before Christmas working on a mockup of the new ‘lookup’ resource for the VARICS project. This will allow speech therapists to submit readings relating to a patient and see how these compare with broader data collected by the project. My initial work involved setting up the database tables to hold the data on measurements, importing this data and setting up an interface through which users can browse and select the measurement they’re interested in. Once a measurement is selected a measurement form loads, which in my initial version displayed some default fields – age, sex and measurement value. In the version I created before Christmas upon submitting the form the inputted values were merely displayed and no actual calculations were made.
When I returned to work this week I continued to work on this mockup, setting up the system that would analyse the data the user submitted and displaying a ‘traffic light’ coding system to inform speech therapists about how their measurement compares to the project’s dataset. I’d been given sample data for three measurements: ‘s duration’, ‘z duration’ and ‘a duration’, with measurements available for each of the seven age bands. As of yet this data is not further broken down by sex, so the ‘Sex’ option in the form is not yet functioning. I wasn’t sure exactly how these measurements relate to the previous list I was given and I therefore made three new test measurements in the ‘Phonation’ section, each with ‘(test)’ after them, and for now these are the only three measurements that are operational.
I also updated the measurement database to include new fields for storing a description of the measurement, a name for the measurement’s input (e.g. ‘Duration (sec)’) and some help text that is used as a tooltip for the measurement. These fields have test data for the three test measurements, with the other measurements displaying defaults (e.g. ‘Measurement’ rather than ‘Duration (sec)’). I also updated the input form to add in tooltips for each field, although these still require some actual text rather than the current placeholders.
When the form is submitted the code checks that the supplied age is in range and the duration given is a number. As our age bands are years only the figure given before the semi-colon is actually required – e.g. if ‘5;3’ is given then this is in the ‘5’ age band and the ‘3’ isn’t actually needed. For now there is no check that anything after the semi-colon is valid, but I can change this. As the age bands we use are years I suggested to the team that we could maybe just have a drop-down list of years rather than allowing free-text entry – e.g. ‘5;0-5;11’, ‘6;0-6;11’. This would cut down on the possibility of user error.
If the supplied age is valid and the measurement is a number then the code finds the data for the age band for the selected measurement in the database and compares the given measurement to the ‘sd 1.5 below’ and ‘sd 2 below’ fields. Anything above (or equal to) ‘sd 1.5 below’ is assigned green, anything below ‘sd 1.5 below’ and above (or equal to) ‘sd 2 below’ is assigned amber and anything below ‘sd 2 below’ is assigned red.
The output displays the information the user submitted and displays a traffic light colour depending on the colour that has been assigned. For now I’ve used an image of a traffic light that I’ve adapted from a photo that is free to use (https://www.freeimages.com/photo/traffic-light-1316690), but depending on what the team thinks, this might be changed to a plain coloured circle or another image. One thing I realised is that these images on their own are not going to be very helpful for any colourblind users: red and amber can be difficult to distinguish and distinctions between red and green are a known issue for colourblind people. I therefore added the colour as text underneath the image, and I also created an alternative view that displays all three lights with the appropriate one lit up and the others dark, as the position of the lit-up light is a useful means of ascertaining the colour. These are just initial ideas, though, and may change.
To the right of the traffic light I placed some text explaining how the colour rating was derived. This is currently in narrative form and includes the number of participants, the age band, a breakdown of sex and text about additional needs. The average duration is also included. Finally, I included the remaining data for the age band in a section beneath this as I thought it would be useful for the team to see all of the data we have (e.g. the standard deviation). It’s possible we might want some of this to appear in the explanatory text.
The screenshot below shows the complete output for one submission. Note that on mobile phones the traffic light and the explanatory text always remain side by side, meaning the image can end up rather small on some devices. Depending on feedback I may change this so that on narrow screens the traffic light appears above the text, with image and text each taking up the full width.
I still need to add in the option to download the output as a PDF, but I’ll probably hold off on this until we’ve finalised the layout. We also need to consider whether we want to store the submissions that users make. Currently nothing is logged, but it could be useful to keep a record of the ages and measurements for future use. If we decide to do this we’ll need to make it clear to users that we’re doing so, and presumably it would then be useful to make users manually enter the exact age rather than choosing a year band as I suggested above. I’ll need to wait until the team get back to me with feedback and more data before I take this any further.
On Thursday I attended the advisory board meeting for the Place-names of Iona project, at which the map-based interface I’d developed was being demonstrated. I was only informed that this meeting was taking place two days beforehand, so I had to spend some time ensuring the interface was working properly. Someone else was leading the demonstration of the resource so thankfully I didn’t need to prepare for this, but there were some issues with the interface that I needed to update and fix.
The PI Thomas wanted a new ‘Help and about’ section to be added to the resource so I added this in as a large popup in the same way as the ‘Attribution’ information appears. I also spotted that some searches and browses were not working with the version of the interface I’d created last month that incorporated other updates and fixes taken from the Ayr map. I spent some time the day before the meeting investigating these. They were occurring because the Iona site is on a different server to the other place-names resources and there was an inconsistency with how null values were being handled by the server – specifically whether ‘null’ and ‘0’ are the same thing. The other sites are hosted via our external hosting supplier, and nulls in AJAX URLs were being blocked by a security setting so I replaced them with zeros. But Iona is hosted on our local server and on this one the zeros were causing problems so I needed to reinstate the nulls. After doing so I went through all of the parts of the map and everything was working. The meeting on Thursday lasted all afternoon and the demonstration went well, with some helpful feedback being given.
Also this week I added some new data to the interactive map of Burns Suppers (https://burnsc21.glasgow.ac.uk/supper-map/) and made some updates to the interactive map of the correspondence of Robert Burns, which has not yet been publicly launched. The map now defaults to only showing correspondence in the ‘Personal and Domestic’ category in an attempt to speed up the map on slower devices. It took a while to set up this category as the default view, and hopefully it will make a difference.
I also made a few fixes to the Anglo-Norman Dictionary’s textbase that the editor Geert had contacted me about, and had a chat with him about further updates that we’ll implement in the new year.