Odds and Ends

Illusions in CSS

March 7th, 2013

The many new CSS features introduced in the CSS3 spec that are increasingly supported by all the modern browsers have interested me for quite a while. In an attempt to put see how powerful CSS without any JavaScript can be these days I decided to try implementing some of my favourite visual illusions in pure CSS. Most of these had previously only been available as Flash implementations, so it seemed like the exercise would also be good in the name of progress. Not only did it turn out to be good fun, I gained quite a few insights into the current state of CSS at the moment. The results of this exercise so far, and some notes on particular lessons learnt, are presented below.

Note: tested in Chrome 25, FireFox 18 and IE 10.

I used LESS and Lea Verou‘s -prefix-free in all the illusions in order to keep the CSS code. Both proved very useful, though -prefix-free turned out to have one or two unexpected quirks.

The code, including the more easily digestible LESS CSS files are all available on GitHub. Please do fork and add in more illusions if you want to!

Lucy In The Sky

Check out this Pen!

This is a variation on a motion illusion originally created by Arthur Shapiro & Justin Charles. It appears to us as though the “bracelet of diamonds” is moving around in 3D space, but actually all that is happening is that the fill colours are oscillating between dark and light (while the edge colours stay constant).

As far as the CSS is concerned, there were a number of interesting parts. Firstly, a commonly found way to create a diamond shape involves playing around with a combination of borders and pseudo-elements. Unfortunately, support for animating pseudo-elements isn’t particularly widespread yet so I wasn’t able to change the background colour suitably. Furthermore, this approach meant I had to use wrapper divs to fake up borders… yuck! Instead, I used a combination of rotation and scaling transforms to achieve a diamond shape with a border, no faking involved!

Laying out the circle of diamonds was a doddle. After realising that by appropriately using a translation in the transform sequence you can rotate around different origins, I was able to combine :nth-child selectors and a LESS parametric mixin to create a very simple way of not only creating the diamond shapes but also positioning them. The mixin looks like this (updated! Thank you Luke):

.diamondPosition (@index) {
  @degs: (45deg * @index);
  transform: rotate(@degs) translateY(-130px) scaleY(0.5) rotate(45deg);
}

The full code is available here.

Mutually Interfering Shapes

Check out this Pen!

In this illusion, devised by Maarten Wijntjes, Robert Volcic & Tomas Knapen, it seems as though the two dots are bouncing off one another as they go around the centre point. Actually the two dots are tracing simple square and circle shapes. However, even when clearly tracing the inner square it seems as though the outer dot follows four arcs rather than a perfectly regular circle.

CSS-wise there is nothing particularly clever going on here: there are two basic animations to create the movement and an animation to fade in the actual shapes.

The full code is available here.

Tilting Pyramid

Check out this Pen!

Do you see the 3D tilting pyramid? The illusion was created by Pietro Guardini & Luciano Gamberini and results from a combination of different Gestalt principles and the motion of a changing angle.

I created the angled area at the bottom by combining solid and transparent borders. This meant the motion could be created by simultaneously animating the angle and the position of the div (well, actually the top margin in this case). The “pacman” shapes are created by using border-radius for the circular shape and multiple background gradients for the “mouth”.

The full code is available here.

Grouping By Contrast

Check out this Pen!

Hover over the illusion to remove the background colours and see how different it looks.

Initially it seems as though the blobs are grouped diagonally, but if you hover over the illusion the background colours are removed and suddenly the blobs are grouped as rows. The illusion was originally presented by Erica Dixon, Arthur Shapiro & Kai Hamburger and is a wonderful demonstration of how we see colours as relatives rather than absolutes, that is, the perception of a colour is entirely dependent on its context.

The main point of technical interest to come out of implementing this illusion was what initially seemed like a bug in -prefix-free: the filter being applied to the blobs to blur them was not being prefixed appropriately by the library. It turns out this is because filter is actually something of an ambiguous CSS property in most browsers, in that they support it as an un-prefixed property for SVG but not for HTML. This means -prefix-free cannot reasonable recognise how to behave.

The full code is available here.

When adaptive design goes wrong…

December 20th, 2012

Reading Avi Itzkovitch‘s article about Creating An Adaptive System To Enhance UX on Smashing Magazine recently brought the notion of adaptive design back to the forefront of my mind again. For those unfamiliar with the concept, from Avi’s article:

In computer science, the term “adaptive system” refers to a process in which an interactive system adapts its behavior to individual users based on information acquired about its user(s), the context of use and its environment.

That same evening, browsing around reading various articles about adaptive design, it struck me why when it comes to the practicalities of adaptive design I go a bit cold: the frustration adaptive design causes when it goes wrong often outweighs the delight it creates when it works. What prompted this was not the articles I was reading but the behaviour of the smartphone I was using to access them on. The automatic re-orientation of the screen from landscape to portrait and vice versa based on the device’s perception of its orientation is a common example of a generally useful adaptive system.

Smartphones in Bed

Assumptions are the termites of relationships – Henry Wrinkler

However, in the context of lying on your side in bed, as I was, you soon realise the flawed assumption this system operates on. The orientation of the screen is based on the orientation of the device relative to the ground, and therefore is essentially assuming you are upright. This means that any context where you are not upright when looking at the device (or the device itself is not upright, for example lying on a desk) becomes an awkward battle. The result is usually that you change your or the phone’s position to accommodate this behaviour, i.e. you adapt to suit the device, the polar opposite of the goal of adaptive design. What the device “should” be doing is to orient the screen based on its orientation relative to the user.

A different kind of of common adaptive system, recommendation services, suffer from some equally strong and arguably misplaced assumption: that a only a single individual will be accessing the service through any particular browser/machine/device. Amazon, for example, recommends other items that may be of interest based on your browsing and purchasing history. At home, my wife and I share a desktop and laptop, and because we are both “lazy” we do not bother with separate user accounts because that would result in half our time spent logging in and out. What this means when it comes to Amazon is that we often get a good idea of what the other one was recently looking at because it doesn’t require explicit log-in before it starts tracking the user. As a result, when I saw the More Items To Consider list yesterday it became pretty clear that I, or someone else in our family, is going to be getting a themed rubber duck for Christmas…

