An off-shoot of this has been Varoom Lab, a web-based international research project, which has just published it’s first collection of peer-reviewed papers.

The journal includes a paper of mine, called Tap My Drawings — The State of Play in Illustrated Book Apps. It critiques current approaches to illustrated iPad book apps and offers some alternatives.

One of the highlights of the whole process was getting a direct email from Dave McKean (a personal hero of mine), giving permission to reproduce one of his illustrations from the Richard Dawkins Magic of Reality app.

You can download the journal as a PDF and find out more about it here

It uses the PugPig framework that I’ve mentioned before. Although the app book is native, each page is an HTML5 document, so if you’re familiar with web standards you can adapt this to make it less image-based.

It also requires a Mac running a recent version of OS X, Xcode (download for free from the Mac App Store) and Adobe DreamWeaver for some stages.

1. Create Your Pages Using a Design Package

Such as InDesign, Illustrator or Photoshop, or scan in some paper designs.

Use the following specifications:

• If you want to include both portrait and landscape orientations, you will need two designs for each page.
• Portrait pages must be 768 x 1024 pixels at 72 ppi.
• Landscape pages must be 1024 x 768 pixels at 72 ppi.
• You can make pages taller than these dimensions (the user can scroll to view), but not shorter. You must not alter the width of pages.
• Font size shouldn’t be less than 16 pixels for legibility.
• Export the entire page as a single image file. PNG format is best, as it is iPad compatible but does not reduce image quality. JPG will also work.
• Name your exported images sensibly, ‘page01-portrait.png’, ‘page01-landscape.png’, etc.

2. Download and Open The App Book Package

bit.ly/mm-appbook

Unzip, and look inside the ‘Data’ folder.

Move all of your exported images to the ‘images’ folder.

Now open the ‘00.html’ document in DreamWeaver. This will become your front cover.

3. Link your Images

In DreamWeaver (with design view active), you will see some dummy portrait and landscape images (scroll up/down in the main window to view both).

Double-click on one of the placeholder images to get an open file dialogue. Navigate to the corresponding image you have created, and click ‘Choose’. This will replace the placeholder with your design. Repeat the process for the other orientation, if you plan to include both, or delete it if not.

Save and close the document. Repeat the image linking process for the other ‘.html’ documents in the Data folder.

4. Make Additional Pages

Each .html document is a separate page. To create more pages for your publication, simply duplicate an existing .html document and then rename it.

(CTRL click on a document in the Finder to get the above menu)

(All page names must be numbered in this way. This makes the app recognise them and determines the order that they will appear).

5. Creating Links to Other Pages or External Websites

Open an .html document in DreamWeaver.

Single-click on the page image. In the ‘Properties’ inspector at the bottom of the screen, there is a section called ‘Map’:

The three shape tools here allow you to draw touchable ‘hotspot’ areas on to your image. Using one of these, create a ‘hotspot’ for the first item that you want to become a link.

In the Properties Inspector, type the name of (or use the grey folder button to browse for) the page you want this hotspot to jump to, when it is touched by the user.

Repeat the process for the other items on your contents page.

6. Create an App Icon

There are a number of different icon sizes that ideally need to be prepared. Your best bet is to use this Photoshop template and action which automates the process somewhat

7. Download and Install the PugPig Framework.

This step will require a Mac with Apple’s Xcode already installed.

Go to the PugPig developers page and download the PugPig Core Xcode Template, then run the installer.

Now open Xcode. Choose ‘Create a New Project’ on the opening page.

Then choose ‘PugPig application’ on the following screen:

Finally, add your name and name the app:

Xcode will now ask you to save the project. Xcode will then open. CTRL-click on the blue project icon on the far left then select ‘Add Files to App’ from the contextual menu.

Browse to and select your ‘data’ folder. Make sure ‘copy items into destination’s group folder’ and ‘create folder references’ are ticked.

8. Set up the App Icon and Display Name

