What is an iBeacon?

iBeacons are small hardware devices that emit a radio signal that can be detected by iPhones and iPads running iOS7. The signal adheres to a particular flavour of the BTLE (Bluetooth Low Energy) Protocol, which has been adopted and customised by Apple.

The devices are really quite small (no more than a couple of inches long), cheap, and use very little power, meaning they can last for up to two years using a small coin battery like those found in wristwatches.

By making an iOS device able to detect the proximity of an iBeacon, Apple has enabled developers to add context-specific events to their apps. The primary sector for this is retail. Shops can now produce apps that deliver specific information about products as you wander around their stores.

Image source: estimote.com

Instead of retail, I’ve been working with researcher Emma Whittaker on a way to apply the use of iBeacons within the culture and heritage sectors. Doing so allows us to produce interactive narrative experiences within museums and public buildings that previously required the installation of intrusive specialist equipment.

What We’re Doing With Them

Emma is developing virtual sound environments and tying these into a game that can be played inside the museum, using visitor’s own mobile phones. What we’ve been looking at is getting an app to detect which room of the museum the visitor is currently in, in order to trigger certain events within the game.

The technology is quite new, and getting hold of beacons right now that work directly with Apple’s protocol is not as easy as you’d think, although more and more manufacturers are popping up out of the woodwork. I got mine by joining a group on LinkedIn and asking if there was anyone local who wanted to sell me some. In the end I went with a guy called Jose at Metavurt who has been very responsive, reliable and helpful.

Here’s what they looked like when they arrived. Not exactly pretty, but they work just fine:

Setting Them Up

You configure iBeacons over-the-air using an app on your phone. There are a few out there, I used one called LightBlue which a lot of people seem to recommend.

There are three main parameters that you can set – ‘UUID’, ‘Major’ and ‘Minor’.

UUID stands for Universally Unique Identifier (an oxymoron if ever I heard one) and is used to associate all your iBeacons with your business or organisation. It’s 32 characters long and you have to generate one using a terminal command on your computer. This prevents other people from messing around with your iBeacons for their own dark purposes I guess. When programming the app, you also have to use the UUID to state which iBeacons you are looking for.

Major and Minor are numbers that you can use to create a hierarchy within your iBeacons. A suggested use for this is that Major can be used to specify a particular building and Minor would identify rooms within that building.

LightBlue lets you set all these, although everything is displayed in hexadecimal (even though Major and Minor are specified using plain old decimal when programming the app), which takes a bit of getting used to.

I found this website useful for converting ‘normal’ numbers to hexadecimal.

Once this has been done, you can develop an app that does things when it gets near any of your beacons, a particular building, or an individual room.

As well as transmitting UUID, Major and Minor identifiers, there are a couple of other things that can be read in relating to proximity: ‘RSSI’, and ‘Proximity’.

RSSI is the raw ‘Received Signal Strength Indicator’, in other words the strength of the radio signal being picked up by your device. The nearer you get to the iBeacon, the stronger the signal becomes, although it is in reality quite erratic and effected by all sorts of environmental factors.

Proximity uses an algorithm that attempts to filter out some of the idiosyncrasies of RSSI and give you something a bit more concrete to work with. What you end up with are three states – ‘Immediate’, ‘Near’ and ‘Far’. Immediate tends to get triggered when the device is touching the iBeacon, Near relates to standing next to it, and Far has a much wider radius.

These can be used to prioritise between beacons if you are picking up more than one at a time, or make proximity-based events (Using Immediate as a trigger has obvious parallels with NFC)

Initial Findings

The following is based on initial sessions that took place in Plymouth City Museum and Art Gallery, using the beacons mentioned above, on an iPhone 5.

I was hoping that RSSI could be used to detect a fairly specific location within a room by placing a grid of beacons at 1m intervals. It turns out that this isn’t really possible as the readings fly around all over the place. Proximity is too slow and unresponsive for this purpose as well. People have looked into trying to position the user using trilateration (what your phone does outside using Wifi hotspots and phone masts when there is no GPS available) and for the same reason, this doesn’t work either.

The proximity property has about a five second lag between you actually moving and the change being detected on the device. This is presumably because the algorithm takes a sample of RSSI readings and then works out an average. This might be fine for someone entering a shop (they would arguably need a few moments to take in their surroundings) but not so good if you need a more speedy response.

Immediate is almost touching the iBeacon. Near has a radius of approximately 1 metre . Far is much larger; about a 10 metre radius. If these increments are no good to you, then you would have to write your own algorithm using the raw RSSI.

The signal can be partially blocked by solid objects, including people, which alters the RSSI and proximity readings.

Even when using proximity, the readings would drop out and jump around from time to time. So these states are good for detecting periodic events, but not so good for continual monitoring without some sort of further filtering.

Curiously, the signal is also affected by height in relation to the device. The least accurate readings were given if the iBeacons were placed on the floor. Placing them within cabinets at waist height (where you would normally hold your phone when in use) gave the best readings. Putting the iBeacons higher up also seemed to be okay, but not as good as waist height. Something to do with the placement of the BlueTooth receiver in the device perhaps?

Using iBeacons on a room-by-room basis was by far the most successful outcome. A fair bit of trial and error was needed to find the perfect spot to place each beacon, dependent on size, shape and contents of room.

Conclusion

Although not quite as versatile as I’d first hoped, there is still quite a bit of scope in terms of what iBeacons could enable within indoor mobile experiences. In particular, the fact that they are cheap, can be installed with a minimum of fuss and work with phones that people carry about with them by default, means that even small organisations can consider using them as part of their visitor ‘package’.

How are we planning to use them in particular? Well… here is a screenshot of an early app prototype:

Abstract

Locative narrative works – recorded narratives designed to be experienced within specified locations – tend towards the aural. This provides such works with the unique ability to overlay everyday places with invisible fictions.

Differing methods of delivery have been explored in the past; cassette walkman, mp3 player, PDA, mobile voicemail, each with an emphasis on listening. Yet the apparent opportunities offered by the smartphone touchscreen present a new challenge to the form. How should one go about crafting a visual interface for a predominantly sound-based experience? Should one even try?

This presentation will analyse the design processes undertaken during the development of The Letters, a locative narrative iPhone app based on material from the Dartington Hall archive. By recounting the visual decision-making journey, it will attempt to show how on-screen representation can support the aural story experience without detracting from it.

Introduction

I have been working with artist and researcher Emma Whittaker since 2010 on the production of locative narrative apps.

This presentation will analyse the design processes undertaken during the development of a recent project, The Letters, a locative narrative app that utilises binaural recordings based on material from the Dartington Hall archive. By recounting the visual decision-making journey, it will attempt to show how on-screen representation can support the aural story experience without detracting from it.

What is a Locative Narrative App?

Locative Narrative apps use technologies built into commercial smartphones to provide context specific interactive narrative experiences. Narrative trajectory is determined by the physical location of the user and alters as they move from one place to the next, enabling different story ‘nodes’ to be triggered as the user enters a particular place.

Today, the availability of consumer smartphones affords a number of advantages for the production of locative narrative works compared with older methods, such as mp3 players or PDAs. Firstly, smartphone handsets contain an array of sensors that, in combination with built-in software algorithms, enable you to determine the location of the user with a reasonable level of accuracy (more on this later).

Secondly, they are able to provide high-fidelity audio that can be manipulated programmatically. Thirdly, their ubiquity means that individuals or institutions wishing to attach a locative narrative work to a particular place of interest can do so without the need to invest in specialist equipment. One simply needs to place the app on the app store, tell people about it, then they can download it directly to their own phone.

Sound Over Vision