Amazon Recommendations

Similar frustration results from other services operating on the same, in my opinion, flawed assumption. For example, it is quite grating to suddenly be hit by a blast of horrendous easy listening music from Last.FM just because my wife used the same device as I did to listen to her music.

Although these kinds of frustration are caused by us not using the services as expected, it can be quite hard to rectify. In the cases of both Amazon and Last.FM there are fairly obtuse mechanisms for editing what they have tracked, but should the user have to fix the adaptive system or is this a symptom that the adaptive system is flawed?

Mindless habitual behaviour is the enemy of innovation – Rosabeth Moss Kanter

The Amazon and Last.FM recommendation services fall into a broader category of adaptive systems that attempt to use past behaviour to predict future behaviour. Google use this approach in all sorts of ways, from their searching functionality to the advertising that is presented in some places and beyond. In fact, they are taking this even further to assist us in many aspects of our everyday lives with Google Now:

I believe it is worth considering these kinds of systems in a bigger context, on a more philosophical level. Given that they are based on past behaviour they are (currently) unable to encourage any real change. In fact, they are inherently based on the notion that you as a user don’t drastically change. While in some respects this is true, as we become more dependent on these kinds of systems it becomes something of a self-fulfilling prophecy because it takes increasingly more conscious effort on our behalf to essentially override or ignore what the system is doing for you. Furthermore, if we do significantly change our behaviour then the system loses its efficacy for a while, thereby frustrating us and, if our dependency on them becomes sufficiently strong, actually discouraging any other change.

This only scratches the surface of one consequence of the increased prevalence of adaptive systems. However, regardless of where you stand on their consequences, it is important that we do recognise and consider them, especially those involved with creating them, rather than passively allow them to change us.

If there is no struggle, there is no progress – Frederick Douglass

Adaptive systems can greatly enhance the experience of many products, but conversely can also undermine it. By their nature they attempt to infer contexts of use, which are hugely variable and complex, especially when human factors are involved. Therefore they require significantly more comprehensive and well thought out user testing. At the same time, designers and developers should thoroughly examine the system and any assumptions it operates on for flaws, and then consider whether the overall experience of the product can overcome any issues that might arise for users. Furthermore, readily accessible mechanisms should be provided to allow any adaptive system behaviour to be overridden by the user if they so desire.

As device sensors and our understanding of human behaviour improve, adaptive systems are going to become evermore prevalent and hopefully make experiences increasingly productive and intuitive. However, on a more philosophical level, this means we should more readily question them and recognise that adaptive systems are just as capable of creating and altering behaviour (for good or bad) as they are at enhancing existing behaviour.

Toob – London Underground travel app

October 4th, 2012

I have recently been working on an application called Toob as an entry for CodeProject’s App Innovation Contest. It is a London Underground travel app for Windows 8 that will be released to the Windows Store in due course. It is currently a work in progress but I have written an article introducing the application and going through some useful technical information for anyone interested in writing HTML5 applications for Windows 8. It is primarily a technical article, but I plan to write up some thoughts about the Windows 8 user experience and designing for Windows 8 in due course. For those of you who can’t wait, here is a sneak preview of my opinion: the Windows 8 user experience is as Frankenstein-ish as you’d expect from its dual-experience nature; it is both truly delightful and painfully awkward.

Toob

Go read the article now!








Pretty pictures don’t always tell the whole truth

July 12th, 2012

I published a graphic last week that tried to put habitat figures from the UK National Ecosystem Assessment into some kind of understandable context. It has got a fair bit of attention since then, largely because Mark Easton kindly tweeted about it, resulting in the BBC website linking to it in various high-profile places. As may be evident from my blog, I like to critically appraise visualisations, so it would be hypocritical not to openly do the same for my own creation.

If broad habitats in the UK were clustered...

By representing the total habitat areas on a commonly recognised geographic map the graphic immediately provides a rough, but more comprehensible, context for the figures. However, the graphic doesn’t effectively support any real analysis beyond this. The complexity of shapes on geographic maps means that attempts to compare areas is cumbersome and error-prone, meaning that we actually just read and compare the percentage figures labels rather than the areas themselves. Even then, the arbitrary, scattered layout of the labels make it cumbersome to scan across them and difficult to get an overall collective view of the numbers.

One way I think the visualisation would have been improved is if the map regions were given more explicit context to better communicate the total area of each habitat. This could be achieved by showing the county borders around which the regions were designed, as below. As a result it is easier to recognise that, for example, the 6.8% urban area of the country is roughly equivalent to an area covering Greater London, Surrey, Kent, West Sussex, East Sussex, Essex and Hertfordshire.

If broad habitats in the UK were clustered... (with borders)

What also becomes clearer when the county borders are shown is that in designing the graphic I chose to sacrifice accuracy in favour of clearer stories. For example, the coastal margins habitat is represented as the same area as Cornwall. However, the actual area for coastal margins given in the report is 336,000ha where as Wikipedia (and Google Maps) give the area of Cornwall as 354,900ha. This is a not insignificant discrepancy, but given that the values in the report are rounded estimates and derivations, I believe the explanation that coastal margins in the UK roughly equate to the area of Cornwall is far more meaningful to most people than 336,000ha.

Note that where county sizes could not be roughly match to habitat areas I opted to use smaller administrative regions. Where even that didn’t suffice, as is the case in Scotland and North Ireland maps, completely artificial, straight-line borders were created as appropriate.

Ultimately, if accuracy and any more detailed analysis is desired, I believe a simple table is the best way to present the information in this case. The original report does a half-decent job of this:

UK NEA broad habitat data table

