Developing custom pictograms for the mobile Web

A matter of trade-offs

Pictograms – miniature graphical representations of states, actions and
objects – made their way into the mobile Web over 15 years ago.
Several normalized (UNICODE, WAP) and proprietary (Japanese emojis, Openwave)
mechanisms are in place to enrich Web applications with pre-defined images.

The various approaches, with correspondence tables between icon dictionaries,
are reviewed in
another article.
However, one cannot always rely upon these standards:

• Numerous devices do not support any standard pictographic facilities at all.
• Many others do not implement all symbols of the reference sets; fall-backs are
  therefore needed to cope with missing elements.
• A service may require images outside
  normalized dictionaries,
  like the sign for RSS feeds
  
  or the indication of a hidden navigation menu
  .
• Finally, an organization may wish to enforce its own look-and-feel across
  platforms, since the typical appearance of default icons can be disparate:

  Symbol	DoCoMo	iOS	Openwave	UNICODE
  upper left
  password
  message
  pull face

Programming techniques for the ad-hoc implementation of pictograms entail
different compromises regarding the properties expected from the resulting
icon resources – apart from their graphical quality:

• They can be inserted in HTML and CSS markup and manipulated like normal
  textual data (alignment, scale, colour, effects).
• Once installed, they are persistent: they survive the end of a browsing
  session and the attendant flushing of the client cache.
• They are accessible to all mobile Web applications running on the
  terminal: different Web pages need not load and store their own version
  of the icons – just as each municipality need not define its own
  variant of traffic signs.

In the following, we describe common methods and discuss their applicability.
While the topic is treated in a resolutely mobile perspective, all techniques
carry over directly to desktop Web development.

System fonts

The only approach that fulfils all the aforementioned requirements consists
of installing an adequate typeface implementing UNICODE pictographs on the
terminal, and then configuring the client software to use it as the default
font. The requisite manipulations imply transferring a font package (the
TrueType format is practically always supported) directly to the end-user
device; what is usually straightforward with linux or Windows can become
quite involved on a mobile operating system:

Should the custom font be associated to a different writing logic (such as
happens with many Asian languages), then keyboard layouts and rendering
functions must be adjusted too, possibly affecting system libraries. A
misconfiguration may well result in an unstable operating system, so all
resources being altered should be backed up beforehand.

Because of its intricacies, specialized utilities have been published to
facilitate font installation on popular devices (such as BytaFont for
jailbroken iPhones). Nonetheless, the overall approach is only reasonably
feasible in a controlled environment where handsets are configured centrally
before being distributed to end-users – such as in a corporation or a public
administration.

Web fonts

CSS includes a construct for downloading an external font to a user agent:

This clause instructs the browser to retrieve font Iconic Fill from
the link matching a suitable format. Following the so-called “bulletproof syntax”,
it includes a redundant declaration for files of type EOT and a URL pseudo-parameter
to cater for limitations of Microsoft Internet Explorer; the identifier
appended to the SVG declaration is indispensable. The font appears in a further
CSS declaration:

In the markup, one inserts the desired symbol with a numeric reference –
or a letter or digit, if the font covers usual alphanumeric code points –
and encloses it within an element of class picto:

Sometimes, HTML elements are systematically endowed with a pictographic marker,
for instance when distinguishing different URL types. The following notation is
then preferred – it eliminates clutter from the HTML markup, and enforces
consistency by concentrating presentation characteristics in one CSS clause:

HTML-5 capable devices may tailor individual elements through
data attributes:

Like other external resources, Web fonts may be evicted from the browser
cache whenever the client software deems it appropriate, and utilization
is restricted to the site that loaded them initially. Furthermore, mobile
platforms impose restrictions on installable font packages (on Blackberry,
for instance, they cannot exceed 90 kB). On the other hand, they exhibit
two distinct advantages over custom system fonts:

• Since a Web font is always explicitly downloaded, all necessary symbols can
  be rendered even if the end-user re-configures the terminal with an unexpected
  default typeface that does not comprise the required glyphs.
• Since a Web font serves to style textual elements explicitly, it can be
  designed so that its symbols are judiciously placed in the UNICODE space –
  for instance within the Basic Latin block. This is valuable whenever the
  client does not recognize code points outside the Basic Multilingual Plane.

Practical Web services for converting a font definition into several formats,
with the associated CSS font-face declaration, can be found at
font2web,
fontface and
fontsquirrel.
Another free online font converter can be found
here.

Images stored locally