To use your icon, drag-and-drop your icon files into the relevant areas such as the one indicated by the red circle below.

If you like, you can check the little ‘prerendered’ tickbox to remove the default glossy effect that Xcode puts on your final icon:

To change the name that appears under the icon, select the ‘Info’ tab in Xcode’s main editing area (indicated) and change the ‘Bundle display name’ from ${PRODUCT_NAME} to the title of your publication:

9. Fixing Orientation to Portrait or Landscape

By default, your app will show a different design when you change orientation between portrait and landscape.

To stop this and fix it to be just portrait or just landscape, you must first return to the ‘summary’ tab and alter the ‘Supported Interface Orientations’ buttons on the main screen:

Next, expand the yellow ‘AppBook’ folder from the list of files on the left, and single-click on the file ‘AppBookViewController.m’:

The main screen will display the code for this file. The bit we need starts on line 81:

Putting two forward-slashes at the start of a line stops it from working. By default, the code on line 82 is active, and this tells the app to use both orientations.

To fix the app to one orientation, comment out the code on line 82, the uncomment the commands on either line 83 (portrait) or 84 (landscape):

This example fixes the app to a landscape orientation.

10. Run in the iPad Simulator

At the top left of the Xcode window are some buttons:

Click on the right-half of the ‘Scheme’ button (indicated) and select an ‘iPad Simulator’ from the list (if there is more than one available, it shouldn’t matter which):

Now click the ‘Run’ button. Your book app should be loaded onto a virtual Ipad. It behaves in a similar way to an actual iOS device:

• Swipe pages by clicking and dragging
• Click and drag whilst holding ALT to simulate pinch/zoom (won’t do anything in the app book as this feature is disabled)
• Rotate the simulator using CMD and the left/right arrow keys to move between landscape and portrait orientation
• CMD + Shift + H activates the home button, which will exit the app and allow you to view your app icon on the springboard
• In the book app, double-clicking will reveal a navigation menu

To load your app book onto an actual iPad (or iPhone), you’ll need an iOS developer account. Details about this can be found on the iOS Developer Program website

Caveats

As hinted at in the introduction, this method isn’t really production-ready, as each page is essentially a single big static image. Ideally you would have the text set as editable/resizable text, and have some form of interactivity or multimedia within the pages.

But if you’ve absolutely no idea of how to do that, yet want to prototype some app book designs, this could do the job.

The first, called A Guide to iOS SDK for Web Designers was published by Smashing Magazine in September. This article gives a comprehensive introduction to building apps for the iPhone and iPad, for designers who have little or no programming experience.

The second, called Tap My Drawings appears in issue 19 of  Varoom!, a UK journal published by the Association of Illustrators. It’s an analysis of current illustrated book app titles and argues that the design of interactivity within given the examples interferes with a user’s engagement with content. I also come up with suggestions as to how the situation could be improved by looking at how the problem is approached in game apps.

Varoom! is an excellent publication by the way, and if you have any sort of interest in illustration or image-making generally it is well worth a look.

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 2012, 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 may not seem like a big deal, but means that 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 surprise through the act of the page turn.

What you have instead is a single sheet that has the potential to be infinitely tall. You also have the ability to show and hide content within the page using interactive elements such as tabbed areas, accordions and carousels.

‘Chunking’

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, or ‘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 size. 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 in pixels, rather than points, as physical scale is dependent on screen resolution and so 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, it is best avoided at present.

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 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)

The Future of Mobile Device Publishing?

Publishing for mobile is a broad area that can encompass formats such as PDF, the web and eReader (ePUB, .mobi) documents. The web allows for custom design and behaviour, but has no inbuilt mechanism for receiving payment for content. eReader docs can be sold through online marketplaces, but the format is best suited to long-form text works and the viewing software (and to a certain extent, the end user) determines how the publication is displayed.

App books combine the best of both worlds in that you have absolute control over the appearance and behaviour of the publication, coupled with the most secure and direct method of selling and distributing your content that is currently available. The snag is that making an app is much harder than creating a web page or eReader doc.