However, after taking a closer look at the data presented in the report’s table something doesn’t seem entirely right. As I’ve highlighted in the table below, the figures don’t appear to add up. The report indicates the values were derived and estimated from a couple of different sources, so one can only assume these anomalies result from whatever method was used. The way the data is presented in the table, with totals and percentages, immediately suggests to the reader that this is part-to-whole information, and few people would actually do the arithmetic to spot that this isn’t quite the case. However, the tabular representation of the data does make it much easier to potentially spot this issue than my map graphic because it inherently encourages and supports scanning across multiple values with minimal effort.

Broad habitat figures as table

To make matters worse, the report goes on to further mislead about the data (probably unintentionally!) by complementing the data table with everyone’s favourite graphic for presenting part-to-whole data: pie charts. Ignoring that pie charts are a somewhat flawed visualisation (see Stephen Few‘s Save the Pies for Dessert paper for an explanation), their design is such that the complete circle represents the whole, i.e. the total or 100%, and the slices represent the parts. However, as highlighted above, the individual broad habitat values do not add up to the total, so either the total represented by the pie charts do not represent the totals in the data table they are linked to or the segments are not accurate reflections of the habitat proportions.

Broad habitat pie charts

Apologies for the slight side-track, but I think it is worth highlighting issues like the pie charts above to remind everyone that visualisations should always be viewed with some skepticism because it is very easy to put all sorts of misinformation in them, whether intentionally or unintentionally.

So do I think my visualisation is any good? Well, yes and no. It does a reasonable job of specifically addressing the question it was originally intended to answer — what does “6.8% of the UK’s land area is now classified as urban” actually mean in real terms? — in an attractive way, but does little to support any other meaningful analysis, to the point that some data quirks are almost completely hidden.

If broad habitats in the UK were clustered…

July 6th, 2012

Intrigued by Mark Easton’s question on Twitter, “How much of Britain is built on?”, and inspired the associated article, The great urban myth of Britain, I wanted to put the UK NEA‘s statement that “6.8% of the UK’s land area is now classified as urban” into some kind of context that actually made sense to me.

The obvious answer is that 6.8% of the UK is just short of 2 million football pitches. Unfortunately, this is still not actually something I can remotely picture (much like genuinely imagining more than 10 otters is a tall order). The best solution I could come up with was to put the information in the context of actual geography:

If broad habitats in the UK were clustered...

And here is the original report from which the numbers were sourced, for posterity: UK National Ecosystem Assessment.

UPDATE: I have written a short critique of this graphic that also provides some insight into how it was created and the figures behind it.

How to undermine a good design: a case study

June 14th, 2012

This article looks at a recent change to the BBC Weather website as an example of how over-use of information visualisation techniques and inconsistent design decisions can undermine what is otherwise an excellent content-first experience.

I have watched with fascination over the last year as the BBC have undergone an extensive redesign of their entire online offering. They have clearly adopted a more user-focused approach than in previous revamps, and their openness about the process has been very refreshing. In my opinion, there have been many positive changes, but some aspects have also changed for the worse*. However, there was one area of the site where the changes really caught my eye: the weather forecasts.

The redesigned BBC Weather site
The redesigned BBC Weather site

The old site was rather dense, and it often felt like you had to wade through an awful lot of extraneous bumf just to get to the main content: the forecast. Furthermore, the days in the forecast run top to bottom rather than adhering to our more intuitive view of time running left to right. The redesigned BBC Weather site addressed these issues and others, creating a much better overall experience of the tool, even if it did still have some issues. The designers involved even published a lovely article detailing the project’s design process.

The redesigned site is also an excellent advert for the bold, content-first, Swiss-style (and dare I say it, Metro-ish) design style I like so much.

The old BBC Weather site
The old BBC Weather site

The redesigned BBC Weather site has recently been tweaked. At first glance the changes seem reasonably minimal and those who are aware of my love of whitespace might even naively suggest to me that it is an obvious improvement. Unfortunately, closer examination highlight various issues that, in my opinion, have resulted in the site taking a step backwards.

An additional, somewhat ill-conceived, infographical element has been added into the design of the forecasts, the single most important part of the site. The weather symbols and temperatures are now presented as if they are on a time vs temperature graph. You might think “cool, now I can quickly see what times of the day are hottest or coldest” (is this ever likely to deviate much from “colder at night than during the day”?), but it actually has a misleading side-effect. The y scale of the graph varies for each day, as its range is always the minimum temperature to the maximum temperature for that day. So although two forecasts on different days might be in the same vertical position, this does not mean they have the same temperature at all. The result is that doing any kind of comparison between days using the graph without actually reading the values is only going to mislead, and if we have to read the values then the abstraction a graph is meant to introduce is broken.

The tweaked BBC Weather site
The tweaked BBC Weather site

One other change that might be argued helps mitigate the issue is the additional of the coloured backgrounds to the temperatures (although I would question whether this was intentional!). This potentially makes it easier to recognise differences in values on the graph by the colours, but given that it is very difficult to consciously see the colour without reading the value this would be a pretty weak design. And you do have to consciously see the colours because, depending on your monitor settings, the differences are very subtle. The choice of a stepped colour scale rather than continuous scale solves the colour differentiation problem a continuous scale would introduce, but, unfortunately, also makes you question why the degree difference between 9° and 10° is significant when that between 8° and 9° is not (ok, maybe I’m being a tad facetious here). My guess would be that the real motivation behind this background colour is to match up to the design used on the interactive maps (but then the maps don’t have the ° symbol after the number, so maybe I’m wrong…). However, I would argue that the static forecast and interactive map contexts are very different and that a big number without the relatively meaningless distraction of a coloured background, as in the original redesign, is much more immediate.

The latest BBC Weather site
The tweaked BBC Weather site (again)

