Did I Click That? or What's up with the Browser User Experience on Slow Network Connections

My Network is Slow

For some reason, right now, there is an awful lot of time between my clicking on a link in a web page and any content displaying in my browser. Things are wrong, things are going wrong: it seems that my ADSL network is at a crawl, that DNS queries are incredibly slow, and overall round trip latency even to a server just across the city is awful.

How wrong? Well, I'm writing from Sydney and browsing the Sydney Morning Herald home page (251 HTTP requests, 6,106KB) and it is taking 8 seconds to reach a page load event. Following a link from the home page (Commonwealth Bank customers say double charges not refunded), I see (an incredible) 340 requests and a further 10,467KB downloaded - with a 6 second delay until I see content.

The purpose of this missive is not to complain about the absurd weight of the two pages cited, but to discuss the user experience during the (seeming interminable) wait for content. Since I use Firefox as my default browser, I'll (mostly) confine my comments to that browser, although my comments may be applicable to other browsers - mobile and desktop.

Did I Click That?

As noted, what's happening right now when I click on a link is, well, nothing much. I can't do much about my network, but the issue of nothing much happening at all might be improved upon.

Let me explain by walking through my actions and Firefox's response when viewing articles on the SMH website:

1. I move my mouse over an article link;
2. my mouse cursor changes, the anchor tag for the link is underlined as I hover over it and the title specified in the anchor is shown (all from HTML/CSS/JS);
3. the URL associated with the link is shown in a small, animated, floating status bar overlay in the bottom left of the browser window;
4. I click my mouse to follow the link - nothing changes between the mouse down and mouse up (again, HTML/CSS - i.e., no CSS :active selector on the SMH website);
5. as I release the mouse button the link turned grey (CSS :visited selector at a guess);
6. the tab in my browser changes from showing the page title to displaying an animated 'throbber' alongside the word "Connecting" and the status bar changes according to page load state - for example, "Waiting for smh.com.au", "Read smh.com.au" and so on;
7. a few seconds later, the tab changes, showing the title of the new page as the browser receives and parses the HTML head element from the server (like I said, things are wrong...); and finally,
8. some time afterwards, the page renders and the 'throbber' icon is replaced by a favicon for the site.

Chrome does something different, but you have to be observant to note that it shows the domain name (www.smh.com.au) when it is in the 'connecting' state and it also shows various 'processing' messages in its status bar during page load.   On closer inspection, Firefox does almost exactly the same thing.

Here's a screenshot of Firefox on a Mac showing a page load in progress, with the tab-bar 'throbber' and status bar both highlighted.

Firefox's loading 'throbber' and status bar during a page load.

Given my slow connection, my experience of clicking a link is poor - it's difficult to understand what's happening.

Why so? My eye and therefore my focus is directed to the link that I clicked, not the 'throbber' in the tab bar and not on the status bar.

Given a slow connection, in order to verify that I have actually clicked on a link, my eye has to scan up to the top of the page and then across in order to locate the tab containing the throbber. Alternatively, my eye can scan to the bottom left of the page. Either way, on my slow connection it is not immediately apparent what the browser is up to, leaving me in a state of cognitive dissonance - I clicked that link, didn't I?

Experimenting on Children

As I write this, I have been careful to control my own behaviour. In particular, I have made sure that I click on links once and only once. That's because I know that, just like a pedestrian crossing where pressing the button multiple times does not make the lights change faster, the page won't load any faster if I click the link lots of times. I tell my kids this, but they press the button at the crossing fifty times and a simple experiment this morning reveals that they do exactly the same thing when faced with links that do not result in near instantaneous page loads.

Unlike pedestrian crossings, clicking the link on the web page multiple times does change the outcome. A quick look in the developer tools (Chrome) shows that when the littlies repeatedly click on the same link, outstanding network requests are cancelled.