Baker and PugPig’s solution is to provide native (currently iOS only) frameworks that let you build an app book using HTML, CSS and JavaScript. Each page is a separate .html document that is loaded into a web view. Some clever page caching techniques optimise performance whilst native controls deal with navigation. Linked and embedded content is dealt with in-app, rather than sending you to an external browser. Best of all, both iOS and Android use WebKit as their HTML rendering engine, so you can use all the latest HTML5 and CSS3 techniques without needing to worry about other browsers.

This last point is important, because in order to get an ‘app book’ accepted onto the iOS app store, it must be more than just a static collection of pages. According to Apple’s review guidelines:

“2.12: Apps that are … simply web sites bundled as apps … may be rejected.”

“2.21: … Apps that are simply a book should be submitted to the iBookstore.”

In other words, the app needs to include some sort of additional functionality to justify it being an app as opposed to a web or eReader document. Since the release of iBooks author, including some ‘multimedia’ elements such as video or an image slideshow may not be enough. Social media integration is a safer bet. Server queries, simple games or geolocation features may also be worth considering. All of these can be achieved through HTML5 and related technologies.

Baker

Baker was released in November 2010, and is an openly developed project founded by Davide ‘Folletto’ Casali. It is free to use but donations are welcomed. Most examples of publications built using Baker are small, independent titles.

The download gives you a folder containing an Xcode project and associated classes and resources. The HTML pages go in a ‘book’ folder. In addition to the pages, you have to include an ‘index’ file if you want your app to include a index bar navigation (page thumbnails that pop-up on a double-tap) and an HPub manifest file, which is a JSON document that provides details and settings for the publication. The order of pages must be listed manually in the manifest file, and the contents of the index bar, including all the thumbnail images, must be generated/inputted by hand also.

PugPig

PugPig was released in November 2011, and is a commercial endeavour by Kaldor Ltd, created in response to the needs of their existing clients. The basic version is free, with additional functionality requiring payment. Some recognisable brand titles have been created using PugPig, including The Week, and even a private publication for the UK House of Commons.

The download gives you an installer that adds a project template to Xcode that can be selected when you create a new project. Saving the project generates all the necessary files. The HTML pages go in a ‘Data’ folder, and PugPig will present them in the order they appear in this folder. The index bar thumbnails are also generated automatically, and are scaled appropriately between iPhone/iPod and iPad. There is no manifest file to edit, but some basic settings, such as enabling scrolling for tall pages (not sure why this isn’t a default) can be performed by editing the Objective-C classes.

A Comparison

Summary

Both are very similar. Baker is more straightforward to customise, whereas PugPig is marginally easier to set up. The Laker compendium that works alongside Baker may also save some time building grids or interactive features from scratch, but the code formatting and file structure take a bit of getting used to, and with a bit of tweaking, Laker would probably work with PugPig too. PugPig appears to offer broader support, but Baker’s GitHub community seems to be regularly visited by the core development team.

PugPig’s big draw is the ability to hook an app up with a CMS such as WordPress or even their own hosted visual editor, but this is targeted at higher end (paying) clients and may be out of scope for independents.

Conclusion

Baker and PugPig offer a quick and easy way of producing app books using web standard technologies. As both mature and become more ‘cross platform’, we should see the availability of publications created using these methods increase.

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.

Sample Video “Cycles” by Cyriak Harris

Download Source (.zip package, 33KB)

What This Method Does

There are several offerings out there for embedding YouTube into your app, most of which are variations on the code provided by YouTube themselves, and this is no different. What is new about this approach is that it positions the thumbnail centrally in all device orientations using some tweaked CSS, places the thumbnail against a black background (which is trickier to work out than it sounds), and enables you to pass a video URL dynamically to the embed code.