The real problem the graph concept introduces is that it makes scanning across the weather for the day awkward because of the varying vertical position. It results in making intra-day comprehension and comparison more time-consuming than it need be. Even the designers appear to have acknowledged this issue, since they provide a mechanism to switch between Graph and Table modes. Pleasingly, as the name suggests, the Table mode organises the information into a more easily readable, tabular layout. Somewhat bizarrely the Table mode also results in more information being displayed than is available in the Graph mode. Such inconsistency is very frustrating to a user, since it may force the user to flick between modes just to get to the information they desire. Unfortunately, the Table mode also introduces labels for the rows of data. Where as in Graph mode it was sensibly recognised that users would know that a weather pictogram represents the weather conditions, a value with a ° symbol is a temperature and a directional arrow with a number represents wind speed and direction, in Table mode we are explicitly told this is the case. The designers should have decided that in this particular case either the context is sufficient for users to easily deduce what a value represents, or the context is not sufficient (hint: it is!).

The latest BBC Weather site in table mode
The tweaked BBC Weather site in Table mode

The designers have also changed their minds on the “do we need to label this or not?” question elsewhere, sometimes for the better, sometimes for the worse. In the original redesign it was felt necessary to inform users that 7am and 10am are the morning, 1pm and 4pm are the afternoon, and so on. Fortunately in the recent update they have recognised that these labels are superfluous and only distract from the genuine content by adding to the density of information on the page. In contrast, the tweaked design has introduced huge, overbearing labels for the “Forecast Summary” and “Environment Summary” where previously they were deemed unnecessary. I would argue that these labels add no meaning and, if anything, only distract from the actual content. Their prominence results in the user only reading the label when scanning over the page, rather than briefly scanning the textual content as they would in the previous version to quickly understand what is being presented.

Just to be completely open, I must highlight that I’m not a regular user of the BBC Weather site and I’m not overly interested in the details of weather forecast. My simplistic needs are far better met by the wonderfully pragmatic Umbrella Today?.

Hopefully the designers and developers involved with the BBC Weather site will pick up on these issues and address them, or, even better, have extensive user testing results that contradict my observations. Either way, I believe this serves as an interesting case study to highlight the kinds of gadfly-ish questions that should always be asked when designing or re-designing anything.

* Horizontal scrolling is suitably intuitive on mobile devices, but isn’t a great option for the desktop factor these days (see exhibit A: the mouse scroll wheel). And who thought “headlines” makes sense as a title for a section with the smallest size of text on the screen, squished in amongst loads of eye-catching glossy photos?!

UX London 2012

April 26th, 2012

Last week I attended the UX London 2012 conference. This was my first public foray into the world of User Experience and it proved to be both educational and thought-provoking.

Having read his book, Sketching User Experiences, I had high expectations of the opening presentation from Bill Buxton (@wasbuxton) and he didn’t disappoint. He introduced the Long Nose Of Innovation: the observation that it takes roughly 20 years for a technology to go from invention to billion dollar industry, with most of that time spent “under the radar”. Taking this further, he highlighted how this means we can easily predict the near future by looking at the recent past. He backed this up with various examples, most with the added side-note that the the first patent for a concept often wasn’t the original invention. Who knew Xerox didn’t invent the mouse, and that in-line skates originate from the early 19th century?!

Anders Ramsay (@andersramsay) had the unenviable task of following Bill Buxton on stage, but his discussion of Agile UX using an interesting rugby analogy went down a treat. His slides are available here and are well worth a look for anyone working in an Agile development environment.

Luke Wroblewski (@lukew) was up next and rammed home the point that not only should we be thinking mobile-first when designing websites, but that our mindset should also be “content first, navigation second”. He went on to detail his current thoughts on responsive layouts and responsive navigation patterns. His website is a treasure trove of information on designing for mobile devices and I highly recommend everyone has a dig around in it.

Kristina Halvorson (@halvorson) focused her 45 minutes on the importance and practicalities of content strategy in user experience design. It is obvious that substance and structure should be connected to workflow and governance, and that all content should support and tie to a single core message, but there is clear evidence around us that this is ignored or forgotten in many projects.

The inimitable Jared Spool (@jmspool) outlined what he considers to be the four major forces that make good design so important these days, or as he puts it, The Perfect Storm:

  • Sturgeon’s Law – “90% of everything is crap” – is as applicable as ever, with Jared supporting this by showing a number of mobile-centric experiences from big brands, such as scanning a QR code, that result in the user going to websites that are not optimized for mobile or, at worst, outright broken on mobile (by using Flash…).
  • There is a recurring market maturity cycle: we start with some technology that fills a void, onto which companies start heaping features, before experiences become the key. Clearly this cycle should be broken and companies should just focus on experience straight away.
  • The difference between activities and experiences is huge. Jared’s comparison of how the Six Flags and Disney theme parks differ emphasised how much value a lot of extra thought and a little extra money can make. “Experience is about filling in all the gaps between the activities”
  • The Kano Model provides a powerful insight into user expectations, and where investment should be in order to satisfy them.

We were then given some shorter, case-study based presentations by Harry Brignull (@harrybr), Bill DeRouchey (@billder) and Leif Roy. What stood out the most to me from these presentations was Bill DeRouchey’s view that we should let opinions shine through our products because opinions provoke engagement.

Jon Kolko (@jkolko) was rounded off the day with an impassioned presentation imploring us to apply our design skills to problems that are genuinely worth solving (rather than another Toilet Finder app!). It was inspirational, bigger picture stuff and drove home a rather important point. His slides are available here.


Yes, there are more than one toilet finder apps… (from Jon Kolko).

The second and third days of the conference consisted of half-day workshops, the first of which was Leah Buley‘s (@ugleah) UX Team Of One Bootcamp. Much as the name suggests, the workshop centred on practicalities of the common situation where you are the lone UX designer on a project or in an organisation. Leah emphasised that whatever the exact activities are you choose to undertake, the key aspects of your approach should be:

  • lowest fidelity possible
  • inclusive and participatory
  • focused on prioritization
  • not rigidly sequential
  • bite-sized and with a purpose

