Olympic User Experience and Design

A great piece from the BBC's Nick Haley on the design thinking that has gone into delivering the BBC Olympic project across desktop, tablet, mobile and connected TV.

18 months in development, the design needed to accommodate the core sports audience as well as those who only become interested at big sporting events. The content structure builds on the design language already established by the BBC's UX team, but adds extra layers of detail as you drill down.

Extensive user testing was used to help the BBC team understand how people wanted to interact with the Olympics and to refine the placing of key information.

Illustrated with some initial post-it note sitemaps development sketches, this is a great case study for students of UX design.

camelCase

I’m seeing a lot of camelCase word structures at the moment.

camelCase, also known as ‘medial capitals’ in the OED, is the practice of writing compound words or phrases in which the words are joined without spaces.

The practice is known by many other names, the most common of which is Pascal case for upper camel case.

In UpperCamelCase, each element’s initial letter is capitalized within the compound and the first letter either upper case – as in ‘BlackRock’, ‘MasterCard’ or ‘PowerPoint’, or left as lower camelCase – as in easyJet’ or ‘iPod’.

An early systematic use of medial capitals is the standard notation for chemical formulae, such as NaCl (Sodium Chloride), that has been widely used since the 19th century.

In the 1970s, medial capitals became an alternative (and often standard) identifier naming convention for several programming languages.

Computer programmers often need to write descriptive (hence multi-word) identifiers, like ‘end of file’ or ‘char table’, in order to improve the readability of their code.

It was only in the late 1960s that the widespread adoption of the ASCII character set made both lower case and the underscore character ‘_’ universally available. Some languages, notably C, promptly adopted underscores as word separators (‘end_of_file’) however, some languages and programmers chose to avoid underscores, among other reasons to prevent confusing them with whitespace, and adopted camel case instead (‘endOfFile’).

One theory for the origin of the camelCase convention holds that C programmers and hackers simply found it more convenient than the standard underscore-based style.

Another account claims that the camelCase style first became popular at Xerox PARC. The PARC Mesa Language Manual (1979) included a coding standard with specific rules for Upper- and lower camelCase that was strictly followed by the Mesa libraries and the Alto operating system.

Since the 1980s, it has become increasingly fashionable in marketing for names of technology products (BlackBerry, YouTube), merged companies (PricewaterhouseCoopers, ExxonMobile, GlaxoSmithkline) and for naming your avatar in online gaming (SpongeBobSquarePants anyone?). However, camelCase is rarely used in formal written English and most style guides recommend against its use.

iPhone screen layout

In developing smartphone screen interfaces, the challenge is to fit the core feature set into the vertical screen area. Make the buttons too big and you need to lose some content. Too small and the interface is frustrating to use. But if size matters, how small is too small?

In the case of the iPhone screen (480x320 pixels), the structure of the vertical interface is established using a 44 pixel grid. This establishes the minimum size for a tap target on an iPhone, like a button or a list item, at 44 pixels – about the size of a fingertip touching the screen. By building the standard controls in proportion to that measure, apps can be developed for handheld devices that are actually built for hands, using finger-sized units.

That doesn’t mean that the button graphics have to be 44 pixels high. Instead, whilst a button graphic may be visually smaller, nominally within a 20x20 pixel box, the graphic sits within an active 44 pixel ‘tap area’ that extends beyond the button edges. That way, if touching slightly above and below, or to the left and right of a button, the tap is still registered by the button footprint.

At least one dimension of Apples’ standard controls always fits to this 44 pixel measurement. For example, although the QUERTY keyboard buttons are as narrow as 30 pixels, they still retain the 44 pixel height.

Rows of buttons are then fitted into multiples of 44 pixels. For example, the iPhone home screen organises buttons into rows 88 pixels deep.

Using multiples of 44 provides a natural rhythm in proportion to your fingers and helps establish the look and feel of your interface in harmony with other iPhone apps.

A periodic table of visualisation methods

© Ralph Lengler & Martin J Eppler

Like the London tube map, the periodic table is frequently used as a structure for classifying other collections.

This classification of visualisation methods works surprisingly well and displays some useful visual examples on rollover.

Visualising data III

A Structural Model for Choosing Visualisation Formats
In my previous posts on Visualising Data  and Practical Steps for Good Visualisation, I defined good data visualisation as something that can help researchers and other users to explore datasets and identify patterns, associations and trends, and also to communicate that understanding to others.

There are three different aspects to the way that visualisations can be used to communicate, so the final format of your visualisation should be informed by where it sits in the visualisation space (adapted from work by MacEachren on how people use maps):

• Communication or understanding: Is the visualisation presenting/communicating known information to an audience, or revealing unknown trends?
• Interaction: How is the user able to interact with the visualisation?
• Audience: Is the visualisation intended for public dissemination (eg, to a general audience), or private use (eg, by more technical audience)

After MacEachren (1994)

The diagram above shows these three aspects plotted in a three-dimensional cube, which shows how different types of visualisation can be classified by the way that they are used.

