The demonstration discussed in this post can be found here.
Part 1 can be found here.
There are a number of issues when it comes to designing an interactive visualisation that works on desktops, tablets and smartphones. Most obvious is probably the variation in screen size, both physical and in terms of pixels. However, there are other issues such as computing power, connection speed and input method (mouse/keyboard versus touch). Moreover, we also have a whole new set of browsers with their own sets of idiosyncrasies. On my phone, for example, I currently have an Android stock browser, Chrome, Dolphin, Firefox, Maxthon, three versions of Opera (Mini, Classic and for Android) and UC Browser. What follows describes some of these idiosyncrasies that I discovered using the versions of said browsers on my phone at the time of creating the map visualisation. Obviously these issues may be ironed out in future versions of the browsers in question.
Opera Mobile doesn’t support “overflow: auto”
There are over 348 regions in the dataset. For the “full-screen” desktop view of the page I set the height of the table in CSS according to the height of the map and used the “overflow: auto” CSS command to make it scrollable. This gives about 30 names on screen. For the narrower screen where the different components of the visualisation are arranged in a stack (using CSS media queries) I reduced the table height, meaning eight or nine regions should be visible. Unfortunately, Opera Mobile Classic doesn’t support “overflow: auto” and instead we get the entire list of countries (see figure below). On my phone that means I have to scroll through eleven screens worth of table entries just to get to the map. Strangely, Opera Mini (and Opera for Android) do cope with “overflow: auto”.
UC Browser doesn’t support SVG
Internet Explorer is notorious for doing things its own way. Until version 9 (released in 2011) it did not support scalable vector graphics (SVG), despite the latter becoming a W3C recommendation in 2001. UC Browser (and presumably some other mobile browsers) still don’t support SVG. This visualisation was based around an SVG map and so even trying to support UC Browser in any meaningful way was impossible.
Event handlers attached to paths
In my previous demonstrations the clickable/tappable objects have been in the form of SVG “rect” or “circle” elements (such as circular data points in scatter plots). Conversely, the map boundaries are created from “path” elements. Testing the demo on the Android, Dolphin and Maxthon browsers I found issues with the events attached to map elements. In short they almost never fired… but occasionally did. Events based on clicking on table entries which ran the same function always fired. The events attached to the rectangles of the key fired properly too.
After much stabbing of my phone with my index finger (and some more structured experimenting) I deduced that these browsers don’t recognise the fill of a path as being part of the path (as far as event firing is concerned). The occasional events that did fire were those events where my finger hit the stroke of the path itself rather than the interior.
Another issue was the inordinate amount of time it took for the page to load on the mobile version of Chrome. After initial loading the page worked seamlessly. I first went through my code and tried to make it more efficient, timing the results in the desktop version of Chrome (which is easier to debug with). I managed to improve things on the desktop significantly through this review but it was still painfully slow on the mobile version – up to 9 seconds to load the page! Going through the process again and testing directly with the mobile browser I located the hold ups: the assignment of event handlers. It didn’t matter what the event handlers themselves did, but the assignment of 348 for the map paths and another 348 for the table really killed mobile Chrome – especially if using touch events rather than click events (which the browser then converts to touch events).
The solution I found for this was event delegation. Rather than attach an event handler to every path and table element I attached one to the map and one to the table and used the event.target property to determine which precise element was tapped. This reduced the number of event handler assignments by 694 and removed the blockage.