I spent the majority of the week continuing to work on the Speak For Yersel resource, working through a lengthy document of outstanding tasks that need to be completed before the site is launched in September. First up was the output for the ‘Where do you think is speaker is from’ click activity. The page features some explanatory text and a drop-down through which you can select a speaker. When this is clicked on the user is presented with the option to play the audio file and can view the transcript.
I decided to make the transcript chunks visible with a green background that’s slightly different from the colour of the main area. I thought it would be useful for people to be able to tell which of the ‘bigger’ words was part of which section, as it may well be that the word that caused a user to ‘click’ a section is not the word that we’ve picked for the section. For example, in the Glasgow transcript ‘water’ is the chosen word for one section but I personally I clicked this section because ‘hands’ was pronounced ‘honds’. Another reason to make the chunks visible is because I’ve managed to set up the transcript to highlight the appropriate section as the audio plays. Currently the section that is playing is highlighted in white and this really helps to get your eye in whilst listening to the audio.
In terms of resizing the ‘bigger’ words, I chose the following as a starting point: Less than 5% of the clicks: word is bold but not bigger (default font size for the transcript area is currently 16pt); 5-9%: 20pt; 10-14%: 25pt; 15-19%: 30pt; 20-29%: 35pt; 30-49%: 40pt; 50-74%: 45pt; 75% or more: 50pt.
I’ve also given the ‘bigger’ word a tooltip that displays the percentage of clicks responsible for its size as I thought this might be useful for people to see. We will need to change the text, though. Currently it says something like ‘15% of respondents clicked in this section’ but it’s actually ‘15% of all clicks for this transcript were made in this section’ which is a different thing, but I’m not sure how best to phrase it. Where there is a pop-up for a word it appears in the blue font and the pop-up text contains the text that the team has specified. Where the pop-up word is also the ‘bigger’ word (most but not always the case) then the percentage text also appears in the popup, below the text. Here’s a screenshot of how the feature currently looks:
I then moved onto the ‘I would never say that’ activities. This is a two-part activity, with the first part involving the user dragging and dropping sentences into either a ‘used in Scots’ or ‘isn’t used in Scots’ column and then checking their answers. The second part has the user translating a Scots sentence into Standard English by dragging and dropping possible words into a sentence area. My first task was to format the data used for the activity, which involved creating a suitable data structure in JSON and then migrating all of the data into this structure from a Word document. With this in place I then began to create the front-end. I’d created similar drag and drop features before (including for another section of the current resource) and therefore used the same technologies: The jQuery UI drag and drop library (https://jqueryui.com/draggable/). This allowed me to set up two areas where buttons could be dropped and then create a list of buttons that could be dragged. I then had to work on the logic for evaluating the user’s answers. This involved keeping a tally of the number of buttons that had been dropped into one or other of the boxes (which also had to take into consideration that the user can drop a button back in the original list) and when every button has been placed in a column a ‘check answers’ button appears. On pressing, the code then fixes the draggable buttons in place and compares the user’s answers with the correct answers, adding a ‘tick’ or ‘cross’ to each button and giving an overall score in the middle. There are multiple stages to this activity so I also had to work on the logic for loading a new set of sentences with their own introductory text, or moving onto part two of the activity if required. Below is a screenshot of part 1 with some of the buttons dragged and dropped:
Part two of the activity involved creating a sentence by choosing words to add. The original plan was to have the user click on a word to add it to the sentence, or click on the word in the sentence to remove it if required. I figured that using a drag and drop method and enabling the user to move words around the sentence after they have dropped them if required would be more flexible and would fit in better with the other activities in the site. I was just going to use the same drag and drop library that I’d used for part one, but then I spotted a further jQuery interaction called sortable that allowed for connected lists (https://jqueryui.com/sortable/#connect-lists). This allowed items within a list to be sortable, but also for items to be dragged and dropped from one list to another. This sounded like the ideal solution, so I set about investigating its usage.
It took some time to style the activity to ensure that empty lists were still given space on the screen, and to ensure the word button layout worked properly, but after that the ‘sentence builder’ feature worked very well – the user could move words between the sentence area and the ‘list of possible words’ area and rearrange their order as required. I set up the code to ensure a ‘check answers’ button appeared when at least one word had been added to the sentence (disappearing again if the user removes all words). When the ‘check answers’ button is pressed the code grabs the content of the buttons in the sentence area in the order the buttons have been added and creates a sentence from the text. It then compares this to one of the correct sentences (of which there may be more than one). If the answer is correct a ‘tick’ is added after the sentence and if it’s wrong a ‘cross’ is added. If there are multiple correct answers the other correct possibilities are displayed, and if the answer was wrong all correct answers are displayed. Then it’s on to the next sentence, or the final evaluation. Here’s a screenshot of part 2 with some words dragged and dropped:
Whilst working on part two it became clear that the ‘sortable’ solution I’d developed for part 2 worked better than the other draggable method I’d used for part one. This is because the ‘sortable’ solution uses HTML lists and ‘snaps’ each item into place whereas the previous method just leaves the draggable item wherever the user drops it (so long as it’s in the confines of the droppable box). This means things can look a bit messy. I therefore revisited part 1 and replaced the method. This took a bit of time to implement as I had to rework a lot of the logic, but I think it was worth it.
Also this week I spent a bit of time working for the Dictionaries of the Scots Language. I had a conversation with Pauline Graham about the workflow for updates to the online data. I also investigated a couple of issues with entries for Ann Fergusson. One entry (sleesh) wasn’t loading as there were spaces in the entry’s ‘slug’. Spaces in URLs can cause issues and this is what was happening with this entry. I updated the URL information in the database so that ‘sleesh_n1 and v’ has been changed to ‘sleesh_n1_and_v’ and this has fixed the issue. I also updated the XML in the online system so the first URL is now <url>sleesh_n1_and_v</url>. I checked the online database and thankfully no other entries have a space in their ‘slug’ so this issue doesn’t affect anything else. The second issue related to an entry that doesn’t appear in the online database. It was not in the data I was sent and wasn’t present in several previous versions of the data, so in this case something must have happened prior to the data getting sent to me. I also had a conversation about the appearance of yogh characters in the site.
I also did a bit more work for the Books and Borrowing project this week. I added two further library registers from the NLS to our system. This means there should now only be one further register to come from the NLS, which is quite a relief as each register takes some time to process. I also finally got round to processing the four registers for St Andrews, which had been on my ‘to do’ list since late July. It was very tricky to rename the images into a format that we can use on the server because the lack of trailing zeros meant a script to batch process the images loaded them in the wrong order. The was made worse because rather than just being numbered sequentially the image filenames were further split into ‘parts’. For example, the images beginning ‘UYLY 207 11 Receipt book part 11’ were being processed before images beginning ‘UYLY 207 11 Receipt book part 2’ as programming languages when ordering strings consider 11, 12 etc to come before 2. This was also then happening within each ‘part’, e.g. ‘UYLY207 15 part 43_11.jpg’ was coming before ‘UYLY207 15 part 43_2.jpg’. It took most of the morning to sort this out, but I was then able to upload the images to the server and I create new registers, generate pages and associate images for the two new registers (207-11 and 207-15).
However, the other two registers already exist in the CMS as page records with associated borrowing records. Each image of the register is an open spread showing two borrowing pages and we had previously decided that I should run a script to merge pages in the CMS and then associate the merged record with one of the page images. However, I’m afraid this is going to need some manual intervention. Looking at the images for 206-1 and comparing them to the existing page records for this register, it’s clear that there are many blank pages in the two-page spreads that have not been replicated in the CMS. For example, page 164 in the CMS is for ‘Profr Spens’. The corresponding image (in my renamed images) is ‘UYLY206-1_00000084.jpg’. The data is on the right-hand page and the left-hand page is blank. But in the CMS the preceding page is for ‘Prof. Brown’, which is on the left-hand page of the preceding image. If I attempted to automatically merge these two page records into one this would therefore result in an error.
I’m afraid what I need is for someone who is familiar with the data to look through the images and the pages and create a spreadsheet noting which pages correspond to which image. Where multiple pages correspond to one page I can then merge the records. So for example: Pages 159 (id 1087) and 160 (ID 1088) are found on image UYLY206-1_00000082.jpg. Page 161 (1089) corresponds to UYLY206-1_00000083.jpg. The next page in the CMS is 164 (1090) and this corresponds to UYLY206-1_00000084.jpg. So a spreadsheet could have two columns:
Page ID Image
Also, the page numbers in the CMS don’t tally with the handwritten page numbers in the images (e.g. the page record 1089 mentioned above has page 161 but the image has page number 162 written on it). And actually, the page numbers would need to include two pages, e.g. 162-163. Ideally whoever is going to manually create the spreadsheet could add new page numbers as a further column and I could then fix these when I process the spreadsheet too. This task is still very much in progress.
Also for the project this week I created a ‘full screen’ version of the Chambers map that will be pulled into an iframe on the Edinburgh University Library website when they create an online exhibition based on our resource.
Finally this week I helped out Sofia from the Iona Place-names project who as luck would have it was also wanting help with embedding a map in an iframe. As I’d already done some investigation about this very issue for the Chambers map I was able to easily set this up for Sofia.