For example, visualisations that lie in the furthest-top-right corner are those that are primarily intended to communicate information to a general audience in a non-interactive way, such as presenting performance data to citizens using printed (or PDF) reports. Visualisations in the lower-bottom-left corner are those that are designed for specialists to actively explore and analyse information, such as using spreadsheet data to identify patterns.

Know who your audience are and what the message is that you want to convey, and design your visualisation accordingly.

Visualising data II

Practical steps for good visualisation
In my previous post on Data Visualisation, I highlighted the four key principles for good visualisation:

• Design for your audience: Think about how to emphasise the key point(s) that you are trying to convey to this audience with this particular visualisation
• Accurately represent the data: The visualisation should show the underlying data without distortion, and avoid common pitfalls that obscure the real information.
• Organise the information: The visualisation should have a clear purpose - communication, exploration, tabulation or decoration.
• Keep it clear: The visualisation should focus on the message(s) for the audience, and all visual clutter kept to a minimum (except where useful to highlight key points).

What does this mean in practical terms? For each principle there are a number of basic steps that can be taken to improve your data visualisation. Some of these are straightforward to implement, for example ensuring that you are not using decorative effects that hide the data. Others require more work, for example testing your visualisation with key audiences.

Design for your audience   

• Test your visualisation with your key audience
• Know when to use dynamic tools, when to use charts, and when to use tables
• Limit the number of categories shown in a visualisation - be selective in what you present in order to emphasise the key message(s)

Accurately represent the data   

• Don’t distort the scale to give undue weight to statistically insignificant data 
• Keep the zero on the axis scale
• For bar-charts, set the base of the bars to zero (not the lowest value)
• Avoid varying the size/area of objects in graphs, except to convey difference in values
• Avoid using line charts where data is only available for a small number of data points

Organise the information

• Bar graphs are good for showing how data changes over time.
• Pie charts are visually simple and easily understood, but can be manipulated to give a false impression.
• Scatter graphs or line graphs are used to investigate the relationship between two variables, providing sufficient data points are available.
• Bubble charts or triangular graphs can be used to show how the relative dominance of one or more factors combined can influence direction of travel.
• Radar or kite charts are good for comparing multiple factors for different options.
• Choropleth/Isopleth maps show areas shaded according to a prearranged key.
• Treemaps display hierarchical (tree-structured) data as a set of nested rectangles.
• Sound and motion can be used to show changes over time, or changes based on dynamic variables.

Keep it clear   

• Avoid using purely decorative effects such as 3D that can hide the data
• When choosing a colour palette, limit the number of colours used and ensure that different colours can be distinguished from each other
• Where colour is needed, use solid blocks of colour and avoid complex fill patterns
• Avoid using strong or bold colours for the background in a visualisation

Visualising data I

Although information design has always been one of the many skills a designer is required to have, the discipline of structuring information is now recognised as a distinct skill set within creative work. Data visualisation, made popular through the Guardian Datablog, is now a central tool in helping people to navigate and explore an increasingly complex data landscape.

Good data visualisation can help researchers and other users to explore datasets and identify patterns, associations and trends, and also to communicate that understanding to others.

Good data visualisations provide an effective representation of the underlying data that illustrates the answer to a particular question. They can inform non-specialist audiences and help decision makers make robust decisions based on the data being presented. Presenting data in this way can support strategic planning, performance monitoring or delivery improvement.

Good data graphics should:

• Make large data sets coherent, and encourage the audience to make comparisons between different data sets
• Reveal the data at several levels of detail, from a broad overview to the fine detail.
• Avoid distorting what the data has to say
• Present many numbers in a small space - but also emphasise any significant numbers
• Help the audience think about the important message(s) from the data, rather than about methodology

Principles of a good visualisation
Good data visualisation is simply another way to communicate with your audience, and the same principles of good communication design applies to data visualisation as with other ways of communicating;

• Identify your key audience;
• Set out the data accurately;
• Identify the point(s) that you want to make; and
• Create the clearest visualisation that conveys that message, using that dataset to that audience.

Design for your audience   
Think about the message that you are trying to convey to your audience with your visualisation - and focus on emphasising this message. Try not to cram too many key points into the visualisation.

Different audiences may need different visualisations. An appropriate design for a visualisation to be used by researchers exploring how economic indicators vary over time and between places may not be appropriate when showing the same data to non-specialists in order to emphasise key economic trends.

Accurately represent the data   
The visualisation should show the underlying data without distortion. For example, axes should always show zero to avoid exaggerating the importance of differences between data values.

Clear, detailed and thorough labelling should be used. Write out explanations of the data on the graphic itself, and label important events in the data.

Don’t try to do everything with one visualisation.
Organise the information in order to emphasise what you are trying to say to the audience. Don’t bury the key messages in a mass of detail.

Set out key points on the graphic itself, and label any significant or anomalous data events - the graphic should speak for itself.

Keep it clear   
The graphic should focus on the message(s) for the audience, and all visual clutter kept to a minimum. But don’t cut out all visual elements - things that emphasise the key message are useful if they help get your points across to the audience

Reduce and refine. Keep asking yourself whether your visualisation suffers any loss of meaning or impact for the audience if an element is taken out.

The next post looks at some practical steps for good visualisations.