Things are looking promising for the hosting of the 18th Century Playbills project, following some email discussions towards the end of last week and a Teams call I had with Andrew Nicolson from IT Services and Luca on Monday this week. The project will require a lot of storage space (hundreds of gigabytes) and a IIIF server and it now looks like these will be available to us. It’s likely that we will have access to a Cantaloupe IIIF server that will be centrally hosted and connected to storage for our images, which will be ideal for us.
Other than making these arrangements, I spent most of the beginning of the week testing the new interface for the Berwickshire place-names resource and fixing issues that arose. This included updating the way in which map markers are coloured when categorised by element language as previously there were too many combinations for the available colours. I’ve updated the colour schemes to use different shades for specific languages. For example, all SSE categories are shades of blue, all Gaelic categories are shades of purple. It can be difficult to differentiate the shades due to the large number of categories, but you can turn a layer on or off using the legend to quickly figure out which markers belong to which group. I’ve also ensured the ‘loading’ spinner gets displayed when the quick search is reset, as this loads in the full dataset, which takes a bit of time, and without displaying the spinner it looked like the map had broken. I’ve applied this to the other place-name maps too. I made many more minor tweaks and updates to all of the resources during my period of testing. I’m still not altogether happy with how long it takes to load the default view of the data (i.e. all place-names), which can take several seconds. Next week I may investigate how I can speed up this process, but other than this (and ensuring redirects from pages of the old resource are in place) I am ready to launch the new resource, and have sent the URL to project PI Carole Hough for feedback. Hopefully we’ll be able to launch the new resource in the coming weeks.
On Thursday this week I was due to lead a session at the DSL’s annual staff meeting about the new interface mockups I’d created for the site a few months ago. I therefore spent some time on Wednesday refamiliarising myself with the mockups and why I’d taken particular approaches. I then created a runthrough of the mockups and practised going through it a few times. However, on Wednesday evening I was informed that the meeting had been cancelled due to the storm that was due to hit Scotland on Friday morning (many attendees at the meeting were due to travel home on the Friday). This was a shame, but for the best and I hope we can rearrange the meeting for another time.
Instead of attending the DSL meeting on Thursday I spent part of the day in discussions to ascertain the status of Transkribus at Glasgow. I’m involved in a project with Joanna Kopaczyk that’s due to start soon and will be digitising and extracting text from the original materials compiled for the Dictionary of the Older Scots Tongue. Joanna and I had both heard (from different people) that Glasgow has an institutional license for Transkribus, but when investigating this I’ve been unable to find any details of such a license. This is concerning as the project was funded on the assumption that such an agreement was in place, and if we have to pay per page we’re potentially going to run into difficulties. This is especially true as in the past month Transkribus has revised their payment plans, and have halved the number of pages that can be processed for free each month, from 100 to 50. Joanna is going to investigate this further and hopefully some further details can be found.
I spent the rest of the week working for the Anglo-Norman Dictionary, replacing Twitter/X with BlueSky on the website and updating the entry page to ensure more of the cognate references (the references to similar entries in other resources) actually link through to online resources. I created a test version of the entry page so nothing is live yet, but I’ve managed to add in links to Gdf, GdfC, DEAF and DMLBS.
This has involved rewriting sections of the XSLT script that processes entries for display and the JavaScript that reworks the links once the entry has been loaded into the browser. The XSLT was previously set to only process cogrefs that had their ‘linkable’ attribute set to ‘yes’ in the XML, e.g.
<FEW_refs siglum="FEW" linkable="yes"> <link_form>discipulus</link_form><link_loc>3,92a</link_loc> </FEW_refs>
I’ve had to change this to ensure the previously unlinked cogrefs do now get linked, e.g.
<Gdf_refs siglum="Gdf" linkable="no"> <link_form>disciple</link_form><link_loc>2,718a</link_loc> </Gdf_refs>
The XSLT now no longer looks at the ‘linkable’ attribute at all, as otherwise we’d have to update every entry XML file to set linkable to ‘yes’ for every cogref like the one above. Instead the XSLT will now attempt to add in a link for all cogrefs other than ‘TL’ (the only one that is not found online), or will display ‘∅’ if there is no matching cogref entry. It is slightly unsatisfying to have an attribute that no longer gets used and we should perhaps consider doing something about this, but the issue doesn’t have a bearing on how the site functions.
For Gdf the links use the numerals where possible, which means removing non-numeric characters (e.g. ‘a’ from 718a) and subtracting one from the page number. E.g. ‘Gdf: 2,718a’ gives the link https://micmap.org/dicfro/next/dictionnaire-godefroy/717/2. Where it’s not possible to use the ‘location’ like this then the headword is used, stripped of any text in brackets. GdfC is handled in the same way as Gdf, but the page number doesn’t need altered.
For DEAF headword text is used in the link. If there is any text in brackets this is extracted and placed after a hash, for example https://deaf.hadw-bw.de/lemme/paele#paelete. Any spaces in the headword are removed so that numerals work (e.g. https://deaf.hadw-bw.de/lemme/nef2). If there are any DEAF headwords that legitimately have spaces we’ll need to consider how to deal with these.
For DMLBS the headword stripped of any bracketted text is used. Unfortunately it’s not possible (as far as I can tell) to link specifically to the DMLBS tab on the Logeion website as their website has no way to reference a specific tab, which is a shame.
Once the AND editor Geert gets back to me I’ll be able to go live with this update, which I’m sure will be very useful to a lot of users.
During last week’s advisory board meeting for the Iona project someone mentioned search engine optimisation and how the Iona site (https://iona-placenames.glasgow.ac.uk/) is generally well situated in search results. This got me thinking of how our new map-based interface would be indexed by web crawlers. While the map interface is great for humans, it will make all of the data much harder for web crawlers to index. With the older style of place-name interface all of the data was easily findable in text form on web pages, but with everything now appearing within the map interface services like Google are much less likely to be able to index our data as it’s buried in pop-ups and other JavaScript elements.
To mitigate this, I decided to create a new, purely text-based alphabetical browse of place-names. This links through to the full records on the map, but more importantly for search engines, it includes the full text of fields like the description and translation, which should be straightforward for web crawlers to find and index. When we go live with the map we’ll just need to add a link to this page to the site menu too. Here’s a screenshot of the new page:
With the new page in place (but not yet live) I then returned to the other place-name sites that I’ve also developed the new map interface for (Ayrshire, Kirkcudbrightshire and Nairnshire) to add the new textual browse page to them too. I also took the opportunity to apply some recent updates to the maps for these resources, such as adding in the new ‘help and about’ pop-up.
I then moved onto setting up the new map interface for the Berwickshire project. This was the first large-scale place-names project I was involved with, and it launched back in 2018. Thankfully it didn’t prove too tricky to set up the new interface for the project, as all subsequent place-names resources are based on the same architecture as this site. I did need to set up a new version of the API, and the new map-based resource currently doesn’t have the map icons of the existing Berwickshire map, as we dropped these from all subsequent projects. There is also an issue when categorising the map markers for the full dataset by element language, as there are so many combinations of elements and not enough colours to apply to these. I’ll need to further investigate this, but on the whole the new interface is working pretty well, and also incorporates the LiDAR data, as the following screenshot demonstrates:
On Thursday I had a meeting with Matthew Creasy to discuss a potential new project about the poems of Mallarmé. We had a good chat and afterwards I spent quite a bit of time writing up my notes and thinking about how the resource would work. I sent the resulting document to Matthew and I’ll just need to see whether anything comes of this.
This took up quite a bit of time on Friday, and I spent the remainder in discussions with various people to get the required space for Deven Parker’s 18th century playbills project. It’s looking like this might be possible now and I’ll be following this up next week.
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.