Locative narratives tend to be predominantly aural works. Unlike augmented reality, where a ‘virtual’ image is overlaid over a live video feed on a handset’s display, the story is introduced to a location through sound. This form of intervention combines recorded sound with sound and image sourced from the inhabited location, enabling comparison, contrast, ambiguity and so on between these elements. It can be argued that by not needing to experience the work through a device screen, an increased amount of transparency (lack of awareness of the media interface) is achieved.

This, then, presents a number of questions when designing a visual interface for a locative narrative app of this type:

• what needs to be communicated on the screen (if anything)?
• what should it look like?
• how can screen imagery support the aural experience, but maintain listening as the priority?

Node Based Narratives Require Some Form of Visual Feedback

The Letters project centers on material selected by Emma from letters of correspondence between Leonard Elmhirst and Dorothy Whitney-Straight that were written prior to the founding of Dartington Hall and it’s surrounding estate. Emma chose to situate the work in the landscaped gardens of the Hall, designed initially by Beatrix Farrand in 1934-39.

(Image credit: Herby Thyme)

As well as implementing innovative spatial sound recording and production techniques, Emma was keen for the app not to be a linear ‘audio tour’, but rather a work where meaning and story had to be assembled by the audience. This lead to the devising of a node-based narrative structure, where the user can listen to each node in any order they choose, and story coherence is derived from connections made from one node to the next.

Each node would relate to letters sent from a particular part of the world (Leonard and Dorothy were avid travellers), present simulated sound spaces from these distant points in space and time, and situate them within an evocative location in the gardens themselves.

In answer to ‘what needs to be communicated on the screen?’ a number of requirements were identified:

Fairly definite:

• the user needs to know where all the nodes are in relation to their current position
• the user needs to know how to get to a chosen node from their current position

Unsure:

• the user needs to be shown that they have entered/exited a node
• the nodes need to visually/textually represent the content of the audio in some way.

A branching narrative structure could facilitate giving aural instruction to the user at each choice point “go to the fountain or go to the tiltyard” but because of the node-based structure, the number of available choices would quickly become unwieldy. Yet if the user has no visual feedback at all, they must wander around until they happen across something. User testing showed that this was confusing and demotivating.

Map Development 1

The obvious solution was to provide some sort of map, showing the location of the user and the location of the nodes.

In terms of representing node activation and audio content, our first attempts had a screen that would pop-up when the user walked into the relevant area.

“what should it look like” was addressed by thinking about the thematic context of the app. A ‘between the wars’ infographic of British industry was used as a stylistic reference and the appearance of icons, typography and textures were adapted from this source.

There were a number of problems with this approach. When tested, the nodes were read as buttons, which users would try to tap to activate. At this point the map was static and the user’s position was displayed using a shaded red area which shifted as they entered different ‘zones’. This failed to successfully communicate to the user their location and purpose. The pop-up screen with the photograph and text was also problematic; it seemed to place too much emphasis on looking at and interacting with the screen. Audio became fragmentary and was no longer the main focus.

The next version introduced a moveable/zoomable map, with a dot to show the location of the user and styled the nodes as ambiguous fuzzy areas. This seemed better, although in bright sunlight the areas of fuzz and user location became difficult to see.

We removed the pop-up screen and had the audio play as soon as you entered a node. But this created all sorts of logical problems. Each clip is quite long in duration (about ten minutes) so what happens when someone walks out of an area in the middle of an audio sequence. Should it stop? Should it carry on? Should it gently fade away? If you walk back in should it resume from where you left off or appear as if it carried on regardless in your absence? Would the narrative still make sense if this happened? What should happen when you get to the end of an audio sequence? Should it just stop or start again from the beginning? How should all of this be indicated visually???

We tried all of these. There were many hours of frustration. None of it really seemed to work and the motivation for the user to perform any of the required actions remained unclear.

We were also experiencing technical problems in that GPS is fairly inaccurate (it can be out by anything from up to 40 metres) and subject to ‘drift’, so users could find themselves shifting in and out of a node, even if they were standing still.

A Fictional Conceit

A breakthrough came when Emma devised a new conceit for the app. Instead of it being just an app on the phone, what about if the app turned the phone into another piece of equipment? Although hardly a novel concept, it allowed us in this case to create a fictional context and motivation for why the user might want to do what we wanted them to do. It also gave me a slightly different visual direction. The idea of a pseudo-scientific device that allowed you to pick up imprints or resonances from the past was introduced. As the user walks around, the device enables them to detect and ‘tune in’ to these imprints and piece together fragments from the history of the place in which they are standing.

This meant designing the appearance of the device. Once again, I looked at material from the period; this time wireless radios and early TV sets.

I came up with this at first, which is pretty ugly:

After a time, it became this slightly more elegant object:

The fact that the device reads as ‘old’ then means that we could introduce visual and aural static discrepancies to mask the actual inadequacies of the ‘new’ technology being used. So, if a sound abruptly cuts to noise due to drift, then this doesn’t seem odd because you are using a slightly decrepit, Heath Robinson device, and not because the GPS chip on your iPhone is being unreliable!

Map Development 2

In-keeping with the device theme, the map now became more monochromatic and higher in contrast, which also worked better outdoors in bright sunlight. Here is the final version:

Further testing showed that people unfamiliar with the gardens still got disoriented easily, even with the improved map. Several testers suggested adding landmarks to the map.

The ones that worked best were the simple, icon-like shapes. The more detailed images were harder to identify at a small scale and appeared stylistically at odds with the rest of the map.

The final issue raised by testing was that of comprehension. The idea of the LociOscope device made sense, and moving to the areas of static to ‘tune in’ to events from the past seemed comprehensible to our testers. But the idea that each node aurally transported you to the place where the letters were written (apparent within the original pop-up screens) was being lost . So the names of the virtual locations were added, along with a graphic identifier that echoed the diamond shape of the LociOscope display, when a user entered a node:

Final App Screenshots

A user about to enter an area of ‘temporal disturbance’:

A slightly more zoomed-out view, with the user experiencing letters written by Dorothy whilst she stayed near the harbour in San Francisco (aligned with a swan-shaped water-fountain in the actual garden):

Conclusion

In answer to those original questions then, and in relation to this particular project:

• What needs to be communicated on the screen (if anything)?
  •     Does the user need to know where all the nodes are in relation to their current position? – Yes.
  •     Does the user need to know how to get to a chosen node from their current position? – Yes.
  •     Does the user needs to be shown that they have entered/exited a node? –Yes, but in an unobtrusive way.
  •     Do the nodes need to visually/textually represent the content of the audio in some way? In this case, text alone is probably enough.

• What should it look like? – Relevant to the subject matter, supporting fictional conceits within the story to aid comprehension and motivation.
• How can screen imagery support the aural experience, but maintain listening as a priority? – A single screen with no onscreen buttons is advantageous. Visual feedback should be there only when needed, as in the case of the user location ‘dot’ and map elements. In other words, the user can ‘dip in and out’ of the onscreen display, using it to navigate between nodes when required but ignoring it when attention needs to be given to the audio.

The Letters app is available now for iPhone on the iOS app store. Get it here!

For a while I’ve been interested in the peculiarities of using Twitter as a structural mechanism for delivering illustrated interactive narratives. The original concept was to create a series of parallel Twitter accounts, each belonging to a fictional character. Each has it’s own linear narrative ‘stream’. The reader can become aware of the narrative by entering one stream, and follow that one for a bit. Then, when the character meets another character, a dialogue between the two can take place using Twitter’s inbuilt ‘@’ messaging system. This in turn alerts the reader to the existence of the other character and allows them to change tracks and discover retrospectively what the other character has been doing. This may lead to the discovery of further characters, and so on:

Then last Autumn I met with Lytton Smith, a poet and lecturer in English and Creative Language, who was also interested in producing a Twitter-based fiction, although his interest was, understandably, from a poetic perspective. He proposed doing a version of his book ‘The All-purpose Magical Tent’ which is a collection of poems centering around events and characters belonging to a circus in 1930s depression-era America. I was keen to include imagery and see how this might work, and so suggested that we involve some of the BA (Hons) Illustration students that I teach to create images in response to his text.

Lytton reworked his book into a series of tweets to be produced by five characters:

These would all be experienced simultaneously, but with some of them messaging each other or referring to each other’s tweets. Lytton was also keen for the entire narrative to loop infinitely, so when it gets to the end, it starts again. This reflects the core theme of the text; the cyclic nature of the circus constructing itself, putting on a show, then being disassembled before moving on and building itself once again.

There was an open call to students, with each choosing the character they would most want to work with. At first I imagined each tweet having an accompanying image, but it quickly transpired that this would be too large a task for the number of people involved, so we worked out a good balance. Each student ended up producing three or four images and there were three to four students per character.

We had two group sessions, one in February where students pitched their roughs to Lytton, and another in April when visuals were presented. After that, they were pretty much left to produce their finals.

Here are some examples of the work produced, by Claire Knight, Jamie Bradford and Sophia Viney respectively:

In terms of publishing the tweets, we needed a way of automating the process, as having a real person bashing in tweets several time a day forever wasn’t an option. This was achieved using a brilliantly useful application called If This Then That, which allows you to link separate web services together and get events on one to trigger actions on another. These triggers can be events on a Google calendar, and since calendar events can be made to recur once a month, this forms the basis of the tweeting mechanism.

The way the final tweets are presented in the main Twitter website, or indeed through most Twitter clients, is in reverse-chronological order. This is so that the most current items are at the top of the list.

This is fine for what Twitter is intended for, but means that in the case of a narrative that flows from one tweet to the next, it runs backwards and becomes harder to follow. Images are also not presented alongside the tweets by default, and I was also interested in readers being able to interactively mix the streams together. So this meant building a web app that read in the streams, interleaved them based on their timestamp, flipped them around to run in chronological order, presented the images with the text and gave readers the ability to toggle the visibility of characters on and off:

The final result can be found at www.magicaltent.co.uk/repurposed

The individual Twitter accounts of the characters (should you want to follow them) are:

The Bearded Lady: @1beardedone
The Ringmaster: @theringled
The Tightrope Walker: @tropewalk
The Carousel Attendant: @garosello
The Lion Tamer: @leotame

Download .ATN (8KB)

Project on Github

What is This?

It’s a Photoshop action that, when installed, allows you to quickly select and export elements from a PSD to images suitable for use on websites and iOS apps.

It has the following features:

• Export to JPEG or PNG with alpha-transparency
• Automatically generate retina and standard resolution images for iOS
• Base export on a combination of selected layers or rectangular marque selection

In the Latest Version

You can now control the export area by making a rectangular marque selection on the canvas. This is a little bit more like the traditional ‘slice’ option in Photoshop but much quicker to and more intuitive to implement. Simply create a marque and run the action to export an image.  This is useful if you want to define a shape beyond the pixel bounds of your chosen layers, want to crop down elements, or you wish to ensure that a range of exported images share exactly the same dimensions.

Generated images now close automatically once the export has finished. This saves a click or two, especially with the iOS option.

The action has also been optimised from previous version so it runs a little bit quicker.

Installation

Download the action using the link above, then drag it onto your Photoshop application.

If this does not work, choose ‘Load Actions’ from the Actions Palette Contextual Menu and browse for the file.

Usage

1. Either select the layers or create a rectangular marque for the image that you wish to export
2. Select the relevant export option from the SuperSlicr actions in the actions palette.
3. Run the action.
4. Check the export settings.
5. Name and save the image in the usual way.

Licence

BSD 3-Clause Licence

Essentially you can do whatever you want with this, but can’t redistribute the code without including the original licence (i.e. you can’t sell it or pretend it’s yours).

Image Source: Kathryn Rotondo

Bret Victor in his ‘Brief Rant on the Future of Interaction Design‘ hinted at the issue, describing current projected visions as “pictures under glass” with more than a hint of exasperation.

Image Source: Michael Ocampo

Yet illustrator Katherina Manolessou made an insightful remark to me about this last year. She pointed out that the majority of mass-produced magazines and picture books were also printed on fairly surfaceless ‘glossy’ paper stock. There are clear parallels between this, and how images come to be presented on screen, she argued.

Image Source: Martin Wichary

Creating a sense of surface texture within interface design isn’t terribly fashionable right now. Microsoft wholeheartedly embraced the surface-less aesthetic with the ‘Metro’ UI for Windows 8, often displayed on their (ironically titled?) new tablet, which consists largely of white icons and text set against flat blocks of colour. This approach makes the virtual nature of the UI design explicit. It is not pretending to represent anything other than what it is; a screen-based paradigm with no physical characteristics. And a fish…

This may have been a conscious decision by Microsoft to place themselves in opposition to Apple’s increased use of skeuomorphism within the interface design of many of their iOS and OS X apps. It was perhaps one of the boldest design decisions made in the history of the company. So much so, that in a reversal of the usual dynamic, Apple appears to have taken it’s lead from Microsoft when devising the new look for iOS7.

Apple, whose origins are intrinsically linked with the first commercially available graphic user interface, had previously championed the use of visual metaphor as a way of making the unfamiliar familiar (and therefore friendly and intuitive) since day one. Many argued that earlier iOS examples pushed this logic into uncomfortably decorative realms. Faux stitched leather, green felting and a podcast app that depicted a Stazi-esque reel-to-reel recorder, all became points of derision.

The redefining of Jonathan Ive’s role to include UI as well as industrial design has lead to the streamlining of some of these approaches. But making UIs allude to familiar and physical objects is still an integral part of Apple’s design philosophy and the use of metaphor is still apparent in the appearance of iOS7’s icons and that shifty parallax effect.

Both the ‘skeuomorphic’ and ‘flat’ design trends are extremes. Both can be appropriate in certain circumstances, and fail in others, depending on what needs to be communicated to the user. They exist at either end of a sliding scale of visual representation; from the figurative to the abstract, and certainly aren’t the only two options available.

Let’s return to the physical world for a moment. Printed designs exist in ambient lighting conditions – even a plain sheet of paper, or those glossy books mentioned earlier, will have subtle tonal differences as they reflect light that strikes them from different sources.

Image Source: Thad Zajdowicz

We are conditioned to expect objects to have these characteristics which is why purely ‘flat’ designs can sometimes look a bit cold and artificial (I think the designers of iOS7 saw this, hence the slightly hurried gradients and layered blurring effects). Yet if designers overtly try to simulate real surfaces or objects, we aren’t fooled, we know they are fake and struggle to take them seriously.

So it becomes a question of balance. With the use of subtle lighting and textures, screen designs can include some of the qualities that we come to expect from real-world items. But by abstracting, honing, removing redundancy, we can ensure that those same designs remain true to their nature; being the representation of ideas, rather than unconvincing simulations.

I don’t want to live in a purely flat world. Do you?

Introduction

Children ask great questions. Each present us with a seemingly spontaneous idea – something unconstrained by preconceptions of how the world works.

In The Dog Exercising Machine, a Study of Children as Inventors, Edward de Bono (1971) states that “Children are good at generating ideas…They are not yet aware of how things should be done”. He purports that because children have yet to learn the rules by which the world operates, they are much more likely to think laterally, that is to arrive at an idea without building upon previous solutions.