The example I give launches the video in a modal view, which is useful if you are working with a Tab Bar application or Navigation Controller stack with a portrait-only orientation, but still want to have videos displayed landscape. Using a modal gets around the issue of all views in a Tab Bar application needing to adhere to the same orientation as outlined by Matt Long, or any other orientation problems. You could, of course, adapt the code to remove the use of a modal if you so wished.

The Launcher View

In this example I am using two view controller classes, one that manages a XIB with some ‘view video’ buttons, and then one for the display of the actual video.

First, create a UIViewController subclass with an associated XIB called “VideoLauncherViewController”. In the interface file, add the following:

#import <UIKit/UIKit.h>
#import "VideoViewController.h"

@interface VideoLauncherViewController : UIViewController {

    NSString *videoURL;

}

@property (nonatomic, retain) NSString *videoURL;

- (IBAction) launchVideo;

@end

Nothing too complex here, just a property to hold the URL for the video and a method declaration. Once the property has been synthesized and released, this is how the method should be implemented in VideoLauncherViewController.m:

- (IBAction) launchVideo {

self.videoURL = @"http://youtube.com/embed/-0Xa4bHcJu8";

VideoViewController *videoViewController = [[[VideoViewController alloc] initWithNibName:nil bundle:nil] retain];

videoViewController.modalTransitionStyle = UIModalTransitionStyleCrossDissolve;
videoViewController.videoURL = self.videoURL;

[self presentModalViewController:videoViewController animated:YES];

[videoViewController release];
}

You’ll get an error about videoViewController not having a videoURL property, but this will get sorted out once it is added in the next step.

The last section of the URL string, found directly after youtube.com/embed/, can be substituted for that of any YouTube video. Just use the ‘share’ button on the YouTube page to get the relevant code:

Passing this URL value to the next view in the way shown above means you could extend the class to make the choice of video user selected, or altered programatically, for instance.

In the XIB, make a button, and bind it to the method, as shown below (click to enlarge):

The Video View

Now create a second UIViewController subclass and XIB called “VideoViewController”. Here’s the interface:

#import <UIKit/UIKit.h>

@interface VideoViewController : UIViewController {

    IBOutlet UIWebView *videoView;
    NSString *videoURL;
    NSString *videoHTML;

}

@property(nonatomic, retain) IBOutlet UIWebView *videoView;
@property(nonatomic, retain) NSString *videoURL;
@property(nonatomic, retain) NSString *videoHTML;

- (void) embedYouTube;
- (IBAction) closeModal;

@end

Again, synthesize and release the properties in the implementation, then add these methods:

- (void)embedYouTube {

videoHTML = [NSString stringWithFormat:@"\
<html>\
<head>\
<style type=\"text/css\">\
iframe {position:absolute; top:50%%; margin-top:-130px;}\
body {background-color:#000; margin:0;}\
</style>\
</head>\
<body>\
<iframe width=\"100%%\" height=\"240px\" src=\"%@\" frameborder=\"0\" allowfullscreen></iframe>\
</body>\
</html>", videoURL];

[videoView loadHTMLString:videoHTML baseURL:nil];
}

- (IBAction) closeModal {
[self dismissModalViewControllerAnimated:YES];
}

Lets go through some of that.

First of all we assign a string of HTML code to the videoHTML property, which will be used to embed the video within a UIWebView. The HTML contains some inline CSS for centering the video correctly on the screen. Note that some characters in the string need to be escaped, notably double quotation marks with a backslash ‘\’ and the percent sign with an extra ‘%’. New lines also need to be preceded with a backslash.

Because this is a stringWithFormat, we can also insert dynamic values, so the %@ symbols found within the src=”” attribute are replaced by whatever value is held by the videoURL property, as sent through from the Launcher view, and identified there at the end of the message.

The next step is to add the following to the - (void)viewDidLoad method:

videoView.backgroundColor = [UIColor blackColor];
videoView.opaque = NO;

[self embedYouTube];

This code sorts out the black background mentioned earlier (trying to achieve this in Interface Builder doesn’t work), plus there is a message to run the embed method.