The Web Local Storage mechanism of HTML-5 serves to manage key-value pairs
kept persistently on the terminal. This makes it possible to avoid downloading
graphical resources anew at every browsing session, as happens with Web fonts.
The approach can be applied effectively to resources other than pictograms –
such as static pictures that appear repeatedly in a Web site. It consists of
storing images as BASE64-encoded strings locally, and, subsequently, retrieving
them to fill in placeholders for pictograms in the HTML pages before these
are rendered.

The landing pages of the mobile Web site include a Javascript function, activated
by the window.onload event, that initializes the persistent store
with all pictograms. We assume the existence of an ancillary routine
hasLocalStorage that determines whether the browser supports the
required capability.

Images are declared in a JSON file with a property list binding
pictogram names (“pid”) to their BASE64-coded bitmap
(“pval”):

Each pictogram is defined in the (X)HTML markup as an image, styled
with a specific class picto and explicitly typed via a
data-picto attribute, but with src left
empty. For instance, one may attach a telephone icon to a click-to-call
link as follows:

Every page featuring pictograms defines a function that, when
window.onload fires, walks through every img
element, checks whether it belongs to class picto, and if so,
fetches the appropriate BASE64 string and assigns it to the
src attribute. If data cannot be found in the local store,
a URL to an external bitmap is used instead.

Finally, a CSS declaration for class picto ensures that
pictograms are scaled to match the dimension of the surrounding
text, with possible spacing adjustments:

Images cannot be embedded as seamlessly as text, but they
entail one major benefit over font-based pictograms: the
flexibility to design rich polychrome symbols. Sharing of
pictograms put in local storage is of course limited to pages
from the same host and domain, but a bigger drawback is that
the technique is rendered inoperative whenever Javascript is
switched off in the browser.

Background CSS images

Absent the local Web storage facility, one can still rely upon BASE64
encoded images to deliver pictograms to terminals. Placing them inside
a style sheet is preferable, since the CSS file can be cached and shared
among several pages, whereas the direct inclusion of static strings in
HTML results in code duplication and ultimately larger payloads to be
transmitted over the air.

One CSS class is reserved for each pictogram, and the corresponding
bitmap drawn as background of the empty textual space allocated for
this purpose:

High-density displays are taken into account by setting up separate
versions of the style sheet for each pixel ratio of interest, and then
instructing client software to download the relevant one through
appropriate CSS media queries – possibly complemented by conditional
statements to cater for Internet Explorer. In (X)HTML:

One inserts pictograms in the markup by stating the relevant CSS
class name:

Developers will have no difficulty finding an abundance of
on-line
services
converting data files to BASE64 strings, as well as a few standalone programs
(notably datauri).
More advanced utilities parse entire CSS style sheets, extract URL to
external media, and replace them with embedded BASE64 data; a couple
of examples are
spritebaker (on-line Internet service) and
cssembed (standalone command line tool).

Sprites

The possibly oldest materialization of Web sprites may not be as well-known
as CSS background image sprites, but it optimizes graphical resources to a
comparable degree. It is especially well-suited for elements that are all
identical in size – a constraint unlikely to prove troublesome in the case
of pictograms.

Assuming the sprite is composed of eleven images N pixels wide by N pixels tall,
arranged consecutively without separation in one column, one sets up a kind of
viewport matching the dimensions of a single character through which the relevant
portion of the sprite is rendered:

The second rule relying upon an attribute selector can of course be
folded into the directives for individual pictograms. Although in
principle equivalent, a horizontal sprite is not recommended, as
many a mobile browser chokes on images that do not fit naturally
within the screen width. The final (X)HTML code includes a semantically
meaningful alt attribute attached to the pictogram and looks
like this:

If one can afford the software brittleness induced by pixel-oriented
declarations, then CSS background sprites may play a role – particularly
when optimizing purely decorative assets such as graphical separators,
repeating background textures, or when tailoring bullets in unordered
lists with icons. Interestingly, these customization capabilities are
also supported by old-fashioned built-in pictograms of the Openwave
browser.

There are numerous on-line sprite generators, configurable interactively
(alignment and padding of icons, colour table, image output format, etc).
This site
lists a selection of such utilities. SmartSprites
is a more elaborate tool to produce CSS sprites and manage the accompanying
style sheets. A tutorial on sprites can be found
here.

Minimal fall-back

If the methods proposed so far turn out to be inapplicable – as it frequently
occurs with low-end phones, older WAP handsets and PDAs running legacy software –
the only recourse left is the default already presented in section 5:
pictograms implemented as external images. Assuming style rules for class picto
identical to those listed in the aforementioned section, one obtains a simple markup:

Unsurprisingly, this technique entails practically none of the performance
benefits associated with built-in pictograms.

