Week Beginning 16th April 2018

I continued to work on the public interface for the REELS project for a lot of this week, and by the end of the week I had managed to implement pretty much all of the features that I’d hoped to create.  The first thing I tackled was adding in different base map options.  I picked out a few other MapBox tilesets that I thought would be useful, including a map that shows relief features and contour lines, a satellite map with labels included (e.g. town and road names) and a ‘clean’ satellite map that doesn’t have any labels.  I also discovered that the NLS offers free access to OS maps from the 1920s and 30s for use as a base map so I added that in as an option too.  By default the base map switcher gets added to the ‘legend’ option that I have in the top right of my map, which for REELS features the ability to turn layers on and off.  This made the box rather long and instead I wanted to have this feature appear in the ‘Display Options’ menu that slides out from the left, where the marker categorisation options are already located.  I figured out how to make buttons to handle base map switching and it’s all working pretty well.

Previously I’d set up the map so that the tooltip labels for map markers automatically appeared at a certain zoom level, and then hid themselves again when the user zoomed out.  This worked ok, but sometimes I found the labels would get in the way when zoomed in, while at other times I wished the labels would appear when zoomed out further.  For these reasons I decided to add in an option to manually choose when labels appeared or disappeared.  I added this option as a couple of buttons to the ‘Display Options’ menu and I think it works nicely.  Here’s a screenshot of how things currently look:

During this week I encountered something that is possibly going to be an issue.  The map layers (apart from the NLS one) all use a service called mapbox.com.  This allows you to customise maps, publish them and use them in your own websites.  It’s a commercial enterprise and they offer a free tier, which allows up to 50,000 map views each month (See https://www.mapbox.com/pricing/).  I had thought this would be ample but looking at the statistics I’ve managed to accrue almost 8,000 map views so far this month just while developing the site.  This is rather worrying as it suggests we’ll very quickly exceed the 50,000 limit.  If we do there’s a cost, $0.50 per 1,000 map views.  Although this doesn’t seem like a lot we’ve no way of knowing how many users and map views we might end up getting, especially in the first few months after publication.  The project has no funds to pay for this and it’s not great for long-term sustainability either.  It means we’re probably going to have to look at alternative free map suppliers and to drop Mapbox, which is a shame.  There is a list of free map suppliers here: https://leaflet-extras.github.io/leaflet-providers/preview/ and I guess we’ll have to pick a few from this.  We still might be able to include one Mapbox layer, but probably not four different ones as we currently have.

Carole emailed me this week to say that the ‘browse historical forms by initial letter’ feature was bringing back some unexpected results.  This is because we have historical forms such as ‘6 mercatas terrarum ville de Mersintoun’, which therefore appeared under ‘6’.  What Carole wanted was for the initial letter used to be that of the italicised text, so in the previous example the name would appear under ‘M’.  I updated the database to add in a new field for storing the initial letter of the text in italics and updated the CMS so that this field was automatically populated when a historical form was added or edited and the browse feature now works as Carole was expecting.  I had also noticed that the place-name element glossary wasn’t being ordered in a properly alphabetical manner, but instead any elements that were only associated with historical forms and not current place-names were appearing below the list of current elements.  Also, where an element was associated with both current and historical forms the element was appearing twice, rather than the historical forms being added to the existing element.  Some tweaking of the API code sorted these issues out.

The next thing I tackled was allowing specific map views to be bookmarked, shared and cited.  It’s really annoying with online map resources when you can’t ‘save’ a particular map you’re interested in, because the URL in the address bar is just for the page with the map on it – saving the URL simply returns you to the default view of the map.  Thankfully there’s a way to solve this issue, using a neat little Leaflet plugin called Leaflet Hash (https://github.com/mlevans/leaflet-hash) that adds the latitude, longitude and zoom level to the page URL as part of the hash value (the part of the URL after the ‘#’ sign).  The plugin updates this value every time the user pans or zooms the map, and when a page loads with a value after the hash the plugin automatically grabs the passed data and positions the map accordingly.  It’s all very nicely done.  However, I needed to pass more than just the latitude, longitude and zoom level in the hash as I wanted other things to be ‘remembered’.  The page has a text list of results in a separate tab so I needed to keep track of whether the user was looking at the map or the text list.  I also wanted the user’s choice of base map, marker classification type and whether the labels were on or off to be tracked as well.  In order to add these things to the hash, and to ensure the plugin didn’t remove them, I needed to update the plugin’s code, which took a bit of time to do.  I also had to write some new sections that handled setting the map up with the right view, based on the contents of the hash.  But with the code in place it means that when a hash like this: ‘#14/55.8405/-2.1199/resultsTabs-0/altitude/tileRelief/labelsOn’ is passed to my code the plugin can tell the map needs to zoom to level 14 and centre on latitude / longitude 55.8405, 2.1199, and it can also tell that the map (rather than the list of results) should be visible, the markers should be classified by their altitude, the relief base map should be selected and the marker labels should be visible.

With this in place I could the create a ‘cite this view’ option, which works in the same way as the ‘cite’ option I created for the Historical Thesaurus:  The user presses a button and a pop-up opens listing the citation in three styles (APA, MLA and Chicago), plus a citation for the whole resource.  The links included will return the user (or anyone else) to the specific view that the user had on screen when they pressed the ‘cite’ button, with information in the cite text about what it is that the view contains, e.g. ‘Map of Berwickshire place-names: Quick search for ‘h_ll’, classified by start date, base map: ‘relief’, labels visible. 2018. In Recovering the Earliest English Language in Scotland: evidence from place-names. Glasgow: University of Glasgow. Retrieved 23 April 2018, from <URL Here>’.

Other than REELS work I did some other smaller bits of work.  A new version of WordPress was released this week, so I upgraded all of the WordPress sites I manage to this version.  Another bunch of University hosted sites was migrated from HTTP to HTTPS this week, so I spent some time testing out the sites I had created that had been affected.  I needed to tweak a couple, but it didn’t take long to sort things.  I also received a request to update one of the Scottish Literature bibliography pages I’d created in T4 a couple of years ago so did that, and I spent a bit of time on App account management duties, removing the details of a user who is retiring and creating a user account for some external developers that are making an ‘university guide’ app.

I also spent about a day working some more on the timelines for the Historical Thesaurus.  I think I’m just about ready to add the feature to the site (well, as a test version – not  actually making it live until it’s been properly tested and approved).  In this version the colours have been replaced by three shades of green taken from the site banner, as Marc pointed out that people might expect the different colours to mean something rather than them being arbitrary.  We’ll add colours back in once we have something to categorise, such as language of origin.  I also added in a facility to sort the timeline by length of use in addition to date and alphabetically, and changing the sort option no longer breaks the tooltips.  Also, changing back to sorted by date now orders the data as it was originally ordered rather than being slightly different (where two categories have the same start date the end date is now taken into consideration).  Finally, there is an option to save the timeline as an SVG image for use elsewhere (e.g. presentations).

I had hoped to include a nice, swish animation when reordering the timeline, with the rows moving about the place but I’ve given up on this idea for now.  This is because the timeline library I’m using (which I’ve already had to adapt quite a bit) doesn’t group the labels and the data together as one entity so it’s not possible to grab an entire row and manipulate it.  I’d have to make some big changes to the library to add this structure and it’s more trouble than it’s worth, really.

Here’s an example of how the timeline looks for the category ‘The World’, ordered by length of use, with a tooltip visible:

My next step will be to create a test version of the HT ‘category’ page with a new button next to the ‘cite’ buttons for opening the timeline, which will probably be some kind of model dialog box.  I’ll also need to investigate the mini-timelines Marc wanted to appear beside each word.