The discussion following a subsequent group exercise involving the creation of a project plan for a hypothetical highlighted two important aspects we have a tendency to forget: a buy vs build analysis; and, the question of whether it is the software or people we should be aiming to redesign. Focus then shifted towards the difficulties around communication in the lone UX designer situation, such as explaining to people what you actually do and how to sell the business case for UX.

In the afternoon I opted to indulge myself and opted for Stephen Anderson‘s (@stephenanderson) wonderfully example-heavy workshop entitled The Quest For Emotional Engagement: Information Visualization. First, Stephen outlined what he sees as a common UI problem that visualisation can solve, namely that we too readily and lazily reach for four often ineffective UI design patterns: spreadsheets, lists, grid views and dashboards. Their common shortcoming is their inability to present relationships in the information such as processes, proportions and changes over time. With the problems identified, we moved to a very detailed walk through Stephen’s 5-step process for information visualisation: identify opportunity → frame problem to be solved → identify nodes of information → explore ways to put that together → clean up, test, and iterate!


The speed boat innovation game, from Anders Ramsay.

After being impressed by his presentation on Agile UX on the opening day, I started the final day of the conference with Anders Ramsay‘s workshop around the same subject. In this very hands-on session, Anders introduced user stories as a means by which design can integrate with and support development in an agile (Scrum) environment. He showed (and we experienced) how product discovery through UX activities such as speed boat innovation game can be used to generate what he terms experience stories – user stories focusing more on why than what. By combining those experience stories with feature stories, the design of the user interface can iteratively take place. In the case of our workshop we did this using a design studio activity. “Standard” development stories can then be extracted from the design to feed into your developers’ product and sprint backlogs. As Anders reiterated throughout, for the best results designer and developers should be working collaboratively throughout. After all, “those who need a document should participate in creating it”.