The matrix below assesses the compatibility of major mobile browsers against every
solution described in the present article. The software versions under consideration
encompass a broad range of device classes and generations. The table reveals that,
while the SVG format is recommended for icons and pictograms because of the well-behaved
properties of vector images under transformations, developers must be ready for a
(still) relatively inconsistent support for this standard across browsers, and be
wary of using full-fledged SVG instead of its “tiny” profile.

Browser	Web fonts	Web local storage	CSS data URI	Image sprites	SVG element
Android	≥ 2.2	≥ 2.1	≥ 1.5	≥ 1.5	≥ 3.0
Blackberry	≥ 6.0	≥ 6.0	≥ 6.0	≥ 4.6	≥ 6.0
Chrome	≥ 18.0	≥ 18.0	≥ 18.0	≥ 18.0	≥ 18.0
IE Mobile	≥ 10.0	≥ 9.0	≥ 9.0	≥ 9.0	≥ 9.0
Meego	≥ 8.5	≥ 8.5	≥ 8.5	≥ 8.5	≥ 8.5
MIB	≤ 2.2.2	≤ 2.2.2	≤ 2.2.2	≤ 2.2.2	≤ 2.2.2
NetFront	≤ 4.2	≤ 4.2	≤ 4.2	≤ 4.2	≥ 3.33
Nokia S40	≤ dp 2	≥ dp 1.1	≤ dp 2	= S40 6th	= S40 6th 2
Obigo	≤ Q7.1	≤ Q7.1	≤ Q7.1	≥ Q7.1	≥ Q7.13
Opera Mini	≤ 7.1	≤ 7.1	≥ 4.0	≥ 4.0	≥ 4.0
Opera Mobile	≥ 10.0	≥ 11.0	≥ 10.0	≥ 10.0	≥ 10.0
Openwave	≤ 7.2	≤ 7.2	≤ 7.2	≤ 7.2	≥ 7.0
Safari	≥ 5.05	≥ 5.05	≥ 5.05	≥ 5.05	≥ 5.05
SEMC	≤ 4.0	≤ 4.0	≤ 4.0	≤ 4.0	≥ 4.03
Symbian	≤ 8.3	≥ 8.3	≥ 7.31	≥ OSS3.0	≤ 8.3
TSS	≤ 2.5	≤ 2.5	≤ 2.5	≤ 2.5	≤ 2.5
UC Browser	≤ 8.9	≤ 8.9	≤ 8.9	≥ 7.94	≤ 8.9

1. Works directly on block-level elements, not on pseudo-elements.
2. Only available on devices running Opera Mini.
3. SVG availability depends on model, implementation often severely limited.
4. Works in paragraphs, not within headings.
5. Older versions not tested.

Resources on the Internet

Instead of firing up Gimp or FontForge to design custom pictograms,
developers can simply look to the wealth of (typo)graphical resources
available on the Internet.

These two
sites
are the first stops for determining which typefaces implement a specific
UNICODE block. Symbola is essentially
restricted to ASCII, Greek and Cyrillic, but encompasses many more pictograms –
including non-standard ones. Quivira
offers better support for European and Asian scripts (e.g. Armenian, Georgian,
Hebrew, Thai, Vietnamese), with a partial, but growing, set of pictograms. Both
free typefaces implement mathematical signs as well as glyphs for musical
notation and several ancient languages.

Relevant UNICODE block	Quivira 3.8	Symbola 7.07	Remarks
Enclosed alphanumerics			Circled digits
Geometric shapes			Triangles for “up”, “next”…
Miscellaneous symbols			Weather, games, zodiac…
Dingbats			Assorted pictograms
Misc. symbols and arrows			Orientated arrows
Enclosed alphanum. supplement			Squared “free”, “new”…
Misc. symbols and pictographs			Assorted pictograms
Emoticons			Smileys
Transport and map			Vehicles, tourist info…

Since their corresponding TrueType files weigh from 1.3 to 2.2 MB, these typefaces
are suitable solely as system fonts. One must recur to specialized font packages,
amounting to just a few KB to a few tens of KB, for binding downloadable resources
to mobile Web pages. Fortunately, there is an expanding supply of such fonts, both
free and commercial ones, professionally designed and covering numerous symbols.
Overlapping collections are presented at
css-tricks,
owltastic,
simurai and
iconsguide.

A plethora of icon sets, in bitmap or vector format, can be procured on the Internet.
The choice is facilitated to some extent by repositories offering a query mechanism
(by keyword, size, license, etc) such as icojoy and
findicons. The frequent round-ups at
smashingmagazine constitute a further
source of information. We emphasize a couple of extreme cases:

