Week Beginning 14th November 2016

I spent a fair amount of time this week working on the SCOSYA project again.  We had a project meeting planned for Wednesday but unfortunately Gary had to postpone this to next week, but I decided to tackle some of the outstanding items on my ‘to do’ list of the project nonetheless.  The first thing I implemented was a ‘history’ feature for the Atlas. This was based on the ‘history’ feature I previously created for the Mapping Metaphor project, allowing you to return to a previous version of the visualisation interface that you had been looking at.  For SCOSYA, the Atlas now ‘remembers’ every search you do during a session and lists these on a ‘history’ page, allowing you to return to something you’ve previously looked at.  A history entry is logged whenever you press one of the ‘show’ buttons to change the atlas display criteria.  Changes in zoom level and map position don’t currently get logged as a new history entry.  I can add these, but I thought it would result in too much information being logged.  However, it is possible to save a snapshot of a particular position and zoom level by pressing the ‘save’ button again.  The history feature can be accessed by pressing on a ‘Browse History’ button that I have added to the bottom of the ‘Atlas display options’ panel.  The list of items shows what you’ve searched for, when you searched for it (with the most recent at the top) and includes buttons that allow you to load the search item.  There’s also a ‘clear history’ option too.

The ‘load history’ aspect took a bit of time to get working as the page content depends purely upon the data contained in the ‘hash’ of the page (the part of the URL after the ‘#’.  The things is, when anything in this part of the URL changes it doesn’t trigger a page reload, meaning pressing on the ‘load’ button didn’t actually do anything.  I investigated just refreshing the page content on the client side when the ‘load’ button was pressed, but I already had a lot of code in place to load the data on initial page load based on the values passed in the hash (not just loading the data but prepopulating all of the search boxes) so I thought it would be simpler just to trigger all of this rather than write something new.  It turned out to be pretty easy to trigger a full page load.  First of all I updated the hash with the new value from the ‘load’ button’s ‘href’ attribute using ‘location.replace’ and then I reloaded the page using ‘location.reload’.

The last SCOSYA item on my ‘to do’ list for the atlas was to add the code descriptions to the atlas.  The atlas display options slide-out for the atlas has a series of drop-down lists for selecting one or more attribute codes.  We wanted to ensure descriptions for these codes were also visible to give users a bit more information about what each code is.  Initially I added these as ‘tooltips’ when you hover over an attribute in the drop-down lists in ‘Atlas options’ using the ‘tooltipster’ jQuery plugin (http://iamceege.github.io/tooltipster/) that I’d previously used for the Thesaurus of Old English.  The screenshot below shows how this works.

tooltip

Unfortunately I came to realise that there were a couple of fairly major limitations with these tooltips in the atlas.  As touchscreens don’t have a ‘hover over’ action it means the tooltips won’t work on tablets or smartphones, and I can’t make the tooltips open on click because clicking selects an option in a drop-down list.  Also, the behaviour of drop-down lists is dependent on the operating system and unfortunately tooltips just won’t work in drop-down lists in MacOS, iOS or Android devices.  Also, I realised that the tooltips don’t work when the ‘full screen’ mode is activated either.  I realised that the only way I’d to be able to get around all (or possibly only some) of these limitations would be to get rid of the drop-down lists and replace them with something that’s purely JavaScript based and therefore works independently of the underlying operating system.  I decided to try the jQuery UI Selectmenu (https://jqueryui.com/selectmenu/) first of all, as the jQuery UI library is what I normally use for such widgets.

I’m afraid this just didn’t work out.  I tried replacing the standard drop-down list with the ‘selectmenu’ and while this did work in MacOS it failed to work at all when in ‘full screen’ mode – i.e. the drop-down list wouldn’t even drop down, effectively breaking the interface. I then thought about other ways we could allow an attribute to be selected, as the drop-down list is rather long and unwieldy.  I thought about maybe having the selection in a new pop-up that would give more space for the attribute list and the descriptions.  For popups I use the jQuery UI ‘modal dialog’, and unfortunately it looks like none of the widgets are going to work when in ‘full screen’ mode.  I figured out that the reason for this is the ‘full screen’ mode hides everything other than elements contained within the ‘map’ section of the page, and as the jQuery UI widgets exist elsewhere on the page they simply don’t show up when in ‘full screen’ mode, even though all associated JavaScript triggers and runs properly.  This is the reason the ‘tooltipster’ tooltips weren’t displaying in ‘full screen’ mode either.

I would consider the ‘full screen’ mode to be hugely important for the atlas as it makes the interface so much more usable.  Therefore I don’t think we should attempt to use any user interface elements that don’t work in this view.  For this reason I abandoned the idea of adding tooltips to the drop-down lists.  Instead I’ve added in something that is a bit more ‘low tech’ but which works across all operating systems, screens and in ‘full screen’ mode:  When you select an attribute from the list its description then appears below the drop-down list, as the following screenshot shows:

new-atdesc

This does unfortunately mean that you can’t see what the description is until you have selected the attribute, but at least it is possible to view the information.  I will also create a link to a full list of attributes and their descriptions that users could consult in conjunction with the atlas interface.  I can always return to this once I start on the public version of the atlas and see if there are any further solutions.  For example, it still might be possible to update the ‘full screen’ view so it does allow non-map elements to be used – possible by ensuring all jQuery UI elements are located somewhere within the map element.

In addition to the above I’ve also reworked the pop-ups that appear on the map so that code descriptions appear.  I’ve also rearranged the individual ratings to group them by their code so the code name and other information isn’t repeated for each rating but appears in a heading above the ratings.

Other than my work for SCOSYA, I spent some time on AHRC review duties and I had a meeting with the Burns people on Wednesday where we discussed the timetable for updates t the website for the next six months or so.  I then spent the rest of the week working on the STELLA Apps.  I’m meeting with Jean Anderson next week to go over the ‘Metre’ app, so in the meantime I’ve decided to return to the two older apps that I never got round to making Android versions of:  ‘English Grammar: An Introduction’ and ‘ARIES’.  I have created Google Play listings for these apps, have generated a new version of the app and have tested this out on my phone.  I have generated icons and screenshots (on my phone, I still need to do this on my Android tablet) and am just about ready to begin the process of building the release versions of the app code.  I’ll hopefully be able to submit the apps to the store next week, if I can get screenshots on my tablet sorted out and the pesky process of building and signing the apps doesn’t take too long.