Finally you need to alter - (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation so it is simply returning YES to allow for all orientations:

    // Return YES for supported orientations
    return YES;

VideoView XIB

Open the VideoViewController.xib, and drag a UIWebView instance from the library onto the canvas. It should scale to fill the full width and height of the canvas.

Next, download and unzip this button graphic, and add both sizes of the ‘close-dark.png’ image to your project.

Drag a Round Rect Button from the library and place it roughly in the top left corner of your main view.

In the Attributes Inspector, set the Type to ‘Custom’, and the background image for the button as ‘close-dark.png’. Also change the Title to ‘Close’, the text colour to white and the font size to 14.0.

In the Size Inspector, set the X position to 36, the Y position to 24, the width to 60 and the height to 30.

Select File’s Owner and bind the videoView outlet to the UIWebView instance and the closeModal action to the ‘Close’ button.

When you are done, it should look like the example below (click to enlarge):

The Result

This should work both in the simulator and an actual device.

When you build and run and tap the button on the launch screen, the modal view is presented with the static video thumbnail.

Tapping the thumbnail will play the video fullscreen, which can be viewed in either landscape or portrait orientations. Pressing the blue ‘Done’ button will return the user to the thumbnail screen. Pressing the ‘Close’ button on the thumbnail screen will dismiss this modal view.

Conclusion

This method provides a clean and extensible way of embedding YouTube videos in your apps, which should work in most situations.

The source code is released under the BSD 3-Clause License.

If you have any problems with the code, or have improved it in some way, feel free to leave a comment below.

Since using it quite heavily on a recent iOS project, I have made a few tweaks to how it works (detailed below) and now can’t live without it! Go on, give it a whirl!

Download ‘SuperSlicr’ Action (Photoshop CS2 +)

Installation

Unzip the package and double-click on the ‘superslicr.atn’ file. It should launch Photoshop and add itself to your Actions palette automatically. If this doesn’t work, install it manually by choosing ‘LOAD ACTIONS’ from the Actions palette’s contextual menu:

Then browse for and select the file.

Instructions

1. Select the layers that you want to export as a single graphic. Note that they do not need to be adjacent to each other in the layers palette and can even exist in different groups.

2. Select which export format you require (JPEG, PNG-24 Standard or PNG-24 iOS Scaling) in the Actions palette.

3. Press the play button in the Actions palette or CMD-SHIFT-F8 for JPEG (High) / SHIFT-F8 for PNG-24 / F8 for iOS Scaling.

4. Your selected layers now appear merged, cropped and ready to export in the save for web dialogue window!

When you return to your document after saving, a new document containing your cropped and merged image will be active. Your original document will also be there, inactive, and in its original state.

Features

• Crops selected layers to pixel bounds — no slice tool required!
• Can select any combination of layers (don’t need to be adjacent in layers palette).
• Works with any layer type, including layer groups, text layers, vector shape layers and smart objects.
• Non-destructive. Creates new document from selected layers and leaves original layers untouched.
• New document remains open at end of process so can be saved as additional format.
• iOS Scaling, PNG-24 (Alpha Transparency) and JPEG (60% compression) flavours.
• Can be activated using F8 function key (this can be altered if needed).

1.0 Release

I haven’t fully tested this on different platforms, Photoshop versions, etc, and although it seems to work without a hitch for me, you may find it it does something strange when used in your particular setup.

UPDATE 24th Oct. 2011: After using SuperSlicr a bit more extensively I have ironed out a couple of bugs that existed and have also added an ‘iOS Scaling’ setting that produces both a Retina Display and Standard version of your selection.

Use the download link at the top of the article to get the latest version, and look at the readme file to see exactly what has changed.

If you experience any bugs, let me know in the comments, explaining what the bug was, what you were doing when it happened, and what OS and Photoshop version you used, so I can have a go at fixing it.

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).

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 50x50 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 50x50 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.