In an HTTP/1.1 world, this is bad news. I mean really, really bad news for performance. This is because a cancelled request results in a torn down connection (TCP close and all that). Only to be re-established and the same HTTP request re-sent. (In the interests of balance I should add that, networks being what they are, this strategy sometimes works.) I should also add that in an HTTP/2 world, the cost is nothing like as great but it still exists, particularly in the case of network that's just plain slow.

A Modest Proposal

At the risk of stating the obvious, sites should do what they can with HTML/CSS/JS available to them to provide appropriate cues to the user regarding followed links and progress. That's not what this proposal addresses, however. I am making a suggestion about what the browser might do during a page load and is thus outside of the realm of normal HTML/CSS/JS.

From a product perspective, I believe that changing the experience of page loads can improve the user's understanding of what just happened and, by so doing, reduce the number of false reloads which, in turn, might actually improve performance on slow networks.

As noted earlier, the state of the art is a throbber in the tab bar and a part-time status bar. The key change I suggest is to (drastically) change the way that page loading state is conveyed. If we accept that the user expects something to happen immediately on clicking a link, then it is reasonable to use the entire browser window's drawing area to convey feedback about the page load operation. Users are accustomed to modal progress spinners in their mobile apps and I am proposing something similar, but writ large:

It's clear that a link was clicked, a page is loading, and the most common options are clearly accessible to the user.

Looking past the fact that I just threw this together using Gimp and Powerpoint, there are a number of product requirements here:

1. The act of clicking on a link that navigates away from the current page should result in immediate unequivocal feedback irrespective of page design, the speed of the network, remote server, etc. (More on 'immediate' in moment.)
2. Information from the anchor URL and title in the followed link should be used to provide feedback about what page is being loaded.
3. Navigation away from a page is immediate and so all other links on the page should be disabled.
4. The user should be provided with a simple means to cancel the page load operation and go back to the prior page.
5. Because sometimes networks will be networks, a means to cancel a slow request and restart it should be provided. 

Arguably the browser already covers off on points 1, 2, 4 and 5.  Therefore, I am only arguing for a change in how this information is presented.

In practice, this might work as follows:

• The user clicks a link to navigate away from the current page.
• An interstitial loading page is inserted into the tab comprised of:
• a background image created from a screenshot of the page being unloaded, with a Gaussian filter applied, is used to indicate that links cannot be followed during page-load. (I chose a Gaussian filter because, hey, why not?);
• an animated throbber echoes that in the tab bar;
• the title of the page being loaded (from the anchor element) allows the user to intervene early in the case where the wrong link is clicked;
• the domain name of the server being contacted is prominent and may assist the user in an early bail-out;
• a button that provides the user with a means to go back to the prior page; and,
• a button that allows the user to reload the page.
• Immediately on receipt of the head element for the new page, the link title is updated in the interstitial and tab bar (so you know you're being rickrolled, just before you really are).
• The interstitial page is removed and replaced with the new page contents as soon as enough content has been retrieved from the network.  They key requirement here is to avoid replacing the interstitial with a blank page during slow loads.  I'm aware of how hard this may be to implement, what with CSS + JS but see no harm in asking.

In order to cater for fast page loads, the creation of the interstitial might be staggered. On navigation to a new page:

• Links on the existing page are immediately disabled.
• The interstitial is immediately created containing a blurred copy of the prior page but with the other interstitial UI elements hidden.
• Some time later - say 500ms - the throbber, text and button elements are made visible in the interstitial.

Whatever the new UI does, it should not degrade the user experience of fast loads, that is.

At this point, my imagination is galloping off - timing of the creation of the interstitial might be varied depending on whether a connection to the host is already open, or whether the link is to the same domain as the page being unloaded. I use a range of apps such as JIRA where one page looks very much like another. In this case, the bluring and redrawing of near identical pages during navigation might be distracting. Again, timing is key. Animation may be useful. I should stop - my point is that immediate might mean in the blink of an eye.  In summary, I think that this idea will be useless if the timing of the presentation of the interstitial is wrong.

HTTP GET requests require no further discussion. Since POST requests are not idempotent, they must work as they currently do, that is, if the user retries a request, they must be warned that information will be submitted twice.

For the avoidance of doubt, I believe this might work for normal links but not for JavaScript.

Summary

In the world of mobile apps, it is common to provide a modal 'spinner' that is displayed in response to a user action to signify that the app is busy, for example whilst waiting for an operation like a network request to complete.  This idea expands upon this.

Utilising the whole of the browser window in order to provide feedback during slow page loads may provide an improved user experience and possibly even lead to modest improvements in load time outcomes.  I reason that the idea is equally applicable to mobile as it is for desktop browsers.

Huninn mesh Part 2 - Architecture, Abstractions and Constraints

Huninn mesh is collection of technologies including a wireless mesh network; a set of physical devices including sensors, relays and gateways that use the implement the wireless network technology; a time series database for storing and manipulating data sampled from sensors; and, a UI for viewing and manipulating sensor data.

In my previous post, I discussed the characteristics of the wireless mesh network devices, describing the system up to and including a gateway. 

In this second post, I examine system architecture from the gateway into the cloud.  I look at the role of a gateway, introduce the device and time series databases, as well as providing a high level view of various abstractions that make it a general purpose system for ingesting and managing time series data. 

This post lays the foundation for a follow on article that will describe the characteristics and structure of the time-series database.

The Gateway

A Huninn mesh Gateway provides the bridge between devices – for example physical Huninn mesh network devices – and a server that resides in the cloud.  The server performs the dual roles of device management and data ingestion from sensors.  (Note that this is a different server from the one discussed in an earlier blog post whose job it is to manage Huninn mesh devices in a wireless network.)

Every device in the Huninn mesh system has a globally unique identity that is allocated and managed in a device database by the server.  This database maintains knowledge of, amongst other things, the gateway to the device, the measurement types supported by the device, the sensor type for each (hardware type and, therefore, the format of messages from/to the device), the sample interval for measurements, etc.

Messages are and moved between the gateway and server using a message queue.  Rabbit MQ was chosen for this role because it is proven, lightweight, scalable and supported on a wide variety of platforms. 

Individual messages are encoded using Protocol Buffers.  For a physical Huninn mesh sensor, the payload might include a timestamp, the temperature, pressure and humidity along with the unique device ID.

A Huninn mesh gateway:

• is specified by an interface;
• knows about all of the devices it manages;
• understands how to ‘talk’ to each device that it manages;
• passes messages from the device to the Huninnmesh cloud via a message queue; and,
• passes messages, received via a message queue from the Huninn mesh cloud, to the device.

Any system that implements the gateway interface can work with the Huninn mesh cloud server.  This is the first high-level abstraction adopted by the system.

A gateway is completely decoupled from a network of physical Huninn mesh devices.  However, a Network of physical Huninn mesh sensors is the most common deployment as shown in the following diagram.

A gateway communicates with the Huninn mesh server using Rabbit MQ.

This figure illustrates that a single gateway g1 manages three sensors, s1… s3 and that two of these s1 & s3 measure temperature, pressure and humidity and the s2 just temperature and pressure.  Measurements are passed to the gateway – in this case a physical Huninn mesh gateway – that publishes them to a Rabbit MQ exchange. 

As noted, this represents a typical Huninn mesh network deployment – where sensors publish measurements that the server collates into a time series. 

The utility of the gateway abstraction becomes apparent when considering how easily other data sources can be incorporated into the system.  Examples of other data sources are external weather measurements (from a web feed) and a Modbus bridge.

Modbus is a serial communication protocol commonly used to interface with HVAC plant equipment in building automation systems.  Read/write access for up to 247 devices can be supported on a single Modbus network

Huninn mesh has built a Modbus Bridge that makes use of the gateway abstraction.  It is built as a standard Linux executable, implements the Modbus protocol and both publishes and subscribes to the Huninn mesh device message queue.  The executable works just like a standard Huninn mesh device: it sleeps, wakes, makes a read Modbus register(s) over the serial interface, packages and publishes the measurement(s) and then sleeps again.

A Modbus gateway might be integrated alongside a physical Huninn mesh network thus:

The gateway abstraction means that it is a simple matter to add other sensors into the system, in this case, Modbus.

In this diagram, the Modbus interface is shown as g2 in red.  This gateway talks to a Modbus device mb1 that reads registers r1…r3. 

This serves to illustrate the point that gateways manage their own devices and know how to communicate with them.  In the diagram two different protocols are employed on the left hand side of the gateway: Huninn mesh and Modbus.   The back end system neither knows nor cares how the gateway delivers messages to the devices it manages, so long as it does deliver them.

The other example cited above is of weather observations, sampled from standard web services.  The weather gateway talks HTTP over the Internet to a RESTful interface providing weather conditions.  As with all Huninn mesh sensors, the feed wakes, reads, publishes and sleeps and, by so doing, fulfils the gateway specification.

In summary, any form of sensor can be integrated into the Huninn mesh system via a software gateway.  Thus, any ‘sensor’, be it hardware or software, can be integrated into the system, publishing data that will be collated into the time-series database.  This is why the Huninn mesh system has wider applicability than just Huninn mesh network devices.

Virtualising a Device

The second significant abstraction is that device addressing.  

Recall that each physical Huninn mesh device has a globally unique identity assigned at the factory.  Devices may have multiple sensors ‘onboard’ (say, temperature, pressure and relative humidity). 

A simple (naive) addressing scheme might be to expose the GUID.Sensor to all users of the system.  This is not what's done, however.  Instead, end users of devices deal with a virtual device ID and this is assigned and managed by the device database.  A virtual device ID is a 64 bit integer.

The reasons why this approach has been adopted will be discussed in a later post when examining the characteristics of the time-series database.   Suffice to say for now that this provides considerable flexibility and significant performance advantages to both internal system components and end users of sensor data. 

The Device Base Period

One important constraint placed upon sensors providing measurements to the Huninn mesh system is that period in which they sample must be a power of two times the base period.  The base period is constant for the entire network.

To illustrate, the base period for the network might be 5ms.  Every sensor in this network is constrained so that it can only return samples at one of: 5ms, 10ms, 20ms, 40ms, 80ms, 160ms, 320ms, 640ms, 1280ms, 2,560ms, 5,120ms and so on. 

The importance of this rule will become apparent when considering how the time-series database, RESTful API and other services are implemented. 

Summary

This post has introduced a series of architectural ideas that underpin the server side of the Huninn mesh network.  A follow on post describing the time series database structure will make clear why each of these abstractions and constraints is useful.

Huninn Mesh Part 1 - What is it?

I am currently working with Huninn mesh, a startup that sells monitoring and control systems that use network of IEE 802.15.4 based wireless devices.  

The stand out capability of a Huninn mesh network is its efficiency: the system can cope with large numbers of networked devices that generate many small data packets.

Physically, devices are compact, battery powered and have a long operational lifetime of five years or more.  These characteristics make a Huninn mesh network an ideal fabric on which to build dense network, low bit rate applications that fall under the umbrella of the ‘Internet of things’. 

This is the first in a series of posts where I discuss the Huninn mesh system.  In this post, I provide an overview of the Huninn mesh network.  In a follow up post, I will go into a deep dive about the back end server infrastructure that handles the data from a dense network in order to provide a platform for service creation.

Huninn Mesh Devices 

A Huninn mesh network extends the IEE 802.15.4 standard with a proprietary higher layer protocol.  A Huninn mesh device is any device that implements this higher-level protocol.  (From here on in, I’ll use term ‘mesh’ interchangeably to refer to a Huninn mesh device or number of Huninn mesh devices configured into a network – where it is not clear from the context, I’ll revert to the long form.)

At its most basic, a mesh device is radio coupled with a simple, low-specification CPU, a tiny amount of memory and, all importantly, one or more sensors.  The device firmware supports simple ‘script’ commands that are delivered over-the-air and provide a very basic programmable capability.

A script instructs a mesh sensor when to do something:

• measure something via a sensor;
• listen for a message from another mesh device; or,
• send a message to another mesh device.

As noted, a typical mesh sensor is compact – about 10cm by 10cm by 1.5cm – has a single, non-replaceable internal battery that gives an operational lifetime of at least five years and a can measure two or three parameters via its onboard sensors.  For example, devices exist that measure dry bulb temperature, atmospheric pressure and relative humidity.  In addition, all devices measure their own ambient network environment, battery level and so on.

The longevity of battery-powered units is achieved through quiescence: for almost all of the time devices are in a low power ‘hibernation’ mode.  Exactly when a device wakes up from hibernation and what it does when it is in the ‘active’ state is under the control of a remote server that provides command scripts – the what and when – to the device. 

There are also gateway devices, powered by mains electricity, with a more powerful radio, that provide a means of bridging between a Huninn mesh network and some other network – typically, the Internet.  Gateways are atypical: they are always on by design and have no sensors.  Their only job is to provide a service to the many battery-powered devices in their vicinity.

Finally, there are also mains powered relay devices - essentially, gateway devices without a NIC whose job it is to relay messages over longer distances or where signal attenuation is too great for the radio of battery powered devices.

Recall the earlier point that any mesh sensor can receive and forward messages from any other sensor.  If a sensor can ‘see’ the gateway, it can deliver the measurement directly.  If it cannot, then it can pass the measurement on to another relay or sensor, and so on.

A mesh network of sensors (blue) communicates via a single gateway (purple) to the Internet. 

This represents the defining capability of a mesh network: nodes do not have to be connected to a gateway in a traditional hub and spoke topology.  Instead, very complex topologies can be created which involve multiple ‘hops’ from one device to another before eventually reaching a gateway.  Huninn mesh has demonstrated one such multi-hop network with over 100 sensors configured in a chain topology.

 

Huninnmesh has deployed 100 sensors in a chain topology.

The Huninn mesh Control Server

Central to the mesh concept is a server whose job it is to manage this network of very simple devices. 

From the server’s point of view, a network has a goal – for example to measure the internal temperature, pressure and humidity at multiple points within a multi-storey building.  The job of the server is to evaluate how best to achieve this goal.  Once it has done this, it dispatches command scripts to each device telling them what they should do when.  This programmable nature means that a Huninn mesh network qualifies as a true software defined network.  

Clearly the server needs to ‘know’ about all of the devices in the network under its control.  It ‘learns’ this via a bootstrap process whereby new devices or groups of devices announce themselves: they discover each other and, by so doing, find a gateway that can be used to pass their details to the server paired with the gateway.  Suffice it to say that this happens but, in this post, I shall not go into detail as to how.

With reference to its goal, the server uses an algorithm to build configuration tables for each device.  These tables rely upon every device in the system having a shared understanding of slots allocated to time and network channel. 

Example configuration tables might say:

• Device A: In time slot 12, integrate temperature and pressure measurements, package these and send as a message on network slot B in time slot 13.
• Device B: In time slot 13, receive a message on network slot B and send this on network slot D in time slot 14.

Message payloads are encrypted and signed at the device preventing eavesdropping and man-in-the-middle attacks.  Message envelope overhead is small compared to payload size, meaning that time-slots can be very short.

As soon as a task is complete, a device immediately hibernates until it is required again.  Everything works with a metronomic beat, moving data through the network in an efficient manner and, so far as possible, doing nothing else for the remainder of the time.  Since the entire system relies on accurate clock synchronisation the device firmware works with the server to accommodate drift and keep every device in lockstep.   

One side effect of the need to keep battery powered network nodes in hibernation is that messages are not dispatched immediately.  Event based message payloads (as opposed to regular time series data) can take fifteen seconds or more to reach their destination.  The time to deliver a message generated by an asynchronous event depends on the time spent in hibernation, number of network hops, etc.   It is a function of system design and subject to battery tradeoffs: a thirty second lag may be acceptable for HVAC control but not for light-switching.

At the time of writing, the state of the art for a stable Huninn mesh using a single gateway is approximately 250 devices each measuring two or three parameters at a up to fifteen second intervals. 

One aspect worthy or a more detailed discussion is battery trade-off.  Consider the 100-hop case discussed above.  The last battery powered device before the mains powered gateway has to wake in order to accept and relay messages on behalf of the 99 ‘upstream’ devices.  Functionally, this is highly desirable, but it comes at a cost to battery life. 

The server uses multiple strategies to minimise battery cost without sacrificing reliability.   In the first instance, using its knowledge of wireless topology, it minimises the hop-count across battery-powered devices.  Therefore, in an ideal case the server will eliminate any hops and arrive at a hub and spoke network.

A hub and spoke network topology imposes the minimum burden on a device's battery.

Where the wireless topology prevents such a network forming, the server attempts to minimise the number of hops to a powered device and also to load spread across battery powered relay devices. 

Even though the device has sophisticated battery management hardware onboard, the server is also able to assist in power shaping by smart choices that seek to harness the recovery effect of the battery. Since battery powered devices also report the battery voltage, the server can understand the true cost of a particular configuration and, in the longer term, use machine-learning techniques to optimise further.

Of course devices fail and wireless conditions constantly change.  For this reason, the server is constantly evaluating the best possible configuration for all of the devices under its control.  By so doing, it is able to evolve and heal the network over time.

Stepping Back

At this point it is useful to step back and examine the big picture – why a Huninn  mesh in the first place?  To answer this, I’ll use the example of building comfort management.

Most people have experienced an uncomfortable office environment: either too warm or too cold.  In older real estate, the reason for this can often be traced to the fact that the output from a single wired thermostat determines the heating, ventilation and air conditioning settings for an entire floor. 

Increasing the number of sensors on a floor improves the information available to the manager who programs the HVAC.  It often proves to be prohibitively expensive to re-wire an entire building with multiple sensors not least because occupants are disturbed, skilled tradesmen are required and a significant amount of time is required. 

A Huninn mesh sensor network does not suffer from these problems: 

• Sensors are battery powered – no wiring required & no mess for tenants.
• Sensors are cheap – many can be deployed.
• Installation is trivial – stick a sensor onto a wall, activate it and walk away.

By far the most complex task is the installation of the single gateway and relays as required.

By way of illustration, we outfitted a forty five year old building on Broadway, NYC that has fifty floors each of which is 24,000 sq. ft.  Floors were instrumented with mesh sensors, some having twenty sensors and some less.  Each sensor measures temperature, pressure and humidity and samples at fifteen-second intervals.

This serves to illustrate why I stated that Hunnin mesh network is ideal fabric for the low bit-rate portion of the Internet of Things.  Temperature, pressure and humidity measurements are sixteen bits each.   They are measured at fifteen second intervals from 200 sensors.  This creates a wealth of data for the building manager without the cost and headache of an expensive building refit.  

A Hunnin Mesh

In this post, I have tried to give a very high level answer to the question of what is a Huninn mesh and why would I want one in the first place.

In summary, a Hunnin mesh provides a low cost means of getting information to and from a large number of wireless devices.  Typically, these devices measure some parameter, say temperature, pressure or humidity.

In my next post, I will provide a deeper dive into some architectural aspects of the cloud system starting with the gateway.