Unfortunately, what started off as a really promising workshop from Leisa Reichelt (@leisa about adding user experience as a strategic aspect of an organisation ended up becoming something of a confusing muddle by descending into a lecture heavy on business jargon with few practical examples (not helped by it being a Friday afternoon at the end of a 3-day conference). Based on what I’ve picked up from her blog, her more sweary, ranty style might have better suited the material and audience.

Also, sponsors Red Gate put Nerf guns in the conference goodybag so get a free shout-out for knowing what all nerds want!

Infographics – info = graphics

February 9th, 2012

This article presents a concern I have regarding the development of infographics and shows an example of the kind of critical thinking I believe the world of infographics is unfortunately all too often missing.

In recent years, numerical infographics have become prevalent in print and on the web. There are even popular sites dedicated to aggregating and archiving them, such as Visual.ly and Daily Infographic. The sheer number of numerical infographics being produced inevitably means there is disparity in quality, but it is important that an overall quality is maintained to ensure the format remains compelling and, more importantly, trusted. Unfortunately, due to the primarily design backgrounds of most producers of infographics, including high-profile proponents such as David McCandless, the critical focus appears to be on aesthetic quality rather than numerical or analytical quality. By definition, infographics are the graphical communication of information, so if the either the information or communication elements fail under scrutiny then all we’re left with is a pretty, meaningless picture.

If the UK were a village of 100 people, it would have a population of 108…

I recently came across a collection of numerical infographics, Britistics, by a talented graphic designer called Matthew Rowett. At first glance the collection is an attractive and engaging proposition because of its wonderfully simple style and interesting subject matter.

However, on slightly closer inspection some serious problems with the information are apparent. In the first visualisation in the collection, a view on the UK population is presented by reducing it to 100 people grouped by age and gender:

Britistics - Age and Gender

Unfortunately, a quick bit of maths shows that 10 + 10 + 36 + 9 + 7 = 108, i.e. the 100 people have somehow become 108. After assuming I had misinterpreted the visualisation somehow and trying to figure out what was going on, including running it past colleagues, we were none the wiser. Tracing the data source seemed like the best option and, luckily, Matthew had followed the good practice of including data references. In this particular case the data came from an article in the Independent. Strangely, the data presented there suggested altogether different figures, with 17 youths mentioned. Furthermore, the numbers appear to not match in other ways as well. It is, of course, entirely possible that the numbers in the source article have changed since being sourced.

In case you are interested, a check against a genuine primary source, in this case the Office for National Statistics, suggests the following breakdown:

0-15 years Male 9.54%
Female 9.10%
Adults Male 32.39%
Female 32.41%
65+ years Male 7.28%
Female 9.27%

The issue here is that unlike most other design, data visualisation relies on factual accuracy that cannot be toyed with. If the underlying numbers are no good then the visualisation is fundamentally flawed, no matter how pretty it is. Furthermore, basic numerical mistakes in one graphic undermine all confidence in any associated material. In the case of Britistics, the various slipups – the aforementioned population breakdown issue is by no means the only numerical error – rather unfortunately cripple the entire piece.

Visualisation Design

Numerical issues aside, Britistics also exhibits the other worrying trend in numerical infographics: an apparent ignorance of the design fundamentals of data visualisation and human perception. That is the communicative, analytical element of the visuals are too readily compromised in favour of aesthetics, thereby at best merely frustrating those seeking to absorb the information or at worst distorting it or making it incomprehensible. The common result is that the graphic becomes little more than an awkwardly presented data table.

Britistics - Religion

The Religion section of Britistics, for example, presents a religious breakdown of the UK population. Although there is a bar chart of sorts, it is relegated in favour of the more attention-grabbing religious symbols used to label the chart. However, despite their prominence, the symbols and associated labels have been equally sized and therefore do not aid our understanding of the information in any immediate way. The bar chart itself has been “stacked” to represent 100%, thereby making it all but impossible to accurately compare segments since they do not share a common baseline. The result of this rather convoluted diagram is that although it seems interesting to a cursory glance, all we can usefully do when looking more closely is read the labels and values presented, i.e. it is no better than a simple table in assisting our analytical understanding of the information, and, arguably, even makes this worse than a table by introducing useless distraction.

An exceptionally useful starting point to gaining a suitable understanding of visualisation (and table!) design, I recommend a copy of Show Me The Numbers.

A critical eye?

It is perhaps unfair of me to have focused entirely on a single example by an upcoming designer, but both the Britistics collection and the reaction to it embody my concern about the direction numerical infographics are heading in. David McCandless highlighted the work on his blog, describing it as “soothingly nostalgic and fascinatingly simple”, but apparently failed to recognise either the numerical or visualisation design issues. Maybe the piece fell into McCandless’ “it can just look cool” category. Similarly, other comments about the work are all (justifiably) positive, but appear to amount to “it’s pretty” rather than an evaluation against its full intended purpose: to beautifully and effectively communicate real data stories.

Infographics lie on the boundary between the scientific and artistic realms. Unfortunately this means they must adhere to the principles of both worlds. Therefore, a deeply critical eye must be cast over both the numeric and aesthetic aspects of a design. This is the only way to ensure the infographic format remains relevant and trusted. Ultimately, I suspect that due to the somewhat conflicting disciplines involved, the most effective, insightful and beautiful numerical infographics will come from collaborations between scientific and artistic individuals rather than the largely design-led examples we see churned out so regularly these days.

Change is afoot in the lands of Flash and Flex

November 14th, 2011

Adobe has recently made a number of rather muddled announcements around Flash and Flex that have caused confusion and concern in the development community. In this post I hope to clarify what actually has been said and present my take on what it might actually mean for those of us on the receiving end.

Adobe has made it clear over the past while that, like the other big players, they see HTML5 as a major force for expressive and rich content on the web. Actions such as the acquisitions of PhoneGap and Typekit, the development of Edge and Wallaby and their contributions to WebKit, jQuery and the CSS3 specification have backed up their openness about where they see the future heading. Unfortunately, how they see Flash (and Flex) fitting into this vision has been a little unclear, and recent announcements have only confused matters further.

Image used under creative commons licence from Janielle Beh

Flash

The most misunderstood and misreported of the announcements is that Adobe is ceasing active development of the Flash Player plug-in for mobile browsers, i.e. there will be no new versions of the browser plug-in for your mobile phone or tablet (except for critical patches). Development of the desktop browser version of the plug-in is very much continuing, with various interesting new APIs and features already announced for Flash Player 12. Personally, I am not surprised by the announcement regarding the plug-in for mobile browsers.

As users on mobile devices we don’t really use, expect or want overly rich content on the browser because it tends to be cumbersome due to high network latency and expensive (depending on your data tariff). Rather, we go to apps whenever we want anything more than fairly static content. Without an equivalent ubiquity to that on desktop browsers, Flash Player is never going to be in any kind of position to even attempt to change that behaviour, and attempting to achieve that penetration looks like a complete non-starter considering the platforms blocking it outright and the vast resources apparently required to support it for the others

In addition to these reasons, the ubiquity of modern, HTML5-supporting browsers on mobile devices undermines one of the other strong motivations for the use of Flash Player. Namely, that it is a solution to the issue of backwards-compatibility and feature support that plagues development for desktop browsers. Few would argue that HTML5 as it currently stands on mobile devices is unable to reliably provide the (limited) richness desired for web content.

Flex

The (rather tepid) announcement regarding Flex that Adobe has made is that after the release of Flex 4.6 in a few weeks, governance of the SDK development is going to change significantly. It is going to be handed over to an open source foundation consisting of members of the current development team, developers from the community, members of the Spoon Project and contributors from enterprise companies. In some respects Adobe has in the past hinted that something like this might happen. At AdobeMAX 2010, Deepa Subramaniam mentioned that they were considering allowing community developers to submit patches that would have to pass through Adobe’s test suits before becoming candidates for inclusion, and this move seems like a logical extension of that train of thought. I feel the Flex SDK actually now requires the kind of TLC only a more open governance can provide because I think it could do with a focus on behind-the-scenes fixing and improving rather than glamorous, headline-grabbing new features.

Flex developers are understandably confused and frustrated by this announcement. As recently as AdobeMAX 2011, Adobe appeared to be giving a strong message about the future of Flex as its solution for enterprise-grade development, with a clear roadmap. The change of governance inevitably means a change of roadmap, regardless of how strong an influence Adobe might have over the new foundation. With hindsight, it is perhaps more obvious that Adobe’s enterprise-related angle has actually related to the future of Flash Player rather than Flex. However, rather than being upset by the timidity with which Adobe has approached this change and seeing it as a negative move, I think the Flex community and business and enterprises with a stake in the technology should embrace this change and realise the opportunity it potentially provides. There is a lot of money and time committed to Flex other than Adobe’s and Adobe is still fully committed to the technologies that underpin Flex, both Flash and AIR, so it is all but guaranteed for the foreseeable future at the very least.

Image used under creative commons licence from Janielle Beh

AIR

At the same time as all of this, Adobe has firmly re-stated its commitment to AIR. Most of the development of the desktop Flash Player plug-in carries over into AIR, and a whole number of new AIR features primarily targeting mobile devices have also been announced. With the recognition that users go to apps for rich content on mobile devices this makes absolute sense, given that, in my opinion, AIR is one of the best genuinely cross-platform development targets. Flex developers in particular should take heart from this, considering the close coupling between the Flex framework and the AIR API. Over time, we may start seeing the runtime shift more towards its JavaScript and HTML capabilities or, at least, applications taking more explicit advantage those capabilities, but at worst AIR would allow a smooth and transparent transition between the technologies.

Summary

Overall, my impression is that Adobe have a similar view on how HTML5 and Flash will play out in the short and long term to the one we laid out in our white paper. Namely, in the short term, the richer, more interactive and dynamic the content/application being developed requires, the clearer the choice for Flash/Flex over HTML5 is. However, over time, as tooling, developer skills and technology improve, and the spread of mobile devices continues at its current pace, HTML5 is likely to become the “better” choice rather than Flash/Flex.

The exciting prospect here is that, historically, what Adobe has excelled at is tooling rather than technology. Photoshop, Premiere, Illustrator, Flash Professional and others are unquestionably fantastic tools, and Edge has already hinted that Adobe could reach similar standards for HTML5 authoring. Adobe’s experience in bona fide IDEs comes primarily from its Flash and Flex tools so it would be reasonable to expect that any new HTML5 tools will feel fairly natural to any developers used to their existing IDEs. Again, Edge supports this view, since it is remarkably similar to the older Flash authoring tools.

It is interesting to contrast Adobe’s apparent approach to the future with HTML5 against that of Google and Microsoft. Where as Adobe appears to content to position itself strongly somewhat on the sidelines from where it might have a better vantage point to allow it to dive in when appropriate, Google and Microsoft seem, to some degree, more intent on outright dictation of the direction we’re all heading in. Regardless of how things pan out, it’s going to continue to make for a fascinating spectacle.

UPDATE: Head here for my colleague Colin’s more general thoughts relating to these announcements, they are well worth a read

UPDATE: The Flex team have added further information to their announcement that further justify my call for optimism.

A Critique of Radar Charts

September 23rd, 2011

This article presents a critique of radar charts, a chart type commonly used to display multivariate data, highlighting how they are poorly designed to effectively communicate information in the underlying data, and presents a number of more effective alternatives

Introduction

Radar charts, sometimes known as spider, start or web charts, are a two-dimensional chart type designed to plot one or more series of values over multiple common quantitative variables by providing an axis for each variable, arranged radially as equi-angular spokes around a central point. The values for adjacent variables in a single series are connected by lines, and, frequently, the polygonal shape created by these lines in filled with a colour. Beyond this there are many subtle variations that have different consequences with respect to the efficacy of the chart. These variations will be covered at appropriate points in the following critique.

Radar Chart from Wikipedia

Chart 1: Radar chart from Wikipedia

Critique

Axes and Values

The axes of radar charts represent independent scales for each of the quantitative variables under consideration. Therefore, barring occlusion, comparing values for a single variable between series is straightforward and relatively effortless since it merely consists of assessing their position along a line, something we are able to do without any thought. However, a number of distinct issues arise when attempting to compare values across different axes.

Firstly (and most easily grasped), by definition there is nothing prohibiting axes representing wildly different scales since they are nominally independent. This is shown at its extreme in Chart 2. Clearly comparison across variables is pointless in this case, yet it is something a radar chart is designed to encourage us to do. Hopefully from this extreme example you are also able to appreciate that even in subtler cases where the scales are genuinely independent, whether that be the inversion of the scale on one axis or slightly different ranges of values being represented, comparison is rather absurd. So much so that very few charting libraries or applications support this in any way.

Radar Chart by Stephen Few

Chart 2: Artificial radar chart by Stephen Few to show independent axis scales

Unfortunately, even with a common scale between axes, comparing values across them remains cumbersome and error-prone. This is because rather than the simple straight-line comparison our visual perception is hard-wired to perform that is found in “conventional” chart types, comparison in radar charts requires conscious thought to mentally project a sort of arc of rotation to map a value from one axis onto another, something we are not particularly adept at.

Radar Chart by Visiblox

Chart 3: Radar chart byVisiblox

In order to help general perception and, in particular, comparison across axes, radar charts usually display gridlines connecting axes when they share a common scale (giving them their traditional spider-web-like appearance). However, even with these gridlines it remains cumbersome to compare values on non-adjacent axes. For example, try comparing the Space and Comfort scores for Monster Truck in Chart 3. It requires a surprising amount of conscious effort, doesn’t it?

Radar Chart by Kap Lab

Chart 4: Radar chart by Kap Lab

Aside from the non-data ink gridlines inevitably add, they also introduce further issues to radar charts. Mainly, they tend to add confusion around axis value labelling by breaking the association by proximity used to associate a particular value label with a mark on an axis. This is very clearly demonstrated in Chart 1. It requires active thought to disassociate the labels from the gridlines over which they inadvertently lie. For example, what is actually the $60 gridline appears to be labelled $50 instead. Chart 3 demonstrates a commonly attempted solution to this problem that unfortunately makes the chart just as difficult to read, only in a different way. Here the labels are so far away from the axis that, once again, conscious effort is required to comprehend what should be an inconspicuous, almost sub-conscious interpretation aide for the chart.

Radar Chart by Dundas Data Visualisation

Chart 5: Radar chart by Dundas Data Visualisation

Occasionally the gridlines on a radar chart are presented as circles rather than straight connecting lines between equivalent values on adjacent axes, as in Chart 5. Conceptually, I do not understand how a chart can combine circular connections between axis values and straight line connections between series values. Surely they must adhere to the same notional underlying data space?! Otherwise the chart is fundamentally broken. If anyone feels like creating a radar chart using strictly polar data space for both gridlines and series shapes, could you please send me a link? I’ve never actually seen one, and always like a giggle…

Connecting Lines and Nominal Scales

The quantitative variables and their values represented on the various axes of a radar chart are, with the exception of some less common cases such as when plotting timeseries data, distinct and unrelated. Yet, by design, radar charts force the suggestion of some relationship between the variables by having a connecting line between values on different axis in order to create the series grouping, thereby misleading the user. To help clarify this point, the chart below is identical to Chart 5 except that the information is plotted using “conventional” cartesian coordinates rather than the (pseudo-)polar coordinates of a radar chart.

Line Chart of Radar Chart by Dundas Data Visualisation

In this more familiar, non-circular format it is hopefully much more obvious that we are in fact dealing with a nominal scale on the x axis. That is, the categories on the x axis are simply named entities that have no intrinsic order and do not represent quantitative values. As such, the relationship and incline or decline in value the connecting line implies is grossly misleading since we could arbitrarily change the relationships by rearranging the categories (something we are free to do because of their lack of intrinsic ordering). When shown this way, many of you will recognise that this kind of information is likely to be best presented as a bar chart in some form, depending on the specific purpose of the chart, as shown for Bar Chart of Radar Chart (Dundas)

Occlusion

Occlusion, in data visualisation, refers to the phenomenon where a part of the visualisation obscures another part. Clearly this should be avoided, or at least minimised, since hidden visuals prevents you from interpreting the information correctly. Unfortunately, the design of radar charts means significant occlusion is inevitable when multiple series are plotted, since they must be “on top” of each other. In cases where the fill colour of the shape of a series is relatively or completely opaque, such as Chart 5, it can be nigh on impossible to see particular values. In these cases, the gridlines are also at best partially obscured, thereby making it even more cumbersome to discern the value any any given point. In Chart 5 this is has been somewhat overcome by adding tick marks on top of the series, which, unfortunately, also adds to the overall clutter on the chart.

When transparency is used to circumvent the problems caused by solid fill colours it creates a new problem: the unavoidable tinting effect can make differentiating the underlying series or matching them to a legend very difficult. As such, the approach that suffers least from occlusion is when no fill colour is used, as in Chart 1.

Shapes

One argument given by proponents of radar charts is that we are naturally adept at seeing and evaluating simple shapes. Although this is true, it overlooks the major issue that the overall shape presented for a series on a radar chart does not leverage any of the pre-attentive attributes we perceive quantitatively. In essence, this means we are unable to attribute much genuine meaning to the shape of a series. The only patterns our visual perception can really discern in a data set presented as a radar chart are similarity and extreme outliers. Both patterns are just as easy, if not easier, to recognise in more effective alternative visualisations, such as line and bar charts, where the shapes also have quantitative perception. Consider the example radar charts above, can you reliably say anything useful about the respective series based on their shapes other than where they are similar or there is an outlier?

A further issue with the shapes presented by radar charts are that the area of the shapes increases as a square of the values rather than linearly. This can cause us to misinterpret the data since a small difference in values results in a significant difference in area, thereby exaggerating any difference when we follow our natural inclination to compare the size of the shapes.

Alternatives

There are numerous more effective alternatives to radar charts, depending on the information being presented. These include bar charts, as shown above, line charts (particularly for timeseries data), parallel coordinates charts and, quite simply, tables showing the raw figures. The latter is commonly overlooked, but when dealing with relatively small, simple data sets it is frequently the most immediate and clear way to represent the information. In more complex cases, a more effective alternative to a radar chart can be to use a concept called small multiples, devised by Edward Tufte, in conjunction with bar charts. Using this approach, individual series are separated onto individual charts, all sharing a common x and/or y axis scale to enable meaningful comparison across them. This way it is easier to gain both a higher level overview and investigate at more detail because the clutter, occlusion and related issues common to complex charts, and particularly radar charts, are removed. The following chart is a redesign of Small Multiples of Radar Chart by KapLab

Note that the x axis scale labels have been omitted because they were not present in the original example and, even after a little background research, I was unable to deduce them. As far as I can tell, the data used to create the original chart is fictional. If the genuine figures are of interest, I would suggest using Google’s Public Data Explorer.

An immediate advantage of using tables, bar columns or small multiples is that they naturally support ordering. With a radar chart, introducing ordering would require the starting point and direction to be explicitly indicated somehow since neither can be inherently deduced from the radar chart design. In the aforementioned alternatives, left-to-right or top-to-bottom ordering is immediately evident. Although ordering is rarely a strict necessity for a chart with a nominal scale, it can provide useful structure to the information that reinforces or enhances the story being told. For example, an ordering of best to worst for some value can add a great deal of clarity to a chart.

Worked Example

Based on what has been explained so far, it is hopefully clear that there are many more effective ways to represent the information shown in radar charts. To further underscore this and to show how a little more thought and effort put into the design of a chart can have a significant effect on its efficacy, here follows a worked example based on Chart 1.

As previously highlighted, the axis categories of a radar chart are frequently a nominal scale, meaning there is no relationship between their respective values. Therefore, it is immediately clear that a bar chart would be a better representation of the data shown in Chart 1.

Alternative Approach Bar Chart 1

In the particular case of Chart 1, it is a fairly safe assumption to say that the chart is ultimately trying to convey the over- and under-spend of the respective departments. As such, the following redesign focuses on the more important value, the actual spending, and its relationship to the budget, by reducing the visual salience of the budget values.

Alternative Approach Bar Chart 2

Furthermore, it can be assumed that in this case the relative over- and under-spend of the respective departments is the primary concern. By charting this difference as a percentage of the original budget and ordering the resulting bar chart from biggest overspend to biggest underspend, we have a very clear story of which departments are the worst offenders at both ends of the scale.

Alternative Approach Bar Chart 3

Conclusion

Hopefully it is clear that radar charts, despite the initial appeal due to their interesting appearance, are ultimately useless, in that they are unable to efficiently and effectively communicate information to users. Regrettably, many vendors of charting products continue to include them and users seem more interested in that first 5-second “cool” reaction than their ability to serve their purpose. Furthermore, vendors are, quite justifiably, assumed to be experts in their field, or at least to have more expertise than consumers. Therefore, so long as vendors of charting products continue to support and encourage fundamentally flawed features like radar charts, users will, unless educated otherwise, understandably continue to assume these features are perfectly suitable. Vendors then often argue that consumers request these features. And so a feedback loop of delusion has developed…

So I implore vendors of charting products to take a “brave” stance: please stop pointlessly including functionality that allows users to create flawed visualisations. Or, at the very least, stop implying they are good practice by featuring them on your websites and marketing material. You are collectively undermining the power of data visualisation by encouraging users towards cumbersome, frustrating charts that do not work, when really you should know better.