The tablet computer is different enough from previous forms to provide an opportunity for devising new ‘book’ concepts in the way that a child might. The task however is being dealt with by adults, meaning that solutions are arrived at in a typically linear way. Current results remediate desktop computing design conventions with printed media metaphors. We are left with image and text that requires repeated left, right, up and down swipe gestures, a loose hybrid of the turn of a physical page and the mouse initiated scroll.

This is to be expected. This is how it usually works. Would it be idealistic to hope for anything more?

The following is about unashamed idealism. It is sometimes also about children. In fact, the story of the tablet computer begins with children…

What is a Tablet Computer?

A tablet computer is a lightweight, portable computer that uses a touch screen as it’s primary input mechanism.

The tablet computer was conceived in 1968 by Alan Kay, an American computer scientist who amongst other things invented the concept of overlapping windows and object oriented programming. A child prodigy, he had purportedly read 150 books before he started school and “knew that the teachers were lying to him”. Perhaps because of this, he became interested in the use of computers for education very early in his career. He was influenced in particular by the cognitive learning theories of Jean Piaget that outlines young children as ‘sensorimotor’ learners rather than passive receptors of information.

When working at the Xerox Palo Alto Research Center, and contributing to the invention of the ‘Windows Icons Mouse Pointer’ graphic interface, he delivered a paper titled A Personal Computer for Children of All Ages (1972), in which he essentially describes the iPad, 12 years before the release of the first Apple Mac. The ‘Dynabook’ as it was called, was intended to encourage active learning in children through problem-based interactions performed on a cheap, portable, wirelessly networked flat-panel computer.

Image source: Kay, A. (1972) A Personal Computer for Children of All Ages

Kay acknowledges at the start of his paper that the idea is “science fiction” but that at some point it would become possible. It takes 32 years before his vision is realised and marketed unsuccessfully by Microsoft in 2002 as a tool for business executives. The concept at this point is largely written off by IT analysts.

Apple, capitalising on the powerful brand association with the iPhone and a devoted core customer base, revive the concept of the tablet computer as a ‘family friendly media consumption device’ in 2010 with the launch of the ‘iPad’. This effectively creates a new market that other manufacturers quickly populate with competing devices.

Kay’s original vision closely resembles Apple’s plans for the iPad, to the extent that a current strategic aim is to try and replace textbooks with iPads in classrooms across the world.

image source: Flickering, B. (2010)

Apple has a view of what a tablet should be used for. But what about book and periodical publishers, authors and designers? For them it presents a puzzle – something that could offer a supplement to languishing print sales, but which presents enough of a leap from existing ways of working to cause confusion in terms of how best to achieve this aim.

What is Tablet Publishing?

• A medium, point-of-sale and distribution platform all rolled into one
• Possibility for authors to sell directly to a (global) audience without an intermediary (i.e. a publisher…)
• Something that still requires quality content and effective promotion to be a success

Platforms

• iPad
• Android Tablets (including Kindle Fire)
• Microsoft Surface?

Formats

• PDF – viewed in ‘reader’ software, fixed layout and orientation, can be designed, easy to copy and share illegally, not naturally suited to screen based presentation, easy to produce.
• eBook– viewed in ‘reader’ software, ‘flowed’ content, orientation aware, can’t be designed, can contain DRM (but possible to crack this), best suited for long-form publications such as novels and textbooks, requires some basic technical skills to produce.
  • eBook (fixed layout) – viewed in ‘reader’ software, fixed layout and orientation, can be designed, can contain DRM (but possible to crack this), best suited to simple illustrated publications, can be produced by a number of DTP-like authoring packages, not compatible with all eBook readers.
  • eBook (iBook) – proprietorial format exported by Apple’s iBooks author that can contain multimedia content but can only be viewed by the iBooks application on the iPad 2+
• Book App– standalone application, complete control over layout, orientation and design, next to impossible to obtain without payment, best suited to ‘media-rich’ interactive publications, require specialist skills to produce. Will only work on the platform it has been produced for.
  • Newsstand App – Apple’s platform for delivering periodicals through an app, that can be paid for via a subscription. The app acts as a shop window, library and viewer of purchased titles. Many Newsstand publications are straight copies of the printed version, with limited interactivity, rather like a PDF. This is presumably due to financial/resourcing constraints. Technically a Newsstand ‘issue’ can do anything that a Book App can do.

Looking at this, it would appear that app-based publications in particular, offer the most interesting potential in terms of commerce and flexibility of function and design.

It is also worth noting that publishers currently are focussing for the majority on producing apps for the iPad platform only. This is because it has the largest market share, and users have a greater tendency to actually pay for apps. Fragmentation on the Android platform also makes the development of high-end titles problematic.

What Isn’t Tablet Publishing?

• The Web – a pool of content, viewed as ‘free’, not necessarily optimised for tablets.
• eReaders – devices designed specifically for the task of reading eBooks. Include the Kindle and Nook (although tablet versions of these are also available).
• A Printed Publication – tactile, has a nice smell, looks good on a shelf, doesn’t run out of batteries or become technically obsolete. Could still be around and functioning in 100 years.

Why Publish (for a Tablet)?

Economics

Since the iPad launch in 2010, nearly 60 million iPads and 12 million Android tablets have been sold, with 300 million tablets predicted to be in use by 2015. Apple currently sells more iPads each week than other manufacturers sells PCs and iPads have sold faster than the iPhone when it was launched in 2007. 3.5 billion apps have been downloaded across both platforms, with books being the largest category in the Apple app store, being 19% of total number of available apps.

Marketing

Tablet publications could be used to target a different demographic, used in conjunction with and in support of other channels (such as print), to promote brand awareness and to cross-sell.

Design

Tablet apps enable you to do some things with a publication that aren’t possible any other way. More of this later on.

The Origins of Tablet Design Conventions

When designing for print, you have a fixed frame (the edges of the paper) within which to work.

When designing digitally for desktop/laptop computers, the frame is indeterminate – dimensions are determined by the proportions and scale of the display, and by the application ‘window’ that can be adjusted by the user.

Tablet apps differ in the sense that the display proportions are known, and the window paradigm is not used, so they are much more akin to a printed ‘page’. They can, however invoke content from beyond the frame using interactive features not possible with a static print.

Mag+

In Dec 2009 (five months before the release of the first iPad), Swedish media group, Bonnier, publisher of Popular Science, presented a video for Mag+, a tablet magazine concept their R&D department had been working on with London design studio BERG:

What is most interesting about this video is that many of the proposed paradigms for presenting and interacting with the content are very much present in publications being released now, over two years later.

In particular, the choice of arranging articles or sections in a swipe-able horizontal sequence of ‘pages’, which in turn can be scrolled vertically has seen wide adoption. This method combines two major GUI models that have been in use since the introduction of WIMP interfaces in the 1980’s, namely ‘cards’ and ‘scrolling’. Cards have a fixed frame and as content increases, text and image flow into the next card and the total number of cards increases. Scrolling uses a flexibly sized frame, that acts like a ‘window’ to content that extends beyond the viewable area, which can be brought in to view using ‘scrollbars’.

The web has adopted a strong bias towards (vertical) scrolling over card-based or other presentational methods. Oliver Reichenstien offers an explanation for why this might be.

Mag+ and consequent iPad app books tend the favour the left/right card model, combined with vertical scrolling in some instances.

Whether this is the best way to present content in an app book is perhaps open to debate.

Bret Victor, designer of the initial user interface concepts for the iPad, in his article ‘A Brief Rant on the Future of Interaction Design’, argues that focussing primarily on “sliding a finger along a flat surface” fails to exploit the full range of possible interactions that are available within the tablet and future computing devices. Worried that we are travelling down too narrow a tunnel, he advocates a more “ambitious, long range vision”.

The Nielsen Norman Group Studies

Some key themes arise from the two NNG reports on iPad usability:

• App designers should ensure perceived affordances / discoverability
• There is a lack of consistency between apps, lots of ‘wacky’ interaction methods. Designers should draw upon existing conventions (either OS or web) or users won’t know what to do.

These are practical interaction design observations, but from a particular perspective, that of perceptual psychology. These conclusions are arrived at through a linear, rather than lateral process. By giving weight to building upon existing convention, because they are familiar to the user, there is a danger that genuinely new ideas (and the kind of ambition called for by Victor Bret) within tablet design will be suppressed.

Kay’s vision of the Dynabook came from lateral thinking, and thinking about how children learn. Shouldn’t the items that we design for this device be generated in the same way?

Recently an iPhone app Clear received a lot of attention not because of what it was (a ‘to do’ list manager, of which there are dozens) but because it’s interface design went against the Nielsen/Norman stance on providing perceived affordances and relying on convention.

In order to operate the app, Clear requires the user to learn an unfamiliar set of interaction methods, without any clues or as to what these might be. It’s positive reception shows that app design does not necessarily need to rely on prior user interface conventions, like NNG suggest, as long as the interactions are simple, distinct from one another, follow some form of logic, and provide feedback to the user.

The Apple iOS Human Interface Guidelines

These are Apple’s attempt to define how one should design for interactivity within iOS apps. Some of it is technical, some of it ideological. If you don’t adhere to it, your app may get rejected when submitted to the App Store.

One section of note is under the ‘User Experience Guidelines‘ heading. Under “Consider Adding Physicality and Realism” and “Delight People With Stunning Graphics”, Apple places an emphasis on Skeuomorphism in the appearance of iOS interface elements. It gives default iOS apps such as the Contacts and Notes apps as examples of how this could be achieved.

The document argues that the use of illusionary surfaces and objects will lead to a more intuitive and pleasurable experience for the user. It also, yet again, looks to prior conventions for solutions rather than starting afresh.

Current Examples and Critique

Current iPad book/magazine publications use a combination of methods borrowed from older digital forms such as the web and smartphone apps, the Mag+ prototype, Nielsen’s recommendations, Apple’s human interface guidelines and some other seemingly unique elements.

Wired Magazine

Wired was one of the first attempts at an iPad magazine app, and perhaps because of the subject matter, there has been an editorial decision to make the experience as multimedia heavy as possible. Each article begins at least with an animated headline and sometimes an animated sequence too. These tend to grate by the third or fourth viewing.

Within articles, there are sometimes slideshow or carousel elements, which work best for images and don’t seem a good idea for copy text. Sometimes these interfere with the swiping action of moving between pages. The method for operating these elements is also inconsistent. Some adverts use multi-column text which is a problem when the top or bottom of a column is cropped during scrolling.

Landscape orientation is not supported. Each layout is fixed and text can’t be resized or copied. Because of the multimedia content each issue is quite a large download.

Wallpaper*

This publication is similar in approach to Wired, but with less reliance on multimedia elements. There are some strange interaction choices, such as having some text columns scrollable, and others fixed within a single layout, for example.

A key feature is being able to tap hotspots within a photograph to view descriptive annotations. These are handled a bit clumsily, and the type treatment and position of these is inconsistent, meaning the experience feels at times awkward rather than pleasurable and informative.

The Guardian iPad Edition

The app for the Guardian newspaper was criticised on it’s initial release for being too static, but wisely chooses to focus more on the experience of reading than on overstated interaction methods. Overall, this approach seems a more natural fit within the tablet form whereas Wired and Wallpaper* feel more ‘forced’. The app experience is also distinct from that of reading a printed paper or a website, although isn’t a huge leap from either.

The hierarchy of the grid based layout can get a bit confusing however, doubly so with the two-tiered scrollable menu – what is the difference between the top categories and a ‘section’, for instance? Once buried within an article, it is also hard to get a sense of where you are in relation to other articles or sections.

POST Matter

This independent publication stands out with its use of enigmatic full screen video backgrounds, creating a unique tone that could not be achieved in print. This technique somehow appears more integral to the reading experience than the Wired ‘skip to read’ approach, even though they are essentially doing the same thing.

Navigation once again can be confusing, with different swipe conventions being used across different sections. Some in-page interactions also interfere with the swiping between pages gesture. The use of parallax scrolling pull-quotes works well though.

Astronaut

This is another independent publication that seems better thought out than some of the more mainstream contenders. This employs consistent interaction methods, although swiping image slideshows within a page can cause the entire page to move, and the title page for each article uses the triangle ‘play button’ convention as a static graphic, which is misleading.

What does work well is the combination of video and text in a way that is normally associated with image and text. It seems quite natural to watch a video and casually scroll through some copy relating to it at the same time.

Color Uncovered

This publication promotes the Exploratorium museum in San Francisco. It contains a series of interactive articles and experiments relating to the perception of colour. What makes it unusual is that is acknowledges the portable and physical nature of a tablet and plays with this, asking users to put drops of water on the screen or hold the device parallel to the floor and swing it about.

Skulls by Simon Winchester

Skulls is by Touchpress, who mostly produce illustrated reference titles in the Dorling Kindersley vein. Their work is celebrated as demonstrating the potential of the medium, as well as being profitable, proving that tablet publishing can have a viable business model.

The book has a vast amount of content and is technically impressive. There are some clever touches, such as utilising the device orientation as a way of switching between a richer level of interaction or more reading-focussed form of presentation.

My main criticism is that it whiffs slightly of late 1990’s CD-ROMs made in Macromedia Director. In other words there is a sense that this is drawing from past models rather than finding truly innovative solutions.

Summary

Certain aspects of these examples are successful whereas others seem problematic. The problems arise from either usability errors or an over-reliance on multimedia elements that detract from the reading/viewing experience.

On a larger scale, there seems to be a lack of real invention or exploration of what may be possible. Most examples are only an iteration or two away from pre-existing forms.

The worry here is that as current solutions become established as convention, true innovation within the form may be stifled.

Jessica Helfand in her essay The Dematerialism of Screen Space (2001) critiques the phenomenon of design practise being led by developments in software engineering. She argues that designers should take the initiative:

“design must submit to a series of commands and regulations as rigourous as those that once defined Swiss typography. Aesthetic innovation, if it indeed exists at all, occurs within ridiculously preordained parameters: a new plug-in, a modified code, the capacity to make picture and words ‘flash’ with a mouse in a non-sensical little dance. We are all little filmmakers, directing on a pathetically small screen – yet broadcasting to a potentially infinite audience. This in itself is conflicting (not to mention corrupting), but more importantly, what are we making? What are we inventing? What are we saying that has not been said before?”

Helfand here is referring to the web, but her argument applies equally well to designing tablet publications. Designers of book and magazine apps should be asking themselves those last three questions. Since tablet publishing conventions are in the process of being formed (like child invention), we have a unique opportunity right now to influence their direction.

Approaching The Problem Like A Child

By looking at a tablet as if encountering it for the first time, we might note:

• That it is a small metal and plastic rectangle that contains a panel that shows text and images (still and moving)
• That it can sometimes do things when I touch the panel with my finger

By perhaps trying to generate ideas without any pre-conceived notion of what is or isn’t possible, we might arrive at a number of ideas, such as:

• A publication that contains all it’s content on a single sheet, and is navigated either horizontally or vertically.
• A publication where pages connect and take you in multiple directions, like following paths in a maze.
• A publication where you have to pan and zoom around a large map-like content area (Yes, a ZUI)
• A publication that requires you to rotate the device because different pages are facing in different directions.

These may not all be practical, but at least suggest that there are new avenues that aren’t currently being explored. Can we take this any further?

By exploring aspects of what a tablet can do, we can discover that also:

• The display panel emits coloured light from almost the entirety of one side
• It can react to environmental light levels
• It can record and process and display still and moving images
• It can record, process and playback sound
• It can work out where I am in the world
• It can send to and receive information from to a vast worldwide network of information
• It can tell what direction it is facing
• It can tell what speed it is travelling (or if it is moving at all)
• It knows it’s own orientation within 3D space

Developing New Ideas For App Publications

Looking at the device capabilities suggests a categorisation between two possible method types that either process received data to create new material (generative) or respond to a stimulus with pre-authored content (responsive). Furthermore, the results could focus on drawing the user into the virtual app space (immersive) or could use the portable nature of tablet to extend the experience into the physical space inhabited by the user (something I have called ’emersive’).

Generative (emersive)

• Books that project coloured ambient light and/or audio into a darkened space

Generative (immersive)

• Books that display abstracted video/audio from cameras/microphone, collaged or augmented with pre-designed content
• Books that contain location specific content from the internet combined with pre-authored/designed content

Responsive (emersive)

• Books that require you (instruct you?) to move between environments to experience or unlock content
• Books that require you to perform physical tasks and record the results with the camera/microphone

Responsive (immersive)

• Books where content adapts in response to movement and orientation of the device rather than touch interaction

By undertaking this simple exercise, it conjures up some intriguing concepts for app publications that aren’t yet being fully explored. Not all may be workable, but they at least raise a question – is the BERG/MAG+ solution the only way that this can be done? Probably not. Should we also be exploring other possibilities? I, for one, think so.

Conclusion

Innovation in current app book design is being constrained by a reliance on convention, resulting in ‘repetitive swipe injury’. By approaching app book design as if one has a limited awareness of prior convention (like a child), more ambitious, forward-looking outcomes can be reached. Jessica Helfand again:

“…our response has been a reactive one: to technological imperatives, to pragmatic considerations, and to each other. To think beyond these practicalities is to respond to a broader and more compelling challenge: the idea that, as designers, we might begin to tackle the enormous opportunities to be had in staking claim to and shaping a new and unprecedented universe.”

This post is a far from exhaustive list, but serves as a ‘way in’ to the subject. Suggestions for further reading are given at the end of the post.

1. Page Hierarchy

The following diagram demonstrates a typical web page hierarchy, in order of importance:

1. Site Title or Logo
2. Header Area
3. Primary Navigation
4. Page Heading
5. Primary Content Area
6. Sidebar / Secondary Content Area
7. Footer Area

Eye-tracking tests performed by the Neilsen Norman Group show that users tend to view web pages in an ‘F’ shaped formation, starting approximately in the top left and then moving along and down, with attention dissipating as the page is traversed.

This is why key elements such as banners, logos and menus tend to be positioned around the top left corner.

These viewing patterns can, of course, be subverted through the manipulation of formal devices such as colour, shape and scale, but it is useful to be aware of this behavioural tendency.

2. Layout

Non-determinate Page Dimensions and Ratio

Web ‘pages’ differ from a printed sheet in that they have no knowable width or height. A web page can be viewed on a high-resolution monitor measuring over 2000 pixels in width, or a phone that uses a mere 320 pixels. Physical pixel densities (the actual size of the pixels that make up the design) also vary widely.

Furthermore, a PC monitor will be landscape in orientation, whereas a smart phone will tend to be portrait. PC users can also adjust the size of their browser window, making it impossible to know what dimensions or ratio a page will be when it is viewed.

A solution is offered by modern web coding techniques, that can enable a layout to adapt in response to its display context. This is known as ‘Responsive Design’, a term coined in 2010 by Ethan Marcotte in his article for A List Apart: http://www.alistapart.com/articles/responsive-web-design/

A good example of this in action is John Hick’s design for his company’s website (resize the browser window to see how the layout changes) http://hicksdesign.co.uk/

Therefore, it becomes necessary when designing to consider a range of probable layout contexts, and produce a layout solution for each. As a starting point, how your design will fare under the following page widths could be considered:

• 1000 pixels (Average resolution PC display, minus scrollbar)
• 768 pixels (Tablet in portrait orientation)
• 320 pixels (Web-capable Smart Phone)

Scrolling and ‘The Fold’

Web pages can contain larger amounts of content than would be possible when using the above dimensions by increasing the page height and allowing the user to scroll. However, when the page loads it is rendered from the top down, so (if on a PC) the user will at first be presented with the top 600 or so pixel rows only. Anything that requires scrolling before it can be viewed is considered below ‘the fold’, a term borrowed from the newspaper publishing industry. Items such as main navigation, calls to action and primary content should be displayed above the fold as these will be seen first. Items lower down in the content hierarchy can go below.

The concept of the fold in web design has existed since the late 90’s and there are many debates as to whether it is still relevant today. Those against cite the proliferation of varying device screen sizes (making the 600px rule meaningless) or a recent trend to create scrolling narratives that end with primary content placed at the bottom. A nice balanced view on the topic is available here.

No ‘Recto Verso’

This means that unlike a paginated publication there is no natural delineation running through the centre of your design, no ‘spread’ to run content across, and no option to create a sense of rhythm or contrast through the act of the page turn.

What you have instead is a single vertically scrollable sheet, that has the potential to be infinitely tall. So rhythm and contrast moves from a horizontally segmented experience to a fluid vertical one. With web pages you also have the additional ability to reveal and hide content within the page using interactive elements such as tabbed areas, accordions and carousels.

‘Chunk-ing’

Users tend to dislike reading large amounts of on-screen text in one go. Breaking large blocks of text into easier to manage ‘chunks’ and allocating these to different sections within a layout or even across several pages can alleviate the issue.

The interactive nature of the web means that users can be given control over the quantity of text they receive. If a page presents a summary first, with a link leading to secondary page that offers more detail, then users are given the power to delve deeper, but only if and when they choose to.

Printed magazines and newspapers will frequently span a mass of text across multiple columns to make it easier to digest. This does not work so well on screen, as the ability to scroll leads to the cropping of the top or bottom of each column, making reading between columns unworkable. Columns can be used to distinguish different areas within the page heirarchy however, and the use of ‘sidebars’ to hold secondary or tertiary content is common practice.

Use of Grids

All web page elements, regardless of their shape, are rendered within an invisible rectangular box. Therefore grid-based design is difficult to avoid! The following link will download some paper and Photoshop grids for web design purposes.

Download Sketch Sheets

The post accompanying these sheets can be found here

3. Typography

Choice of Typeface

Until recently, typography on the web was restricted by the number of typefaces you could use, known as ‘Web Safe Fonts’. This was due to end users needing to have a font installed on their computer in order for it to display within a design. If a user didn’t have the correct font installed, text would be displayed using a default typeface, usually Times New Roman. Since there are only about twelve font families that it can be assumed are installed on the majority of computers in the world, these were the only typefaces that it was ‘safe’ to design with.

More details on which fonts can be considered ‘web safe’, including a downloadable cheat sheet can be found here.

Workarounds for this limitation included the use of embedded images or Flash documents to represent text, or drawing text directly on to the page using JavaScript. All of these methods had significant drawbacks, and could only be used in moderation.

Recent developments in browser technologies and CSS, a stylesheet language for defining web page appearance, have introduced a new method that allows designers to temporarily install a font to an end user’s computer for use on a web page. This means that in theory, it is now possible to use any typeface that you like in a web page design.

In practice, this is not quite the case.

The first issue relates to licensing. From a legal perspective, if an end user installs a commercially licensed font to their computer, even on an unknowing and temporary basis, they need to own the license to do so. This means having to buy the font. Since it is far-fetched to expect an end user to purchase elements of the design of a page before they can be allowed to view it, using commercial fonts with this new technique would seem, at first, out of the question.