• The set published by FatCow
  comprises some 3000 colourful icons originally intended for desktop applications.
  Several of them are used in the compatibility tables of the present article.
• Pixelated and
  BacktoPixel feature icons with a
  minimalist design and particularly small dimensions (10×10 and 9×9 pixels).

The sheer number of pictographic resources, the diversity of application domains,
and the variety of requirements make any attempt at a comparative evaluation of
available font and icon sets a daunting endeavour. We present here a small sample
illustrating the stylistic range exhibited by current packages, based on a handful
of pictograms relevant for modern mobile Web applications:

• One pictogram present in every standard: the symbol for making a phone
  call, generally used for click-to-call links.
• Two symbols absent from pictographic standards, indicating a hidden menu
  (the “navicon” or approximations thereof), and an RSS feed.
• Two symbols available in some optional dictionaries: the cog traditionally designating
  a “settings” menu, and a sign denoting photographic functions.

Package	type	phone	menu	feed	config	photo	Attribution
Farm Fresh Web	icon						FatCow Web Hosting
Web0.2ama	icon						Christian Burprich
Frankfurt	icon						Patricia Clausnitzer
105 loops	icon						Pranav Pramod
Typicons	font						Stephen Hutchings
Entypo	font						Daniel Bruce
Font Awesome	font						Dave Gandy

There is a greater design and colour variability with icons,
whereas fonts provide flat, black and white glyphs, to be livened up with CSS.

The Web service at icomoon, running on
HTML-5 capable browsers, is invaluable to fine-tuning pictographic resources:

• Developers can mix and match symbols from various packages – including
  one’s own pictograms uploaded from SVG images or SVG font definitions –
  and then generate both a set of image files and a Web font out of them.
• The Web font is produced in WOFF, TTF, SVG and EOT formats, with a CSS
  boilerplate for @font-face declarations and related rules.
  It is very compact, as it excludes superfluous glyphs. Characters are
  assigned to the Basic Latin Block, the Private Use Area, or individual
  codes in UNICODE.
• Image files are produced in SVG and PNG; corresponding sprites are also
  generated, with a CSS file containing the necessary rules to use them.

One should of course study the relevant license for the permission to
create and use derivative works from a font or icon package processed
through IcoMoon.

Concluding remarks

Beyond issues of portability, each mode of implementing custom pictograms
produces subtly different representations. The screen dump below, taken from
an Opera Mobile 12.0 session with an HTML-5 page exercising all four main
techniques on the 105loops set, highlights their peculiarities
regarding scale, alignment, and text formatting. In this test, Web fonts
are black by default, whereas bitmap resources have been painted in various
colours. Only those used in the “Web Local Storage” test are
polychrome – but images in “Sprites”, “Data URI”
and “SVG image” could have been too.

Mobile Web sites are geared towards delivering synthetic information on displays
constrained in size, for immediate interactions in all situations of daily life.
Pictograms stand out from the surrounding text, and thus quickly draw attention
towards important content; they identify data elements, making it easier to skim
a page for an item of interest; they supplement styling attributes such as colour
and font when these become inapplicable (monochrome display, disabled CSS).

However, pictograms may impair accessibility when the client software can neither
handle them directly, nor map them to another appropriate representation (such as
a vocal enunciation of the associated concept). Thus, screen readers are often
confused by icon typefaces overriding the standard semantics of their underlying
code points – such as when letter O serves to depict a clock. Developers
can keep Web pages containing pictograms accessible in the following ways:

• Specify a meaningful alt attribute for pictograms implemented as
  external images with , as well as for Openwave icons and
  WAP fall-backs.
• Assign pictograms implemented as characters to adequate code blocks in UNICODE –
  such as “Miscellaneous symbols and pictographs” – or to
  the Private Use Area,
  whose members are generally passed over by screen readers but correctly displayed
  by normal browsers.
• When the pictogram is inserted in the HTML code, mark the enclosing element as an
  item to be ignored by screen readers:
  
  1	<span class="picto" aria-hidden="true">&#xE06E;</span>

• Use an aural property to force screen readers to skip pictograms introduced in
  CSS markup via the content directive:
  
  1 2 3 4 5

  [data-picto]:before {     font-family: 'IconicFill';     content: attr(data-picto);     speak: none }

Support for ISO pictographs is becoming common in newer smartphones, but equivalent
effects can be achieved on less well-endowed devices thanks to the methods
explained in this article. Hence, nothing more prevents developers from
taking advantage of pictograms to improve their mobile Web sites.

Acknowledgements

Many thanks to Sriram Sridharan from ScientiaMobile Inc. for his help in testing Internet Explorer Mobile.