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.