Services such as TypeKit https://typekit.com/, recently acquired by Adobe, seek to address this problem, by allowing designers to effectively ‘rent’ commercial typefaces for use on a web page through the use of a subscription model.

If you (or your client) can’t afford to do this, there is a growing pool of open-license fonts that can be used. The Font Squirrel website http://www.fontsquirrel.com/ provides a searchable catalogue of fonts that can be used freely and also provides a tool for converting fonts to the four main formats required by different browsers.

Google also provides a free font service http://www.google.com/webfonts but beware! Many of the typefaces available here have not been designed for the screen and become illegible at smaller sizes on systems running Windows XP, which does not smooth font edges by default and is installed on over 30% of all computers worldwide.

Having a greater choice also means being more responsible as a designer. Just because you can use a range of different typefaces, doesn’t mean that you should. All the principles for selecting and combining typefaces that apply to print, apply equally to the web.

Line Height and Line Length

Line height, (type body height + leading) needs to be greater for the web than is typically used for print, for ease of readability. As a general rule, line height looks most comfortable when set between 140% – 180% of a type’s body height. This can be controlled using the line-height CSS property.

Traditionally, the suggested optimum line length for screen reading is around 50 – 75 characters http://baymard.com/blog/line-length-readability, although a quick Google search will reveal a range of opinions regarding this, with some suggesting that up to 100cpl is permissible and does not significantly impede readability.

Text Scale

Screen text size is measured using pixels, rather than points, as physical type scale is dependent on an end user’s display resolution and so is impossible to ascertain.

Text with a body height of less than 16 pixels can become difficult to read.

Text Direction

Screen based text that runs in any direction other than horizontal can be difficult to read.

Unlike with print, it is not possible to rotate a desktop/laptop computer monitor to read a line of text that runs at a non-horizontal angle. Even with a phone or tablet, the viewport will tend to keep the page level whilst the device itself is rotated.

Current browser rendering of text running at a non-perpendicular angle also generates baseline positioning errors:

…although this may be improved in the future.

So, use non-horizontal text with caution.

Figure/Ground Relationship

Contrast between text and its ground is important for readability, however too much contrast on screen can cause eye strain due to colour being generated with light rather than pigment.

It is best to avoid fully black text on a white ground or the reverse. A dark grey against a very light grey tends to be more readable. When working with colour, try to consider how the contrast may affect readability.

Be wary of placing text over a texture or photograph that contains large variations in tone. Print design rules apply equally to the web in this regard.

Dynamic Text

Different web browsers, such as Internet Explorer, Firefox, Chrome and Safari, will render text differently. The precise weight, size and hinting of characters will vary depending on which browser is used to view a page. The situation is much better than it used to be, but there are still discrepancies:

Users can also change the size of text on a page to make it more readable.

Furthermore, on many websites, text content may be generated dynamically, meaning that you may not know the exact copy that will appear in an aspect of your design.

It is also not possible to hyphenate web text without JavaScript workarounds.

These combined factors can often result in widows, orphans, rivers, overtly ragged edges to text blocks and other typographic misdemeanours.

At some stage you will have to accept that you do not have the same level of control over typography for the web that is available when designing for print. However, testing a design with a range of different placeholder texts can sometimes help.

4. Interactivity

Hyperlinks in Text

Hyperlinks contained within a body of text can be made easily discernible through the convention of underlining. Colour can also be used, but be wary of identifying hyperlinks by using a different typeface, weight or style to the rest of the body text, particularly during cursor hover effects.

Underlining text that isn’t a hyperlink will be confusing for the user.

Buttons

Buttons should be obviously clickable/pressable. They also need to communicate to the user what will happen when then button is pressed. Concise, clearly defined text can be used, or an unambiguous icon, or a combination of both.

Interactivity should be intuitive. If you need to give the user written instructions to perform an action, such as “Click here to go to the products page…” Then your design is not working as well as it should.

Navigation

When a user visits a page for the first time they will scan the layout for familiar objects in order to learn about how it might work.

Navigation methods such as menus, breadcrumb trails, ‘previous’ and ‘next’ buttons and pagination controls are key elements that users will seek to recognise and commit to memory.

Therefore, to aid usability, design of these elements should build upon cultural conventions, conjure up perceived affordances or at least not deviate from common understanding to the extent that they become difficult to recognise and interpret.

Navigation design, once established, should remain consistent throughout the site. For instance, the sequence of buttons within a main menu should not change from page to page as this will contradict the user’s memory of that element and will cause disorientation. Similarly, the position and overall appearance of navigation elements should not alter wildly from page to page.

5. Accessibility

Accessibility in terms of the web is the act of making “reasonable adjustments” to ensure that users are able to access information displayed on a page, regardless of any physical or cognitive disabilities that they possess. In the UK, the 2010 Equality Act states that any public information, including that displayed on websites should be made accessible. It is possible for legal action against organisations to be taken under this act if accessibility isn’t addressed appropriately on their websites. Similar legislation exists in many other countries.

Many adjustments are to do with how a site might function, and are dealt with at the programming stage. Below is a summary of the main considerations for designers. More detailed guidelines for ensuring web page accessibility can be found on this part of the W3C website

Ability to Alter Presentation of Content

Users should be able to alter elements of a page such as text size and contrast. Although this function is achieved at the programming stage, having an awareness of how this might affect the layout and appearance of your design is important. Considering how content containers might dynamically expand or reposition to accommodate larger blocks of text is a key factor of web design that is at first alien to the print designer.

Use of Colour

If something is communicated using colour, it should also be discernible without colour.

Avoid figure/ground combinations that can cause difficulties for those with colour blindness, such as (but not limited to) green and blue.

Animated Elements

Repeatedly flashing or blinking elements, when placed alongside text, can cause severe reading difficulties for users with dyslexia and related traits, and may also trigger epilepsy, so these should be avoided.

Further Online Reading

• Designing for the Web
  (more detailed info)
• A Guide to Web Typography
  (expands on areas covered in ‘Typography’ section of this page)
• Thinking With Type
  (not specifically to do with web design, but a great resource none-the-less)
• Design and Code Your First Website In Easy To Understand Steps
  (walkthrough tutorial for beginners)
• The Elements of Typographic Style Applied to the Web
  (if you are familiar with CSS, this shows how it can be applied using Robert Bringhurst’s typography principles)

Download .zip 1.2MB

The Responsive Sketch Sheet Problem

There are several well argued articles that champion the browser as the only place where the behaviour of adaptive/responsive layouts can be accurately described. This may well be true, but I would still advocate starting the whole design process with sketches on paper. Put simply, using a pencil to think visually has an immediacy that is clouded once software interfaces and html/css are introduced – these should come later, after the initial design concept has been formed.

But paper is static, responsive designs change according to display context. So how can you use the former to describe the latter?

An Attempt at a Solution

Responsive designs consist of two main properties, a series of layout ‘states’ assigned to a number of specified viewport widths, and fluid-width layout elements that form a transition between the states.

Jeremy Palford offers an easy solution for how to represent differing states within a sketch sheet by creating a series of adjacent rectanges for each sketch. I’ve taken this idea and created two set of sheets, a thumbnailing version and a more detailed set of wireframe templates with some grids:

The grey areas indicate the space below the fold. Not all possible display sizes or orientations are covered, but what I see as the three most useful are represented.

Then, if we devise symbols that indicate if an element should be fluid or fixed:

…we have a way of communicating responsive properties within a static diagram. Perhaps not the best way, but a way none the less.

I’ve also included some PSD templates that relate to the wireframe sheets. Again, I’m not completely convinced by the ‘design in the browser’ argument, as to do so infers that you must create visual elements (that can’t be generated using CSS, such as background images and textures) in isolation to the rest of the design. I prefer to view a design as a whole whilst developing it, so this fragmented approach seems strange to me.

Photoshop and/or Fireworks are inadequate tools for the job, but until a photoshop/browser hybrid is devised, they are, in my opinion, the best option for crafting the visual aspect of a design. I can see how showing clients browser prototypes over static visuals would be a good idea, however.

In Conclusion

These sketch sheets may help you in the early stages of developing a responsive design. I am going to test their use with students on the BA(Hons) Graphic Communication with Typography course at Plymouth University to see how they fare.

If anyone else either finds them useful, or has some suggestions for improvements, please leave a comment below.

Demo
Download (CSS code snippet, 2.2K)

How To Use It

The simplest implementation is to paste the code into your existing CSS, then give any HTML elements that you want to apply noise to a class="noise" attribute. Yes, I know that’s an unsemantic use of markup, but there is a workaround that I will detail later.

If you want to apply noise to the body element, use class="body-noise" instead.

How It Works

A quick look at the source will reveal that the trick here is a simple one, namely a data uri. This has been generated from a 50 x 50 pixel repeating tile PNG image of monochromatic noise that I made using Photoshop.

It is layered over elements using the :before pseudo selector using the technique outlined by Nicolas Gallagher and the opacity property. This means that no additional elements are required, and the noise is placed over the top of any existing background colour or image that the element might possess, but sits behind the element’s nested content.

Because the properties used are CSS 2.1 and not 3 then there is pretty good browser support too (breakdown below). Yet because this added progressively, browsers that aren’t supported won’t break, they just don’t get any noise.

Why ???

Adding a subtle amount of noise to aspects of an interface design is becoming more common, since it gives the designer the ability to create a more natural and less ‘digital’ looking aesthetic for interface elements that can be apparent when working with flat colours and gradients alone. Using noise also allows for an enhanced contrast in texture between figure/ground and between distinct areas of a layout.

This of course is already possible using sliced image files, but requires use of an image editor and some experience to create a tile in-keeping with the design in question, and generates an additional HTTP request for each linked image used.

There is a JavaScript based alternative, but this needs to create an additional <canvas> element for it to work, and is quite processor-intensive if used a lot, so although interesting, isn’t that practical.

Adding noise using CSS could be seen as an extension to the popular practice of dynamically adding drop shadows, rounded corners and gradients, etc, using the new CSS3 properties.

Using noise may be just a current ‘trend’, but is generic and understated enough (unlike, say, ‘brushed metal’ or ‘grunge corners’) for me to believe it will here for a while and warrants some sort of CSS solution.

As a side-note, I first tried to see if this was possible using CSS3 gradients, as inspired by Lea Verou’s CSS Pattern Gallery. I thought perhaps that it could be done using a combination of gradients and Alex Walker’s Cicada Principle. As you can see below, things didn’t quite work out as a ridiculous amount of code is required for something that looks less than satisfactory:

Better Semantics

As mentioned above, including a “noise” class to your HTML elements is convenient, but no better than adding color="red" or font="bold" attributes, in terms of semantics and the separation of content and presentation.

If you want to avoid this, then group the selectors of the elements that you want to add noise to, like so:

#myFirstElement, #mySecondElement, #myThirdElement {

position: relative;
z-index: 1;

}

#myFirstElement:before, #mySecondElement:before, #myThirdElement:before body:before {

//noise code here...

}

Grouping selectors avoids you having to declare the noise code more than once. This approach is slightly harder to set up since you need to work out the selectors for each element, but still isn’t that onerous.

If you want to add the body selector to the list, only include it in the second :before declaration, as demonstrated, because giving body a relative position and z-index messes things up.

The code shouldn’t interfere with or break any other declarations being called on the selected elements, unless you are heavily using generated content already. You could theoretically put this anywhere in your stylesheet, but because it’s so big and ugly it makes sense to put it at the bottom for ease of maintainability and bug-testing.

Don’t be tempted to separate out the code into it’s own stylesheet though, or you’ll be generating another HTTP request and defeating the point of the whole exercise.

Make Your Own

The downside of using a Data URI is that it is fairly inflexible; you can’t edit the visual characteristics of the noise on-the-fly. For the sake of compatibility, you can’t even play around with it’s opacity either, because  IE8 won’t apply it’s proprietary alpha() filter to generated content (I’m guessing MS filters only work on DOM elements?).

So, if you want a slightly different looking noise, you need to create a new Data URI. As a reference, here’s how to replicate the one I created:

1. In the bitmap-editor of your choice, create a new 50×50 px document (Through experimenting I discovered that anything larger than this tends to make the resulting URI too large to make it beneficial over using a linked image. Making it any smaller tends to create a noticeable repeat in the tiled pattern, so 50×50 seems the optimum size).

2. Create a new layer and fill it with 50% grey. In Photoshop this is achieved by selecting EDIT > FILL. from the main menu.

3. Apply a noise filter. In Photoshop this is found by selecting FILTER > NOISE > ADD NOISE from the menu. I found that uniform, monochromatic noise of about 5 – 6% works best.

4. Increase the contrast of the noise slightly. I did this in Photoshop by adding an Adjustment Layer and increasing the contrast by ’50’ with ‘Use Legacy’ selected.

5. Because noise is randomly generated, you will find there are some overly dark or light ‘clumps’ in the pattern. When the tile is repeated, these will become noticeable, so they need to be smoothed out as much as possible. I did this by using the Clone Stamp to copy over the offending areas with other bits of noise that were more uniform.

6. Reduce the opacity of the noise and delete any unwanted background layers so that the image is translucent. I did this by grouping the adjustment layer and the noise layer together and changing the opacity of the group to 25%.

7. Save for Web. You must use the PNG-24 format to retain the translucency and because it’s compression is lossless. In Photoshop, make sure that the ‘Transparency’ tick box is checked.

8. The resulting PNG can be compressed further by running it through Opti-PNG. On a Mac you can use the excellent ImageOptim which I first wrote about back in April 2010 and provides a nice drag-and-drop GUI for Opti-PNG and some other PNG compressors. It should reduce the file size by about half. It also tells you the size of the resulting image file, which is useful for step (10).

9. Turn the image into a Data URI using one of the many online tools available. I used the one found on dopiaza.org but there are plenty others out there.

10. Data URIs will contain more data than the binary of the original image. Check the size of the resulting URI using bytesizematters.com. You should be trying to aim for a size as close to the original image as possible, otherwise the benefits of saving an extra HTTP request or two will be cancelled out.

Browser Support

A good range of browsers support this, specifically:

Internet Explorer 8+, FireFox 3.5+, Chrome 1+, Safari  4+, Opera 9+

Final Notes

This project is a bit rough around the edges and could definitely do with some further tweaking, so if anyone has any improvements to contribute, please let me know.

The concept could be applied to other frequently-used textures too, such as paper, stone or cloth. I’m certainly going to have a go at some of these and if anyone has some examples of their own, leave a link in the comments.

The site has been rebuilt from scratch, using custom theme templates and a handful of plug-ins, so that it now includes more dynamic elements, the most notable of which is this shiny new blog.

As with all web based projects, it is very much under continual development, and will evolve and improve over time.

In the coming months, the blog will be used to publish a range of news, articles and some free resources. There is a series of articles planned entitled “behind the scenes”, which will showcase a range of techniques, from image-making through to programming.

I also have a series of projects up my sleeve. These will relate to web design and development, web based typography, and interaction design more generally. Time is always an issue with regards to personal work, but I hope that these will come on stream fairly soon.

Enjoy the new site and please check for updates and new posts when you have a spare moment. There is now also a RSS feed for you to subscribe to.

Also feel free to leave comments using the box below.

Thanks!

MightyMeta.