Skip directly to content

Smashing Magazine

Subscribe to Smashing Magazine feed
For Professional Web Designers and Developers
Updated: 3 hours 10 min ago

Design Accessibly, See Differently: Color Contrast Tips And Tools

Wed, 10/22/2014 - 13:07

When you browse your favorite website or check the latest version of your product on your device of choice, take a moment to look at it differently. Step back from the screen. Close your eyes slightly so that your vision is a bit clouded by your eyelashes.

  • Can you still see and use the website?
  • Are you able to read the labels, fields, buttons, navigation and small footer text?
  • Can you imagine how someone who sees differently would read and use it?

In this article, I’ll share one aspect of design accessibility: making sure that the look and feel (the visual design of the content) are sufficiently inclusive of differently sighted users.

1Web page viewed with NoCoffee low-vision simulation. (View large version2)

I am a design consultant on PayPal’s accessibility team. I assess how our product designs measure up to the Web Content Accessibility Guidelines (WCAG) 2.0, and I review our company’s design patterns and best practices.

I created our “Designers’ Accessibility Checklist,” and I will cover one of the most impactful guidelines on the checklist in this article: making sure that there is sufficient color contrast for all content. I’ll share the strategies, tips and tools that I use to help our teams deliver designs that most people can see and use without having to customize the experiences.

Our goal is to make sure that all visual designs meet the minimum color-contrast ratio for normal and large text on a background, as described in the WCAG 2.0, Level AA, “Contrast (Minimum): Understanding Success Criterion 1.4.3523.”

Who benefits from designs that have sufficient contrast? Quoting from the WCAG’s page:

The 4.5:1 ratio is used in this provision to account for the loss in contrast that results from moderately low visual acuity, congenital or acquired color deficiencies, or the loss of contrast sensitivity that typically accompanies aging.

As an accessibility consultant, I’m often asked how many people with disabilities use our products. Website analytics do not reveal this information. Let’s estimate how many people could benefit from designs with sufficient color contrast by reviewing the statistics:

  • 15% of the world’s population have some form of disability4, which includes conditions that affect seeing, hearing, motor abilities and cognitive abilities.
  • About 4% of the population have low vision, whereas 0.6% are blind.
  • 7 to 12% of men have some form of color-vision deficiency (color blindness), and less than 1% of women do.
  • Low-vision conditions increase with age, and half of people over the age of 50 have some degree of low-vision condition.
  • Worldwide, the fastest-growing population is 60 years of age and older5.
  • Over the age of 40, most everyone will find that they need reading glasses or bifocals to clearly see small objects or text, a condition caused by the natural aging process, called presbyopia6.

Let’s estimate that 10% of the world population would benefit from designs that are easier to see. Multiply that by the number of customers or potential customers who use your website or application. For example, out of 2 million online customers, 200,000 would benefit.

Some age-related low-vision conditions7 include the following:

  • Macular degeneration
    Up to 50% of people are affected by age-related vision loss.
  • Diabetic retinopathy
    In people with diabetes, leaking blood vessels in the eyes can cloud vision and cause blind spots.
  • Cataracts
    Cataracts clouds the lens of the eye and decreases visual acuity.
  • Retinitis pigmentosa
    This inherited condition gradually causes a loss of vision.

All of these conditions reduce sensitivity to contrast, and in some cases reduce the ability to distinguish colors.

Color-vision deficiencies, also called color-blindness, are mostly inherited and can be caused by side effects of medication and age-related low-vision conditions.

Here are the types of color-vision deficiencies8:

  • Deuteranopia
    This is the most common and entails a reduced sensitivity to green light.
  • Protanopia
    This is a reduced sensitivity to red light.
  • Tritanopia
    This is a reduced sensitivity to blue light, but not very common.
  • Achromatopsia
    People with this condition cannot see color at all, but it is not very common.

Reds and greens or colors that contain red or green can be difficult to distinguish for people with deuteranopia or protanopia.

Experience Seeing Differently

Creating a checklist and asking your designers to use it is easy, but in practice how do you make sure everyone follows the guidelines? We’ve found it important for designers not only to intellectually understand the why, but to experience for themselves what it is like to see differently. I’ve used a couple of strategies: immersing designers in interactive experiences through our Accessibility Showcase, and showing what designs look like using software simulations.

In mid-2013, we opened our PayPal Accessibility Showcase9 (video). Employees get a chance to experience first-hand what it is like for people with disabilities to use our products by interacting with web pages using goggles and/or assistive technology. We require that everyone who develops products participates in a tour. The user scenarios for designing with sufficient color contrast include wearing goggles that simulate conditions of low or partial vision and color deficiencies. Visitors try out these experiences on a PC, Mac or tablet. For mobile experiences, visitors wear the goggles and use their own mobile devices.

Fun fact: One wall in the showcase was painted with magnetic paint. The wall contains posters, messages and concepts that we want people to remember. At the end of the tour, I demonstrate vision simulators on our tablet. I view the message wall with the simulators to emphasize the importance of sufficient color contrast.

Showcase visitors wear goggles that simulate low-vision and color-blindness conditions. Some of the goggles used in the Accessibility Showcase. Software Simulators Mobile Apps

Free mobile apps are available for iOS and Android devices:

  • Chromatic Vision Simulator
    Kazunori Asada’s app simulates three forms of color deficiencies: protanope (protanopia), deuteranope (deuteranopia) and tritanope (tritanopia). You can view and then save simulations using the camera feature, which takes a screenshot in the app. (Available for iOS6210 and Android6311.)
  • VisionSim
    The Braille Institute’s app simulates a variety of low-vision conditions and provides a list of causes and symptoms for each condition. You can view and then save simulations using the camera feature, which takes a screenshot in the app. (Available for iOS6412 and Android.)13
Chromatic Vision Simulator

The following photos show orange and green buttons viewed through the Chromatic Vision Simulator:

14Seen through Chromatic Vision Simulator, the green and orange buttons show normal (C), protanope (P), deuteranope (D) and tritanope (T). (View large version15)

This example highlights the importance of another design accessibility guideline: Do not use color alone to convey meaning. If these buttons were online icons representing a system’s status (such as up or down), some people would have difficulty understanding it because there is no visible text and the shapes are the same. In this scenario, include visible text (i.e. text labels), as shown in the following example:

16The green and orange buttons are viewed in Photoshop with deuteranopia soft proof and normal (text labels added). (View large version17) Mobile Device Simulations

Checking for sufficient color contrast becomes even more important on mobile devices. Viewing mobile applications through VisionSim or Chromatic Vision Simulator is easy if you have two mobile phones. View the mobile app that you want to test on the second phone running the simulator.

If you only have one mobile device, you can do the following:

  1. Take screenshots of the mobile app on the device using the built-in camera.
  2. Save the screenshots to a laptop or desktop.
  3. Open and view the screenshots on the laptop, and use the simulators on the mobile device to view and save the simulations.
How’s the Weather in Cupertino?

The following example highlights the challenges of using a photograph as a background while making essential information easy to see. Notice that the large text and bold text are easier to see than the small text and small icons.

18The Weather mobile app, viewed with Chromatic Vision Simulator, shows normal, deuteranope, protanope and tritanope simulations. (View large version19) Low-Vision Simulations

Using the VisionSim app, you can simulate macular degeneration, diabetic retinopathy, retinitis pigmentosa and cataracts.

20The Weather mobile app is being viewed with the supported condition simulations. (View large version21) Adobe Photoshop

PayPal’s teams use Adobe Photoshop to design the look and feel of our user experiences. To date, a color-contrast ratio checker or tester is not built into Photoshop. But designers can use a couple of helpful features in Photoshop to check their designs for sufficient color contrast:

  • Convert designs to grayscale by going to “Select View” → “Image” → “Adjustments” → “Grayscale.”
  • Simulate color blindness conditions by going to “Select View” → “Proof Setup” → “Color Blindness” and choosing protanopia type or deuteranopia type. Adobe provides soft-proofs for color blindness22.

If you’re designing with gradient backgrounds, verify that the color-contrast ratio passes for the text color and background color on both the lightest and darkest part of the gradient covered by the content or text.

In the following example of buttons, the first button has white text on a background with an orange gradient, which does not meet the minimum color-contrast ratio. A couple of suggested improvements are shown:

  • add a drop-shadow color that passes (center button),
  • change the text to a color that passes (third button).

Checking in Photoshop with the grayscale and deuteranopia proof, the modified versions with the drop shadow and dark text are easier to read than the white text.

If you design in sizes larger than actual production sizes, make sure to check how the design will appear in the actual web page or mobile device.

23Button with gradients: normal view; view in grayscale; and as a proof, deuteranopia. (View large version24)

In the following example of a form, the body text and link text pass the minimum color-contrast ratio for both the white and the gray background. I advise teams to always check the color contrast of text and links against all background colors that are part of the experience.

Even though the “Sign Up” link passes, if we view the experience in grayscale or with proof deuteranopia, distinguishing that “Sign Up” is a link might be difficult. To improve the affordance of “Sign Up” as a link, underline the link or link the entire phrase, “New to PayPal? Sign Up.”

25Form example: normal view; in Photoshop, a view in grayscale; and as a proof, deuteranopia. (View large version26)

Because red and green can be more difficult to distinguish for people with conditions such as deuteranopia and protanopia, should we avoid using them? Not necessarily. In the following example, a red minus sign (“-”) indicates purchasing or making a payment. Money received or refunded is indicated by a green plus sign (“+”). Viewing the design with proof, deuteranopia, the colors are not easy to distinguish, but the shapes are legible and unique. Next to the date, the description describes the type of payment. Both shape and content provide context for the information.

Also shown in this example, the rows for purchases and refunds alternate between white and light-gray backgrounds. If the same color text is used for both backgrounds, verify that all of the text colors pass for both white and gray backgrounds.

27Normal view and as a proof, deuteranopia: Check the text against the alternating background colors. (View large version28)

In some applications, form fields and/or buttons may be disabled until information has been entered by the user. Our design guidance does not require disabled elements to pass, in accordance with the WCAG 2.0’s “Contrast (Minimum): Understanding Success Criterion 1.4.34129:

Incidental: Text or images of text that are part of an inactive user interface component,… have no contrast requirement.

In the following example of a mobile app’s form, the button is disabled until a phone number and PIN have been entered. The text labels for the fields are a very light gray over a white background, which does not pass the minimum color-contrast ratio.

If the customer interprets that form elements with low contrast are disabled, would they assume that the entire form is disabled?

30Mobile app form showing disabled fields and button (left) and then enabled (right). (View large version31)

The same mobile app form is shown in a size closer to what I see on my phone in the following example. At a minimum, the text color needs to be changed or darkened to pass the minimum color-contrast ratio for normal body text and to improve readability.

To help distinguish between labels in fields and user-entered information, try to explore alternative visual treatments of form fields. Consider reversing foreground and background colors or using different font styles for labels and for user-entered information.

32Mobile app form example: normal, grayscale and proof deuteranopia. (View large version33) NoCoffee Vision Simulator for Chrome

NoCoffee Vision Simulator6634 can be used to simulate color-vision deficiencies and low-vision conditions on any pages that are viewable in the Chrome browser. Using the “Color Deficiency” setting “achromatopsia,” you can view web pages in grayscale.

The following example shows the same photograph (featuring a call to action) viewed with some of the simulations available in NoCoffee. The message and call to action are separated from the background image by a practically opaque black container. This improves readability of the message and call to action. Testing the color contrast of the blue color in the headline against solid black passes for large text. Note that the link “Mobile” is not as easy to see because the blue does not pass the color-contrast standard for small body text. Possible improvements could be to change the link color to white and underline it, and/or make the entire phrase “Read more about Mobile” a link.

35Simulating achromatopsia (no color), deuteranopia, protanopia using NoCoffee. (View large version36) 37Simulating low visual acuity, diabetic retinopathy, macular degeneration and low visual acuity plus retinitus pigmentosa, using NoCoffee. (View large version38) Using Simulators

Simulators are useful tools to visualize how a design might be viewed by people who are aging, have low-vision conditions or have color-vision deficiencies.

For design reviews, I use the simulators to mock up a design in grayscale, and I might use color-blindness filters to show designers possible problems with color contrast. Some of the questions I ask are:

  • Is anything difficult to read?
  • Is the call to action easy to find and read?
  • Are links distinguishable from other content?

After learning how to use simulators to build empathy and to see their designs differently, I ask designers to use tools to check color contrast to verify that all of their designs meet the minimum color-contrast ratio of the WCAG 2.0 AA. The checklist includes a couple of tools they can use to test their designs.

Color-Contrast Ratio Checkers

The tools we cite in the designers’ checklist are these:

There are many tools to check color contrast, including ones that check live products. I’ve kept the list short to make it easy for designers to know what to use and to allow for consistent test results.

Our goal is to meet the WCAG 2.0 AA color-contrast ratio, which is 4.5 to 1 for normal text and 3 to 1 for large text.

What are the minimum sizes for normal text and large text? The guidance provides recommendations on size ratios in the WCAG’s Contrast (Minimum): Understanding Success Criterion 1.4.34129 but not a rule for a minimum size for body text. As noted in the WCAG’s guidance, thin decorative fonts might need to be larger and/or bold.

Testing Color-Contrast Ratio

You should test:

  • early in the design process;
  • when creating a visual design specification for any product or service (this documents all of the color codes and the look and feel of the user experience);
  • all new designs that are not part of an existing visual design guideline.
Test Hexadecimal Color Codes for Web Designs

Let’s use the WebAIM Color Contrast Checker4239 to test sample body-text colors on a white background (#FFFFFF):

  • dark-gray text (#333333).
  • medium-gray text (#666666).
  • light-gray text (#999999).

We want to make sure that body and normal text passes the WCAG 2.0 AA. Note that light gray (#999999) does not pass on a white background (#FFFFFF).

43Test dark-gray, medium-gray and light-gray using the WebAim Color Contrast Checker.(View large version44)

In the tool, you can modify the light gray (#999999) to find a color that does pass the AA. Select the “Darken” option to slightly change the color until it passes. By clicking the color field, you will have more options, and you can change color and luminosity, as shown in the second part of this example.

45In the WebAim Color Contrast Checker, modify the light gray using the “Darken” option, or use the color palette to find a color that passes. (View large version46)

Tabular information may be designed with alternating white and gray backgrounds to improve readability. Let’s test medium-gray text (#666666) and light-gray text (#757575) on a gray background (#E6E6E6).

Note that with the same background, the medium text passes, but the lighter gray passes only for large text. In this case, use medium gray for body text instead of white or gray backgrounds. Use the lighter gray only for large text, such as headings on white and gray backgrounds.

47Test light-gray and medium-gray text on a gray background. (View large version48) Test RGB Color Codes

For mobile applications, designers might use RGB color codes to specify visual designs for engineering. You can use the TPG Colour Contrast Checker49. you will need to install either the PC or Mac version and run it side by side with Photoshop.

Let’s use the Colour Contrast Checker to test medium-gray text (102 102 102 in RGB and #666666 in hexadecimal) and light-gray text (#757575 in hexadecimal) on a gray background (230 230 230 in RGB and #E6E6E6 in hexadecimal).

  1. Open the Colour Contrast Checker application.
  2. Select “Options” → “Displayed Color Values” → “RGB.”
  3. Under “Algorithm,” select “Luminosity.”
  4. Enter the foreground and background colors in RGB: 102 102 102 for foreground and 230 230 230 for background. Mouse click or tab past the fields to view the results. Note that this combination passes for both text and large text (AA).
  5. Select “Show details” to view the hexadecimal color values and information about both AA and AAA requirements.
50Colour Contrast Analyser, and color wheel to modify colors. (View large version51)

In our example, light-gray text (117 117 117 in RGB) on a gray background (230 230 230 in RGB) does not meet the minimum AA contrast ratio for body text. To modify the colors, view the color wheels by clicking in the “Color” select box to modify the foreground or background. Or you can select “Options” → “Show Color Sliders,” as shown in the example.

Colour Contrast Analyser, with RGB codes. Show color sliders to modify any color that does not meet minimum AA guidelines.

In most cases, minor adjustments to colors will meet the minimum contrast ratio, and comparisons before and after will show how better contrast enables most people to see and read more easily.

Best Practices

Test for color-contrast ratio, and document the styles and color codes used for all design elements. Create a visual design specification that includes the following:

  • typography for all textual elements, including headings, text links, body text and formatted text;
  • icons and glyphs and text equivalents;
  • form elements, buttons, validation and system error messaging;
  • background color and container styles (making sure text on these backgrounds all pass);
  • the visual treatments for disabled links, form elements and buttons (which do not need to pass a minimum color-contrast ratio).

Documenting visual guidelines for developers brings several benefits:

  • Developers don’t have to guess what the designers want.
  • Designs can be verified against the visual design specification during quality testing cycles, by engineers and designers.
  • A reference point that meets design accessibility guidelines for color contrast can be shared and leveraged by other teams.

If you are a designer, try out the simulators and tools on your next design project. Take time to see differently. One of the stellar designers who reviewed my checklist told me a story about using Photoshop’s color-blindness proofs. On his own, he used the proofs to refine the colors used in a design for his company’s product. When the redesigned product was released, his CEO thanked him because it was the first time he was able to see the design. The CEO shared that he was color-blind. In many cases, you may be unaware that your colleague, leader or customers have moderate low-vision or color-vision deficiencies. If meeting the minimum color-contrast ratio for a particular design element is difficult, take the challenge of thinking beyond color. Can you innovate so that most people can pick up and use your application without having to customize it?

If you are responsible for encouraging teams to build more accessible web or mobile experiences, be prepared to use multiple strategies:

  • Use immersive experiences to engage design teams and gain empathy for people who see differently.
  • Show designers how their designs might look using simulators.
  • Test designs that have low contrast, and show how slight modifications to colors can make a difference.
  • Encourage designers to test, and document visual specifications early and often.
  • Incorporate accessible design practices into reusable patterns and templates both in the code and the design.

Priorities and deadlines make it challenging for teams to deliver on all requests from multiple stakeholders. Be patient and persistent, and continue to engage with teams to find strategies to deliver user experiences that are easier to see and use by more people out of the box.

References Low-Vision Goggles and Resources

(hp, al, il, ml)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73

The post Design Accessibly, See Differently: Color Contrast Tips And Tools appeared first on Smashing Magazine.

Hybrid Mobile Apps: Providing A Native Experience With Web Technologies

Tue, 10/21/2014 - 09:00

According to a recent report1, HTML is the most widely used language for mobile app developers. The main reasons among developers for selecting web technologies2 are cross-platform portability of code and the low cost of development. We’ve also heard that hybrid apps tend to be sluggish and poorly designed. Let’s prove whether it’s possible to deliver the native look and feel that we’re used to.

This article provides many hints, code snippets and lessons learned on how to build great hybrid mobile apps. I’ll briefly introduce hybrid mobile app development, including its benefits and drawbacks. Then, I’ll share lessons I’ve learned from over two years of developing Hojoki and CatchApp, both of which run natively on major mobile platforms and were built with HTML, CSS and JavaScript. Finally, we’ll review the most prominent tools to wrap code in a native app.

What Are Hybrid Mobile Apps?

Mobile apps can be generally broken down into native, hybrid and web apps. Going the native route allows you to use all of the capabilities of a device and operating system, with a minimum of performance overhead on a given platform. However, building a web app allows your code to be ported across platforms, which can dramatically reduce development time and cost. Hybrid apps combine the best of both worlds, using a common code base to deploy native-like apps to a wide range of platforms.

There are two approaches to building a hybrid app:

  • WebView app
    The HTML, CSS and JavaScript code base runs in an internal browser (called WebView) that is wrapped in a native app. Some native APIs are exposed to JavaScript through this wrapper. Examples are Adobe PhoneGap3 and Trigger.io4.
  • Compiled hybrid app
    The code is written in one language (such as C# or JavaScript) and gets compiled to native code for each supported platform. The result is a native app for each platform, but less freedom during development. Examples are Xamarin5, Appcelerator Titanium6 and Embarcadero FireMonkey7.

While both approaches are widely used and exist for good reasons, we’ll focus on WebView apps because they enable developers to leverage most of their existing web skills. Let’s look at all of the benefits and drawbacks of hybrid apps compared to both native and mobile web apps.

  • Developer can use existing web skills
  • One code base for multiple platforms
  • Reduced development time and cost
  • Easily design for various form factors (including tablets) using responsive web design
  • Access to some device and operating system features
  • Advanced offline capabilities
  • Increased visibility because the app can be distributed natively (via app stores) and to mobile browsers (via search engines)
  • Performance issues for certain types of apps (ones relying on complex native functionality or heavy transitions, such as 3D games)
  • Increased time and effort required to mimic a native UI and feel
  • Not all device and operating system features supported
  • Risk of being rejected by Apple if app does not feel native enough (for example, a simple website)

These drawbacks are significant and cannot be ignored, and they show that the hybrid approach does not suit all kinds of apps. You’ll need to carefully evaluate your target users, their platforms of choice and the app’s requirements. In the case of many apps, such as content-driven ones, the benefits outweigh the drawbacks. Such apps can typically be found in the “Business and Productivity,” “Enterprise” and “Media” categories in the app store.

Both Hojoki and CatchApp are very content-driven productivity apps, so we initially thought they would be a great match for hybrid development. The first three benefits mentioned above were especially helpful to us in building the mobile app for Hojoki in just four weeks. Obviously, that first version lacked many important things. The following weeks and months were filled with work on optimizing performance, crafting a custom UI for each platform and exploiting the advanced capabilities of different devices. The learning in that time was crucial to making the app look and feel native. I’ll share as many lessons as possible below.

So, how do you achieve a native look and feel? To a mobile web developer, being able to use the features of a device and operating system and being able to package their app for an app store sounds just awesome. However, if users are to believe it is a native app, then it will have to behave and look like one. Accomplishing this remains one of the biggest challenges for hybrid mobile developers.

Make Your Users Feel at Home

A single code base doesn’t mean that the app should look and feel exactly the same on all platforms. Your users will not care at all about the underlying cross-platform technology. They just want the app to behave as expected; they want to feel “at home.” Your first stop should be each platform’s design guidelines:

While these guidelines might not perfectly suit all kinds of apps, they still provide a comprehensive and standard set of interfaces and experiences that users on each platform will know and expect.

DIY vs. UI Frameworks

Implementing all of these components, patterns and animations on your own can be quite a challenge. All kinds of frameworks exist to help you with that, ranging from commercial (Kendo UI11) to open-source ones (Ionic12) and from ones with a common UI (jQuery Mobile13 and Onsen UI14) to many platform-specific UIs (Sencha Touch7615 and ChocolateChip-UI16). Some are really good at providing a pixel-perfect layout, while others are rather sloppy, thus making it easy for the user to identify a web app. However, my impression is that their main drawbacks are performance-related, because most UI frameworks try to be as all-embracing as possible. Judge for yourself by taking a few minutes to try the demos on your own device.

At Hojoki, we try to craft all components on our own using CSS3 and minimal JavaScript. This keeps us in control of performance and reduces overhead. We obviously use small libraries for complicated tasks that someone else has solved just fine.

Custom UI Components

Custom UI components also have many good use cases. Deciding between a platform’s UI and a custom UI will obviously depend on your target audience. If you want to do your own thing, you should have a deep understanding of UX design, because the guidelines linked to above were crafted by experts to meet the particular requirements of their platform’s users.

Whether you stick to a platform’s UI guidelines or do your own thing with custom components, know that there are certain design patterns that most people use every day and love. How are people usually introduced to a new app? Through a slideshow walkthrough or an instructional overlay. How do people navigate? With a tab bar or a sidebar drawer17. How do users quickly load or refresh data? By pulling to refresh. (Native-like scrolling will be covered extensively further below.)

Resources for Mobile UI Design Design A Native-Looking Header Bar

One important part of a UI is the header bar, with its title and navigation elements, most notably the “up” and “back” buttons. To me, many popular frameworks fail to provide a HTML and CSS solution that compares to a native app. Mimicking this part of the UI with a minimal DOM and a few lines of CSS for each platform is actually fairly easy:

<header> <button class="back">Feed</button> <h1>Details</h1> <!-- more actions (e.g. a search button on the right side) --> </header>

Check out the full code of the native-looking header bar for iOS, Android and Windows Phone21 on JSFiddle. This is my result:

Native-looking headers made with HTML5 and CSS.

Using the same DOM across all platforms is generally preferable because it results in cleaner code and, therefore, maximizes maintainability. I’ve found this to be easily possible for many UI components on iOS and Android (including the header bar, tab bar, custom navigation menu, settings page, popover and many more). However, this becomes much harder when adding support for Windows Phone, which comes with some very different design patterns.

Support High-Resolution Screens

Nowadays, smartphones and tablets with high-resolution screens make up the vast majority of mobile devices, making up more than 80% of iOS devices22 and over 70% on Android devices23. To make your images look crisp for everyone, you usually have to deliver twice the dimensions than what is actually shown in your app. Serving properly sized images for all different resolutions is one of the most discussed topics in responsive web design. There are various approaches, each with its benefits and drawbacks related to bandwidth, code maintainability and browser support. Let’s quickly review the most popular ones, in no particular order:

  • server-side resizing and delivering
  • client-side detection and replacement via JavaScript
  • HTML5 picture element
  • HTML5 srcset attribute
  • CSS image-set
  • CSS media queries
  • Resolution-independent images (SVG)

As always, there is no silver bullet for responsive images. It pretty much depends on the type of images and how they are used in the app. For static images (such as the logo and tutorial images), I try to use SVG. They scale perfectly without any extra effort and have great browser support as long as you’re fine with Android 3+24.

When SVG is not an option, the HTML5 picture element and srcset attributes25 are definitely where front-end development is heading. Currently, their main drawback is the very limited browser support and, therefore, their need for polyfills.

In the meantime, CSS background images and media queries26 are the most pragmatic solution:

/* Normal-resolution CSS */ .logo { width: 120px; background: url(logo.png) no-repeat 0 0; } /* HD and Retina CSS */ @media only screen and (-webkit-min-device-pixel-ratio: 1.25), only screen and ( min--moz-device-pixel-ratio: 1.25), only screen and ( -o-min-device-pixel-ratio: 1.25/1), only screen and ( min-device-pixel-ratio: 1.25), only screen and ( min-resolution: 200dpi), only screen and ( min-resolution: 1.25dppx) { .logo { background: url(logo@2x.png) no-repeat 0 0; background-size: 120px; /* Equal to normal logo width */ } }

However, your app might already contain a lot of content (such as news articles), and adjusting all of the img tags or replacing them with CSS would be exhausting. A server-side solution is the best choice in this case.

Starting last year, more and more Android manufacturers have gone one step further with what is called XXHDPI (or very very high-resolution) screens. Whichever solution above fits your need, keep in mind that you’ll need images that are three times the original dimensions to support Android’s latest flagship devices.

Use System Fonts

A simple yet important way to make users feel at home is to use system fonts.

Native fonts for iOS27, Android28 and Windows Phone29.

These are my recommended font stacks on the major platforms:

/* iOS */ font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; /* Android */ font-family: 'RobotoRegular', 'Droid Sans', sans-serif; /* Windows Phone */ font-family: 'Segoe UI', Segoe, Tahoma, Geneva, sans-serif;

Furthermore, iOS 7 offers some interesting presets that automatically set the correct font family, font size and line height. It’s as easy as using font: -apple-system-body for normal text and font: -apple-system-headline for headings. This not only simplifies font declarations, but also improves accessibility through “dynamic type30,” Apple’s system-wide font-size setting. You can dig deeper into iOS 7 font presets in a post by Thomas Fuchs31.

An Icon Is Worth A Thousand Words

Iconography is an important part of the user experience on all major mobile platforms. As with fonts, you’re usually best off using icons that your target audience already knows. Recalling what I said about high-resolution screens earlier, make sure that your icons are scaleable. Implementing them as a font via CSS’ @font-face rule is a great way to achieve this, and it comes with wide browser support32. It even allows you to change an icon’s appearance (for example, its color, shadow and transparency) seamlessly via CSS. Here are my recommendations:

  1. Get various platform icon fonts.
    Ionicons33 is our baseline set because it includes nearly everything we need. This includes specific icons for iOS and Android in addition to their general ones. The rest come from specific platform icon fonts for iOS34, Android set 135 and set 236 and Windows Phone37.
  2. Combine them with a icon font generator.
    Using multiple icon fonts is confusing and quickly adds up in size. That is why we use Fontello38 to combine the different sets, adjust key codes and export them for each platform. The result is <span class="icon">s</span>, which looks like a search icon on iOS, Android and Windows Phone. Also, check out the popular alternatives IcoMoon39 and Fontastic40.

On Windows Phone, you can also get away with the native font-family: 'Segoe UI Symbol'41.

Optimize For Performance

Performance is usually considered to be one of the major disadvantages of a hybrid mobile app. This is mostly true if your app has a lot of heavy animations, contains huge scrolling lists and needs to run on old devices. However, if you are all right with supporting only newer platform versions (Android 4+, iOS 7+ and Windows Phone 8+), then you’ll very likely have satisfying results. It’s ultimately a question of how much effort you put into optimizing DOM and CSS selectors, writing performant JavaScript, reducing rendering time and minimizing the number of reflows and repaints. An endless number of articles and tutorials cover mobile web performance. These are some of my favorites:

Beyond that, mobile hardware and rendering engines are improving at a rapid pace, with new devices coming out every other day. Developers can make the performance of a hybrid WebView app difficult to distinguish from that of a fully native app on the iPhone 5 series and on Android phones comparable to Nexus 4 and 5.

Increase Perceived Speed

Building a performant app is one thing, but making it feel fast is a whole other. Whether your app needs some time for a certain task (such as some heavy calculation or client-server communication), presenting instant feedback is crucial to providing a fluid and responsive experience. A common technique is to delay tasks that the user doesn’t need yet, while predicting and preloading the steps the user might take next. A famous example is Instagram, which uploads photos in the background47 while the user is busy adding tags and sharing. Perceived speed can be very different from actual speed, so let’s use it in our favor. Here are some no-brainers.

Remove the Click Delay on Touch Devices

A normal JavaScript click event handler on a touch device comes with a slight delay between the touchstart and the click being fired (usually around 300 milliseconds). This feature is built into the browser to detect whether the user is performing a single- or double-tap. If you don’t need the “double-tap to zoom” feature, you can safely eliminate these 300 milliseconds to get a much more responsive tap behavior. My favorite solution for this is the FastClick48 library. Use it on everything except Internet Explorer:

if ('ontouchstart' in window) { window.addEventListener('load', function() { FastClick.attach(document.body); }, false); }

Internet Explorer 10+ is a bit easier. You just need some CSS:

html { -ms-touch-action: manipulation; /* IE 10 */ touch-action: manipulation; /* IE 11+ */ } Style the Active State

As soon as the user taps an actionable element such as a button or a link, they should immediately get some kind of feedback that the app has detected their action. While the CSS pseudo-class :hover works great for this on the desktop, you need to switch to :active or a JavaScript solution for it to work on mobile. I’ve compared the three approaches to the active state49 on JSFiddle. While they all work one way or another, you judge which is best for you.

Furthermore, remove the default tap highlight while adjusting your active states on mobile. I’d also recommend disabling user selections on actionable elements, because the selection menu would be quite disruptive if the user accidentally taps the button for too long.

iOS and Android:

button { outline: 0; -webkit-tap-highlight-color: rgba(0,0,0,0); -webkit-tap-highlight-color: transparent; -webkit-touch-callout: none; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; }

Windows Phone 8+:

<meta name="msapplication-tap-highlight" content="no"> Indicate Loading

Whenever your app is performing an action that will take some time to finish, even just for a second, consider adding a loading indicator. If you don’t, users will think that your app freezes occasionally, or they’ll click around when they shouldn’t, or they might even break things and then blame your app. From what I’ve experienced, animated GIFs are usually a bad idea in mobile browsers. As soon as there is a load on the CPU, the GIF freezes, thus defeating its entire purpose. I prefer Spin.js50 for its configurability and ease of use. Also, check out some other JavaScript solutions51 and CSS loaders52.

Cross-platform tools like PhoneGap and also provide access to native loaders, which is great for showing a full-screen loading animation.

Get the Scrolling Right

Scrolling is one of the most important factors in the user experience of many apps. This is both a curse and a blessing because the success of its implementation will depend heavily on the scrolling niceties that your app relies on and on the mobile operating systems that need to be supported.

Scrollable content and a fixed header and/or footer bar are common to nearly all apps. There are two common approaches to achieving this with CSS:

  1. Enabling scrolling on the body, and applying position: fixed to the header;
  2. Disabling scrolling on the body, and applying overflow: scroll to the content;
  3. Disabling scrolling on the body, and applying JavaScript custom scrolling to the content.

While the first option has some benefits (such as iOS’s native scroll-to-top action and a simple code structure), I highly recommend going with the second option, overflow: scroll. It has fewer rendering issues53 (although still a lot), and browser support is great on modern platforms (Android 4+, iOS 5+ and Windows Phone 8+), with a nice little polyfill for some older ones54. Alternatively, you could replace overflow: scroll with a custom scrolling library (the third option), such as iScroll55. While these JavaScript solutions allow for more flexibility with features (for example, the scroll position during momentum, event handling, customization of effects and scrollbars, etc.), they always penalize performance. This becomes critical when you’re using a lot of DOM nodes and/or CSS3 effects (such as box-shadow, text-shadow, opacity and rgba) in the content area.

Let’s look at some of the basic scrolling features.

Momentum Effect

The touch-friendly momentum effect enables users to quickly scroll through large content areas in an intuitive way. It can be easily activated with some simple CSS on iOS 5+ and in some versions of Chrome for Android. On iOS, this will also enable the content to bounce off the top and bottom edges.

overflow-y: scroll; -webkit-overflow-scrolling: touch; Pull Down to Refresh

Various solution for this are available on the web, such as the one by Damien Antipa5756. While the solutions for iOS and Windows Phone have a similar look and feel, Android recently introduced its own mechanism (see below). We’ve implemented this in CatchApp using some JavaScript and CSS keyframes. (I have yet to wrap it up nicely and put it on GitHub, so stay tuned!)

Pull down to refresh on iOS. (Image credit: Damien Antipa5756)
Pull down to refresh on Android. (Image credit: Android Widget Center58)
Pull down to refresh on Windows Phone. (Image credit: David Washington59) Scroll to Top

Unfortunately, disabling scrolling on the body will also break iOS’ native feature that enables users to quickly get to the top of the page by tapping the status bar. I’ve written a small script that can be added to any element and that takes care of scrolling to the top using JavaScript60, even if the content is currently in momentum. Add it to the header of your mobile website or to the status bar with a native plugin (for example, in PhoneGap).

Many other scrolling features could be implemented on top of the native overflow: scroll, such as snapping to a certain element or just infinite scrolling. If your requirements are more advanced, definitely look at the JavaScript options out there.

Make It Easy To Hit Stuff

When performing a touch action, users will quite often miss their target by a few pixels, especially on small buttons (such as the ones in iOS’ top bar). Developers can assist users while keeping the design elegant by enabling an invisible touch area around small targets:

<button> <div class="innerButton">Click me!</div> </button>

You’ll have to put the event handler on the button element, while restricting the styles to div.innerButton. Check out the full example, including CSS61, on JSFiddle.

Using Touch Gestures

A smartphone is all about touching and gestures. We swipe, pinch, zoom, drag and long-tap all the time when interacting with touch devices. So, why not offer users the same means of controlling your hybrid app? QuoJS62 and Hammer.js63 are well-known libraries for supporting all kinds of gestures. If you’d like more choice, check out Kevin Liew’s comparison of “11 Multi-Touch and Touch Events JavaScript Libraries64.”

Don’t Miss Out on Native Functionality

Building your app with web technology doesn’t necessarily mean that you can’t use native features. In fact, all major cross-platform development tools provide built-in access to the most important functionality. This includes APIs for device data, the file system, the network connection, geolocation, the accelerometer, notifications (including push) and much more.

You can usually even extend a development tool by building custom plugins. At Hojoki, we added many missing features, including reading the user’s setting for push notifications for our app, detecting the user’s time zone, and checking whether a third-party app is installed and launching it. Let’s look at two very simple examples for things that can be realized with native plugins. First, let’s enable JavaScript focus() for input fields on iOS 6+:

if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 6) { [YourWebView setKeyboardDisplayRequiresUserAction:NO]; }

And here’s the code to copy a given string to the device’s clipboard on iOS:

[[UIPasteboard generalPasteboard] setString:@"Your copied string"]; Always Provide a Way Out

Web developers often overlook how to handle bad situations in a hybrid app (for example, a connection timeout, a bad input, a timing issue, etc.). A hybrid app is fundamentally different from a website, mainly because there is no global refresh button, and an app can easily run in the background for weeks on some mobile operating systems. If the user runs into a dead end, their only option will be to restart the app, which entails force quitting and then restarting. Many people don’t even know how to do that, especially on Android 2.x (where it’s hidden deep in the app’s settings) and on iOS 6 and below (where you have to double-tap the home button, long-press the icon and kill it).

So, ignore the refresh button during development, and handle bad situations as they come up. For all other situations that would have unexpected outcomes, such as ones involving client-server communication, be prepared for things to go wrong, and provide a way out for users. This could be as easy as showing a full-screen error message — “Oops! Something bad happened. Please check your connection and try again” — with a big “Reload” button below.

How To Wrap It

Developing a hybrid mobile app means using the same tools and processes that you would usually use to develop (mobile) websites. Having said that, one thing I really like about the hybrid approach is that you can deploy HTML, CSS and JavaScript code as a mobile web app with relative ease. Make sure to implement fallbacks for native features, or find elegant workarounds if they are not supported at all. Most mobile developers prefer to keep users in a native app, and you could even advertise the app to your mobile website’s users.

65A native WebView wrapper, with an HTML, CSS and JavaScript code base. (View large version66)

What about the native part? Your mobile web app (plain HTML, CSS and JavaScript) will be loaded in a WebView, which is an internal browser engine that renders an app the way a default browser on the device would render it (there might be slight differences — your mileage may vary). Additionally, native “bridges” are used to expose features of the device and operating system through an API to make them accessible with JavaScript. This usually includes access to the device’s camera, address book, geolocation, file system and native events (for example, via one of the hardware buttons on Android), to name just a few features.

A few cross-platform development tools provide that native bridge and simplify the whole process of wrapping it. Let’s dive into some options.

PhoneGap and Apache Cordova

PhoneGap67 is certainly one of the most popular tools for cross-platform development. The name itself is often used synonymously with hybrid mobile app development.

There has been some confusion about its name68 and relation to Apache Cordova69, which is understandable. The latter is a top-level Apache project that was formerly called PhoneGap. It offers a set of device APIs to access native functionality from HTML, CSS and JavaScript code running in a WebView. Now, Adobe PhoneGap is a distribution of Cordova — not unlike the way Chrome uses WebKit as its engine.

Both are open-source and free to use, with support for all major platforms and with an active community developing all kinds of plugins and extensions.

PhoneGap has shaped the hybrid lanscape significantly, and many new tools have emerged that offer additional services or that streamline the development process. They usually add a lot of convenience by enabling you to build an app in the cloud, thereby saving you the effort of locally installing all of the different platform SDKs and tools. Each tool has a different focus, level of platform support and price:

Sencha Touch

Sencha Touch7615 started out as a UI framework for the mobile web and has been around for years. Traditionally, developers have used Sencha to build an app while using another service, like PhoneGap, to deploy it as a hybrid app. Nowadays, Sencha offers this kind of functionality built in for free. Platform support includes iOS and Android (both via Sencha’s own native packager) BlackBerry, Windows 8 and more (via PhoneGap Build).

At Hojoki, we started using Trigger.io77 two and a half years ago because we were looking for a lightweight alternative to PhoneGap. Even though iOS and Android are its only supported platforms, it offers a good set of native APIs, custom plugins and third-party integration (including Parse push notifications, Flurry analytics and parts of Facebook’s SDK).’s command-line tools allowed us to integrate the app’s packaging into our Grunt78 build process, which is great if you love automation.

One of its key features is Reload9179, which enables developers to push HTML, CSS and JavaScript updates to an app on the fly. Unlike PhoneGap Build’s Hydration80, Reload is specifically designed for development and production apps. This makes it possible to legally bypass Apple’s submission process to push bug fixes and iterate quickly with A/B testing.

Once the 14-day trial is up,’s steep pricing81 is probably the biggest downside for many developers.

With MoSync82 having gone offline a couple of days ago, seems to be the only remaining tool that is not associated with PhoneGap.

Test on Real Devices

Building a mobile app with web technologies obviously tempts us to do most of our testing in a web browser. This might be fine when developing non-native features, but definitely avoid it when releasing. Test with as many manufacturers, platforms and form factors as possible before submitting the app. Android’s fragmentation brings endless possibilities of differences in browser rendering, unsupported features and manufacturer modifications. While iOS does much better with rendering differences, Apple has a growing number of devices with varying sizes, resolutions and pixel densities. Check out “Prioritizing Devices: Testing and Responsive Web Design83” to learn more.

When Facebook famously ditched most of its HTML5 and went native in 2012, it cited missing debugging tools and developer APIs84 as one of its main reasons. LinkedIn drew the same conclusions85 half a year later, stating that HTML5 itself is ready, but basic tools and the ecosystem don’t support it yet. From what I’m seeing, the situation is getting better, with remote debugging in WebView on Android 4.4+ and an increasing number of development tools on all platforms:

Start Thinking in Terms of Hard Releases

When building an app for web browsers, deploying a hot fix to users is a simple step, which means that testing can lose some of its importance. This obviously needs to be reconsidered when you’re releasing an app through an app store. Think of it like software development in the ’90s: You’re now living in the world of hard releases.

So, why is this bad? First, the submission process could easily take a week or two (Hello, Apple!). Secondly, even if your hot fix is released quickly, that doesn’t guarantee that users will update the app any time soon. Here are my suggestions:

  1. Make testing a high priority.
  2. Have some kind of “force update” logic to deprecate old client versions.
  3. Use mechanisms like’s Reload9179 to fix code on the fly.
  4. Apply for an expedited app review92 (Apple only) if you need to be fast.
Get It in the Stores

The tools mentioned above spit out a binary for each platform, which can then be submitted to the relevant store. From this point on, the process is exactly the same as publishing a “normal” native app. Some of the tools we’ve looked at might even have better documentation for this. Nevertheless, here are the official guides:


Now that our hybrid mobile apps have been in Apple’s App Store and in Google Play for two years, I’d like to recapitulate some of the benefits and drawbacks mentioned at the beginning of this article.

For us, a web startup company with very limited resources and no native iOS or Android experience, building an app for multiple platforms in just a few weeks would have been impossible. Choosing the hybrid path enabled us to reuse a lot of code from the web app and to iterate quickly based on user feedback. We’ve even managed to publish native apps for Windows 8 for the desktop and Microsoft Surface as well as Mac OS X with exactly the same code base. The effort of moving to another platform will depend largely on the capabilities of the given browser and device and on the level of your need for native functionality. We needed push notifications, in-app purchases and access to the user’s contacts, among other things. Depending on your needs, a lot of native functionality could make you heavily dependent on the native wrapping tool that you choose.

Finally, let’s see whether hybrid apps really can deliver a native look and feel. Below is a compilation of user reviews from the app stores. Both positive and negative comments are included, but many of the negative reviews are for early releases, which had the same UI for all platforms and was comparatively slow in performance.

★ Great idea, but not a good app. The app runs extremely slow on my Samsung Galaxy Ace and Tab. The app also looks and controls like an iPhone app. This is confusing when you have never had an iPhone.

★★ Another reason apps should not use WebViews for UI.

★★ Service great but WebView app sucks.

★★★ It’s the right app in concept, but it really is too laggy to be practically used. And I’m using Jellybean so there is no excuse.

★★★ It lags a lot and the UI is not beautiful.

★★★ Good but very very slow.

★★★★ This app is very handy, but is a little slow to boot up.

★★★★★ This is working really hard well since the update. It’s a great app to begin with and now it’s working smoother and faster than before.

★★★★★ Extremely smooth and effective.

★★★★★ The app work flawlessly…

★★★★★ Beautiful designed app! Love the interface and the great overview of all your tools! Good job! Keep shippin!

★★★★★ This is an absolutely beautiful aggregate that runs buttery smooth, even on a 3GS. Recommend to anyone doing any sort of project.

We’re definitely moving away from platform-specific app development and towards the many new technologies that are emerging. Larry Page said this97 when asked at Google I/O last year about the future of the web:

In the very long term, I don’t think you should have to think about, as a developer, am I developing for this platform or another, or something like that. I think you should be able to work at a much higher level, and software you write should run everywhere, easily.

The (mobile) web is a major success story in this regard. Being able to use this platform and still be able to distribute an app in all stores is a huge step forward. It will be interesting to see how this all plays out. Whatever happens, using a technology that over a third of the world’s population98 (over two thirds in Europe and the US) relies on probably won’t be a bad choice.

(da, al, ml)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76
  77. 77
  78. 78
  79. 79
  80. 80
  81. 81
  82. 82
  83. 83
  84. 84
  85. 85
  86. 86
  87. 87
  88. 88
  89. 89
  90. 90
  91. 91
  92. 92
  93. 93
  94. 94
  95. 95
  96. 96
  97. 97
  98. 98

The post Hybrid Mobile Apps: Providing A Native Experience With Web Technologies appeared first on Smashing Magazine.

Improving Your Information Architecture With Card Sorting: A Beginner’s Guide

Mon, 10/20/2014 - 13:29

Information architecture (IA) is one of those buzzwords you’ve probably heard before. It refers to the organization of the information on your website and how it all fits together. When planning your IA, involve users of your website in the process as soon as you can.

In this article, we’ll discuss card sorting, a tried and true technique for doing just that. We’ll go through some practical tips for running a card-sorting session, and also cover some examples.

What Is Information Architecture?

One of the great things about modern web design is the way it considers users’ needs from the start. Successful projects are successful often because the owners commit to understanding users, their backgrounds and their goals as early as possible. Like anything else in this game, though, a successful project takes work and planning.

1Good IA helps to make a project successful. It makes content easy to find on a complex website. This is also helped by effective navigation; however, there is some confusion about the difference between the two. What is the difference, anyway? (Image source2) Good Navigation Starts With Good IA

IA refers to the structure of information on a website, and it is depicted with site maps, diagrams and spreadsheets. Navigation refers to elements of an interface that people use to make their way through that structure — menus, breadcrumbs, links — and it is depicted in wireframes or prototypes. Therefore, improving IA starts with analyzing the website’s content and structure first — navigation comes after.

As with many website improvements, it helps to use techniques that involve users. Card sorting is one such technique that has been used for many years due to its reliability and effectiveness. To start with, we’ll examine the causes of poorly organized information — prevention is always better than a cure! We’ll then cover some practical tips for running your own card-sorting sessions and consider how they can improve the IA in your own projects.

Bad IA Is Everywhere

Bad organization can happen anywhere. When was the last time you spent ages looking for something within a complex system and couldn’t find it? A typical example is trying to find something at a large supermarket. Most people could easily find household staples in the frozen goods, dairy or fresh produce section. But which section would you visit to find more obscure products? Where would you find gluten-free bread, your favorite imported brand of hot sauce or that artisanal handmade bean dip you tried at the party last weekend?

Where’s the Hot Sauce?

I sometimes struggle when looking for products at my supermarket, which increases my frustration. I usually end up asking a store employee where to find the item, assuming I haven’t left the store already. The same is true of the web, except that users are even less patient. If users can’t find what they want in seconds, by either browsing or searching, they’re unlikely to stick around. As a result, websites (and supermarkets) benefit greatly from an intuitive structure and organization. Unfortunately, some fail to address these issues properly, leading to lost sales as customers grow frustrated and leave.

How Bad IA Happens

It’s not difficult to end up with a badly organized website, despite one’s best intentions. But how does a website end up like this in the first place?

One of the most common reasons is that the IA is created from the business structure of the organization, rather than from users’ needs. This is the default option for many clients. More common still is when the information is organized according to the preferences and whims of senior members in the company. This is often due to the influence of the HIPPO3 (the highest paid person’s opinion), usually made by an assertive individual who often lacks a grasp of what makes a good website.

The Importance of Content Strategy

For larger websites, the issue is often the lack of a clear content strategy. Managing content is crucial for websites that are large or frequently updated. Content strategy covers processes like:

  • who updates the website and how often,
  • the system for managing old or out-of-date content,
  • maintaining the taxonomies for content on the website (tags, types, categories, labels).

As web professionals, we take pride in our work and planning abilities. Being confronted by an overbearing HIPPO and archaic content strategies is frustrating. However, both of these problems have a common solution. User-centered techniques such as card sorting are powerful because they enable you to be much more scientific in diagnosing and fixing website problems. Later on, we’ll look at how card sorting and content strategy work hand in hand.

How Card Sorting Helps

So, how do we get users involved in organizing the information on our website? Ideally, we want a solution that’s cheap, quick and useful. Thankfully, card sorting is all three of these. The process is much like it sounds. You write down all of the discrete elements that you wish to organize onto cards, and then ask participants to collect them into groups that make sense to them. But is that all there is to it? When can it be used, and what should the outcome be?

When to Use It?

The process of organizing content is fraught with questions. Should it be grouped by type or by subject? Which category does this FAQ question belong to? Card sorting answers these types of questions and is useful in many situations. Some specific examples include:

  • classifying the products in an e-commerce store,
  • organizing questions in an FAQ section,
  • untangling a complex site map.

One of the great things about card sorting is that it needn’t be confined to client projects or even websites. After having used it for clients, we saw its value as a general purpose tool. We have started using it in our own internal meetings to incorporate feedback from our team about how to organize a particular business process or how to structure an upcoming presentation.

Ultimately, the goal of any card sort is to improve the labelling, grouping and organization of information. However, it is best suited to organizing content, and it won’t fix everything on its own. If your website is very task-focused (if it’s an airline-booking website, for example), then card sorting on its own will provide limited benefit. Best to direct your energies towards usability testing, especially if your time or budget is tight.

Card sorting can be useful in your own internal meetings when you need to organize something. It’s a great way to incorporate feedback from your team. (View large version5) Open or Closed?

Card sorting sessions can be classified as one of two types — open or closed. Open card sorting is the more flexible option of the two. Here, users are free to organize the cards you supply into groups that make sense to them, and then come up with their own names for these groups. They are also free to rename cards or make their own suggestions for new cards if they wish.

This type is best when you want to understand how users would group your content. Gathering their ideas and suggestions for names and labels goes a long way to making your website more intuitive.

The alternative method, closed card sorting, is where the categories or labels are fixed. This is useful when you want to understand how users fit content into an existing structure. It’s also used when new content needs to be added to a website.

As an example, consider an e-commerce website and the top-level categories they might have for their products, such as technology, home and garden, and sports and leisure. Now suppose that the store has started stocking a new range of products that have just been launched. Which top-level category on the website should these products be added to? Involving users in a closed card sort could help you to arrive at an answer.

Sometimes you can mix the two techniques. Run an open card sort with one group of users to define the top-level categories. Then run a closed card sort using these new categories, and see how easy it is for users to fit existing content into them.

This Time, It’s Personal

Traditionally, card sorting is as low-tech as it gets, requiring no advanced technology or software. You simply write all of the items on pieces of paper or cards, spread them out on a table, and let your users have their way with them. This method is the most widely used because it’s cheap, quick and intuitive. Being in the same room as your users means you’ll be on hand to guide them through the process.

6OptimalSort is an online tool for card sorting. (Image source7) (View large version8)

The focus of this article is offline sessions, but online sorting tools, such as OptimalSort309 and ConceptCodify2910, present some key advantages. Recruiting participants is easier, which makes it easier to scale up. Many feature advanced reporting tools to identify correlations and patterns, which can take a lot of time when done manually. Free tools such as Trello11 also work well for card sorting, but you lose the ability to generate reports.

The disadvantages of online services are that they are often a lot more expensive and you lose that personal touch. You’ll gain unique insight by observing people’s behavior and body language, which online sessions can’t capture.

Step By Step 1. Prepare

The first task in running an offline session is to prepare your cards. Create a document that lists all of the items you are testing, and give each one a number — spreadsheets are ideal for this. These items could be pages in a site map, product categories or labels in a taxonomy. Each item in this list then gets written on a single card, with the corresponding number written on the reverse. This numbering will help if you want to run more advanced analysis once the sessions are complete.

For the cards themselves, use actual cards instead of paper, which can get lost, worn out or torn easily. Also, don’t test too many things at once. From experience, I can say that no more than 50 to 70 items per session is about right. If you’re trying to organize a massive system, break it up into chunks, and then run sessions for each chunk.

This is pretty much all you need. And a table. (Image source13) (View large version14)

Choosing what to write on the cards can be challenging. Ideally, the labels should be short enough that they can be read quickly, but long enough to make sense and for participants to understand what is being represented. Short titles usually make sense only in the context of the group they belong to. Therefore, summarizing the content as briefly as possible could help, rather than simply using a title.

For example, a label like “More information about our phones” would be preferable to just “More information.” The second item would make sense within an existing parent group named “Our phones,” but on its own it doesn’t make much sense.

In summary:

  • Use a spreadsheet when preparing your cards.
  • Get cards that are durable.
  • Find a balance for labels between simple and intuitive.
2. Walk Before You Can Run

If this is your first time using this technique, use it in a smaller project if you can. Organizing and analyzing the results will be easier, and it will be an opportunity to fine-tune your technique for next time. One decision you’ll need to make early on is whether to run group or individual sessions. The answer usually depends on the complexity of the system, as well as your time and budget. If you’re just starting out, get your feet wet with individual sessions first — you can always scale up later if you need to.

When you’re organizing a lot of content, groups of three users will reach consensus faster. However, they will need more moderation, and they could cost you more time and money. You also run the risk of dealing with aggressive HIPPOs, which can skew the results.

How many users should you include in a session? For the data to be useful, you will need more users than for a typical usability test. Jakob Nielsen recommends about 15 users15 to arrive at statistically useful results. Be wary of including more and more users in your tests, however, because the returns diminish as you go higher.

In summary:

  • If this is your first go with card sorting, try it on a smaller project first.
  • Groups reach consensus faster.
  • Individual sessions are easier to moderate.
  • Get around 15 participants to achieve useful results.
3. Find Participants

The next step is to find participants. For best results, find actual users of the website, especially if it’s a niche or specialized system. If you’re trying to improve the organization of a student intranet, for example, find students. For something more general, like a large e-commerce website, find users with a broad range of demographic indicators, such as age, income or technical ability.

If possible, involve your client in finding users. The client could even provide them directly — say, if you’re redesigning a staff intranet. Offering a small financial incentive, like a gift voucher, also helps to make sure they turn up.

In summary:

  • For niche websites or intranets, find existing users.
  • For more general websites, find users from varied demographics.
  • Clients are often helpful in finding participants.
4. Put It All Together

The final step in preparation is to get the meeting room ready. Get a large table or notice board — the bigger the better. You’ll also need some kind of recording system in place. This could be anything from a camcorder to a smartphone, as long as it enables you to play back the audio and video from the session. Make sure enough drinks and refreshments are on hand, too.

Once you’ve prepared the cards and your users have arrived, it’s time to run the sessions! Provide clear instructions, and let the users know you will be recording their sessions for later review. Explain that you want them to organize the cards into groups that make sense to them and that there is no right or wrong answer. If you’re running an open card sort, get some blank cards for them to write their own names once the initial organization stage is over.

While you’re running the sessions, you might need to act as a moderator. Be on hand if they get stuck (there will likely be a lot of “ums” and “ahs”), but explain that this isn’t a problem. In fact, knowing where they are getting stuck is useful because it indicates a problem with labelling. If they find some cards difficult to classify at all, then leave them off to one side and note what they are. Also, be aware that the demands on you as a moderator will increase in group settings.

In summary:

  • Record each session and take notes.
  • There is no right or wrong answer.
  • The demands on you as a moderator will increase with more participants.
5. Wrap Up

Once they have gotten as far as they can, feel free to ask some questions if you have time. You could ask them to explain their choices in more detail, what made them hesitate about this particular card, and so on.

Finally, record the arrangement they’ve made. The easiest way to do this is simply by taking a photo, but in a small room it can be hard to make sure that all of the cards are in the shot. Taking a photo isn’t always feasible, so if you have numbered the cards, then you can note which numbers were grouped together. This will also help you when you do a more detailed statistical analysis of the groupings, which is out of scope of this article.

Once that’s done, write the participant’s name on your notes and photos. To reduce any potential bias, shuffle the cards for the next user, and then invite them in.

In summary:

  • Taking photos is a quick way to record the arrangements.
  • Ask questions if you have time.
  • Shuffle the cards before each session to reduce bias.
Further Tips
  • Offering a small incentive is a good way to encourage participation.
  • When choosing what to sort, try to choose content from similar levels (i.e. category pages or individual help topics). Mixing child and parent categories is confusing.
  • Provide clear instructions. Have an idea of what you want to say before you start.
  • Provide blank cards and a marker pen for new suggestions — essential for open card sorting.
  • Try not to interrupt participants unless they ask for help.
  • It’s OK if participants can’t group everything. This is useful information.
  • Set a time limit for each session, which will make scheduling much easier.
  • In individual sessions, ensure that no one else is present. This would be distracting.
  • Always record the sessions, and take notes!
Interpreting The Results

Congratulations! You’ve just run your first card-sorting sessions, and your notebook is full of fresh insights. The next step is to interpret the results. Because this is probably your first card-sorting session, you won’t have mountains of results to sort.

For each participant, document two sets of observations for each session. The first step is to create a new document, and then transfer any notes that you made during that session. These should be qualitative observations, such as any new names that were suggested and whether the person hesitated on a particular card.

Next, note that participant’s groupings. You could simply arrange the groupings in a bulleted list in your document or show the groupings in a spreadsheet. A spreadsheet is ideal if you want to perform some advanced statistical analysis later. Various methods and pieces of software can do this for you, and the specifics of this could fill another article by themselves. The important thing is to depict the hierarchy, the parent-child relationships, that each participant created.

What to Look For

Once this is complete, it’s time for analysis. This is as much art as science. The goal is to identify trends that correlate across different sessions, and to answer some of the following questions:

  • Which items appeared together most often?
  • Which items did participants struggle to classify?
  • What new suggestions or labels were made?
  • Were any items put in more than one grouping?
  • Were any other items of interest brought up during the sessions?

If many users organized the cards in a similar way, then the job is fairly straightforward. It’s a matter of applying that same organization to your content. If you have time, then follow up with further user testing to confirm that the new structure is superior to the old one.

For IAs that are complex, users often come up with wildly different structures. You might need to involve a larger group until broad trends emerge. This is the hard part, and it might take a couple of passes to sift through the chaff and get to the good stuff. After running a few sessions, you’ll get the hang of it.

Online tools are a great help in these situations because they make statistical analysis much easier. Advanced techniques of analysis include creating dendrograms. These are tree-like diagrams that show the grouping of information within hierarchies and show how closely items are related. Some online services provide tools for making these, but they’re quite onerous and out of scope for this article.

Dendrograms represent visual groupings of information, but they are tricky to create without specialized software. (Image source17) (View large version18) Example From A Real-World Project Background

Recently, the team at Decibel Digital19 worked on the redesign of a major UK animal charity website. The existing website had a section simply named “A–Z,” which contained hundreds of pages. A lot of the pages were genuinely useful and included varied content such as news, help, videos and downloads. The problem was that there was little to no structure. Everything was simply mixed together and then organized alphabetically. It was the largest section of the website by far, so locating what you needed without relying on search was incredibly hard.

Upon speaking with the digital team, we realized that part of the problem was a lack of oversight. Anyone in the company was able to upload new content to this section, and they would often upload duplicate content with a slightly different name. Over many years, the content in this section grew into a chaotic mess, like an asteroid belt — and just as difficult to navigate.

Running a Content Audit

Getting into the habit of auditing content before redesigning a website is a good thing. We gathered all of the website’s pages and their URLs in a spreadsheet, along with a short description of the content — text, images, video, articles and so on. These URLs can be exported from an existing CMS, but we used a tool named Screaming Frog20.

SEO Spider is a nifty little utility that crawls a website and lists all of its pages and elements. You can use this list to perform a content audit. (View large version22)

Once the spreadsheet was prepared, the next step was to evaluate the content. We used a method called a ROT analysis. We checked each piece of content using the following criteria:

  • R: Is the content redundant?
  • O: Is it outdated?
  • T: Is it trivial?

Working through the website’s content like this can seem laborious, but it was actually very therapeutic. The client felt relieved once they started unravelling the content monster that their old website had spawned, which made everyone feel better about the project. Using this ROT analysis made it faster to reach consensus on choosing pages to remove or archive. Pretty soon, the content was whittled down to manageable levels. The next step was to figure out how to organize this content. Enter card sorting!

A content audit is way more fun than a tax audit. (View large version24) Running a Card-Sorting Session

Following on our content audit, we all felt that the existing A–Z section wasn’t really fit for the purpose, despite a lot of the content being useful and valuable. We decided to run a card-sorting session to organize the content in a way that would inform the new website’s navigation. The goal was to develop a structure that made the content browser-friendly and easily findable without the user having to rely on search.

What to Test?

The website still had a lot of pages, so we had to decide which to include in the sessions. Having too many cards to sort becomes laborious and difficult, so we decided to include only first- and second-level pages to keep things manageable. We also didn’t include utility pages, such as “Contact Us,” “Privacy Policy” and the like, which are commonly found on many other websites. Once this was done, we had about 50 pages left, which we felt was ideal to begin the sessions.

Finding Users

The next step was to find users to test, for which we enlisted the help of the client. The users of the website tended to skew to an older female demographic, so having the client’s input here was very useful. Some of the users we tested had already engaged with the client in offline marketing activity and were excited to help!

Open vs. Closed

We decided to run an open card sort because the content from the existing A–Z section was diverse, comprising news, videos, blog posts, help articles and advice. We wanted to rely on the users’ input to create labels for these content types that made sense to them. As a result, we supplied plenty of blank cards and pens for them to write their own suggestions.

During each session, we took plenty of notes, particularly about the items that users found difficult to sort and any suggestions they made for new labels that we hadn’t considered. We also recorded each session as a backup, so that we could go over the recordings later to observe anything we missed.

What We Found

At the conclusion of the sessions, we took photos of the groupings and updated our spreadsheets. We looked for quantitative data — were there any trends? Did multiple users make similar suggestions for new labels? Did any labels consistently cause users to struggle? We looked at qualitative data, too: specific comments that users made or what they said out loud as they struggled to categorize a particular card.

25The results from your card-sorting sessions might surprise you. (View large version26)

Being a charity, the client relies a lot on donations and support from the public, so getting the labels for these sections right was important. We found some interesting points:

  • The website offered annual paid memberships as a means of supporting the charity, as well as the ability to register a free account on the website. These were labelled as “Register an account” and “Become a member”; however, many users were confused by the difference. We ended up changing the wording of the membership call to action to eliminate the confusion.
  • We had suggested the name “Knowledge Centre” as a label for the help content, but many users suggested alternatives. We ended up using “Help & Advice” on the website instead.
  • The charity ran monthly “Appeals” as another means of getting donations, and it also campaigned on many issues that were listed in “Campaigns.” Lacking any context, though, every user we tested struggled to differentiate these cards. We ended up incorporating the “Campaigns” section into another area of the website.
  • To indicate a desire to support, nearly every user suggested the term “Get Involved” as a major category label. We noticed this convention on other charity websites, too.

After all this was done, we presented our findings in a report. We decided not to include masses of quantitative data. While it was useful to us internally, we felt the client would be unfamiliar with the quantitative data and wouldn’t know how to interpret it without sufficient explanation.

Instead, we presented our key findings (like those listed above) in plain English, and we classified our findings as high, medium and low priority. We also included some recommendations on how to resolve the issues we found. This made it much easier for the client to identify “quick wins” with their content’s structure, and it made it easier for us to implement the required improvements.

The client doesn’t always need to see the messy details. Putting your key findings into a clear report is often preferable. (View large version28) Final Thoughts

Card sorting is a favored technique because it’s cheap, reliable and easy to set up. It’s a great way to become familiar with concepts such as information architecture and user-centred design. Remember that it’s not a silver bullet, and it won’t fix all of the problems on an existing website. A website might be performing poorly or be hard to use for many reasons, and improving the IA might address only some of them. However, when used in tandem with other user-centered design techniques, it can go a long way to starting off a project or redesign on the right foot.

Hopefully, you have enjoyed learning about card sorting. When implemented well, it results in a product that is intuitive and easy to navigate. If you’ve made it a part of your own process already or you have anything to ask or share, please join the discussion in the comments section.

Other Resources

(il, al)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32

The post Improving Your Information Architecture With Card Sorting: A Beginner’s Guide appeared first on Smashing Magazine.

Freebie: Touristic Icons (100 Icons, PNG, SVG)

Fri, 10/17/2014 - 14:10

Icons are a lot like real monuments — they can both be easily recognized. Today’s icon set consists of a set of vector icons that represent monuments across the globe, so they can be literally used anywhere. This colorful set was carefully designed by Freepik131 and is completely free to use for commercial as well as your personal projects, including software, online services, templates and themes.

This icon set is licensed under a Creative Commons Attribution 3.0 Unported2. You may modify the size, color or shape of the icons. No attribution is required, however, reselling of bundles or individual pictograms is prohibited. Please always provide credits to the creators and link to the article in which this freebie was released if you would like to spread the word.

3A few monuments that can be found across Europe. (View large version4) 5From Turkey to the Philippines, including other countries in Asia. (View large version6) 7Well-known monuments across North and South America. (View large version8) 9And even more monuments across Europe. (View large version10) Close-up view: A great architectural work of art, the Sydney Opera House. Close-up view: The well-known white marble mausoleum, the Taj Mahal. Close-up view: The longest inhabited bridge in Europe, the London Bridge. Download The Icon Set For Free Insights From The Designers:

“These icons are trendy and present a good number of reference sites in regards to graphic design. Due to the fact that designers and developers have increasingly become quite demanding when choosing icons, we’ve chosen this line style to capture the elegance and cleanliness. The fluorescent colors are also in line with the trend and, in this case, are the best way to highlight line icons on black and white.

We created this icon set with a modern and minimalist style that contrasts with the traditional character of the photographs in black and white. They can be used to create logos to adorn websites, travel guides, and even video motion graphics. We’ve prepared them in vector format so that they can be used in any type of medium. You’re welcome! ;)”

Thank you to the creative minds behind Freepik131 — we sincerely appreciate your time and efforts! Keep up the brilliant work!


  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13

The post Freebie: Touristic Icons (100 Icons, PNG, SVG) appeared first on Smashing Magazine.

Be A Better Designer By Eating An Elephant

Fri, 10/17/2014 - 11:12

I can’t imagine any other industry in which so much change happens so quickly. If you stop paying attention for a week, it can feel like you’ve not been listening for a year. There’s so much to learn.

Falling behind is easy, too. We might be in the middle of a major project, so we put off learning about this newfangled thing called Sass or Node.js or even quickly experimenting with the new Bootstrap or Foundation that everyone is raving about. Before we know it, we have these elephants of missing knowledge wandering around our minds, reminding us of what we should know and do but haven’t found the time for.

Even just looking at beautiful work and seeing what new technique we could use ourselves can seem like too big a task when we’re swamped with projects. So, we tell ourselves we’ll come back to it later. But later never shows up. The guilt definitely does, but not that elusive deadline of later.

We feel guilty because we know something out there could help us become a better designer or developer and we’re not paying attention to it. Luckily, we can change this and start to catch up on what we’ve been missing out on.

Eating Elephants To Get Things Done

I always liked the productivity quip about how to start and finish a huge project: You do it the same way you eat an elephant, one bite at a time.

I’m not suggesting we go out and eat endangered animals, but what if we did just one small thing a day to expand our knowledge and skill set — and not just for a week or only on weekends, but every day, for 30 days straight? Would we catch up on that knowledge and experience we’re missing?

This challenge of stacking knowledge daily will enable you not only to learn 30 things, but to learn 30 things that will increase in complexity and fit together as a whole new branch of working knowledge for you.

1I’m sure you remember this kind of graph from finance class in high school when you would discuss compound interest. Knowledge is no different: A little bit every day adds up quickly. Actively stacking up your knowledge daily will help you stay on the red path. (View large version2)

How does that sound? Want to give it a go? It’s only 30 days, and it could alter the path of your career, even if slightly.

Pick A Challenge

Pick the right challenge, something that will keep you curious and excited for 30 days, something you’d be happy to chew on slowly. But the challenge should be able to be comfortably broken down into easy pieces, small bites.

Suppose you’re a web designer who wants to learn the CSS processor Sass. No shame in that; I’ll bet, like me, you’ve been very busy. But the prospect of learning Sass is kind of huge, isn’t it? What if we did it in the same way that we’d metaphorically eat an elephant?

Your day-one task might be to learn how to install Ruby and Sass locally. You can’t just be reading, though. That’s not learning — that’s memorizing. You have to do it as you go, downloading the installation files or loading the terminal.

Day two might be learning about and actually writing variables. Day three might be nesting. Days four through six might be setting up your files as partials. And then importing. And then mixins. Then, day seven could be inheritance. You might find that, once you’ve planned these days out, you have enough work for only 15 days, so maybe you’ll jump into learning Bourbon, Foundation or Bootstrap?

That all sounds like a lot to take on, especially if the names all sound intimidating. Biting them off one at a time would make things a lot easier. Downloading and installing a file might not seem like much, but tack that on to learning the basics over the next few days and you’ve started to develop a new skill.

But this isn’t about being perfect. You don’t need to build a beautiful website, or even a functional one. You just have to learn a collection of techniques and stay on track. To do so, to maintain focus, you need a plan.

Plan Your Bites And Prepare As Best You Can

You know what they say about the best laid plans of mice and men. So, avoid setting specific daily goals. Stumbling on day one would put you a day behind from the very start. A lacklustre performance for the following 29 days would then be almost certain. Rather than planning based on days, I’d suggest mapping your progress, which is really just a fancy way of saying “write a checklist” or even “keep a bucket.”

A Sass-loving designer would benefit from having an ordered list of, say, 45 to 60 things to learn and do. Some days, they’ll wake up and not get as much done as they’d like. Other days, they’ll work hard and everything will flow, and they’ll get two days’ worth of work done.

The other option is what I call a bucket. The bucket for my latest challenge was one of those nasty yellow “internal mail” envelopes, filled with topics I could write about. No need to be fancy about it: A list cut up into strips and then put into an envelope is all you need.

3Having a map to work to in these situations, an ordered list, will make the process easier. You will simply have no concern about slipping ahead or falling behind. (Image source4)

But why 45 to 60 topics and tasks if it’s a 30-day challenge? The bucket method makes things truly random, right up to the last day. Well, depending on the challenge, randomness might be exactly what you need. It worked well for me when doing my writing challenge.

Or, if you’re working with the map, it means you’ll focus more on the journey than on the destination. You’ll know well that you’re not going to finish everything in the 30 days, so you’re more likely to focus on what needs to get done day to day. You’ll also have leftovers, which will be perfect to keep you busy learning once the 30 days are up.

But where to find these small tasks? That depends entirely on the challenge you’re undertaking. Don’t overthink at this stage. You could spend far too much time worrying about learning the right thing that you’ll end up not learning anything at all.

For our Sass student, it could be as easy as going through introductory articles, both official ones and on blogs, or a series of classes on YouTube, or something structured like Lynda5 or curated like Gibbon6, Oozled7 or HackDesign8.

Set Time Goals, Limitations And Accountability

In The Creative Habit, Twyla Tharp talks about her morning gym routine. Her goal each morning isn’t to make it to the gym, but simply to get into a taxi. Once she’s done that, all she has to do to reach her morning goal is tell the driver to head towards the gym. Once there, she’ll exercise. What else is there to do? But her winning moment is getting into the taxi.

It seems to run counter to what was mentioned above about not setting goals for tasks, however, goals for start and finish times set us up for success. The real “work” is often simply showing up.

During my last challenge, dragging my foggy head from a warm and loving bed to my cold, sunless office proved to be a bigger challenge than I had anticipated. While the writing eventually became a natural part of my morning, getting to the desk did not.

Focusing on the seemingly insignificant goal of waking up and stumbling a few feet so that I could start typing meant that I had approached my task that day with a fresh accomplishment resting comfortably in memory.

Pressure is relieved before an initial effort is made, and with that first win comes the momentum to keep going. In these kinds of time goals you’ll find limitations and accountability. If you’re goal is to do two hours of work between 5:00 and 7:00 am, then your limit is 7:00.

Having a frequent finish time means that you’ll know how to ration out your effort, and your mind will appreciate the daily rest point that finishing provides. Once this kind of routine is established, you’ll be surprised by how easily you find the energy to keep working, often longer than you thought you would be able to, right up to the last minute.

Friends and followers will come to expect an outcome at the same time daily. Tweeting is simple, but throwing out a tweet at the same time every day sets up expectations for others. Getting a response, even if barely an occasional one, can keep you motivated for days.

In his quick talk at TED, Google’s Matt Cutts gives his take on how to learn or do something you’ve always wanted to in 30 days.


You’re excited. You have your plan of attack; you have your small goals; and you’re ready to get to work and start chewing. Day one arrives and perhaps you wake before dawn, or you’re up when only the owls are about. Either way, you’re ready to work. On that first day and the few that follow, excitement isn’t hard to find. But with it comes a coating of struggle.

A part of you will ask why you’re bothering. You’ll wonder what benefit could possibly be derived from this silly little game you’re playing. Ignore such miserable thoughts. They’ll probably arrive whether you like it or not. And for the first few days you’ll find yourself frequently battling your internal resistance. This scares many, but it’s natural.

Chances are you’re doing something challenging, something you’ve never done before, in parts so small that they won’t seem to matter. The lizard in your brain will tell you that surfing TV or the Internet would be easier. But that will go away. For me, it always goes around day 10. I hope it’s sooner for you, but by day 10 I find that things have become incredibly automatic and the resistance has almost completely disappeared.

However, not long after this, things get too easy. You might even end up setting your own little time traps. For my latest writing challenge, I gave myself up to two hours to do the work, but near day 20 I realized that I could write a piece in less than a quarter of that, and so I would leave it until that was all the time I had left. I’d still wake up on time at be at my desk, but I would mindlessly surf and read. What a wonderful signifier of development leftover time is, but one that I embraced poorly.

Time would be much better spent being reinvested in skill development. You could get dramatic returns by pouring this time into increasingly difficult tasks, and your framework of knowledge would be the richer for it. I’d suggest aiming for discomfort instead of finishing quickly.

In a 30-day challenge, defining your daily problems is up to you, so make sure to revise your plan every day. Look at the task you did that day and adjust for the following days. Was it too hard? Then maybe simplify tomorrow’s expectations. Was it too easy? Spice it up somehow. Write more words, write more code, further develop a design.

You don’t develop when you practice what you’re already good at. Aim to finish with excitement, but not exhaustion.

It’s 30 Days Of Achievement, Not Just Knowledge

You’ve spent 30 days working on a challenge, but not so that the skills you develop become automatic, but to show yourself what you can achieve in a tiny window. You’ve found an hour or two a day and have probably lost nothing because of it. Just keep going.

From day 31, don’t think of what you’re doing as a challenge. It’s simply how you work. It’s how you plan your time, and it’s how you grow your knowledge. Don’t make the mistake I’ve made too many times and expect that once the 30 days are out the door, perfect autonomy will walk into the room.

Before you hit day 31, plan out what you’ll do next. Continue following the map or emptying the bucket, but top it up with another 30 or 50 items, and just keep working. Review frequently, as you would during the 30 days, keep your schedule, and ensure that you’re enjoying the right kind of challenge.

Perhaps this is the biggest gift of the 30 days: not the skills you acquire or any habit you set out to establish, but rather the realization that you can find the time, that you can learn something every day, and that planning your education is important.

A few years ago, Karen X. Cheng posted a time-lapse video of herself learning to dance, a wonderful reminder of how far you can go with daily effort. She went on to cofound Giveit1009, a website that lets you follow others as they go through their own daily development, as well as keep track of your own challenge.


Learning something daily is not hard. Some amazing websites will help you do it; they’ll give you some random, small, independent piece of knowledge that’s great to talk about over coffee but that won’t stack. And that is what’s valuable: stackable knowledge. You can start stacking with such a small number of days — just 30 of them.

30 days. That’s all it takes to learn a skill that could change your career.

You might be able to develop your skills to keep up with, and then break ahead of, the pack. You might be able to charge more because you can offer more or offer better. You could learn to better tell the stories of your clients, to produce work that is more sustainable or even delightful. With time, you could become an authority to whom others in your field, both students and professionals, call on for help in becoming more skilled and knowledgeable themselves. Instead of simply meeting standards and expectations, you could be setting them.

10In all of these are opportunities for happiness, both professional and personal. (Image source11)

You could challenge yourself in ways you can’t imagine, pushing the edge of your knowledge and experience, finding new avenues previously hidden. Your work could becoming increasingly meaningful because of it, as every month or year finds you working at increasingly complex and sophisticated problems. You could, in ways both small and large, shape an industry that I’m willing to bet you love. All that, just because you worked on it an hour or two a day, one bite at a time.

The process is so simple. This is all you’re doing:

  1. Pick a topic.
  2. Break it down into parts.
  3. Map out or randomize those parts.
  4. Show up daily, at the same time, and get to work.
  5. Review progress, and make sure you’re being challenged just enough, adjusting as you go.
  6. Do it for 30 days.

Easy, isn’t it?

That’s how you take your daily bite. Soon, you’ll realize you’ve consumed an elephant-sized body of knowledge. You just have to show up and take action. Most of the people who read this article and like what they’ve learned will forget it all within a couple of hours or days. Or even minutes.

But not you. You’re going to work, and when you do, when you do this silly little challenge thing for 30 days, you’ll find yourself ahead of most of the people you know. Do it for 60 or 90 days or every single day for the rest of your career and you’ll be in a league of your own.

Pick your topic. Take action.

What’s Your Challenge?

What’s that thing you’ve been wanting to achieve? What’s that thing you’ve been wanting to learn?

  • Always wanted to learn how to design your own font? Try a letter a day. Start small by copying a font you love.
  • Need more experience with branding? Design one logo per day, or one brand per month. The first day could be research, the second could be brainstorming, the third sketching, all the way through to a polished style guide.
  • Want to learn photography? What if you started by learning what a single setting on the camera does? Then, work your way through to composition, style and post-production?
  • Want to learn to write? Grab any number of amazing books on writing, and read one rule or lesson per day. Then, write as many examples using that lesson as you can in an hour.
  • Want to learn a programming language? Learn and practice one command per day, with the aim of building a small working prototype.

Let us know what you’ve chosen in the comments. It might keep you on point and, even cooler, might inspire others to join you on the path.

Whatever you decide to do, don’t put it off. Start next Monday. Don’t wait a month or three or start first thing next year. Start next week, maybe the week after if you have to work on your list of tasks. Just start. As soon as you can.

  • Get one of those compound interest and investment charts that shows how just a small bit every day adds up.
  • Five Years of 100 Days12,” Michael Beirut
    Design legend Michael Beirut gives his students at Yale a 100-day design challenge. The results range from brilliant to hilarious. One of my favorites is Ely Kim’s “Boombox”13 dance challenge.
  • 100/100/10014, Zak Klauck
    Klauck undertook this challenge as part of Michael Beirut’s course at Yale. He designed a poster a day based on a short phrase or word, in only one minute.
  • Design Something Every Day!15,” Jad Limcaco, Smashing Magazine
    In 2009, Limcaco interviewed a few designers and illustrators who were doing year-long challenges to make something every day.

A lot of learning and inspiration can be found in what’s been written about design and development sprints in the last couple of years:

(al, il)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19

The post Be A Better Designer By Eating An Elephant appeared first on Smashing Magazine.

CSS-Only Solution For UI Tracking

Thu, 10/16/2014 - 11:55

The web is growing up. We are building applications that work entirely in the browser. They are responsive; they have tons of features and work under many devices. We enjoy providing high-quality code that is well structured and tested.

But what matters in the end is the impact for clients. Are they getting more products sold or are there more visitors for their campaign sites? The final results usually show if our project is successful. And we rely on statistics as a measuring tool. We all use instruments like Google Analytics1. It is a powerful way to collect data. In this article, we will see a CSS-only approach for tracking UI interactions using Google Analytics.

2The Problem

We developed an application that had to work on various devices. We were not able to test on most of them and decided that we had to make everything simple. So simple that there wasn’t a chance to produce buggy code. The design was clean, minimalistic, and there wasn’t any complex business logic.

It was a website displaying information about one of the client’s products. One of our tasks was to track user visits and interactions. For most cases, we used Google Analytics. All we had to do was to place code like the example below at the bottom of the pages:

(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//','ga'); ga('create', '......', '......'); ga('send', 'pageview');

This snippet was enough for tracking page views, traffic, sessions, etc. Moreover, we placed JavaScript where the user interacts with the page. For example, clicking on a link, filling an input field, or checking option boxes.

ga('send', 'event', 'ui-interaction', 'click', 'link clicked', 1);

The guys from Google handled these events nicely, and we were able to see them in our account. However, at some point the client reported that there were devices that have bad or no JavaScript support. They represented roughly 2% of all the devices that visited the site. We started searching for a solution that did not involve JavaScript. We were ready to admit that we could not collect statistics under these circumstances.

It was not that bad, but the client shared another issue. Our little application was going to be part of a private network. The computers there had JavaScript turned off for security reasons. Also, this private network was important for the client. So, he insisted that we still get stats in those cases. We had to provide a proper solution, but the problem was that we had only CSS and HTML available as tools.

3The Solution

While searching for a solution, I was monitoring the Network tab in Chrome’s developer tools when I noticed the following:

4(View large version5)

In the beginning, I thought that there was nothing unusual. Google Analytics’s code made few HTTP requests for its tracking processes. However, the fourth column shows the Content-type header of the response. It is an image. Not JSON or HTML, but an image. Then I started reading the documentation and landed on this Tracking Code Overview6. The most interesting part was:

When all this information is collected, it is sent to the Analytics servers in the form of a long list of parameters attached to a single-pixel GIF image request.

So, Google indeed made the HTTP request but not the trivial Ajax call. It simply appends all the parameters to an image’s URL. After that it performs a request for a GIF file. There is even a name for such requests: beacon7. I wondered why GA uses this approach. Then I realized that there are some benefits:

  • It is simple. We initialize a new Image object and apply a value to its src attribute: new Image().src = '/stats.gif?' + parameters
  • It works everywhere. There is no need to add workarounds for different browsers as we do for Ajax requests.
  • Tiny response. As Stoyan Stefanov said8, the 1×1px GIF image could be only 42 bytes.

I made few clicks and sent events to Google Analytics. Knowing the request parameters, I was able to construct my own image URLs. The only thing to do in the end was to load an image on the page. And yes, this was possible with pure CSS.

background-image: url('');

Setting the background-image CSS property forces the browser to load an image. Finally, we successfully used this technique to track user actions.

9Tracking User Actions

There are several ways to change styles based on user input. The first thing we thought about was the :active pseudo class. This class matches when an element is activated by the user. It is the time between the moment the user presses the mouse button and releases it. In our case, this was perfect for tracking clicks:

input[type="button"]:active { background-image: url(''); }

Another useful pseudo class is :focus. We recorded how many times users started typing in the contact form. It was interesting to find out that in about 10% of cases users did not actually submit the form.

input[name="message"]:focus { background-image: url(''); }

On one page, we had a step-by-step questionnaire. At the end, the user was asked to agree with some terms and conditions. Some of the visitors did not complete that last step. In the first version of the site, we were not able to determine what these users had selected in the questionnaire because the results would have been sent after completion. However, because all the steps were just radio buttons, we used the :checked pseudo class and successfully tracked the selections:

input[value="female"]:checked { background-image: url(''); }

One of the most important statistics we had to deliver was about the diversity of screen resolutions. Thanks to media queries this was possible:

@media all and (max-width: 640px) { body { background-image: url(''); } }

In fact, there are quite a few logical operators10 that we can use. We can track screens with a specific aspect ratio; devices in landscape orientation; or those with a resolution of 300dpi.


The problem with this kind of CSS UI tracking is that we get only the first occurrence of the event. For example, take the :active pseudo class example. The request for the background image is fired only once. If we need to capture every click then, we have to change the URL, which is not possible without JavaScript.

We used the background-image property to make the HTTP requests. However, sometimes we might need to set a real image as a background because of the application’s design. In such cases we could use the content property. It is usually used for adding text or icons but the property also accepts an image. For example:

input[value="female"]:checked { content: url(''); }

Because we are requesting an image, we should make sure that the browser is not caching the file. The statistics server should process the request each time. We could achieve this by providing the correct headers. Check out the image below. It shows the response headers sent by Google:

12(View large version13)

Sending the following headers guarantees that the browser will not cache the image:

Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0

In some cases, we may decide to write our own statistics server. This is an important note that we must consider during development. Here is a simple Node.js-based implementation. We used that for testing purposes:

var fs = require('fs'), http = require('http'), url = require('url'), img = fs.readFileSync(__dirname + '/stat.png'), stats = {}; var collectStats = function(type) { console.log('collectStats type=' + type); if(!stats[type]) stats[type] = 0; stats[type]++; } http.createServer(function(req, res){ var request = url.parse(req.url, true); var action = request.pathname; if (action == '/stat.png') { collectStats(request.query.type); res.writeHead(200, {'Content-Type': 'image/gif', 'Cache-Control': 'no-cache' }); res.end(img, 'binary'); } else { res.writeHead(200, {'Content-Type': 'text/html' }); res.end('Stats server:<pre>' + JSON.stringify(stats) + '</pre>\n'); } }).listen(8000, ''); console.log('Server is running at');

If we save the code to a file called server.js and execute node server.js we will get a server listening on port 8000. There are two possible URLs for querying:

* - shows the collected statistics * - collecting statistics.

By requesting the PNG in the second URL, we are incrementing values. The following piece of code shows the HTML and CSS that we have to place in the browser:

<input type="button" value="click me"/> input[type="button"]:active { background-image: url(''); }

Finally, as a last drawback we have to mention that some antivirus software or browser settings may remove 1×1px beacons. So we have to be careful when choosing this technique and make sure that we provide workarounds.


CSS is usually considered a language for applying styles to webpages. However, in this article we saw that it is more than that. It is also a handy tool for collecting statistics.

(ds, il, og)

  1. 1
  2. 2 #the-problem
  3. 3 #the-solution
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9 #the-tracking
  10. 10
  11. 11 #drawbacks
  12. 12
  13. 13
  14. 14 #summary

The post CSS-Only Solution For UI Tracking appeared first on Smashing Magazine.

Ready For Retina HD: Create Pixel-Perfect Assets For Multiple Scale Factors

Wed, 10/15/2014 - 09:00

The 6 Plus is the first iPhone that sports a “Retina HD” display — the sharpest display Apple has ever made. It forces designers to provide an additional set of image resources to developers to match that sharpness.

We needed only one set of assets for the original iPhone up to iPhone 3GS. And when iPhone 4 came out with the Retina display, we also needed 2x assets — images twice as detailed. Now, with the display of the 6 Plus being even more detailed than that of the iPhone 4, we will also need to provide 3x assets. The numbers 1x, 2x and 3x are also called “scale factors.”

Of course, Android developers have always had to deal with many different sets of assets. Still, designers are finding themselves questioning their production workflow. In this article, we’ll focus on iOS, but you could easily extend this approach to Android and the web. We won’t try to provide a silver bullet, and perhaps other ways might seem easier at first, but this article lays out a solid workflow that scales up for big projects.

First off, your icon sets should be vector-based. The approach described in this article focuses on generating multiple asset versions from a single vector shape in a Photoshop document that contains all of your icons.

A unified icon document has the advantage of keeping everything together in one file, allowing you to see how well your icons and assets harmonize.

If you’re designing for iOS 7 and above, then you might think that 1x versions aren’t needed anymore. However, you’ll still need them for devices such as the original iPad Mini, the iPad 2 and potentially Android and the web.

Set Up Photoshop

First, I’ll show you how I set up Photoshop. If you know what you’re doing, you can use other settings. But for those curious about how I like to work, this is it:

  1. Disable eye candy like “Animated Zoom” and “Flick Panning.”
  2. Disable “Snap Vector Tools and Transforms to Pixel Grid.”

The first point is a matter of personal taste, but not following the second point can get in your way when you’re trying to be precise with the Direct Selection tool.

1These selections will help you working precise with the Direct Selection tool. (View large version2)

Then, I’ll configure the Move tool (V) to select layers. You don’t need to check “Auto-Select” because you can select a layer automatically by pressing the Command key while clicking. Disabling this option protects you from moving layers unintentionally.

3Configure the Move tool (V) to select layers. (View large version4) Feel Free

First and foremost, I believe that design and production are two separate phases. When your creativity is flowing, you shouldn’t worry much about production constraints.

Design at your favorite resolution (perhaps 2x), and lay out using the dimensions of a device you’re familiar with. But definitely use a real device, and use apps like Skala Preview and xScope to mirror the design live on your device. You should not be working with apps unless you are constantly checking the design on a real device.

Tidy Up Those Vectors

As noted, I’ll assume that you’re designing your icons in Illustrator. Before copying them to Photoshop, you’ll need to tidy them up. Use Pathfinder to add and subtract paths until you have a single shape.

5If you design your icons in Illustrator, you need to tidy them up before copying them to Photoshop. (View large version6)

On the left above is a complex icon made up of multiple shapes, including a white shape to simulate transparency. For the icon on the right, I subtracted the white rectangle from the black one behind it. Do this by selecting the two rectangles and pressing the “Minus Front” button in the Pathfinder panel. Then, select all shapes and click “Unite” to combine them into one.

Now, copy the path to Photoshop, and paste it as a shape layer.

Paste your path as a shape layer.

If your shape ends up a mess, that means you didn’t tidy the vector graphic properly.

Align Forces

When you paste the icon in Photoshop, it might look something like this:

7When you paste the icon in Photoshop you will probably see those gray pixels around the shape. (View large version8)

When you zoom in close on the icon, you will probably see those gray pixels around the shape. Those “partial pixels” occur if a shape does not fill an entire pixel. We don’t want any of those.

We want to start working from a 1x version of the icon because, when tidied up properly, you will be able to scale this version up to 2x and 3x without any problems. If you did the original design in 2x, then you’ll need to scale the shape down to 50%.

Now it’s time to align the horizontal and vertical lines to the next full pixel. It’s OK if curves and diagonal lines don’t fill up entire pixels.

Use Photoshop’s Direct Selection tool to mark a group of misaligned anchor points, and use the arrow keys to move these points between two pixels.

Note: The closer you are zoomed in (use Option + Shift + mouse wheel), the more precisely you will be able to move the anchor points.

The anchor points of the bottom and the right side are now aligned to the pixel grid. All partial pixels are gone. Do A Check-Up

Now, make sure all anchor points are on the grid by scaling your 1x version up to 500%. If you see partial pixels, then align them as described above. If everything checks out, then scale the shape down to 20%.

Remember: From now on, you should always scale proportionally from the upper-left corner, and always make sure that the X and Y values are round numbers.

9If you see partial pixels, then align them as described above. (View large version10) Scale It

Let’s see how different resolutions of our icon work out. Select the 1x version (V, then Command + mouse click), and duplicate the icon (Option + click and drag) to a position next to the 1x version.

Scale the duplicated icon up to 200% proportionally from the upper-left corner. The 2x version should show no new partial pixels. It should only be bigger.

To keep things simple, we will assume you are happy with the 1x and 2x versions and that you now want to see the 3x one.

Duplicate the 2x version (Option + click and drag), move it off to the side, and then scale it up by 150%. (So, 200% × 150% = 300%)

Later in this article, I’ll tell you what to do if you are not happy with the results. But if you are happy with the 2x and 3x versions, then you know now that 2x and 3x versions can be generated from the 1x version without any problems.

Go ahead and delete the 2x and 3x versions — we will be generating them automatically.

Generate And Enjoy

Photoshop has a built-in tool called “Generator” that automatically renders a shape layer to multiple image versions. To do that, we have to create a layer group and give it a special name: the file name and scale factor for each version.

In this case, it should look like this: cover.png, 200% cover@2x.png, 300% cover@3x.png

The commas separate the versions, and the percentage tells Photoshop the amount of scaling.

11The commas separate the versions, and the percentage tells Photoshop the amount of scaling. (View large version12)

Now, activate Generator.

13Activate Generator. (View large version14)

Generator will create a folder next to your PSD file and will automatically save PNG files to it when you save the Photoshop document.

15Generator will automatically save PNG files when you save the Photoshop document. (View large version16)

To add a new scale factor at a later point in time, you simply have to alter the layer’s file name.

Get Creative For Different Resolutions

Modifying artwork for different scaling factors is a common practice because you can show more detail in a 2x graphic than you can in a 1x version.

In the following example, the 1x version of the icon contains just a single eighth note, whereas the 2x version contains a beamed note.

17Create different icons for different resolutions. (View large version18)

Obviously, you wouldn’t delete the 2x version because it is different from the 1x. Create an extra group for the 2x version, and give it a layer name that is compatible with Generator. Because you’ve already scaled the 2x version in Photoshop, don’t add “200%.”

To end up with a 3x version after working in 2x, you’ll have to scale by 150%. So, you would add this number to the 3x file name.

19To end up with a 3x version after working in 2x, you’ll have to scale by 150%. (View large version20) Size Matters

Making the 2x versions of your assets exactly two times larger than the 1x assets is absolutely critical. Sometimes this is harder to do than you think. Consider this keyboard:

21Making the 2x versions of your assets is sometimes harder to do than you think. (View large version22)

For the 1x version (the smaller keyboard on the left), I decided that 1-pixel-wide black keys were to thin, so I used 2 pixels.

When you scale that version up (marked in pink in the keyboard on the right), you end up with black keys that are 4 pixels wide, which looks a little too wide.

But with 3-pixel-wide keys, the distance between all of the keys changes. To keep everything symmetrical, we need to make the keyboard 1 pixel shorter. And because we can’t scale 3 pixels by 1.5 without ending up with fuzzy graphics, we also need a special 3x version.

To fix the export size of our 2x asset, we can add a layer mask. Generator will always use the dimensions of a layer mask if one is present.

23To fix the export size of our 2x asset, we can add a layer mask. (View large version24) 25Generator will always use the dimensions of a layer mask if one is present. (View large version26) Summary

Hopefully, the methods described here will simplify your workflow. As you can see, creating pixel-perfect assets for different screen sizes and densities isn’t such a chore when you use vector graphics to your advantage and let Photoshop do the grunt work.

Downsides of This Approach
  • Assets are stored at 1x in the Photoshop file.
Upsides of This Approach
  • Create multiple image assets from a single shape layer, potentially saving yourself a lot of time in the future.
  • Icons are all in one document.
  • Generating assets for other scale factors from your PSD becomes easy for other people.
  • Seeing which resolutions of an icon need special attention becomes easy for other designers.

(ml, al)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26

The post Ready For Retina HD: Create Pixel-Perfect Assets For Multiple Scale Factors appeared first on Smashing Magazine.

Taking A Closer Look At Tech Conferences: The Nitty Gritty Details (A Study)

Tue, 10/14/2014 - 13:13

As I was flying back from the Smashing Conference in New York, I wondered whether it was a success. This wasn’t an original thought. We are always wondering what makes a conference good and what elements will make industry workers stay away.

Good and bad are such subjective terms, though, with almost as many expectations as there are attendees. We decided that just looking at the numbers instead might be a good idea. This article will not present best practices for planning a conference1, but rather will look at how it’s actually done most of the time. While this is not a guide to putting together the perfect conference, it gives a good overview of what seems to work and which elements are so unpredictable that they do not serve as reliable guidelines.

The Aspects Considered

I analyzed the statistics of about 85 different conferences. I looked all over the world, looking at everything from big well-known events to small non-profit community meetings. I chose conferences that have been around for years and that have features that set them apart from other events.

Some of the data is straightforward, such as dates, number of speakers, tracks and workshops. Other aspects yielded much more varied and specific data (such as themes and technical considerations). So, I’ll present some fairly solid figures about some aspects, and convey just a sense of the variability of others. You can find the results in this PDF2.

The Questions
  1. How many speakers were invited to the conference?
  2. How many days did the conference last?
  3. How many tracks were offered?
  4. How many workshops were linked to the conference?
  5. How long did individual sessions last?
  6. How long were the workshops?
  7. How much did the conference cost?
  8. How much did the workshops cost?
  9. How many people attended?
  10. What were the technical details? (Was there Wi-Fi? Were videos made available?)
  11. In which month did the conference take place?
  12. Was the theme a popular one?
  13. Which country hosted the conference?
  14. In what kind of venue did it take place?
  15. How high was the percentage of male/female speakers?

First, a few things regarding the statistics. I will compare both the average and the median, because the discrepancies are at times pronounced. The median lists all values of the data set and picks the middle value. It’s therefore not influenced by extreme values, and gives better information about the real data distribution. The average value is the sum of the sample data divided through the number of values. It’s influenced by extreme values and therefore gives only information about the data distribution in theory. The difference will become clear by directly comparing the figures.

Conference Size

Anyone who is interested in organizing a conference or just attending one will notice that conferences are run in two very different styles. This has a huge impact on scale (number of speakers, choice of tracks, length of conference).

Some conferences, such as TYPO3 Conference 2013163, with its 65 speakers and multiple tracks, aim for large audiences and maximum information propagation. Others, such as the Smashing Conference4, have only around 18 speakers and a single track and set out to create a community experience. Two styles, two different goals.

The data shows a clear tendency towards smaller conferences, most likely for the simple reason that organizing a big conference is much more costly and restrictive in some ways than a smaller one.

  • Median number of speakers per conference: 19
    This median indicates that more than half of the conferences analyzed were fairly compact community events.
  • Average number of conference speakers: 31
    This shows by how much the average is skewed by the few very large events when compared with the median.
  • Median number of tracks: 1
    This is a fairly logical progression from the median number of speakers. Small conferences tend to stick with single tracks.
  • Average number of tracks: 1.9
    This average implies that two tracks are the norm. While the difference between one and two tracks seems negligible, it is anything but. A single-track event demands fewer compromises than multi-track events from both attendees and organizers. Attendees don’t have to worry about overlapping topics, speakers and interests, while organizers can set up the event days exactly as they want. On the other hand, multi-track events give attendees much more flexibility and a wider range of networking opportunities.
  • Median number of conference days (workshop days included): 3
  • Average number of conference days (workshop days included): 2.7
    Conferences rarely last longer than four days. The lower average reflects the lower number of conferences that are longer than the median.

There is a clear tendency towards smaller conferences. Back To School

This indirectly brings us to the topic of workshops. Most events offer a certain number of workshops, usually around the conference days. Only 9% of conferences do not feature any workshops. Combining standard talks and workshops makes a great deal of sense for both organizers and attendees (and their employers!). The combination reduces yearly travel time to training events for attendees, and it spares employers’ pursestrings from the added travel expenses of repeated training excursions.

Conferences that do feature workshops around the event average five full-day workshops; the median, however, drops down to three full-day workshops. This number is not completely arbitrary. Organizers should plan according to the number of attendees expected, keeping in mind that not all of them will attend the workshops. It comes down to the desirability of the workshops, which is a difficult variable to accurately evaluate. The theme, speaker and geography come into play, in ways that are not always easy to discern.

Finally, not to be forgotten are two-hour half-day workshops and “lightning talks.” These are fairly popular, especially at big conferences. Some small conferences also prefer to feature a lot of half-day workshops, instead of highly visible full-day ones. Altogether, 13% of conferences feature short workshops, either next to the full-day ones or exclusively.

The Cost Of Learning

Evaluating conference and workshop prices is quite tricky because the spectrum is quite wide and is determined by different variables, including sponsorship deals and regional standards. A detailed analysis of the motivations behind setting a certain price for an event is beyond the scope of this article. Keep in mind that the numbers below are merely an approximation because I couldn’t find data for all of the conferences that I reviewed. Additionally, several conferences have a one-price-fits-all approach, including workshops in the conference price.

The average and median costs of workshops are very close, at $311 for the former and $307 for the latter (US dollars). This make perfect sense because the costs of workshops vary only according to the duration of the events. A few outliers are worth mentioning because of the regional considerations. Meta Refresh 20145 in India, for example, offers four half-day workshops at the relatively low price of $49 for both days. Reasons to be Creative6 in the UK comes to $501 to $669 per workshop, which is fairly standard for the UK.

Conferences are less predictable. The average and median are quite close, with the former at around $420 and the latter around $349. This, however, is a skewed representation of conference costs. For one, early-bird prices differ significantly from latecomer rates. Also, included in both figures are all conferences prices, without differentiating between one- and multi-day conferences.

Conferences mostly seem to cost between 300 and 400 USD.

Comparing the prices of conferences and workshops to those of other events in the same country might be more telling. This would give a good indication of whether the prices are reasonable.
We The People

Despite our figures here being very spotty, the average (840) and the median (500) number of attendees differ greatly. I would attribute this discrepancy to missing data. However, despite the spotty data, I suspect that the actual average is very close to the median that I calculated, simply because the majority of conferences reviewed here are small single-track events.

The Technical Side

There is insufficient data to make any definitive conclusions about the technical aspects of conferences. Still, several features seem to recur at almost every conference.

On the websites of the 84 conferences in this study, 14 specifically mention that they offer Wi-Fi access to attendees, and 32 promise to release videos of the talks and workshops on their website or on their YouTube or Vimeo channel.

Interestingly, despite many events offering Wi-Fi access, reliability is usually so difficult — or expensive — to guarantee that some conferences (such as Blend7) state up front that Wi-Fi access is not provided, even going so far as to prohibit devices entirely. The rationale is that the presence of devices and the cost of Wi-Fi detracts from the quality and enjoyment of the talks; some hand out pen and notebooks instead. This approach does have some merit because it frees organizers to focus on curating their themes and speaker.

The Ephemera

Finally, let’s quickly look at some figures that are relevant but difficult to evaluate: conference themes, supporting events, location and gender. These factors are mostly determined according to either convenience or the subjective perspective of the organizers.


Themes are plentiful in this industry, ranging from UX design and development tools to marketing and commerce. This chart8 shows some of the most common themes, but keep in mind that these fluctuate as our industry rapidly evolves.

Events That Round Out the Conference Experience

These are a staple. For more than 50% of conferences, this means parties. And this is the one area where organizers can get as crazy and imaginative as their budget allows. You’ll find everything from mundane and marginally productive networking parties with drinks to enthusiastically creative affairs (such as Build9’s). Some employers, the ones footing the bill, might find this to be over the top. A more psychological study might examine the value of associating pleasurable social experiences with work, but that is beyond the scope of this article.

After-parties are where — to paraphrase Pat Allen10 — organizers often make mistakes. From experience with organizing them, I know how important it is for the background music not to interfere with the conversations. Organizers should know that venues tend to get this wrong; many venues can’t seem to believe that large congregations of people don’t automatically want to “get down and boogie.” At the first Smashing Conference’s after-party, I found myself running to the DJ every half hour to ask him to turn down the volume, which would mysteriously and gradually return to the same deafening level. I insisted repeatedly that just because some of the attendees were swaying to the music while talking did not mean they were eager for a rave, but neither the venue’s manager nor the DJ seemed to grasp this.

While a few conferences focus mostly on the basic content, most offer additional experiences, most likely reflecting the idealism of their organizers. For many conference enthusiasts — including organizers — a key function of conferences is to unite the web design and development community. This is often reflected in the wording of promotional materials (“Let’s get together in the company of a few friends11”).

Some discussion lately has focused on reevaluating these traditional events, such as after-parties, which some argue betray some insensitivity. For instance, alcohol is, to put it mildly, not everyone’s cup of tea. As Sara Soueidan explains12 in an interview for CSSconf EU, that is a reason why some attendees or speakers do not attend certain events. JSConf US 201413 provides bikes for people who want to explore the area, and it even offers a “Significant Other Track” for the families of attendees. There are definitely alternatives to the traditional approaches that generate a different ambience.


Below are some figures related to location.

  • 52% of conferences are in Europe, 38% in the Americas, 6% in Asia, 3% in Australia and New Zealand. None are in Africa!
  • 34% are set in the US, more than half in the east (see map).
  • 18% take place in the UK.
  • 14% are set in Germany.
  • Just one is set in Southern Asia (India), and one (not on the list) in Southeast Asia (Philippines).
  • The five biggest conference cities on the list also host the most conferences for their region.
  • Among the five biggest cities are the three cities that host the most conferences (New York, London and Berlin).
  • The fourth most-frequented city, however, is also one of the smallest on the list. With only 156,000 inhabitants, Brighton is only more populous than Faenza, Columbia and Osijek.

The US and EU are the two hottest spots for web conferences.
The size of the city doesn’t seem to be the deciding factor for choice of location, but it is relevant. Gender

I’ll devote a short space to the statistics for the most debated topic of this study, gender. While a gender count among attendees has proven to be impractical, I was able to count — by hand! (never has a more repetitive endeavor been undertaken since Sisyphus’ boulder roll) — the number of male and female speakers at almost all conferences. I found that 22% of speakers were female. Or, to put in in hard numbers, the median number of speakers at the conferences was 19. Of those, 5 were women.

This subject has been heavily discussed in our community recently, with some of the biggest tech firms disclosing their gender-related statistics. According to John Mindiola in an article from 201014, 82.6% of web designers are male. However, while this is the current reality, the issue has reached popular awareness, leading some organizers to actively try to incorporate an equal number of male and female speakers. Such efforts are not only attributable to small conferences either, which can pick their speakers much more carefully; colossal events such as WebTech Conference 201315 and TYPO3 Conference 2013163 are trying to even out the playing field, too (see study PDF).

Gender disparity in the web industry is not a myth. That being said, the percentage of women in content-generating areas is higher than that of men. And while the area of web development boasts a frighteningly antiquated male-dominated environment17, many hope that conferences — being the public face of the industry — will lead by example.


To sum up (pardon the pun), the majority of conferences are small, with around 20 speakers. Most are single-track events, except for those that are 10-plus-track affairs. Many offer workshops to round out the experience. The events usually cost around $500 and offer a slew of fun activities to complement the learning experience, following the proud tradition of “work hard, play hard.”

The full range of the web industry’s work is covered, although the latest advances are getting the most attention, such as the mobile web. Most conferences take place in the EU, but the US hosts the most events of any single country. Finally, the web industry still needs to work on the male-female disparity, which is reflected in the ratio of female-to-male speakers at conferences.

(ml, al)

Front page image credits: Marc Thiele18.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18

The post Taking A Closer Look At Tech Conferences: The Nitty Gritty Details (A Study) appeared first on Smashing Magazine.

Wayfinding For The Mobile Web

Mon, 10/13/2014 - 13:05

When designing mobile first, navigation takes a back seat to content, and ruthless editing paves the way for more focused experiences. The pursuit of simplicity, combined with the tight spatial constraints of mobile viewports, often leads us to strip away elements in an attempt to minimize the interface. But the space-saving convenience we gain through clever editing and a compact UI can come at the expense of the very navigational aids our users rely on.

To help balance the craving for visual simplicity with the need to keep websites easy to navigate, we can borrow some concepts from the world of wayfinding. This article shows how you can apply these concepts to the mobile web.

The Importance Of Wayfinding

As the name implies, wayfinding is how we make sense of our surroundings and navigate the space around us. We continually rely on cues in our environment to orient ourselves and figure out where we’ve been and where to go next. If you’ve ever flown, recall the experience of stepping off the plane in an unfamiliar airport. It may have gone something like this:

  1. You pause at the gate and glance around to quickly survey your surroundings.
  2. You observe which direction most people seem to be walking in and start heading in that direction.
  3. As you begin walking, your attention darts from one sign to another, scanning for any symbol or text that resembles “baggage claim” or “ground transport” and ignoring anything that doesn’t match either of those.
  4. Once you feel like you’re headed in the right direction, your attention relaxes and you begin to pay attention to any shops or restaurants that you might want to return to the next time you’re at the airport.

The way that people orient themselves in digital spaces is not so different from how they find their way around in the real world. Our ability to focus shifts according to whether we’re on the hunt for information or recreationally browsing. We even experience the same emotion and sense of frustration when we’re lost or struggling to reach our intended destination.

Following are three wayfinding concepts that can be incorporated into mobile and responsive designs to help your visitors navigate with more ease.

  1. Circulation systems
    The infrastructure that allows people to move around within a space
  2. Spatial cues
    The observable qualities of a space that help people make sense of their surroundings
  3. Signage
    Instructional signs, symbols and iconography to guide people
Circulation Systems

When moving through a town, the streets and sidewalks are the pathways we use to get from one point to another. Within a building, we might rely on stairways and corridors to make our way around. A variety of routes often coexist, giving people multiple options for reaching their destination. The network of available pathways forms the circulation system of a space. On the web, circulation systems are shaped by navigational structures. The most familiar one is the hierarchical tree menu, a model synonymous with widescreen desktop design.

Hierarchical Tree

This type of top-down categorical tree is the de facto convention for information-rich websites. Users can access top-level (parent) navigation and local (sibling) content. This is advantageous in that it provides many different routes for users to explore.

The hierarchical tree model usually manifests in a horizontal navigation bar, often with a single or multilevel dropdown menu. (View large version2)

This model has the tendency to become link-heavy, making it well suited to large screens but potentially cumbersome when packed into the confines of a small screen. Rather than trying to squish expansive menus onto itty-bitty mobile screens, designers have been exploring the concept of unfolding experiences, a term designer and researcher Rachel Hinman3 uses to describe systems that progressively reveal information to users. As you plan a circulation system for your website, consider how you might be able to incorporate the following “unfolding” patterns:

Nested Doll

Nested doll navigation is a linear menu pattern that is conventional in mobile web apps. Users incrementally tap or swipe to reveal additional menu options as they traverse up and down through the site map. Funnelling users from broad overview pages to detail pages helps them hone in on what they’re looking for and focus on content within an individual section. This approach is well suited to small screens, but comes at the expense of easy lateral movement across sections.

4With the nested doll navifation, users incrementally tap or swipe to reveal additional menu options as they traverse up and down through the site map. (View large version5) Hub and Spoke

This model utilizes a central screen that acts as the launchpad for exploration. Links point outward to other sections of the website or independent applications, each siloed from the others. To move from one section to another, you must first jump back to the hub. This home-screen approach eliminates the need for global navigation on each page, making it a popular choice for task-based applications that benefit from focus and minimal distraction.

6The hub and spoke utilizes a central screen that acts as the launchpad for exploration. (View large version7) Bento Box

The bento box model is a dashboard-style application that pulls in dynamic components and information. Most interactions occur in the context of a single multi-purpose screen that unfolds to reveal layers of additional information. This is a popular choice for websites on which users interact with data aggregated from a variety sources.

8The bento box model pulls in dynamic components and information. (View large version9) Filtered View

Unlike dashboards, which provide a control center for interacting with a variety of data, filtered view systems deal with a single data set. Information may be explored from multiple perspectives, with a variety of views and sorting options controlled by the user.

10Filtered views are seen in music apps, directories and other interfaces in which people navigate large volumes of data. (View large version11) Combining Systems

Even with nice styling and transitions, the bulkiness of traditional navigation systems can feel kludgy on small touch-enabled screens — especially when compared to the elegant, immersive interactions associated with native applications. Trying to shoehorn an information-rich website into an app-like navigation system might be too constraining, yet adopting a fully hierarchical model might be overkill. Fortunately, the models need not be mutually exclusive.

One of our recent projects involved working with a healthcare organization to centralize their content and online tools under a single website. We initially started down the path of building a hierarchical site map that included a section for all of the members-only content. We also toyed with the idea of introducing an additional menu on the website: the public navigation as well as navigation that appears for logged-in members.

This felt more complex than it needed to be and would have been tricky to organize on small screens. Recognizing that current members have very little need for marketing-heavy public content, we ended up dropping all public menus from the members section. And because members were coming to the website primarily to access a few key applications, they benefited from moving away from a hierarchical content structure and toward a hub-and-spoke model with a home screen that would launch their various online tools.

12Rather than stick with a single information-architecture model and nest members-only content within the overall content hierarchy, we saw that a hub-and-spoke approach to the members center made sense. (View large version13)

This turned out to be a big departure from our original plan to create a global header and footer that spanned the entire website, but it permitted us to design a system that was both lean and simple to navigate. This still left us with the challenge of making the transition between public and members content as seamless as possible. We turned to spatial cues to build continuity across the interface.

Spatial Cues

If circulation systems represent the paths that enable people to get to where they want to go, spatial cues are the recognizable qualities of the space that help them orient themselves and that illuminate available paths. Designers rely on a few powerful spatial cues to help users find their way.


A landmark is any remarkable, unique or memorable object you observe in your surroundings. Some landmarks are visible from a distance and help you figure out where you are based on your position relative to them. For example, Chicago is home to one of the world’s tallest skyscrapers, the Willis Tower. If at any point you become disoriented while exploring the city, you need only scan the skyline and compare your relative position to the tower to get a sense of where you are and which way is which. Other landmarks just line your route, helping you find your way to and back from a particular place. Landmarks help us define and make sense of space. The degree to which we rely on landmarks is evidenced by how we offer directions: “Turn left at the fork in the road,” or “Continue straight three blocks until you reach the Starbucks, and then hang a right.”

In UI design, a landmark is any consistently positioned or notable element that helps visitors orient themselves. Some examples of global elements (i.e. visible throughout a website) are:

  • Logo
    For returning to the home screen easily
  • Primary navigation
    Quick access to primary landing pages, enabling users to pivot and explore other sections.
  • Breadcrumbs
    reinforces current location within the system and acts as a ladder to traverse up the site map
  • Search
    Provides reassurance and an alternate way to seek information when users don’t want to backtrack or continue browsing

Other landmarks might appear only in certain places, helping visitors distinguish where they are within a particular section of the website:

  • Section banners
    Reinforces which section user is in
  • Section navigation
    Access to similarly categorized content
  • Unique templates or components (slideshows, galleries or event calendars)
    Visually identifiable points that users might remember passing and try to return to

This alone is pretty straightforward stuff. It gets interesting when you factor in multiscreen behavior and adaptive design. You see, as website visitors peruse your website, they are constructing a mental map of all the identifiable landmarks they encounter. Data shows that many interactions occur over time and across devices. If the landmarks in your interface appear drastically different from one breakpoint or device to another, then you risk disorienting users. On the other hand, if you intentionally build continuity into the UI, persisting recognizable qualities of those landmarks across all screen sizes, then you’ll foster a more familiar, intuitive experience for returning visitors. You can increase continuity of landmarks in your design by examining how UI elements adapt across breakpoints:

  • Position
    Do they retain their relative page position, or do they jump around?
  • Form
    Do items retain their form or transform into something totally different?
  • Color
    Do foreground and background colors stay the same or switch?
  • Priority
    Do the most prominent page components retain their proportional visual weight across screen sizes, or does the hierarchy change?
  • Visibility
    Are visible things still revealed and hidden objects still concealed?
United Pixelworkers’ website has continuity between landmarks across breakpoints. The logo is red in the top left, the navigation is in a black bar along the top, and you can always access the cart from the bright blue button in the top right — no matter which size screen you visit from! (View large version15)

Cleverly adapting the UI to best fit the available screen size or viewport is a worthy goal. Just keep in mind that each adaptation creates a new environment that your users must orient themselves to. While adaptation is a necessity, balance it with an equal focus on continuity.


Edges demarcate the end of one object or section and the beginning of another. In the world around us, we are surrounded by geographic boundaries, like mountains, shorelines and tree lines, as well as man-made ones designed to compartmentalize our environment, like fences and walls. In UI design, clearly defining the edges of regions and objects can more quickly familiarize users with an interface. Boundaries help to demarcate things on a website, such as chrome from content, primary navigation from secondary navigation, and global tools from page-specific functions. At a micro level, edges help define the boundaries of tap targets and separate individual blocks of content.

16Foursquare’s app (left) packs a lot of tappable items into a small space; clearly defined button boundaries improve scannability and minimize mis-taps. Yummly’s app (right) uses distinct interface edges to define button tap targets and to visually separate the masthead region from the content area and to distinguish between individual recipes. (View large version17)

When designing for wide screens, we can rely on white space and columns to delineate content boundaries. When dealing with narrow viewports, we have less space to compose columns and to utilize white space to effectively differentiate sections of a page. We can reclaim the usable benefits of edges in small-screen scenarios by:

  • providing obvious visual cues to suggest the active tap target area of links and buttons,
  • using shifts in background color or strong borders to distinguish template regions.
18Defining edges by using horizontal dividers or shifts in background color can provide important visual cues to distinguish one region of content from the next (for example, separating main content from related links). (View large version19) Signage

Signs are visual aids that provide instruction to people at decision points within a space. Signs communicate through pictographic or typographic elements. In our interfaces, most non-content elements play the role of signage. Elements such as labels, buttons, pagination, menus and calls to action all act as signs. Because symbols tend to take up less space than written text, they are heavily used in mobile design. Because people process images and text differently, designers need to consider certain factors when deciding how and when to use one or the other. Let’s take a quick look at how to use icons effectively.

Using Icons

Icons can be an effective way to communicate information and highlight navigation options while conserving space within the tight confines of a small screen. Universally recognizable symbols can also overcome language barriers, making an interface more globally accessible.

While icons might appeal to aesthetic sensibilities and provide a great solution for visually organizing your interface, they also have the potential to introduce impediments to usability.

Icons work great when they are familiar and obvious, leaving no room for misinterpretation. But even many of the most commonly used icons have multiple meanings. Consider the following icons, which at first seem innocent. What does each represent?

20Because they often have multiple meanings, even simple icons can be ambiguous. (Image credit: IcoMoon21) (View large version22)
  • Pencil
    Write or edit?
  • Plus
    Add item or expand?
  • Minus
    Remove item or collapse?
  • x
    Close or delete?
  • Magnifying glass
    Zoom or search?
  • Caret
    Play, go or slide right?

As we see, even in simple scenarios, icons can be ambiguous. Meanwhile, the allure of a minimal UI tempts many a designer to use icons to represent far more complex concepts. This again challenges us to weigh the value of saving space against the importance of comprehensibility of the interface. Even if the icons are ultimately decipherable, the act of interpreting them increases the cognitive load on the user. This introduces friction to the decision-making process and could impede navigation.

Text Labels

In contrast to icons, well-written text labels can leave less room for misinterpretation, thus resulting in less cognitive load on the user.

Compare the following two screenshots, both of which pair icons with text. The first example focuses first and foremost on the icons, whereas the second places emphasis on text labels.

23The University of Delaware uses mainly icons (left). Walmart emphasis on text labels. (View large version24)

The abstract nature of the graphics demands a fair amount of interpretation, and the accompanying text is harder to scan, partially because of the grid arrangement and partially because of the type’s size. Keep in mind that, with mobile devices, the text is likely to be viewed at arm’s length and with the person and device possibly in motion. In the second example, labels assume focus. The left alignment of text provides a straight reading line down, making it easier to scan and compare navigation options. Here, icons are used to supplement text. Because we process images quickly, once a user has learned what a symbol means, their future interactions will be expedited through recognition (i.e. associating the image with the link it represents).

The previous example also assumes two things. The first is that the text labels are indeed well written. Unclear text can be just as detrimental to navigation as ambiguous iconography. The second assumption is that the visitor is a first-time user. Once a person has learned the positions and meanings of the icons in the first screenshot, the cognitive load will decrease and the interface will have become familiar and, therefore, easier to use.

This aligns with research conducted by User Interface Engineering25, which found that:

  • text and images work better than just text;
  • text alone works better than images alone;
  • icons are learned, but icon positions are learned faster (so, if your favorite app gets a new icon, you won’t be confused; but if someone jumbled the positions of apps on your phone’s home screen, you’d be driven crazy).
Visibility and Decision-Making

Another conflict between graphics and text arises when you’re determining how to present a list of products. An advantage to displaying images is that they help the user visually differentiate between options. Because product images take up more space than their text counterparts, the number of items visible within the viewport will be reduced. So, which is more important, showing more detail for each option or showing more options in a single view?

When category distinctions are obvious, the addition of visual cues (such as product images) minimally benefits usability. The main objective is to show options and make it easy for the user to scan and compare those options. In these scenarios, titles alone might be the best choice because comparing items is easier to do when you can see all (or most) of your options at once. If visitors must scroll or swipe to see their options, they’ll be forced to rely on memory, comparing what’s currently in view with what was previously in view.

On the other hand, for products that are similar to each other, images would help users to better distinguish between them. In this case, differentiating between items might be more important than comparing items within a single view.

26Using images to display category information takes up more space, resulting in fewer categories fitting in the viewport. Although less visually appealing, a simple text list of categories is easier to scan and select from. When browsing individual products, however, product images and visual detail play an important role in helping users to distinguish items. (View large version27) Paving Your Paths

What’s in and out of view is critical to how people find their way. The answer to “Where can I go from here” is shaped by the routes that the user can easily perceive. The most highly trafficked routes (or the ones you want to drive the most traffic through) should be made most visible. Less-traveled routes can afford to be less overtly marked. Whether a navigation system is the primary or secondary one is an important consideration, and it needs to be prioritized as such in the UI. Does the visual prominence of your navigation map to the navigation’s actual priority?

Route Visibility and Hidden Menus

Many popular mobile navigation conventions involve hiding and showing menus. This technique relies on a menu button (often the infamous hamburger icon) that triggers the appearance of a menu, either by toggling open a panel or pushing in navigation from off canvas. Debate persists about whether the hamburger icon is universally recognized as a symbol to represent a menu. It’s potential ambiguity aside, the debate overlooks a larger concern: Even if people recognize it as a cue to summon a menu, the menu options are initially hidden, and so those routes are obscured.

Users following the scent of information will scan the screen for trigger words: text that maps to the words or phrases in their mind that describe what they’re looking for. On wide screens, when navigation is exposed, those trigger words are visible and increase the likelihood that users will spot them and click through. Assuming that your primary navigation menu has concise, mutually exclusive and familiar labels, by storing them out of view, you are concealing those powerful trigger words and in effect obscuring the primary navigation routes.

28Responsive and mobile navigation patterns that conceal and reveal menu items keep content as the focus of the UI. Just be aware of what trigger words you’re also hiding. (View large version29)

Compare this to the “skip to nav” pattern, in which a menu icon scrolls the user down to a menu anchored at the bottom of the page. In this model, the button still affords quick access to the menu via a tap or click, but those trigger words still exist within the visible canvas. Users who scroll or swipe past the main content will discover in plain view the menu options laden with trigger words.

When evaluating which elements to make visible and which to tuck away, consider the following questions:

  • How are your users seeking information?
    If a large number of your visitors are “known-item seekers,” meaning they arrive with a clear idea of what they are looking for, then they will more likely want to search; so, making the search field visible would be an excellent prompt. If most users will have only a general idea of what they want, then they might be more apt to browse and, therefore, would benefit from exposed trigger words.
  • What are your users looking to do, and how else could they get there?
    Compare what’s visible on screen to key content that your target audience is looking for or tasks they intend to complete. Do the content and links you make visible provide an easy enough path for users to accomplish what they came for? Or must they rely on navigation. If the navigation is a supplemental tool, serving as shortcuts to get around the website, then it might benefit from being tucked handily away. On the other hand, if a menu is the primary (or exclusive) means of navigating the website, then it might need greater visibility (or be visible by default).
  • What is your hidden content competing with?
    On a page with minimal content, clicking on an icon to reveal a list of hidden menu options is a no-brainer. But as more content and links are added to the screen, the menu icon has more to compete with. Compound this with the fact that visible links are filled with information scent (i.e. some graphical or textual cue that suggests what content exists behind the link). Meanwhile, an abstract symbol has relatively poor information scent, hinting only that “more options” can be found behind it.

Despite the incredible difference between the physical and digital worlds, the similarity in how we orient ourselves and decide where to go in both spaces is uncanny. The same cues that architects and urban planners rely on to help us process our location, know where to focus and choose our way could be applied in our day-to-day work on the web. Keep in mind that every person who browses an application is making their way through a space — often an unfamiliar one. As the user embarks on their journey, what types of wayfinding assistance are you providing to guide them?

(da, al, ml)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29

The post Wayfinding For The Mobile Web appeared first on Smashing Magazine.

Freebie: Icons Of Autumn (50 Icons, EPS)

Fri, 10/10/2014 - 14:02

There are icons that you can find quite easily, and icons that are difficult to come across. With Icons of Autumn, we are humbled to release a set of 50 free autumn-themed EPS icons illustrated in a lovely sketchy style.

Designed by Nick Botner as line art in Adobe Illustrator, the icons are available in EPS, enabling you to change both the color or the weight of the strokes with ease. However, if you want to make the icons into solid shapes, it shouldn’t take much effort either.

The autumn season has a lot to offer! (View large version31)

This icon set is licensed under a Creative Commons Attribution 3.0 Unported2. You can use the icons in your commercial as well as your personal projects, including software, online services, templates and themes. You may modify the size, color or shape of the icons. No attribution is required, however, reselling of bundles or individual pictograms is prohibited.

You can change both the color or the weight of any of the icons. One of a kind: the leaf of a maple tree. A preview of some of the icons included in the “Icons Of Autumn” icon set. (View large version31) Download The Icon Set For Free! Insights From The Designer:

“Normally, I shy away from designing seasonal things, but I have a special place in my heart for Autumn. Actually, that’s because I used to live in Florida and always welcomed the “cold”. However, now that I live in the PNW, I guess you could say this might be the last time I love Autumn.

And as far as the set goes, it’s a continuation of icons that I have been slowly creating in this smooth sketch style. Previously I designed a nautical set, a weather set, and a scientific set. Now with Autumn added to the family, I need to think about what comes next.”

Thank you to the creative minds behind @nickbotner6 — we sincerely appreciate your time and efforts! Keep up the brilliant work!

(vf, il)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6

The post Freebie: Icons Of Autumn (50 Icons, EPS) appeared first on Smashing Magazine.

“Stop Being So Hard On Yourself”: An Interview With Designer And Entrepreneur Cat Noone

Fri, 10/10/2014 - 11:40

More and more designers and developers in our industry are making the leap into becoming entrepreneurs by starting their very own products. One of these aspiring designers is Cat Noone, co-founder of Liberio.

Cat is a young and talented designer and entrepreneur from Brooklyn, New York, now living and working in Berlin. She worked in the field of special education before jumping into a career that she really loves and makes her happy.

Since switching tracks, Cat has worked as a product designer at Prolific Interactive and as design lead at ADP Innovation Labs, and she has freelanced and advised startups. She is the co-creator of Designer Relationships131 and The Gentle Hound2 and works now on her own start-up Liberio3, an eBook creation and self-publishing platform for everyone.

In this interview, Cat shares insights about her personal life and Berlin, talks about her latest project (the startup Liberio) and gives advice to young designers and developers in the industry.

Q: First, tell us a little about yourself, Cat. Where did you grow up, and how did you start designing?

Cat: I grew up in Brooklyn, New York, in a time when kids still played outside and knew that the street lights turning on meant it was time to come inside. It was great and taught me a lot of the common street sense I have today — I’m grateful for it.

I was surrounded by art throughout my entire childhood. My grandfather and aunt were fantastic with doodles, sketches and more. I remember my aunt pulling out this beautiful piece of Belle from Beauty and the Beast that she did in college — I loved it and that kind of sparked the urge to do the same. I still see the details of that piece in my head, and it inspired me to sketch and draw the characters I loved so much, too.

My family knew the love I had, and still have, for art. They fully supported my passion by swarming me with coloring and sketch books, canvas and paints, pastels and more. I always had pencils, crayons, markers and paint nearby, and I also had this awesome art desk where I kept everything. Paintings, sketches and self-made characters filled my books and donned the refrigerator like they were masterpieces, courtesy of my family — I was always so proud of them.

As I got older, the sketchbook was often the only thing I brought to school. I drew my school notes in there, and the information was retained much easier when the notes were doodled, versus writing them so plainly.

Even though I never intended to be a designer when I was younger (I wanted to be a veterinarian), I guess I should have known I would become one. I was always quite particular about the way things should look, work and be constructed. When I was a kid, I had a clear idea in my head of what made sense and what didn’t. However, despite the love I had for design, I was scared to make the jump into designing full-time when the opportunity first came around.

Brooklyn, New York, the city that Cat grew up in.

I wasn’t sure whether or not I would be able to make a living off of it, and I think I would have failed if I had jumped into it at that time. In hindsight, I certainly wasn’t ready. Instead, I thought that a college degree in something else like psychology or education would be safe, so I went into college as a biology major and minored in psychology. I ended up in the special education field before I decided that you just have to be willing to jump sometimes — and I did.

Q: You live in Berlin now. How did you end up there, and what has made you stay?

Cat: Always a story I enjoy telling! I actually ended up here because of my significant other, Benedikt. We met in the United States, but he lived in Berlin. We knew that, eventually, it would come down to “What now? Who moves where?” [laughs]

I had been in the Valley for a bit and needed something different. I needed a break and knew the change of scenery would work out for me. We discussed it at length, each fully willing to support whatever decision we came up with, and finally came to a conclusion: I would come to Berlin, we’d stay out here for a while, travel around Europe, and after some time we would eventually head back to the States together.

From the moment I stepped foot in Berlin, I knew I made the right decision. For being such a major city, it’s so relaxing and beautiful. There are these little pockets within the center of the city that are so suburban-like. On top of that, the difference in culture, language and more is a nice opportunity to learn so much. I love it.

The so-called “Fernsehturm” is one of the most prominent buildings in Berlin, and is visible throughout the central and some suburban districts of the city.

Q: Having spent a while in Berlin, do you think Berlin (and Germany) is an encouraging place for people in our industry?

Cat: I think it’s great for a variety of reasons. It’s not “busy” out here, for one. The city surrounding the scene is much more calming, making it feel less chaotic in an industry that is always on the go. Compared to the other cities I’ve been in, it’s still a baby startup scene. But that’s part of the reason I’m happy to be out here now rather than later. It’s growing and needs to be molded. Building a company that is part of that feels awesome.

When it comes to the Valley, there are a lot of qualities people in the industry are not happy about. I also see and hear of more designers and developers choosing Berlin over San Francisco, which is interesting. So, I think Berlin could learn from what people dislike about other places and can mature and shape itself into what it should and needs to be in order to thrive. It has a lot of potential; some awesome startups are sprouting lately, and I’m excited to see where it goes. I recommend everyone experience a startup scene at the stage Berlin is at now.

Berlin’s calming scene makes it feel less chaotic in an industry that is always on the go.

Q: Coming to a new city, what do you think is the best strategy to build a creative network and to find people to build something?

Cat: Reach out to people, for sure. You have to break out of your comfort zone and just contact people. One thing I enjoy doing is connecting with people who are in my area on Twitter. It’s nice to see what others are working on and what you can learn from them. Much like the Valley, something is always happening, and someone is always willing to link up for a coffee or lunch. Take advantage of that!

It may feel weird at first, reaching out to someone you don’t know, but it’s well worth it.

Q: You also met cofounder Nicolas Zimmer in Berlin. How did you come up with the idea for Liberio?

Cat: Nicolas actually came up with the core idea for Liberio. He grew up in a family that at one point ran a publishing house. So, he experienced firsthand the transition from traditional to digital and the struggle that self-publishers face.

For me, I had personally tried creating an eBook at one point and knew what it was like to design and create a high-quality one. It was not fun. And I could imagine how many others out there are not as tech-savvy but want to share their thoughts, stories and more with the world.

Once Nicolas and I met and sat down to discuss Liberio further, we solidified it, built on the idea and created what you see today.

4Cat uses the iOS Paper app to sketch. (View large version5)

Q: What makes Liberio better than other solutions?

Cat: Until Liberio, there was no product that enabled the average individual to create and publish an eBook in the simplest, easiest and most beautiful way possible. Before, you had to use multiple and often difficult tools to do so. The publishing market is mostly in the hands of publishing houses, or else the products are made for professionals, which totally eliminates the chance for self-publishers to go far without major help. Realistically, that needed to change. Self-publishing is no longer a niche trend, and we wanted to create something that enables everyone to share their ideas, stories and knowledge.

The one thing we emphasize is that we want to do for eBooks what the App Store did for software: which is to allow individuals to create and publish their ideas and knowledge. Ultimately, we want to be the one-stop shop for it all. Liberio is for everyone. On our platform, we currently have students, teachers, doctors, authors, engineers, designers, chefs, bloggers and more. And that’s really exciting to see.

Q: What were the basic features and main goals you started with, and how did your product evolve?

Cat: Writing and reading are very emotional experiences, and one of the things we wanted from the beginning was to tap into that as much as possible through the branding and voice. That’s the main reason why we went with the illustrative design and friendly voice that we have. From there, we could bring our story, characters, objects and more to life — similar to what you’re familiar with from books.

Our goal from the beginning was to make the design as easy as possible to understand, so that people could easily create and publish an eBook. We started in private beta to ensure that our platform was solid and easy to pick up on, allowing you to simply create and publish right from Google Drive. We knew doing that in private beta would allow people on the platform to talk to us and validate or correct the assumptions we were making and the direction in which we were taking Liberio.

6Early version of Liberio. (View large version7) 8The final version of the front page. (View large version9) 10The final back-end version. (View large version11)

The process helped us to gain a better understanding of our next steps. We’ve learned a lot about what is needed in the self-publishing world versus what is simply wanted. I think our biggest insight was understanding the different ways we need to showcase and promote authors as much as possible; and now, post-launch, we’re working on ways to do so.

Q: There has been a lot of discussion lately about the future of self-publishing. Do you think publishers will become redundant, and will Liberio play a part in that development?

Cat: Definitely. People are realizing they don’t need publishing houses to succeed anymore. Before, having a company like Penguin on your book cover meant dollar signs. However, in the digital world we live in now, with social networks, self-publishers no longer need a publishing house to push their digital content out there, and consumers certainly don’t need the vanity logo to assure them that this is something they’ll want to read. Consumer reading lists are now drawn solely from suggestions based on previous reads and from others in your circle.

Nicolas and I laugh because a lot of people don’t realize that the (infamous) 50 Shades of Gray series started out as a self-published book. Only once it blew up did a publishing house want it because they were guaranteed to make so much money off of it. Before that, they didn’t want to touch it. That’s the problem self-publishers face. But the great thing is, they no longer need the publishing house.

Q: What are your future plans, dreams and hopes for Liberio?

Cat: Ultimately, I want Liberio to be the one-stop-shop not only for authors, but for any individual who wants to easily create and publish content that can then be consumed by everyone. I want to provide them with tools on our platform that enable them to create the most interactive and engaging content and to profit from it emotionally and financially.

There are so many stories left untold, and I’d love to continue doing everything possible to ensure they are written, distributed without a hassle and seen by everyone.

Q: What are the biggest challenges or fears you’ve faced as an entrepreneur, and how did you tackle them?

Cat: So, what come to mind instantly are speed and efficiency. Right now, it’s just Nicolas and I building Liberio, and while it really is great on the one hand, it also has its cons. The number of people on the platform is quickly increasing week by week, and although I won’t and never will complain about that, it means that a lot more hands are needed on deck.

Nicolas is handling all things development and business and some support. I’m focusing on all things design and brand management, business and marketing and some support also. With more people on board, this would obviously alleviate pressure on both of us and free us up to focus on other areas, pushing the product forward in a much faster, more efficient and more strategic way.

Q: You’re life must be very busy right now. What inspires you, and how do you get out of designer’s block?

Cat: I’m definitely influenced by the innovative products around me. They definitely get me excited about what’s to come, and they keep pushing me to work harder and think differently.

I do my best to ensure designer’s block doesn’t happen, because it ends up being kryptonite for me, and my brain becomes toast for a long period of time. It’s happened once already, and I just couldn’t stare at another pixel — it was bad.

When I just can’t get into a groove, though, or I’m not satisfied with how something is going, I make it a point to step away from the Internet and the computer for inspiration. I love traveling, seeing the area around me, reading or looking at magazines and more. I make sure I get lost and mentally detached from the tech world as much as I can.

At the end of the day, I make it a point not to look at my phone or computer as much as possible. It takes a long time for my brain to wind down as it is, so feeding it continually into the night is just counter-productive. To do so, I enjoy cozying up in the living room with Benedikt and our puppy, Dex, watching our shows or going for a nice long walk together.

After a long day at work, Cat mostly likes to relax in her living room.

Q: Besides turning Liberio into a successful product, what are your personal and business goals for this year?

Cat: Oh wow. This is a pretty deep question. I think this year I have more personal goals than I do business-wise, mainly because I know one hand will wash the other — I know, that’s such an old grandma saying.

My biggest battle is and probably always has been myself. I expect a lot from myself. This isn’t necessarily a bad thing, but the problem is that I beat myself up a lot at the same time, and it honestly makes me unproductive. It’s funny because I tell everyone, “Stop being so hard on yourself” — but when it comes to myself, I really don’t take my own advice often.

Although I’m satisfied with a lot of what I do and with the progress I’ve made, there is always the other side talking to me saying, “It isn’t good” or “You’re not going to make it,” and it feels rather low. So, that’s something I want to work on. I want to turn the “It isn’t good” voice into “Can this be improved? If so, how? Look at it from a different angle.”

12A quote from Designer Relationships131 — one of Cat’s side projects.

Personally, I also want to enjoy life more. I spent a lot of time prior to this year focusing on things that I thought would get me closer to “success,” instead of realizing that success is what you make of it. Being successful isn’t about how big your business becomes, but about how happy you are, about the beautiful relationship I create with my significant other. Now, don’t get me wrong: I want to make a big difference in the community, and I want Liberio to be successful, but getting there is so much more likely if the cofounder has a level head to do so.

In business, I want to learn a lot from every aspect of my work right now. I want to educate myself in areas that I am subpar in (development, business, finances, etc.), to ensure I always keep up and continue to hone my skills. I want to build up my network and profile and to connect with a lot of people who I can learn from as best as possible, so that I can apply it to everything I work on.

Q: And last but not least, what advice can you give to young designers and developers who want to start a successful side project or startup?

Cat: Yes, I have a few points that I consider very important to becoming “successful.”

  • Know what you excel and suck at.
    It’s important to know where you flourish and where you fail and to be willing to accept that so that you can accept help. Most people have such big egos that they refuse to admit and ask. It’s a career-killer.
  • Connect.
    Get to know people in the field who you can watch and learn from, speak to and get advice from when you ask. Reach out to them! The worst that’s going to happen is they say no.
  • Use the tools you have.
    Use your tools to make something fast, meaningful and beautiful all at the same time. Use what you know, and then go from there. Adapt once you have the basics down. There’s always going to be something new sprouting up.
  • Love what you do.
    Nothing is worse than going through life doing something that isn’t truly satisfying. It will make life hell for you, your employees and, in the end, the company. It’s not worth it. Find what you love, do it, and the world will benefit. You might be scared, but you have to do what makes you happy — you only have one shot at this.
  • Enjoy the ride.
    When it comes to startups, months are like years. The life cycle is really quick. 90% of companies fail, but in the failure is a compilation of mistakes that blossom into lessons learned. In the end, you take those lessons and learn from them. You apply them to your next venture and hope you’ve learned enough not to make the mistakes again. You’re in the air flying for what seems like a lifetime, and it could be exhausting or exhilarating. So, flap your wings as hard as possible while you’re up there, because there’s no telling when it’ll be time to come back down again.

Thank you for sharing with us these inspiring insights into your work, Cat! Please feel free to follow Cat Noone on Twitter14 and check out her website15.

(al, il)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15

The post “Stop Being So Hard On Yourself”: An Interview With Designer And Entrepreneur Cat Noone appeared first on Smashing Magazine.

A Front-End Developer’s Ode To Specifications

Thu, 10/09/2014 - 13:18

In the physical world, no one builds anything without detailed blueprints, because people’s lives are on the line. In the digital world, the stakes just aren’t as high.

It’s called “software” for a reason: because when it hits you in the face, it doesn’t hurt as much. No one is going to die if your website goes live with the header’s left margin 4 pixels out of alignment with the image below it.

But, while the users’ lives might not be on the line, design blueprints (also called design specifications, or specs) could mean the difference between a correctly implemented design that improves the user experience and satisfies customers and a confusing and inconsistent design that corrupts the user experience and displeases customers.

For those of us who create digital products, design specs could mean the difference between efficient collaboration and a wasteful back-and-forth process with costly implementation mistakes and delivery delays. It could also mean the difference between your business making money and losing money, in which case lives might actually be on the line.

In short, specs can help us to build the right product more quickly and more efficiently.

What Are Blueprints (And Why Are They Blue)?

Why are blueprints blue? To find the answer, let’s go back in time a bit, courtesy of Wikipedia1:

“A blueprint is a reproduction of a technical drawing, documenting an architecture or an engineering design, using a contact print process on light-sensitive sheets. Introduced in the 19th century, the process allowed rapid and accurate reproduction of documents used in construction and industry. The blue-print process was characterized by light colored lines on a blue background, a negative of the original.”

Architectural blueprints were the photocopier of the 19th century. They were the cheapest, most reliable technology available to copy technical drawings.

2Architectural drawing, Canada, 1936 (Image: Wikipedia3) (View large version4)

Blueprints were created by sending light around an ink drawing on transparent film. The light would shine through everywhere except the ink and hit a paper coated with a light-sensitive material, turning that paper blue. This outlined a white copy of the engineering drawing on a dark-blue background.

These copies were then distributed to builders who were responsible for implementing the designs in those drawings.

Today, many graphic designers also distribute design specs to the front-end developers who are responsible for implementing the designs. Design specs are no longer made with paper and light, and they are no longer blue, but, as before, they ensure that the product gets built correctly.

From Bricks To Bits And Bytes

I learned the value of architectural blueprints in my previous career as a real estate developer. One of my responsibilities was to find great architects to create blueprints so that the construction workers we hired knew exactly what to build. Somewhere along the way, I realized that real estate development was not for me: I wanted to make a greater impact by building the scalable skylines of the virtual, rather than the real, world. I learned HTML, CSS and JavaScript and went in search of startups that were hiring. My understanding of the importance of detailed blueprints went with me.

In the wild west of World Wide Web startups, I had to build single-page JavaScript applications that looked good and performed well, and I had to do it quickly. Designs were often handed down to us one week before the product’s release date, and we were asked to start sprinting. The designs usually consisted of Photoshop files (PSDs) with a lot of layers and zero specs to accompany them.

For a former real estate developer, working with graphic designs without specs was like getting a set of architectural blueprints with all of the drawings and none of the numbers. Without the necessary CSS “measurements,” I was forced to hunt through layers and sublayers of shapes and text elements to figure out the right HEX value for the border around the “Buy” button or the font family used in the “Forgot Password?” field. Such a workflow was very unproductive.

I was starving for specs when my friend Chen Blume5 approached me with the idea of Specctr156, a tool that would bring the familiar benefits of architectural blueprints to the world of graphic design and front-end web development. I immediately recognized the value and potential of this idea, so we started working together right away, and soon after that, the first version of Specctr was released.

Properties of objects (specs) created with the Specctr plugin (Source: “Blueprints for the Web: Specctr Adobe Fireworks Plugin447”)

Initially, the Specctr plugin was for Adobe Fireworks users8 only, which at the time — 2012 — seemed to be the best tool for UI and web designers. Later, we expanded the range of supported apps, and today it includes Fireworks, Illustrator, Photoshop and InDesign.

A Picture (And Some Numbers) Are Worth More Than A Thousand Words

They say that a picture is worth a thousand words9. Well, a picture and some RGB values could be worth much more!

“One look is worth a thousand words” appears in a 1913 newspaper advertisement for the Piqua Auto Supply House of Piqua, Ohio (Image: Wikipedia10).

The phrase “A picture is worth a thousand words” means that a complex idea can be conveyed with just a single still image. It also characterizes well one of the main goals of visualization, which is to make it possible to absorb large amounts of data quickly. However, in the design and development business, a picture or a single PSD is not enough.

Developers need to know a design’s exact attributes to be able to write the HTML and CSS necessary to recreate the text and shape elements via code. If a PSD is not accompanied by detailed specs, then making approximate guesses or hunting through layers could lead either to errors or the loss of precious development time.

Developer Focus

When developing something, I might need several minutes to load the necessary mental models in my head before I can be productive. Any interruption could bring a wrecking ball to the intricate imaginary machinery I’ve struggled to assemble inside my head.

This is why having to look up an RGB value or turn to a teammate to ask which typeface is being used could lead to big gaps in my productivity.

And if you’re a member of a distributed or remote team, then you don’t even have the luxury of immediately getting your questions answered by a colleague — you’re off to an asynchronous communication tool like Skype, Hipchat or, worse, email. As Chris Parnin puts it11:

“The costs of interruptions have been studied in office environments. An interrupted task is estimated to take twice as long and contain twice as many errors as uninterrupted tasks. Workers have to work in a fragmented state as 57% of tasks are interrupted. For programmers, there is less evidence of the effects and prevalence of interruptions. Typically, the number that gets tossed around for getting back into the ‘zone’ is at least 15 minutes after an interruption. Interviews with programmers produce a similar number.”

This is why you shouldn’t interrupt a programmer. Seriously. (Check the full comic strip12 by Jason Heeris!) A Carnival Of Errors: Developer Edition

Julia had been at her computer for eight straight hours and was late for dinner with her parents, but she had promised to have this CSS transition between the “product” overlay and “buy” overlay on the master branch by the end of the day. She was almost done, but the type on this “Submit” button didn’t look the same as the one that was live on the website now.

“It’s fine,” she thought. “I’ll change it tomorrow.”

Faced with short deadlines and the prospect of rummaging through Photoshop layers, some developers would take a stab in the dark with what type to use — thus, negating the hours of design research they’ve invested with one stress-fueled decision.

The font looks the same. Well, almost.

In the end, we’ll have to redo it anyway, but for now we’ll meet the deadline. It’s all about developer convenience.

No one in the history of forever put in extra effort to do the wrong thing. Mistakes are usually the result of following a tempting shortcut.

The record industry’s failed attempt to halt the digital distribution of music is a good example of this. Spotify’s whole business model13 is based on the fact that “people were willing to do the right thing but only if it was just as rewarding, and much less hassle, than doing the wrong thing.”

Give your front-end engineer a fully spec’ed design and then bask in the rays of gratitude emanating from their face. They’ll get all of your margins and padding exactly right; that subtle gradient will have the precise values you took so long to match; and it will all get done faster. Why would they do anything else? All of the information they need is right there in front of them!

The Triumph Of Tediousness: Designer Edition

Lauren took a second to appreciate her finished design. It was well-balanced and conveyed a sense of calmness, all while guiding attention towards the “Submit” button.

She was tired and ready to go home after a long day of work, but she had promised to deliver the finished design so that Julia could get a head start on developing it for tomorrow’s deadline. She sometimes created specs for the developers she worked with, but she just didn’t have it in her to type and draw out each individual annotation “by hand.”

“Julia will figure it out,” she thought to herself as she hit “Send.”

It’s all about designer convenience.

If design specs (i.e. blueprints) have so much to offer, then why aren’t they a part of every designer’s workflow? The reason I, as a developer, might skip looking up the type is the same reason many designers don’t create specs: It’s easier not to.

This is because designers are not using the right tools. They manually measure and draw each dimension, and they type each pixel value and RGB value “by hand,” using the same general-purpose drawing tools that they used to create the design.

Any time you ask an artist to stop creating and focus on process, you’re fighting an uphill battle. The hill becomes dramatically steeper when the process is slow and tedious.

With the right tools to automate the creation of specs, designers can reduce costs and enable their whole team to reap the benefits of creating and distributing design specs.

Let’s Create (And Use) Design Specs

The two examples above — with Julia and Lauren — are imaginary, but that doesn’t mean they don’t happen constantly in real life. Developers should not have to make any guesses that lead to errors and lose time. On the other hand, creating detailed specs manually is tedious and takes a lot of the designer’s time.

Is there a better way? I believe there is.

We should start using tools that help us to create design specs with a minimum of hassle. Such tools would save time for both designers and developers and would lead to better designer-developer workflows.

Below are some excerpts from a design document annotated with Specctr. With the help of the Specctr plugin, a designer could quickly provide the color values of any design element, along with the exact width and height, gradient values, type attributes (including font family, weight, kerning, leading, etc.), margins, padding, border properties and more. This would greatly help the developer to implement the design because they would not need to hunt through layers and sublayers or make any guesses.

14Text and spacing specs generated with Specctr156 (View large version16) 17hape and text specs generated with Specctr (View large version18) 19Coordinate and spacing specs generated with Specctr (View large version20)

As a bonus side effect, using detailed design specs will help you to avoid errors and inconsistencies in the final version of the design when it’s implemented in real life. Below is an example of the “drift” that can occur when implementation details are not made explicit and are left up to the developer’s guesswork.

21A comparison of how a design can deviate from a designer’s vision without proper documentation: spec’ed design on the left, unspec’ed design on the right. (View large version22)

Note: Specctr is not the only tool that automatically generates detailed design specs. Plugins such as PNG Express23 (designed to work with Photoshop) do similar tasks, but I’ve been mentioning Specctr because I developеd it myself and have the most experience with it. If you have tried other spec-generation tools, please, share your experience in the comments below.

Components And Style Guides

Developers have long been familiar with the advantages of breaking a large system down into small components through object-oriented programming24, which is currently the dominant programming paradigm, thanks to the adoption of languages such as Java25. Breaking a complex project into self-contained parts that make up the whole allows a single part to be reused in multiple places in a project and allows for greater project organization and easier maintenance.

Designers are also finding26 that breaking down a design into its atomic components allows for greater efficiency because they’re able to combine them to reuse their code and styles27. Seeing the components from which a project’s entire design is derived allows for the immediate communication of style choices made across that project. Examples of the components that would be shown are the grid, buttons, forms, tables and lists.

28Grid component from Mozilla’s “Style Guide”29. (View large version30 31List component from Mozilla’s “Style Guide”. (View large version32

Components combined with design specs make up a style guide33. A style guide serves as a reference both to communicate a project’s design aesthetic and to provide details of its implementation to developers. Developers no longer have to rely on designers to spec individual documents, and can instead use this reference to find the information they need. In this way, a style guide is another great tool for more efficient collaboration between designers and developers.

34A style guide will help you to maintain a consistent look over time. (Source: “How to Make an Effective Style Guide With Adobe Fireworks4335”). (View large version36 Conclusion

I reached out to a few designers for comments about the process they follow to document designs. One of my favorite responses comes from Jason Csizmadi, senior visual designer at Cooper37:

“Developers at all stages of projects expect and demand strong documentation.

Although documentation is never the most exciting aspect of design, it’s a critical step in ensuring smooth working relationships, timely delivery and a successful hand-off at the end. Ultimately, design documentation acts as a life-support system, ensuring that your vision is executed properly.”

Like any good business process, design specs should support the primary endeavor — in this case, to create beautiful websites and applications. Creating these products requires collaboration between designers and developers, and effective collaboration requires effective communication. Investing in the development of workflows and tooling around to make this communication easier and more efficient will pay off big with the speed and effectiveness with which products are built and, ultimately, with the success of the businesses that depend on those products.

Further Reading

I’d like to thank Michel Bozgounov46, who helped me research this article and made a few useful suggestions to improve it.

(mb, al, il)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46

The post A Front-End Developer’s Ode To Specifications appeared first on Smashing Magazine.

Mobile Design Pattern: Inventory-Based Discrete Slider

Wed, 10/08/2014 - 12:57

Sliders are cool. When they’re done well, customers love to interact with them. When they’re not done well, they can cause a lot of frustration (not to mention lost sales) by standing between your customers and what they want. And getting them wrong is surprisingly easy.

In this article, we will present a solution, including the design and code, for a new type of Android slider to address common problems, along with a downloadable Android mini-app for you to try out. It’s a deep dive into sliders based on a chapter in Android Design Patterns. The experimental inventory-based slider we will look at would be at home in any application that asks for a price, a size, or any other faceted input within a widely distributed range.

Why Sliders?

Sliders are intuitive. They provide affordance, a quality that makes a control right for a particular task. They just feel right for dialing a value within a range. Sliders translate well from the physical world to touchscreens, where they look great and are easy to manipulate, without taking up a lot of space. Dual sliders in particular are great for limiting search filters and form values to a set range.

In the physical world, sliders serve a function similar to twist knobs. However, knobs are hard to “turn” on touchscreens, and they usually take up more space than sliders. For touchscreens, sliders are better.

Types Of Sliders

Sliders come in two types: single and double. Single sliders are best for entering one value. Dual sliders are great for searching within a range of values.

There are also two kinds of adjustments: continuous and discrete. Continuous adjustments are for indeterminate values in a range, such as a price or temperature. Discrete adjustments are for predefined values (such as clothing sizes). Both single sliders and dual sliders can take either kind of adjustment. Let’s look at some examples.

Zillow has customers use two single sliders with continuous adjustment to set a price range.

The Zillow app uses two single sliders, both with continuous adjustment. (View large version2)

This real-estate app Trulia uses two dual sliders with continuous adjustments:

The Trulia app uses two dual sliders with continuous adjustments. (View large version4)

Continuous adjustments for prices make sense. Why? Because price ranges are continuous. But they do allow for more precision than most shoppers care about. (A price difference of one cent is unlikely to make a customer reconsider a purchase.)

Discrete adjustments are different. They let you choose values, but only within predefined (i.e. discrete) increments. Facets like shoe size consist of discrete values; in the US and Western Europe, shoes are typically incremented in half-sizes: 6, 6.5, 7 and so on. You can’t buy shoes in a size of 6.25, so providing a control for this level of precision would not make sense.

One way to understand the difference is that single sliders with a low count of discrete values are similar to stepper controls: You can dial the value you want, but only from a predefined set.

This is an example of a dual slider with discrete adjustment stops. (View large version6) Experimental Slider Patterns

Sliders with histograms and sliders based on inventory counts are two great experimental patterns that are variations on the standard slider. It’s unfortunate that they are not more common because they solve many of the problems that sliders can cause for users. We explain the problems with regular sliders in the “Caution” section below and detail the experimental solution in the “Super-Sliders” section (right after “Caution”).

So, at this point, you might be thinking, “Sliders sound great. What’s the downside?” Glad you asked.


Even the best patterns can go bad. Like Harvey Dent, the once loyal ally of Batman and Gotham City’s impeccably ethical district attorney, most things have a dark side. There’s a slippery slope between delight and dismay, and much like the Two-Face character who Dent becomes, sliders can be helpful or hateful. It all depends on how they’re implemented.

Here’s how to sidestep slider problems and keep your customers happy.

Make Sure Reasonable Values Can Be Entered Easily

Kayak has a continuous dual slider for filtering hotel prices (see screenshots below). To get a hotel in Los Angeles that you can afford on a humble mobile UX design consultant’s salary, you must place the pegs right on top of one another. This adjustment is anything but precise. For wide ranges, consider using a slider based on inventory counts, as explained in the “Super-Sliders” section coming up.

The continuous price slider fails to dial a reasonable hotel price in Los Angeles on Kayak’s app. (View large version8) Show the Range

Speaking of range, showing the actual range of prices available in an entire collection is a great idea, as shown in the Kayak screenshots above ($38 to $587), instead of using arbitrary numbers such as $0 and max. Neither Zillow nor Trulia show the true maximum and minimum associated with their local home inventory.

Imagine how useful these sliders would be if they stated from the beginning that they ranged between $476,000 and $3,234,700. Showing the range also helps to avoid dead zones, such as when you’re looking for a home in San Francisco priced below $476,000, which would yield zero results. Be aware of how filtering affects the inventory; setting the range for the overall collection without applying the filters is best.

Don’t Cover the Numbers

As the customer adjusts the slider, the values should appear above the pegs, where the user’s fingers would not cover them. Placing the numbers below or to the side of the slider is not as useful. Kayak’s slider (shown above) is good in this regard: The range is covered while the customer adjusts the slider, but the filter’s actual value is not, which is about the best you can do on a mobile device.

Opt for a Slider With Discrete Positions

Continuous sliders are sexy in principle, because you can dial an exact number and get just the inventory you want. But the reality is that sliders are hard to adjust precisely — both in the physical world and on touch devices. That’s why you almost never see a slider for volume adjustment on a stereo. Ironically, the larger the device, the harder that adjusting the slider precisely seems to be. This is Fitts’ law in action: The time required for an action depends on the distance and size of the target. In other words, adjusting a tiny peg in the middle of a large tablet is difficult.

Regardless of the screen’s size, adjusting a continuous slider precisely while being bumped around on a train is hard. (You have permission to refer to this hereafter as Nudelman’s law if you wish.)

Continuous dual sliders also make it easy to over-constrain the range. For example, creating a continuous slider that enables the customer to dial a price of $45.50 to $46.10 might yield zero results and would not serve the customer well. On the other hand, sliders with discrete positions (i.e. stops) are much easier to adjust. The chance of dialing a range that is too small is also less.

Super-Sliders Save The Day

How can you implement a dual slider so that the user is able to input a price range without running into the dreaded problem of zero results mentioned in the “Caution” section above? Here’s where the experimental patterns discussed earlier come in. These are like regular sliders slightly souped up — super-sliders, if you will. Let us explain.

Regular Slider

A slider could use discrete values arranged according to inventory counts. This type of slider is typically arranged in a linear pattern, which means that a certain distance of movement on the slider’s axis represents an equal absolute change in value. For example, in a five-position slider, the price would go from $0 to $100 in $20 increments:

Each mark on the axis represents an equal absolute change in value on a linear price slider. (View large version10)

Although this is intuitive, the design makes it easy for customers to come up empty-handed, especially if the range is wide and the inventory is not equally distributed.

As explained in the “Caution” section, a customer shopping for superhero capes might select a range for which the inventory is zero — say, $40 to $60 — not knowing that a whole closetful of capes are available in the $62 to $65 range — literally, For a Few Dollars More. (Apologies to Clint Eastwood and Westerns lovers everywhere.)

Super-Slider (With Zero-Results-Fighting Histogram)

This is where a slider with a histogram (as shown below) is helpful. The idea behind this experimental pattern is simple: The 50 to 100 pixels above the fixed-position slider is a histogram that represents the inventory in a particular section of the linear price range. A high bar represents a large numbers of items, and a proportionally short bar represents a smaller number of items. That’s it.

A linear price slider with histogram provides more information. (View large version12)

When using a slider with a histogram, you can still dial the part of the range with low inventory; but making that mistake accidentally is difficult because the inventory counts are clearly shown in the histogram. You can use a slider with a histogram where a standard discrete-position slider would be used; it would take up only a little more vertical space in exchange for a more satisfying customer experience.

No Room for a Histogram?

Another way to implement a slider without using histograms is to arrange the slider’s intervals based on the inventory counts. To do this, divide your entire inventory — say, 100 capes — into five intervals, and you’ll get 20 capes per interval. Now, scan the price range to figure out the price (rounded to the nearest dollar) that corresponds to the approximate inventory count of 20. Suppose the first 19 capes cost between $0 and $60 (remember that we’re assuming no inventory in the $40 to $60 range), the second 21 capes fall in the $61 to $65 range, and so on. Here is what such a slider might look like:

The alternative price slider is based on the inventory counts. (View large version14)

Which implementation should you choose? It depends on the task. Most people don’t mind paying a few dollars outside of their budget, but they absolutely hate getting zero results. An inventory of fewer than 20 items in a given interval is not a satisfying result for most tasks, so use one of the other approaches to provide a better experience. Both a slider with a histogram and a slider based on inventory counts are far superior to the traditional slider. Breaking down the interval according to price is the more flexible approach because it shows the distribution clearly, while never yielding zero results. If the customer’s price range is larger than that of a single 20-item interval, then they can simply select a larger interval using the dual slider.

Both of the experimental sliders out-performed the regular slider in a study we did for a large retailer. Try it yourself. Create a quick prototype and do some “hallway usability.” Ask users to find some items around $70, and compare how they do with the histogram version, the inventory-based version and the regular version.

Tablet Apps

Sliders perform well in tablet apps. Make sure you heed the warnings in the “Caution” section; in particular, opt for a slider with discrete values to ensure accuracy, instead of a continuous slider (adjusting a continuous slider accurately on a large device is harder). Consider device ergonomics and avoid placing sliders in the middle of the screen. Instead, place sliders near the top of the screen, next to the right or left margin, optimized for one-handed operation with the thumb while the fingers hold on to the back of the tablet.

Depending on the design and purpose of your app, experiment by having two sets of sliders on the left and right sides of the screen, to be adjusted by the left and right hands, respectively. This would be especially interesting in apps such as music synthesizers. Finally, experiment with placing sliders vertically along the edge of the tablet (top to bottom), rather than horizontally from left to right, which is the easiest direction to adjust precisely with the thumb, while the fingers hold the back of the tablet.

Try It Out

To see how a slider app feels, a completed slider mini-app is available for you to download and try out. If you’re a developer, you can use it in your own project free of charge (see the “Code” section coming up). To install it, consider using an app installer such as the one made by FunTrigger15, which you can get free on the Play market. Here’s how it works. Connect your Android device to your computer. You should see the Android file-transfer window open automatically. If not, you might need to install software on your computer such as Android File Transfer (Mac users, take note). Download the APK source file 16, and place it in the “App Installer” directory (you might have to create the directory).

Place the APK file in Android’s file-transfer window. (View large version18)

Now, you will be able to launch the app installer on your device. Navigate to the right directory, and tap the icon for the APK file that you want to install.

Use the app launcher to install the app.

After a few customary Android disclaimers, the app will be installed in the normal app area on your device, and you can launch it from there.


We’re providing you with the Java code19 and a demo of a simple dual slider with discrete stops.

This demo has five intervals between the minimum and maximum values, which we’ve arbitrarily set to $47 and $302. It’s arranged in a linear pattern, which means that a certain distance of movement on the slider’s axis represents an equal absolute change in value, making the increment value $51. In a real app, the values would most likely be derived from a database.

private static final int RANGE_MIN_VALUE = 47; private static final int RANGE_MAX_VALUE = 302; private static final int[] RANGE_STEPS = new int[] { 47, 98, 149, 200, 251, 302 };

While five is a good number in principle, you might want to experiment with intervals of seven or nine, depending on the size of the screen.

We recommend that you use the MOD function to determine how many capes need to be in each interval. Then, walk the interval to determine the price breakdown within each range. Finally, if MOD yields a remainder, you can add it to the last interval, or you could get fancier and loop through it to add one or more “excess” capes to each of the intervals. For example, if you have 103 capes, the intervals would be 21, 21, 21, 20, 20. This would more evenly distribute the inventory.

You could use the app as is for your own projects or as a starting point for something fancier. May we suggest a slider with a histogram or an inventory count?

If you do use the code, we’d love to see what you’ve done with it.

This code is provided free of charge and distributed under the GNU General Public License v3. See the README_LICENSE file for details.

  • Say it with us, “Done right, sliders delight.”
    Sliders turn your customers into empowered explorers and instant item locators. Don’t let a good pattern go bad: Remember these rules, and sidestep slider problems.
  • Make sure that reasonable values can be entered easily, and don’t cover the numbers.
    Say no to fat-fingered fumbling with small increments in large ranges. Speaking of ranges…
  • Show the range.
    Stamp out unhelpful labels like “$0” and “No limit.” Instead, show the actual minimum and maximum values that the customer can search within.
  • Be discrete.
    Continuous range sliders aren’t always the best choice. Discrete stops are better for small sets of predefined values, such as shoe sizes (and cape sizes.) And finally…
  • Zap zero results.
    Fight the frustrating fruitless search. Want to give your customers ninja navigational powers? Add a histogram, or use smart intervals based on your inventory.

That’s all there is to it. Working with sliders is no great mystery. You know the patterns. You’ve nabbed the code. Now there’s nothing to stop you from trying a slider.

Want more patterns? Android Design Patterns: Interaction Design Solutions for Developers21 has over 70, including a free design mini-course.

(al, ml)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21

The post Mobile Design Pattern: Inventory-Based Discrete Slider appeared first on Smashing Magazine.

An Introduction To Unit Testing In AngularJS Applications

Tue, 10/07/2014 - 13:03

AngularJS1 has grown to become one of the most popular single-page application frameworks. Developed by a dedicated team at Google, the outcome is substantial and widely used in both community and industry projects.

One of the reasons for AngularJS’ success is its outstanding ability to be tested. It’s strongly supported by Karma112 (the spectacular test runner written by Vojta Jína) and its multiple plugins. Karma, combined with its fellows Mocha173, Chai184 and Sinon205, offers a complete toolset to produce quality code that is easy to maintain, bug-free and well documented.

“Well, I’ll just launch the app and see if everything works. We’ve never had any problem doing that – No one ever.”

The main factor that made me switch from “Well, I just launch the app and see if everything works” to “I’ve got unit tests!” was that, for the first time, I could focus on what matters and on what I enjoy in programming: creating smart algorithms and nice UIs.

I remember a component that was supposed to manage the right-click menu in an application. Trust me, it was a complex component. Depending on dozens of mixed conditions, it could show or hide buttons, submenus, etc. One day, we updated the application in production. I can remember how I felt when I launched the app, opened something, right-clicked and saw no contextual menu — just an empty ugly box that was definitive proof that something had gone really wrong. After having fixed it, re-updated the application and apologized to customer service, I decided to entirely rewrite this component in test-driven development style. The test file ended up being twice as long as the component file. It has been improved a lot since, especially its poor performance, but it never failed again in production. Rock-solid code.

A Word About Unit Testing

Unit testing has become a standard in most software companies. Customer expectations have reached a new high, and no one accepts getting two free regressions for the price of one update anymore.

If you are familiar with unit testing, then you’ll already know how confident a developer feels when refactoring tested code. If you are not familiar, then imagine getting rid of deployment stress, a “code-and-pray” coding style and never-ending feature development. The best part of? It’s automatic.

Unit testing improves code’s orthogonality. Fundamentally, code is called “orthogonal” when it’s easy to change. Fixing a bug or adding a feature entails nothing but changing the code’s behavior, as explained in The Pragmatic Programmer: From Journeyman to Master6. Unit tests greatly improve code’s orthogonality by forcing you to write modular logic units, instead of large code chunks.

Unit testing also provides you with documentation that is always up to date and that informs you about the code’s intentions and functional behavior. Even if a method has a cryptic name — which is bad, but we won’t get into that here — you’ll instantly know what it does by reading its test.

Unit testing has another major advantage. It forces you to actually use your code and detect design flaws and bad smells. Take functions. What better way to make sure that functions are uncoupled from the rest of your code than by being able to test them without any boilerplate code?

Furthermore, unit testing opens the door to test-driven development. While it’s not this article’s topic, I can’t stress enough that test-driven development is a wonderful and productive way to write code.

What and What Not to Test

Tests must define the code’s API. This is the one principle that will guide us through this journey. An AngularJS application is, by definition, composed of modules. The elementary bricks are materialized by different concepts related to the granularity at which you look at them. At the application level, these bricks are AngularJS’ modules. At the module level, they are directives, controllers, services, filters and factories. Each one of them is able to communicate with another through its external interface.

Everything is bricks, regardless of the level you are at. (View large version8)

All of these bricks share a common attribute. They behave as black boxes, which means that they have a inner behavior and an outer interface materialized by inputs and outputs. This is precisely what unit tests are for: to test bricks’ outer interfaces.

Black box model (well, this one is gray, but you get the idea) (View large version10)

Ignoring the internals as much as possible is considered good practice. Unit testing — and testing in general — is a mix of stimuli and reactions.

Bootstrapping A Test Environment For AngularJS

To set up a decent testing environment for your AngularJS application, you will need several npm modules. Let’s take a quick glance at them.

Karma: The Spectacular Test Runner

Karma112 is an engine that runs tests against code. Although it has been written for AngularJS, it’s not specifically tied to it and can be used for any JavaScript application. It’s highly configurable through a JSON file and the use of various plugins.

If you don’t see this at some point in the process, then you might have missed something. (View large version13)

All of the examples in this article can be found in the dedicated GitHub project14, along with the following configuration file for Karma.

// Karma configuration // Generated on Mon Jul 21 2014 11:48:34 GMT+0200 (CEST) module.exports = function(config) { config.set({ // base path used to resolve all patterns (e.g. files, exclude) basePath: '', // frameworks to use frameworks: ['mocha', 'sinon-chai'], // list of files / patterns to load in the browser files: [ 'bower_components/angular/angular.js', 'bower_components/angular-mocks/angular-mocks.js', 'src/*.js', 'test/*.mocha.js' ], // list of files to exclude exclude: [], // preprocess matching files before serving them to the browser preprocessors: { 'src/*.js': ['coverage'] }, coverageReporter: { type: 'text-summary', dir: 'coverage/' }, // test results reporter to use reporters: ['progress', 'coverage'], // web server port port: 9876, // enable / disable colors in the output (reporters and logs) colors: true, // level of logging logLevel: config.LOG_INFO, // enable / disable watching file and executing tests on file changes autoWatch: true, // start these browsers browsers: ['PhantomJS'], // Continuous Integration mode // if true, Karma captures browsers, runs the tests and exits singleRun: false }); };

This file can be automagically generated by typing karma init in a terminal window. The available keys are described in Karma’s documentation15.

Notice how sources and test files are declared. There is also a newcomer: ngMock16 (i.e. angular-mocks.js). ngMock is an AngularJS module that provides several testing utilities (more on that at the end of this article).


Mocha173 is a testing framework for JavaScript. It handles test suites and test cases, and it offers nice reporting features. It uses a declarative syntax to nest expectations into cases and suites. Let’s look at the following example (shamelessly stolen from Mocha’s home page):

describe('Array', function() { describe('#indexOf()', function() { it('should return -1 when the value is not present', function() { assert.equal(-1, [1,2,3].indexOf(5)); assert.equal(-1, [1,2,3].indexOf(0)); }); }); });

You can see that the whole test is contained in a describe call. What is interesting about nesting function calls in this way is that the tests follow the code’s structure. Here, the Array suite is composed of only one subsuite, #indexOf. Others could be added, of course. This subsuite is composed of one case, which itself contains two assertions and expectations. Organizing test suites into a coherent whole is essential. It ensures that test errors will be reported with meaningful messages, thus easing the debugging process.


We have seen how Mocha provides test-suite and test-case capabilities for JavaScript. Chai184, for its part, offers various ways of checking things in test cases. These checks are performed through what are called “assertions” and basically mark a test case as failed or passed. Chai’s documentation has more19 on the different assertions styles.


Sinon205 describes itself as “standalone test spies, stubs and mocks for JavaScript.” Spies, stubs and mocks all answer the same question: How do you efficiently replace one thing with another when running a test? Suppose you have a function that takes another one in a parameter and calls it. Sinon provides a smart and concise way to monitor whether the function is called and much more (with which arguments, how many times, etc.).

Unit Testing At The Application Level

The point of the external interface of a module in an AngularJS application is its ability to be injected into another module — that it exists and has a valid definition.


This is enough and will throw an error if myAwesomeModule is nowhere to be found.

Unit Testing At The Module Level

An AngularJS module can declare several types of objects. Some are services, while others are more specialized. We will go over each of them to see how they can be bootstrapped in a controlled environment and then tested.

Filters, Services and Factories: A Story of Dependency Injection

Filters, services and factories (we will refer to these as services in general) can be compared to static objects or singletons in a traditional object-oriented framework. They are easy to test because they need very few things to be ready, and these things are usually other services.

AngularJS links services to other services or objects using a very expressive dependency-injection model, which basically means asking for something in a method’s arguments.

What is great about AngularJS’ way of injecting dependencies is that mocking a piece of code’s dependencies and injecting things into test cases are super-easy. In fact, I am not even sure it could be any simpler. Let’s consider this quite useful factory:

angular.module('factories', []) .factory('chimp', ['$log', function($log) { return { ook: function() { $log.warn('Ook.'); } }; }]);

See how $log is injected, instead of the standard console.warn? While AngularJS will not print $log statements in Karma’s console, avoid side effects in unit tests as much as possible. I once reduced by half the duration of an application’s unit tests by mocking the tracking HTTP requests — which were all silently failing in a local environment, obviously.

describe('factories', function() { beforeEach(module('factories')); var chimp; var $log; beforeEach(inject(function(_chimp_, _$log_) { chimp = _chimp_; $log = _$log_; sinon.stub($log, 'warn', function() {}); })); describe('when invoked', function() { beforeEach(function() { chimp.ook(); }); it('should say Ook', function() { expect($log.warn.callCount).to.equal(1); expect($log.warn.args[0][0]).to.equal('Ook.'); }); }); });

The pattern for testing filters, services or other injectables is the same. Controllers can be a bit trickier to test, though, as we will see now.


Testing a controller could lead to some confusion. What do we test? Let’s focus on what a controller is supposed to do. You should be used to considering any tested element as a black box by now. Remember that AngularJS is a model-view-whatever (MVW) framework, which is kind of ironic because one of the few ways to define something in an AngularJS application is to use the keyword controller. Still, any kind of decent controller usually acts as a proxy between the model and the view, through objects in one way and callbacks in the other.

The controller usually configures the view using some state objects, such as the following (for a hypothetical text-editing application):

angular.module('textEditor', []) .controller('EditionCtrl', ['$scope', function($scope) { $scope.state = {toolbarVisible: true, documentSaved: true}; $scope.document = {text: 'Some text'}; $scope.$watch('document.text', function(value) { $scope.state.documentSaved = false; }, true); $scope.saveDocument = function() { $scope.sendHTTP($scope.document.text); $scope.state.documentSaved = true; }; $scope.sendHTTP = function(content) { // payload creation, HTTP request, etc. }; }]);

Chances are that the state will be modified by both the view and the controller. The toolbarVisible attribute will be toggled by, say, a button and a keyboard shortcut. Unit tests are not supposed to test interactions between the view and the rest of the universe; that is what end-to-end tests are for.

The documentSaved value will be mostly handled by the controller, though. Let’s test it.

describe('saving a document', function() { var scope; var ctrl; beforeEach(module('textEditor')); beforeEach(inject(function($rootScope, $controller) { scope = $rootScope.$new(); ctrl = $controller('EditionCtrl', {$scope: scope}); })); it('should have an initial documentSaved state', function(){ expect(scope.state.documentSaved).to.equal(true); }); describe('documentSaved property', function() { beforeEach(function() { // We don't want extra HTTP requests to be sent // and that's not what we're testing here. sinon.stub(scope, 'sendHTTP', function() {}); // A call to $apply() must be performed, otherwise the // scope's watchers won't be run through. scope.$apply(function () { scope.document.text += ' And some more text'; }); }); it('should watch for document.text changes', function() { expect(scope.state.documentSaved).to.equal(false); }); describe('when calling the saveDocument function', function() { beforeEach(function() { scope.saveDocument(); }); it('should be set to true again', function() { expect(scope.state.documentSaved).to.equal(true); }); afterEach(function() { expect(scope.sendHTTP.callCount).to.equal(1); expect(scope.sendHTTP.args[0][0]).to.equal(scope.document.text); }); }); }); });

An interesting side effect of this code chunk is that it not only tests changes on the documentSaved property, but also checks that the sendHTTP method actually gets called and with the proper arguments (we will see later how to test HTTP requests). This is why it’s a separated method published on the controller’s scope. Decoupling and avoiding pseudo-global states (i.e. passing the text to the method, instead of letting it read the text on the scope) always eases the process of writing tests.


A directive is AngularJS’ way of teaching HTML new tricks and of encapsulating the logic behind those tricks. This encapsulation has several contact points with the outside that are defined in the returned object’s scope attribute. The main difference with unit testing a controller is that directives usually have an isolated scope, but they both act as a black box and, therefore, will be tested in roughly the same manner. The test’s configuration is a bit different, though.

Let’s imagine a directive that displays a div with some string inside of it and a button next to it. It could be implemented as follows:

angular.module('myDirectives', []) .directive('superButton', function() { return { scope: {label: '=', callback: '&onClick'}, replace: true, restrict: 'E', link: function(scope, element, attrs) { }, template: '<div>' + '<div>{{label}}</div>' + '<button ng-click="callback()">Click me!</button>' + '</div>' }; });

We want to test two things here. The first thing to test is that the label gets properly passed to the first div’s content, and the second is that something happens when the button gets clicked. It’s worth saying that the actual rendering of the directive belongs slightly more to end-to-end and functional testing, but we want to include it as much as possible in our unit tests simply for the sake of failing fast. Besides, working with test-driven development is easier with unit tests than with higher-level tests, such as functional, integration and end-to-end tests.

describe('directives', function() { beforeEach(module('myDirectives')); var element; var outerScope; var innerScope; beforeEach(inject(function($rootScope, $compile) { element = angular.element('<super-button label="myLabel" on-click="myCallback()"></super-button>'); outerScope = $rootScope; $compile(element)(outerScope); innerScope = element.isolateScope(); outerScope.$digest(); })); describe('label', function() { beforeEach(function() { outerScope.$apply(function() { outerScope.myLabel = "Hello world."; }); }) it('should be rendered', function() { expect(element[0].children[0].innerHTML).to.equal('Hello world.'); }); }); describe('click callback', function() { var mySpy; beforeEach(function() { mySpy = sinon.spy(); outerScope.$apply(function() { outerScope.myCallback = mySpy; }); }); describe('when the directive is clicked', function() { beforeEach(function() { var event = document.createEvent("MouseEvent"); event.initMouseEvent("click", true, true); element[0].children[1].dispatchEvent(event); }); it('should be called', function() { expect(mySpy.callCount).to.equal(1); }); }); }); });

This example has something important. We saw that unit tests make refactoring easy as pie, but we didn’t see how exactly. Here, we are testing that when a click happens on the button, the function passed as the on-click attribute is called. If we take a closer look at the directive’s code, we will see that this function gets locally renamed to callback. It’s published under this name on the directive’s isolated scope. We could write the following test, then:

describe('click callback', function() { var mySpy; beforeEach(function() { mySpy = sinon.spy(); innerScope.callback = mySpy; }); describe('when the directive is clicked', function() { beforeEach(function() { var event = document.createEvent("MouseEvent"); event.initMouseEvent("click", true, true); element[0].children[1].dispatchEvent(event); }); it('should be called', function() { expect(mySpy.callCount).to.equal(1); }); }); });

And it would work, too. But then we wouldn’t be testing the external aspect of our directive. If we were to forget to add the proper key to the directive’s scope definition, then no test would stop us. Besides, we actually don’t care whether the directive renames the callback or calls it through another method (and if we do, then it will have to be tested elsewhere anyway).


This is the toughest of our little series. What is a provider exactly? It’s AngularJS’ own way of wiring things together before the application starts. A provider also has a factory facet — in fact, you probably know the $routeProvider and its little brother, the $route factory. Let’s write our own provider and its factory and then test them!

angular.module('myProviders', []) .provider('coffeeMaker', function() { var useFrenchPress = false; this.useFrenchPress = function(value) { if (value !== undefined) { useFrenchPress = !!value; } return useFrenchPress; }; this.$get = function () { return { brew: function() { return useFrenchPress ? 'Le café.': 'A coffee.'; } }; }; });

There’s nothing fancy in this super-useful provider, which defines a flag and its accessor method. We can see the config part and the factory part (which is returned by the $get method). I won’t go over the provider’s whole implementation and use cases, but I encourage you to look at AngularJS’ official documentation about providers21.

To test this provider, we could test the config part on the one hand and the factory part on the other. This wouldn’t be representative of the way a provider is generally used, though. Let’s think about the way that we use providers. First, we do some configuration; then, we use the provider’s factory in some other objects or services. We can see in our coffeeMaker that its behavior depends on the useFrenchPress flag. This is how we will proceed. First, we will set this flag, and then we’ll play with the factory to see whether it behaves accordingly.

describe('coffee maker provider', function() { var coffeeProvider = undefined; beforeEach(function() { // Here we create a fake module just to intercept and store the provider // when it's injected, i.e. during the config phase. angular.module('dummyModule', function() {}) .config(['coffeeMakerProvider', function(coffeeMakerProvider) { coffeeProvider = coffeeMakerProvider; }]); module('myProviders', 'dummyModule'); // This actually triggers the injection into dummyModule inject(function(){}); }); describe('with french press', function() { beforeEach(function() { coffeeProvider.useFrenchPress(true); }); it('should remember the value', function() { expect(coffeeProvider.useFrenchPress()).to.equal(true); }); it('should make some coffee', inject(function(coffeeMaker) { expect(coffeeMaker.brew()).to.equal('Le café.'); })); }); describe('without french press', function() { beforeEach(function() { coffeeProvider.useFrenchPress(false); }); it('should remember the value', function() { expect(coffeeProvider.useFrenchPress()).to.equal(false); }); it('should make some coffee', inject(function(coffeeMaker) { expect(coffeeMaker.brew()).to.equal('A coffee.'); })); }); }); HTTP Requests

HTTP requests are not exactly on the same level as providers or controllers. They are still an essential part of unit testing, though. If you do not have a single HTTP request in your entire app, then you can skip this section, you lucky fellow.

Roughly, HTTP requests act like inputs and outputs at any of your application’s level. In a RESTfully designed system, GET requests give data to the app, and PUT, POST and DELETE methods take some. That is what we want to test, and luckily AngularJS makes that easy.

Let’s take our factory example and add a POST request to it:

angular.module('factories_2', []) .factory('chimp', ['$http', function($http) { return { sendMessage: function() { $'', {message: 'Ook.'}); } }; }]);

We obviously do not want to test this on the actual server, nor do we want to monkey-patch the XMLHttpRequest constructor. That is where $httpBackend enters the game.

describe('http', function() { beforeEach(module('factories_2')); var chimp; var $httpBackend; beforeEach(inject(function(_chimp_, _$httpBackend_) { chimp = _chimp_; $httpBackend = _$httpBackend_; })); describe('when sending a message', function() { beforeEach(function() { $httpBackend.expectPOST('', {message: 'Ook.'}) .respond(200, {message: 'Ook.', id: 0}); chimp.sendMessage(); $httpBackend.flush(); }); it('should send an HTTP POST request', function() { $httpBackend.verifyNoOutstandingExpectation(); $httpBackend.verifyNoOutstandingRequest(); }); }); });

You can see that we’ve defined which calls should be issued to the fake server and how to respond to them before doing anything else. This is useful and enables us to test our app’s response to different requests’ responses (for example, how does the application behave when the login request returns a 404?). This particular example simulates a standard POST response.

The two other lines of the beforeEach block are the function call and a newcomer, $httpBackend.flush(). The fake server does not immediately answer each request; instead, it lets you check any intermediary state that you may have configured. It waits for you to explicitly tell it to respond to any pending request it might have received.

The test itself has two methods calls on the fake server (verifyNoOutstandingExpectation and verifyNoOutstandingRequest). AngularJS’ $httpBackend does not enforce strict equality between what it expects and what it actually receives unless you’ve told it to do so. You can regard these lines as two expectations, one of the number of pending requests and the other of the number of pending expectations.

ngMock Module

The ngMock module22 contains various utilities to help you smooth over JavaScript and AngularJS’ specifics.

$timeout, $log and the Others

Using AngularJS’ injectable dependencies is better than accessing global objects such as console or window. Let’s consider console calls. They are outputs just like HTTP requests and might actually matter if you are implementing an API for which some errors must be logged. To test them, you can either monkey-patch a global object — yikes! — or use AngularJS’ nice injectable.

The $timeout dependency also provides a very convenient flush() method, just like $httpBackend. If we create a factory that provides a way to briefly set a flag to true and then restore it to its original value, then the proper way to test it’s to use $timeout.

angular.module('timeouts', []) .factory('waiter', ['$timeout', function($timeout) { return { brieflySetSomethingToTrue: function(target, property) { var oldValue = target[property]; target[property] = true; $timeout(function() { target[property] = oldValue; }, 100); } }; }]);

And the test will look like this:

describe('timeouts', function() { beforeEach(module('timeouts')); var waiter; var $timeout; beforeEach(inject(function(_waiter_, _$timeout_) { waiter = _waiter_; $timeout = _$timeout_; })); describe('brieflySetSomethingToTrue method', function() { var anyObject; beforeEach(function() { anyObject = {foo: 42}; waiter.brieflySetSomethingToTrue(anyObject, 'foo'); }); it('should briefly set something to true', function() { expect(; $timeout.flush(); expect(; }); }); });

Notice how we’re checking the intermediary state and then flush()’ing the timeout.

module() and inject()

The module()23 and inject()24 functions help to retrieve modules and dependencies during tests. The former enables you to retrieve a module, while the latter creates an instance of $injector, which will resolve references.

it('should say Ook.', inject(function($log) { sinon.stub($log, 'warn', function() {}); chimp.ook(); expect($log.warn.callCount).to.equal(1); expect($log.warn.args[0][0]).to.equal('Ook.'); }));

In this test case, we’re wrapping our test case function in an inject call. This call will create an $injector instance and resolve any dependencies declared in the test case function’s arguments.

Dependency Injection Made Easy

One last trick is to ask for dependencies using underscores around the name of what we are asking for. The point of this is to assign a local variable that has the same name as the dependencies. Indeed, the $injector used in our tests will remove surrounding underscores if any are found. StackOverflow has a comment25 on this.


Unit testing in AngularJS applications follows a fractal design. It tests units of code. It freezes a unit’s behavior by providing a way to automatically check its response to a given input. Note that unit tests do not replace good coding. AngularJS’ documentation is pretty clear on this point: “Angular is written with testability in mind, but it still requires that you do the right thing.”

Getting started with writing unit tests — and coding in test-driven development — is hard. However, the benefits will soon show up if you’re willing to fully test your application, especially during refactoring operations.

Tests also work well with agile methods. User stories are almost tests; they’re just not actual code (although some approaches, such as “design by contract26,” minimize this difference).

Further Resources

(al, ml)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29

The post An Introduction To Unit Testing In AngularJS Applications appeared first on Smashing Magazine.

The Skeptic’s Guide To Low-Fidelity Prototyping

Mon, 10/06/2014 - 13:01

Designer Paul Rand once said, “An understanding of man’s intrinsic needs, and of the necessity to search for a climate in which those needs could be realized, is fundamental to the education of the designer.” Prototyping helps us to unveil and explore these human needs, opening the door to insightful interaction and more empathetic design solutions.

Low-fidelity prototypes, in particular, are rough representations of concepts that help us to validate those concepts early on in the design process. Throughout this article, we will look at some of the features that make low-fidelity prototyping a unique tool to radically improve your work and to build an environment in which users’ needs can be truly realized.

This article focuses on the practice and general principles behind integrating low-fidelity prototypes in design in general, covering applications that range from graphic, web and user experience (UX) design to business and service design.

What Is Low-Fidelity Prototyping And Why Will It Improve The Way You Work?

Have you ever spent an overwhelming amount of time and resources designing something that a client or user discards in a matter of seconds? I’ve seen it happen far too many times. It is never pleasant, always frustrating, yet often preventable. Designing a product without continual validation is like walking blindfolded over a plank into a sea of sharks. Even Apple, a company that has repeatedly spoken against using focus groups to design products, pioneered a process called the Apple new product process1 (ANPP), which involves creating and testing hundreds of early prototypes.

Some of us are quick to jump into building (what to us seem like) brilliant products, to the point of pixel perfection, without even stopping to ask whether our user or client feels the same way. The fact is that designing without introducing potential users to raw versions of our ideas is unsafe, uncomfortable and wasteful.

On the other hand, perfection can also haunt some of us to the point of inaction. While some are too quick to act and end up wasting resources, others are completely paralyzed by the “excessive” amount of work behind building something new. There’s just “so much to get done” before delivering the product to the user that we end up feeling frustrated and overwhelmed.

Have you ever overspent resources in a rush or accomplished too little for being a perfectionist? Low-fidelity prototyping helps us to find the middle ground between overspending and overthinking, between too little investment and too much user validation. By building a practical, preliminary version of your product, you will catch potential problems and promising insights faster and earlier in the process.

2UX designer Matt Tyas presents a prototype concept. (View large version3)

The word “prototype” comes from the Greek prototypos4, a compound of protos (“first”) and typos (“mold,” “pattern,” “impression”). This initial, raw presentation of our ideas is precisely what we’ve come to know as low-fidelity prototyping. Unlike high-fidelity prototyping, this method requires less time, specialized skills and resources. Its purpose is not to impress users, but to learn from them. Instead of wowing people with our product, the goal of low-fidelity prototyping is to have users wow us with their insight. In a way, the technique facilitates listening, rather than selling. It opens a conversation in which users’ needs, designers’ intentions and other stakeholders’ goals are discussed and aligned.

Scientist Jim Rudd and his colleagues at IBM helped to define the difference between the two major types of prototypes in a much recommended piece titled “Low vs. High Fidelity Prototyping Debate5” in Interactions Magazine:

Low-fidelity prototypes are generally limited function, limited interaction prototyping efforts. They are constructed to depict concepts, design alternatives, and screen layouts… These prototypes are created to communicate, educate, and inform.

“Fidelity” can be a confusing term. In broad terms, it can be defined (according to Oxford Dictionary) as “the degree of exactness with which something is reproduced.” In other words, a prototype’s level of fidelity answers the question, How precisely does this represent the final solution?

Why Now?

Though low-fidelity prototyping has existed for centuries, it has recently become popular with the spread of agile design methodologies, inspired by several movements:

  • Design thinking advocates for “thinking with your hands” as a way to build empathetic solutions.
  • Lean startup relies on early validation and the development of a minimum viable product to iterate on.
  • User-centered design calls for a collaborative design process where users deliver continual feedback based on their reactions to a product’s prototype.

As pointed out, we can’t really say that low-fidelity prototyping is new because people have been laying out concepts on cavern walls since time immemorial. What we can say is that, given the speed with which we are expected to design market-appropriate solutions, low-fidelity prototyping has never been more important to all kinds of designers.

6Designers in companies such as Nintendo use low-fidelity prototyping. Designer Kazuyuki Motoyama explains7 that the only way to actually know what a Miiverse would feel like was to hold it. That’s when he built this prototype out of cardboard. (Imag credit: Nintendo8) Advantages

All low-fidelity prototypes, regardless of the type of product being built, bring the following advantages.

Detect and Fix Major Problems Early

Building a low-fidelity prototype that can be quickly exposed to user feedback enables us to visualize and solve core issues related to the product’s usability and proposed functionality. Because the prototype is not supposed to generate insight about the final look and feel of the product (they are rough approximations), users generally submit thoughtful ideas from what they see. By removing the bells and whistles associated with high-fidelity prototypes, we strip our concept down to the core. Addressing whatever problems we detect at this stage is vital to the product’s eventual success.

Consultant Nigel Heaton wrote a key paper titled “What’s Wrong With the User Interface? How Rapid Prototyping Can Help9,” presenting it at the 1992 IEE Colloquium on Software Prototyping and Evolutionary Development. He explains that rapid prototyping should be able to solve around 80% of all major interface issues. In the process of designing products that truly match users’ needs, low-fidelity prototyping provides a much-needed wake-up call right from the start.

Aside from helping us to detect major problems, low-fidelity prototyping also gives us the motivation required to fix them. In a 2012 study10 of the psychological experience of prototyping, researchers at Stanford and Northwestern University found that “the practice of low-fidelity prototyping… led to reframing failure as an opportunity for learning, fostering a sense of forward progress, and strengthening beliefs about creative ability.” The study concluded that building low-fidelity prototyping affects not only the final product, but our level of engagement with the design process itself.

Build Cheaply and Easily

Low-fidelity prototypes can be easily built by individuals and teams with little or no technical skills. As long as the goals of the product and project are clear, then the emphasis with low-fidelity prototyping will be not on form or function, but on focus. Where should we invest our resources next? Where should we avoid investing them? Which features will be key for the user? Are we headed in the right direction with this raw concept? Do we need to pivot towards new models or explore other options?

The best low-fidelity prototypes are built resourcefully, on a small or nonexistent budget and in a short time period. You may also be familiar with the term “rapid prototyping11,” which is merely the practice of “quickly mocking up the future state of a system.” In the spectrum of rapid prototyping, low-fidelity prototypes are on the speedy end.

Draw Feedback That Focuses on High-Level Concepts, Rather Than Execution

In his article “Prototyping for Tiny Fingers7512,” interaction designer Marc Rettig points to the imminent risk of working with high-fidelity prototypes, which is that you will likely “hear criticisms about your choice of fonts, color combinations, and button sizes.” Being exposed to an elaborate prototype, users might feel compelled to comment on these details and neglect to gather their thoughts on high-level concepts such as user flow, layout and language.

Rather than being focused on validating the product’s underlying assumptions and core value, high-fidelity prototypes redirect attention towards the aesthetics of the product. A rougher low-fidelity prototype, on the other hand, “forces users to think about content rather than appearance.”

Iterate More Willingly

Because the effort and resources required to produce a low-fidelity prototype are significantly less, we are less reluctant to change the prototype completely. Think about it: When has it been easier for you to completely scrap something you’ve been working on? When you’ve invested a few minutes sketching it or when you’ve spent countless hours perfecting a prototype? In Rettig’s words, “Spend enough time crafting something and you are likely to fall in love with it.”

Iteration is key in a truly agile design process. Only by continually evolving our concepts will we be able to create empathetic solutions that will succeed in the current market. Low-fidelity prototypes encourage this type of shameless, stress-free environment of iteration. Making sharp changes, pivoting to a new business model or even starting from scratch feels more natural to us because there is simply not that much to scrap.

Carry and Show Them Easily

While some high-fidelity prototypes require a special device or environment to be shown, most low-fidelity prototypes can be easily carried around and shared. Rudd states, “Low-fidelity prototypes are easily portable — they can be presented on paper, view graphs, or white boards.”

How hard is it to transport a piece of paper? Does it require any special conditions, spaces or advanced instructions? Paper-based low-fidelity prototypes liberate us from the burden of technical and portability requirements.

If you decide to build a low-fidelity prototype using any of the software listed at the end of this article, then reconsider whether showing it on a screen is the best choice. A study showed that paper encourages collaborative work more readily than screens in several interesting ways. Researchers at the University of Nottingham, University of Surrey and Cambridge EuroParc examined how paper and screens foster collaboration13 in three different work settings: an architectural practice, a medical center and the control room in London’s underground railway. They concluded that paper generates an added flexibility that enables individuals to interact and collaborate in a wide range of ways.

The researchers noticed, among other things, that by handwriting (i.e. drawing, writing or sketching low-fidelity prototypes), participants were able to take notes quickly, while remaining engaged with subjects. This flexibility is particularly important when designing collaboratively and communicating with users to obtain feedback. The natural versatility of paper (it can be folded, cut, scribbled on) also made cooperation significantly easier. Consider these advantages when you decide to expose users to a low-fidelity prototype. Printing out your screenshots or wireframes could radically change the input that you receive.

Types Paper-Based 2D

It doesn’t get any simpler than a plain old sheet of paper. Marc Rettig estimates that paper-based prototyping frees designers to spend 95% of their time thinking about the design itself and to spend only 5% on technical issues (which he calls the “mechanics of the tool”). Reflect on your own experience: How many times has your attention diverted from the essential elements of design to the technicalities of a tool?

In web design, for instance, paper-based low-fidelity prototypes can include screenshots of interface elements. In his article “Using Paper Prototypes in Home Page Design14,” former Sunsoft engineer Jakob Nielsen suggests that “Pop-up menus, messages, and dialog boxes can be simulated with Post-it stickers, or transparent overlays printed on overhead foils.” Sunsoft’s experience with redesigning its home page revealed that primitive, rough prototypes are valuable sources of insight into usability.

15This low-fidelity prototype of a new web design for SCAD’s Interaction Design department16 shows the initial concepts for improving reading and posting interactions. (View large version17) 18The team at Flow New Media Design shows how it starts with paper-based prototypes19 to “strip things back to the bare bones [and] concentrate on the important things.” (View large version20) 21Two interaction design students launched a company named Sticky Jots22, which offers kits to help anyone get started with low-fidelity paper-based prototypes, such as storyboards. (View large version23) 3D

If you want to get more creative and provide users with a 3D prototype to interact with, several fascinating options are available. Using cardboard, foam, wood, plastic, clay and building blocks has become increasingly popular, especially with the spread of design thinking’s hands-on approach.

3D prototypes add a level of interaction that 2D prototypes do not achieve. While building it might take slightly longer, a 3D prototype encourages manipulation and could draw a higher level of engagement in the concept-testing phase. The three-dimensional nature will add realism and open the door to valuable feedback.

24Ashley Costanzo developed this 3D low-fidelity prototype for HealthyMade25: fresh ingredients and recipes packaged into a healthy preplanned meal. This product answers the question, “How might we provide healthier food options to people in need?” (View large version26) Business origami is a paper prototyping method developed by Hitachi to facilitate the design of services and systems. It was developed in-house but eventually attracted the attention of other organizations. The paper cut-outs of various objects improve prototyping systems and interactions with them. 27LEGO Serious Play28 was created to facilitate innovation and business performance. The sets can be used to build low-fidelity prototypes of business and service experiences. Liquid Agency, for instance, used this method29 to prototype an answer to the question, “What type of health care do we aspire to offer that would make a difference today and tomorrow?” (View large version30) Quick Start Guide 1. Define Your Goals: What Will You Show?

Which main features do you want to expose your users to? List two to three pieces of core functionality that you will include in the low-fidelity prototype. In the next step, we will make sure that these aren’t left out.

You can use a simple table like the one below to list your features:

Core features Complementary features

Here are some sample features that you might include as either core or complementary:

Sample features to prototype in graphic, web and UX design Sample features to prototype in business and service design
  • Geolocation
  • Branch finder
  • Contact form
  • Blog roll
  • Instant quote generator
  • Image uploading
  • Feedback system
  • Color customization
  • Social media integration
  • Analytics
  • Gamification
  • Task manager
  • PDF exporting
  • Web conferencing
  • Directory
  • Collaboration spaces
  • Retail experience
  • Sales pitch
  • Price list and payment plans
  • Customer support
  • Consulting appointments
  • Delivery
  • Subscription payments
  • Reward points
  • Special packaging
  • Business model
  • Content generation
  • Brand personality
  • No-hassle contracts
  • Returns policy
31Business model canvas. (Image credit: Aberdeen Global Service Jam32) (View large version33) 34Concept development and sketches for flower seed packaging. (Image credit: Shavonne Maclin35) (View large version36) 2. Define the Method: How Will You Show It?

Decide what kind of low-fidelity prototype would suit your project best. What could you build quickly that would help users to deliver valuable feedback? How could you display and test the concept simply, investing the least amount of resources? To find the simplest method possible, continue asking the question, “Is there a simpler way to show this?” until you arrive at a feasible way to depict the product’s features.

The level of detail that is right for your prototype will depend on a few factors:

  • What type of user will be exposed to this prototype?
    Would they be able to deliver insightful feedback based on the model that you are presenting? Would they need to see a certain level of detail in order to understand the concept?
  • What resources are accessible to you?
    With low-fidelity prototyping, agility is crucial. Think of the tools and resources that surround you as you ideate. Be resourceful and find clever ways to use what you have.

Think about it in this way:

What I want to show Is there a simpler way to show this? Is there a simpler way to show this? Is there a simpler way to show this? Inputting a QR code 37
(View large version38) 39(View large version40) 41
(View large version42) Geolocation feature (for browsing nearby) 43(View large version44) 45(View large version46) 47(View large version48)

Note: The prototypes above show the evolution of the design of the payment screen in Foursquare49’s existing app and were designed by Marta Fioni.

Still struggling to find a method that suits your project? Here are some ideas:

50Download this graphic and hang it somewhere visible in your office. It will keep you motivated to make low-fidelity prototyping a consistent part of your design process. (View large version51) 3. Execute: Show It

Start out by defeating your “My skill in [x] isn’t good enough” mindset. Low-fidelity prototyping is not about how sophisticated your model looks, but about the conversation it generates about the future of the product. Remember, not form or function, but focus.

Sample Low-Fidelity Prototypes From Different Design Fields Graphic, web and UX design Business and service design
  • user flow
  • sketch board
  • wireframe
  • sketches
  • mood board
  • sample brochure
  • landing page
  • flyers
  • business cards
  • sample ad
  • scenarios
  • storyboard
  • 3D model
  • explainer video
  • business model canvas

Try any of the following digital and analog tools to speed up your prototyping process:

Graphic, web and UX design Business and service design Digital Analog
  • paper
  • whiteboard
  • poster
  • sticky notes
  • sketchbook
  • notebook
  • napkin
  • squared paper
  • print template
  • cards
  • overhead sheet
  • cardboard
  • carton
  • plastic
  • wood pieces
  • plastic pieces
  • glue
  • scissors
  • markers
  • foam pieces
  • UI stencil
  • paper
  • whiteboard
  • poster
  • sticky notes
  • sketchbook
  • notebook
  • napkin
  • squared paper
  • print template
  • cards
  • overhead sheet
  • cardboard
  • carton
  • plastic
  • wood pieces
  • plastic pieces
  • glue
  • scissors
  • markers
  • foam pieces
4. Test: How Will You Evaluate What You’re Showing?

Go beyond the idea that “It’s so rough-looking that users will hate it.” Having to explain the limitations of your low-fidelity prototype is normal. In fact, it is expected. Guide users to understand the aims of the project, and ask probing questions. If it helps, prepare a short guide before you present the prototype. List a few of the questions that you’d like to be answered during the session, and write an introduction that you could read out loud to help the user contextualize what they are looking at. These are some of the types of questions you will want to ask:

  • Regarding perceived benefits
    “What, in your opinion, is the key benefit offered by this product concept?” “From the features you have seen today, which ones would make you use the product?” “Which features didn’t you see that would make you want to use it?”
  • Regarding positive and negative reactions
    “On a scale of one to five, how much do you like this concept?” “Why?”
  • Regarding awareness
    “Having looked at this concept today, what do you remember most about it?” “What do you recall?”
  • Regarding comparative advantage
    (If you showed users two or more versions of a concept, ask which variant works best.) “Which of these options appeals to you the most?”
  • Regarding emotional reactions
    “How did looking at this concept make you feel?” (Help them by providing a list of emotions — happy, frustrated, angry, excited, bored, etc. — or face illustrations that depict these emotions. Have each user select one or more emotions triggered by the prototype.)
  • Regarding intention of use
    “Having looked at this product concept today, on a scale of one to five, how much would you be willing to use it once it has been refined and launched?” “Why?”
  • General feedback
    “Feel free to annotate any changes or corrections that you feel would improve this concept.”
5. Learn: We’ve Shown. Now What?

Collect your users’ feedback and find similarities in their evaluations of the concept. Build an affinity diagram67 to identify the most common suggestions. Incorporate their feedback, and move on to building a high-fidelity prototype that reflects the product’s look and feel with a greater level of detail. Repeat the testing session with as many users as needed.


Hopefully, this article has helped you understand the impact that low-fidelity prototypes can have on our design processes and outcomes. The five steps outlined above are meant to guide you through the process of building and testing a low-fidelity prototype, and they will surely improve the quality and depth of your design work. Think about the concepts that you are currently working on: How could you validate them before investing an overwhelming amount of time and effort into polishing them? It isn’t always easy to see that a raw representation of what you are building might just be the right amount of fidelity needed to ask the most crucial questions about its effectiveness. When in doubt about whether you’re ready to test an early concept, always keep author Elizabeth Gilbert’s words close to heart:

Part of the elasticity that you need, in order to continue to try to create, is the foregone conclusion that not all of it is going to be fabulously successful. But it’s all going to be part of a long lifetime body of experimentation.

Other Resources References

(ah, il, al, ml)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76

The post The Skeptic’s Guide To Low-Fidelity Prototyping appeared first on Smashing Magazine.

Icons Of Digital Design

Fri, 10/03/2014 - 12:46

Apple launched the Macintosh personal computer in 1984. It was more user-friendly than other PCs at that time — and, with its desktop publishing software, graphical user interface and mouse (all novel at the time), the Mac was uniquely geared to designers. Compared to what we can create on the computer today, the original Macintosh, with only 128 KB of memory, had limited capabilities. At the time, though, it opened up so many new possibilities.

Of course, using a computer didn’t automatically make designers better at their craft. Instead, the new technology gave them more control and sped up their exploration process. As with anything unfamiliar, the Mac sparked debate among designers during this time: While some saw the computer as simply another tool for creating work, like a drawing pen, others saw its potential as a medium in itself.

Emerging digital technology also changed typography, exploding the number of typefaces available and giving designers the tools to create and distribute their own fonts. Some digital typefaces were updated versions of classics, while others were brand new: type that was made for low-resolution screens, and type that was less functional and more illustrative. It was easier to break the rules. There was a refreshing jolt of youthful experimentation as people moved past the limits of the rational and functional.

I wrote my book Graphic Icons: Visionaries Who Shaped Modern Graphic Design to highlight the era’s influential designers, from El Lissitzky in the early 1900s to Stefan Sagmeister today. Each of these designers broke from tradition and changed the world of design in some way. Those who designed not only on the screen, but for the screen, ushered in a new era of digital design, mixing media and incorporating motion, sound and interactivity. Below are a few of those pioneers.

Wim Crouwel

First, though, let’s step back. Twenty years before the Macintosh was released, Dutch designer Wim Crouwel1 had an uncanny sense of how computers would influence design and vice versa. In the 1960s, developments in printing technology gave designers more control over their work: Instead of relying on a printer to compose type and position images in a layout, designers used rub-down type and photomechanical transfer to do it themselves. This DIY approach gave designers more freedom and flexibility in using, manipulating and creating type.

New alphabet, 1967

The computer was in its early stages at the time, and Crouwel saw an exhibition in Germany on digital type production. The limitations were clear to him. Dot-matrix printers and computer screens couldn’t reproduce traditional type with curved letterforms. So, he created a groundbreaking typeface to work with this emerging technology.

Starting with the Swiss typographic grid, Crouwel based letters on the rectangle, using only vertical, horizontal and diagonal lines. The result was 1967’s New Alphabet, so radical in appearance that it was almost abstract. It was never meant to be used; it was just an experiment. Crouwel must have been surprised to see the New Alphabet used on the cover that Peter Saville designed for New Order’s Substance album 20 years later.

Still, that concept influenced his future work, like his poster for Vormgevers (“Designers”), for which he hand-rendered the lettering based on squares in a visible grid. Crouwel developed a system for Amsterdam’s Stedelijk Museum where each piece — posters, brochures, advertisements — used the same grid. Although these pieces promoted art exhibits, they never depicted the art itself. The type-centric design and common grid unified the museum’s communications, yet the system was flexible enough to remain fresh and interesting.

Vormgevers poster, 1968, for the Stedelijk Museum

Crouwel also broke new ground in how Dutch designers worked. In the 1960s, Dutch companies with large projects often hired larger firms in cities like London, thinking that the local designers who usually worked solo wouldn’t be able to handle the workload. In order to attract those large projects, Crouwel and four partners, with a range of experience in graphic and industrial design, formed Total Design. It was the country’s first multidisciplinary studio, where teams handled complex two- and three-dimensional projects. It was successful: Private corporations, government agencies and arts organizations hired Total, and their designs for postage stamps, airport signage and museum posters made a distinct mark on the country’s visual culture.

Leger poster, 1957

Hans Rudi Erdt, A.M. Cassandre and especially Josef Müller-Brockmann2 are big influences on Crouwel’s work, and in turn, Crouwel remains a prevalent figure in the design world — in 2013, he was celebrated with a retrospective at London’s Design Museum3. Crouwel inspires young designers, including Philippe Apeloig and Spin, who created a series of posters based on the grid he developed for the Stedelijk Museum.

Calendar, 1964 April Greiman

April Greiman4 uses different words to describe what she does: “hybrid imagery,” “transmedia,” “visual communication.” But not “graphic design.” She feels that term refers exclusively to print, and her work combines elements from different types of media. Greiman thinks in terms of space when she designs, not in terms of a page. This is probably why designing digitally has been such a good fit for her.

Your Turn My Turn 3-D poster, 1983

New Wave typographer Wolfgang Weingart5 encouraged Greiman, while she was in graduate school at Basel in the early 1970s, to break free from a grid-based approach to design — to layer type, and to float it in space. She brought this knowledge to New York; and, after growing frustrated by the rigid limitations imposed by East Coast clients, she moved in 1976 to Los Angeles and opened a studio. The change of location opened her eyes and encouraged her to explore. She began teaching at the California Institute of the Arts (CalArts) in 1982 and gained access to the school’s computers and video equipment.

The new technology opened so many possibilities for Greiman, enabling her to combine print, video and type into multiple layers that were previously impossible to create. She felt strongly that these new tools weren’t just a means to arrive at the same old solutions, but that they should lead us to explore ideas and create something new.

“Does it Make Sense?” in Design Quarterly, 1986

When Greiman designed an issue of Design Quarterly for the Walker Art Center in 1986, she blew up the traditional magazine format, creating a 2 × 6-foot folding collage that combined a nude portrait of the designer overlaid with multiple layers of images and text. While the fact that Greiman used a computer to create the work hardly seems noteworthy today, consider that the computer had one megabyte of RAM and a monochrome 9-inch display.

Greiman built the collage on the computer and outputted letter-sized pages on her dot-matrix machine, then directed the magazine’s printer to assemble the pages and photograph the entire composition. Greiman wasn’t just tinkering with the computer; she was exploring the idea of making sense, touching on philosophy and physics. Like much of Greiman’s work, the project wasn’t just about technology, but was personal.

19th Amendment commemorative stamp, US Postal Service, 1995

Greiman’s list of influences is well-rounded: Among them are her former teachers Armin Hofmann6 and Wolfgang Weingart; singer, songwriter and poet Leonard Cohen; theoretical physicist David Bohm; psychiatrist Carl Jung; and spiritual leader the Dalai Lama.

“Hand Holding a Bowl of Rice” mural, Wilshire Vermont Station, Los Angeles, 2007

As the world continues to change, so does Greiman. More recently, she’s been creating web design, branding, signage and public art and has been consulting on color, finishes and textures for architectural projects. She continues to teach and believes in always being open to new ways of doing things.

Do what you love to do, with a vengeance. It’s not what you do but who you are.

– April Greiman

Muriel Cooper

Muriel Cooper had two design careers: first as a print designer and secondly as a groundbreaking digital designer. Both revolved around the Massachusetts Institute of Technology (MIT), and both were based on her quest to make static media more dynamic.

MIT’s Office of Publications hired Cooper in 1952 and continued working with her after she established her own studio. She then became art director for MIT Press, where she designed classic books, such as Hans Wingler’s Bauhaus7. She designed the first edition of Learning From Las Vegas; authors Robert Venturi, Denise Scott Brown and Steven Izenour hated what she did, but many graphic designers loved it. She also designed the abstract logo for MIT Press, a modern classic.

MIT Press logo

Cooper took her first computer class at MIT in 1967, and it bewildered her. However, she could see the computer’s potential in the creative process and soon began the second phase of her career: applying her design skills to computer screens. With Ron MacNeil, Cooper cofounded the research group Visible Language Workshop in 1975, which later became part of MIT’s Media Lab8. Cooper didn’t write code; she was the designer and the thinker. She knew what she wanted visually and encouraged her students to use technology to present well-designed information.

Image rendered as soft type, MIT Media Lab’s Visible Language Workshop

Cooper presented the group’s research9 at the influential TED5 (Technology, Entertainment, Design) conference in 1994. For the first time, computer graphics were shown in three transparent dimensions, which moved, changed sizes and shifted focus, instead of the standard Microsoft Windows interface of opaque panels stacked like cards. She made a big impact: Even Microsoft founder Bill Gates was interested in her work. Unfortunately, she died soon after of a heart attack, but her legacy in interactive design continues.

Muriel Cooper taught me that design had very little to do with how you make something, and instead why you make something.

– John Maeda

“Information Landscape,” MIT Media Lab’s Visible Language Workshop, 1994 Rudy VanderLans And Zuzana Licko

Apple broke new ground when it introduced the Macintosh computer in 1984. Designers Rudy VanderLans and Zuzana Licko did the same (albeit on a smaller scale) with Emigre10 magazine that same year.

While many designers initially resisted the computer, VanderLans and Licko embraced it, though in different and complementary ways: VanderLans liked the freedom it gave him in designing layouts, while Licko found a disciplined method for designing type.

Emigre magazine cover, number 19

VanderLans studied design in The Netherlands and worked at Wim Crouwel’s Total Design. But he was more attracted to the expressive work of Herb Lubalin11 and Milton Glaser12 than to the Dutch modernists. He went on to study photography at UC Berkeley, where he met Licko, his future wife and business partner, as she studied graphic communications.

Emigre magazine quickly became a forum for designers, especially those interested in experimentation and technology. It featured in-depth articles and visual essays, in layouts that broke all the rules — with varying type sizes, overlapping layers, text columns crashing into each other and distorted letterforms, all techniques that the Mac made easier. VanderLans and Licko sold their type designs to fund the magazine (which meant they didn’t have to cater to advertisers).

Emigre magazine spreads: Number 43, Number 49

The typefaces13 were an important part of the magazine’s design as well. After the first two issues, the magazine was set exclusively from the collection of Emigre Fonts. Licko began with rough pixelated typefaces, like Oakland, and progressed to more versatile fonts, like the popular Mrs Eaves. Emigre Fonts also carried select designs by Barry Deck, Jonathan Barnbrook, Elliot Earls, Eric Donelan and Bob Aufuldish and Ed Fella, among others.

Oakland type specimen

The magazine ceased publication in 2005, but Licko continues to design fonts, and VanderLans designs the type specimens. They also sell books, ceramics and collectibles.

Emigre magazine cover, number 33 John Maeda

John Maeda14 was a computer science graduate student at MIT in the late 1980s on his way to becoming a user interface designer. Then he read Thoughts on Design15, by Paul Rand — an experience that shifted the course of Maeda’s career.

One of ten poster designs for Japanese type foundry Morisawa, 1996

Maeda took a humbling message from Rand’s book: Understanding the computer did not necessarily make one a good designer. Encouraged by his professor Muriel Cooper, Maeda decided to study graphic design in Japan, where he added traditional design skills and concepts to his knowledge of computers.

Time Paint software for Macintosh, 1994

Maeda then returned to MIT to teach, and founded the Aesthetics and Computation Group at the Media Lab. It was there that Maeda, who as a child excelled at both math and art (though his father only bragged about the math part), explored the area where design and technology meet. For Maeda, the computer is a tool and a medium. Through the Media Lab, Maeda created digital experiences like The Reactive Square, in which shapes responded to sound, and Time Paint, a time-based program of flying colors. His Design by Numbers project (no longer active) encouraged designers and artists to learn computer programming.

Shiseido poster celebrating 30 years of commercial films, 1995

In his quest to educate, Maeda writes books, too: The Laws of Simplicity16 outlines his hopes that technology will simplify, rather than complicate, our lives. From 2008 to 2013, Maeda was president of the Rhode Island School of Design. As an educator, he considers creative thinking equally important as technical capability in the development of the leaders of tomorrow. To the emphasis on science, technology, engineering and math — STEM — throughout the country’s educational system, Maeda proposes adding an A for art, to create STEAM. His goal? Not to make the world more high tech, but to make it more humane.

MIT math department poster, 1998 Summary

Of course, digital technology wasn’t the only new development during this era: Design education programs expanded and became more rigorous. Design writing evolved into its own discipline, as practitioners took matters into their own hands by writing articles, books and criticisms that brought new perspectives to the design canon. And designers were — and are — affected and influenced by social, political and cultural changes as they explored new ways to engage their audiences.

Today, people all over the world can communicate with each other like never before. With the rise of the Internet, social media and mobile applications, the user has gained control over how, when and where they access information. The digital revolution continues, and design is sure to play a significant role in shaping the future.

(il, al)

Portions of this article are from the book “Graphic Icons: Visionaries Who Shaped Modern Graphic Design” by John Clifford. Copyright © 2014. Used with permission of Pearson Education, Inc. and Peachpit Press.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16

The post Icons Of Digital Design appeared first on Smashing Magazine.

What Every App Developer Should Know About Android

Thu, 10/02/2014 - 07:17

In today’s fast-paced mobile market, consumers have no patience for mobile apps that compromise their experience. “Crashes” and “Not working” are the most common feedback1 on Google Play for unstable or sluggish apps (including games). Those comments and ratings make hundreds of millions of potential downloaders skip those lousy apps. Sounds harsh, but that’s the way it is.

An app succeeds not by chance. It is the result of the right decisions made at the right time. The most successful mobile app developers2 understand the importance of performance, quality and robustness across the array of mobile devices that their customers use.

Examples abound of just how easily a developer can go very, very wrong with their app. An app can behave differently on a variety mobile devices3, even ones running the same OS version and identical hardware components.

4Testdroid Cloud hosts hundreds of working Android and iOS devices. (Image credit: Testdroid145) (View large version6)

During Q1 of this year (1 January to 31 March), we gathered a significant amount of data from Testdroid Cloud7 on tests done by many mobile app and game developers. Testdroid Cloud is an online cloud-based platform for mobile developers to test that their apps work perfectly on the devices that their customers use.

During this period, over 17.7 million tests were run on 288 distinct Android hardware models. To be clear, different versions of some popular models were tested but are counted in the data as one distinct device (such as the Samsung Galaxy S4 GT-i95058 running 4.2.2, API level 17). Some popular devices also had different versions of a single OS, such as the Google Nexus 7 ME370T9 with Android OS version 4.1.2 (API level 16), 4.2.2 (API level 17) and 4.3 (API level 18).

All tests were automated, using standard Android instrumentation10 and different test-automation frameworks11. In case you are not familiar with instrumentation, Android has a tutorial12 that explains basic test automation. Also, the tests caught problems through logs, screenshots, performance analysis, and the success-failure rate of test runs.

Note: The data includes all test results, from the earliest stage (=APK ready) to when the application gets “finalized.” Therefore, it includes the exact problems that developers encountered during this process.

13The research statistics, testbed and global coverage. (Image credit: Testdroid145) (View large version15)

The goal for this research was to identify the most common problems and challenges that Android developers face with the devices they build for. The 288 unique Android device models16 represent a significant volume of Android use: approximately 92 to 97% of global Android volumes, depending on how it gets measured and what regions and markets are included. This research represents remarkable coverage of Android usage globally, and it shows the most obvious problems as well as the status of Android hardware and software from a developer’s point of view.

We’ll dive deep into two areas of the research: Android software17 and hardware18. The software section focuses on OS versions and OEM customizations, and the hardware section breaks down to the component level (display, memory, chipset, etc.).

Android Software

Your app is software, but a lot of other software is involved in mobile devices, too. And this “other” software can make your software perform differently (read “wrong”). What can you do to make sure your software works well with the rest of the software in devices today? Let’s first look at some of the most common software issues experienced by app developers.

Android OS has been blamed for platform fragmentation19, making things very difficult for developers, users and pretty much every player in the ecosystem to keep up. However, that is not exactly the case. The OS very rarely makes things crack by itself — especially for app developers. More often it also involves OEM updates, hardware and many other factors — in addition to the OS.

20Data collected for seven days, ending on 7 July 2014. (Image credit: Google21) (View large version22)

One reason why Android is tremendously popular among mobile enthusiasts and has quickly leaped ahead of Apple’s iOS in market share is because it comes in devices of all shapes23, prices and forms, from tens of different OEMs.

Also, the infrastructural software of Android24 is robust, providing an excellent platform with a well-known Linux kernel, middleware and other software on top. In the following sections, we’ll look at the results of our research, broken down by OS version, OEM customizations and software dependencies.

How to Read the Graphs

The findings from this study are plotted on graphs. In those graphs, the dark black line is the median (50%) of the failure percentage of different devices in that group. The lines above the bars mark the upper quartile (75%), and the lines below mark the lower quartile (25%). The dashed lines are the maximum (top or right) and minimum (bottom or left). The circles represent outliers.

OS And Platform Versions

We’ll start with the most important factor in the problems experienced by app developers: Android OS versions25. This dramatically affects which APIs developers can use and how those APIs are supported in variety of devices.

Many developers have experienced all of the great new features, improvements and additions that Android has brought version by version26. Some late-comers have played with only the latest versions, but some have been developing apps since the early days as days of Cupcake (1.5) and Doughnut (1.6). Of course, these versions are not relevant anymore.

The following table shows the release dates for the various OS versions (along with their code names) and notes why certain versions were excluded or were not used on the devices being tested.

27The release version of each OS version. (Image credit: Testdroid75726966625349433128) (View large version29)

The most typical situation with app developers who want to maximize support for all possible variants is that they’ll start testing from version 4.0 (Ice Cream Sandwich, API level 14). However, if you really want to maximize coverage, start from version 2.3.3 (Gingerbread, API level 10) and test all possible combinations up to the latest release of Kit Kat (currently 4.4.4 and, hopefully soon, Android L). Versions older than 4.0 still have serious use — and will continue to for some time.

30The failure rate of each OS version. (Image credit: Testdroid75726966625349433128) (View large version32)

When it comes to the latest versions of Android — and let’s count Ice Cream Sandwich (4.0.3 to 4.0.433), Jelly Bean (4.1.1 to 4.334) and Kit Kat (4.4 to 4.4.235) among them — Ice Cream Sandwich is clearly the most robust platform. OEM updates were obviously the least problematic on this version, and the majority of tested apps worked very well on API level 15 (4.0.3 to 4.0.4).

The upgrade to Jelly Bean and API level 16 didn’t significantly introduce new incompatibility issues, and the median failure percentage remained relatively low. However, API level 16 had many outlier cases, and for good reasons. For instance, more problems were reported with Vsync, extendable notifications and especially with support for the lock screen and home screen rotation.

API level 17 brought improvements to the lock screen, and this version was generally stabile up to version 4.2.2. The failure rate went up when the majority of OEMs introduced their updates to this version. Apparently, it became more problematic for users than previous versions.

Perhaps most surprisingly, the failure rate went up36 when Kit Kat API level 19 was released. The average failure percentage reached nearly the same level as it was with Gingerbread. Google patched Kit Kat quite quickly with two releases (4.4.1 and 4.4.2). Of those, 4.4.2 seemed to live much longer, and then the 4.4.3 update came out more than half a year later.

Key Findings From OS Versions
  • On average, 23% of apps behave differently when a new version is installed. The median error percent was the smallest with Ice Cream Sandwich (1%), then Jelly Bean (8%), Honeycomb (8%), Kit Kat (21%) and, finally, Gingerbread (30%). This is actually lower than what was found in the study conducted with Q4 data (a 35% failure rate).
  • Despite old Android versions being used very little and Gingerbread being the oldest actively in use, some applications (40% of those tested) still work on even older versions (below 2.2). In other words, if an app works on version 2.2, then it will work 40% of the time in even older versions as well.
  • Over 50% of Android OS updates introduced problems that made apps fail in testing.
  • Testing failed 68% of the time when 5 apps were randomly picked out of 100.
  • The average duration of testing was 57 cycles per platform. Old versions were tested less than new ones: Gingerbread (12 test cycles), Ice Cream Sandwich (17), Jelly Bean (58) and Kit Kat (95).
  • An average testing cycle reduced 1.75% of bugs in the code overall.

Note: A test cycle constitutes an iteration of a particular test script executed in one app version. When an app is changed and the test remains the same, that is counted as a new test cycle.

Tips and Takeaways
  • For maximal coverage either geographically or globally, using as many physical devices as possible is recommended. Track your target audience’s use of different OS versions. The global status of versions is available on Google’s dashboard37.
  • All OS versions above 2.3.3 are still relevant. This will not likely change soon because users of Gingerbread and Ice Cream Sandwich represent nearly one quarter of all Android users, and many of them do not update (or would have done so already).
  • If you want to cover 66% of OS volume, then testing with Kit Kat (4.4.x) and Jelly Bean (4.1 to 4.3) is enough (covering API 16 to 19).
  • To cover 75% of OS volumes, then test from version 4.0.3 (API level 15).
  • We recommend testing the following devices to maximize coverage:
    • Amazon Kindle Fire D01400 — 2.3.4
    • HTC Desire HD A9191 — 2.3.5
    • Huawei Fusion 2 U8665 — 2.3.6
    • Sony Xperia U ST25i — 2.3.7
    • Asus Eee Pad Transformer TF101 — 4.0.3
    • LG Lucid 4G — 4.0.4
    • HTC One S X520e — 4.1.1
    • Motorola Droid XYBOARD 10.1 MX617 4.1.2
    • Acer Iconia B1-A71 — 4.2
    • BQ Aquaris 5 HD — 4.2.1
    • HTC One mini M4 — 4.2.2
    • Samsung Galaxy Note II GT-N7100 — 4.3
    • LG Google Nexus 5 D821 — 4.4
    • HTC One M8 — 4.4.2

Note: These devices were selected because they are a good base to test certain platform versions, with different OEM customizations included. These devices are not the most problematic; rather, they were selected because they provide great coverage38 and are representative of similar devices (with the same version OS, from the same manufacturer, etc.).

OEM Customizations

One stumbling block with Android — like any open-source project — is its customizability, which exposes the entire platform to problems. What is called “fragmentation” by developers would be considered a point of differentiation for OEMs. In recent years, all Android OEMs have eagerly built their own UI layers39, skins and other middleware on top of vanilla Android. This is a significant source of the fragmentation that affects developers.

In addition to UI layers, many OEMs have introduced legacy software40 — tailored to Android — and it, too, is preventing developers from building their apps to work identically across different brands of phones.

Drivers also cause major problems41, many related to graphics. Certain chipset manufacturers have done an especially bad job at updating their graphics drivers, which makes the colors in apps, games and any graphic content inconsistent across phones. Developers might encounter entirely different color schemes on various Android devices, none close to what they intended.

42Failure rate by OEM. (Image credit: Testdroid75726966625349433128) (View large version44) Key Findings Related to OEM Customizations
  • No surprise, Samsung devices are among the most robust and the most problematic. For example, Galaxy Nexus GT-I9250 is one of the most robust devices in all categories, while the Samsung Infuse 4G SGH-I997 failed the most in those same categories.
  • Asus devices, along with Xiaomi devices, are the most robust. Xiaomi implements Android differently, however; for instance, pop-ups make the controllability of some devices impossible.
  • Coolpad has, by volume, the most problems. Among the biggest brands, HTC has the least error-prone devices.
  • All of the big brands — HTC, Samsung, Sony and LG — have customizations that are problematic for certain types of applications. For example, Sony’s customizations breaks some basic functionality, such as viewing PDFs. Samsung’s customizations has problems with taking photos with the camera and interrupting calls.
Tips and Takeaways
  • The most common misconception is that Nexus devices are the best for testing. Those devices typically have the latest OS version and little to no OEM customization.
  • Pay attention to carrier- and operator-branded devices as well. Some of them implement Android totally differently, regardless of the name of the device or brand.
Dependencies On Other Software

Some applications require access to other apps. For example, many apps and games incorporate social media, and in the worst implementations, developers have assumed that every device integrates popular social media apps. Some devices come with those social media apps preinstalled, but if not, then your application just won’t work properly. Unfortunately, problems with software dependency turn into problems for app developers.

Key Findings Related to Dependencies on Other Software
  • 92% of apps integrate with the given platform to show ads.
  • 65% of apps integrate with at least one social media platform.
  • 48% of apps integrate with at least two social media platforms.
  • 33% of apps integrate with at least three or more social media platforms.
Tips and Takeaways

Check whether the software that your application depends on is installed on all devices. Do not assume that all of those third-party apps and other software exist on every device!

Android Hardware

The Android device eco-system continues to grow and evolve. Many handset manufacturers continue to churn out devices with amazing specifications and hardware and with different form factors. Naturally, the sheer number of possible device configurations45 presents a challenge to developers. Ensuring that an application works well on the widest range of devices is crucial and is the easiest way to avoid frustrating end users.

Most developer carefully weigh the pros and cons of testing on emulators and testing on real devices46 to follow the right strategy. Typically, emulators are used in initial stages of development, while real devices are brought in later in the game. Your choice of platform on which to build your next big thing should be as honest as possible — from day one. In our experience, that is a cornerstone of creating a successful app — and gaining those hundreds of millions of downloads.

Screen Resolution, Display and Colors

The key to success with any app — especially games — is to get the UI and graphics right. This is a challenge because there are a lot of different resolutions, a lot of ways to present content and, naturally, a lot of different hardware.

With new high-end devices gaining popularity among users, the Android eco-system seems to be quickly headed towards high-resolution displays. High-resolution screens obviously make for a better user experience, but to take advantage of this, developers need to update their apps and test for them47.

48Can you see the difference? An identical app is running on three different Android devices with the same OS version and hardware specifications. (Image credit: Testdroid75726966625349433128) (View large version50)

However, display resolution51 is not always the cause of headaches for developers. In fact, applications fail more often because of screen orientation, density, color and the overall quality of the device’s screen. For example, many games suffer from poor-quality displays. For instance, a button in a certain part of the UI might get shown in a different shade than the one intended by the designer — or, in some cases, a totally different color.

This is a common issue. It can result not only from hardware components, but also when display drivers are implemented incorrectly. Graphical content could even be invisible in some apps because of color brightness or low pixel density. This kind of failure is apparent from screenshots in our tests.

52Failure rate by screen resolution. (Image credit: Testdroid75726966625349433128) (View large version54)

No surprise that as the display resolution gets higher, apps present fewer problems. There are a few exceptions to this, but they can be attributed to how certain OEMs use various resolutions55 in both low- and high-end devices.

The Android OS provides a environment to develop apps consistently56 across devices, and it handles most of the work of adjusting each application’s UI to the given screen. Also, it comes with APIs that enables the developer to optimize an application’s UI for a particular screen size or density57. For example, you might want one UI for tablets and another for handsets. Although the OS scales and resizes to make an application work on different screens, you should still optimize your application for different screen sizes58 and densities. In doing so, you’ll improve the user experience on all devices, and users will believe that your application was designed for their particular device, rather than simply stretched to fit their screen.

Key Findings Related to Screen Resolution
  • The median of error was the smallest in resolutions of 2560 × 1600 pixels (0.4%), then 1280 × 800 (0.7%) and 1280 × 720 pixels (1.5%). It was highest in resolutions of 400 × 240 (45%) and 320 × 240 pixels (44%).
  • The most typical problem relates not to resolution or the scaling of graphical content, but to how content adjusts to the orientation of the screen. According to our data, problems with screen orientation are 78% more likely than problems with the scaling of graphical content.
  • Wrong color themes and color sets were reported in 18% of devices, while 24% of apps appeared correctly on all 288 different devices.
  • In some cases, an Android OS update or OEM update fixed a display issue, but the percentage was relatively low (6%).
  • Apps worked nearly the same on high- and low-end devices (based on chipset) with the same resolution (just a 2% difference).
  • In general, the bigger a device’s display, the more likely an app will perform better.
Tips and Takeaways
  • Design graphical content for multiple screen sizes, but make it scale to different sizes automatically. This is strictly a design issue.
  • Many problems with resolution, display and color can be avoided by designing an application correctly in the first place and by testing it thoroughly on real Android devices. Emulators won’t yield reliable results or lead to a robust application.

Anything can happen when an Android device runs out of memory59. So, how does your application work when a device is low on memory?

Developers deal with this problem rather often. Many apps won’t run on certain Android devices because they consume too much memory. Typically, the most popular apps60 — ones rated with four and five stars — do not have this problem because memory management has been implemented the right way, or else they have been excluded from being downloaded on low-end devices entirely. Too many of today’s apps were originally developed for high-end devices and can’t be run on low-end devices. What is clear is that you can easily tackle this problem by checking how your app works with different memory capacities.

Memory seems to significantly affect how a device copes with an application. If a device’s RAM is equal to or less than 512 MB, then the device will crash 40% of the time when certain applications are running.

61Failure rate of apps by memory size of device. (Image credit: Testdroid75726966625349433128) (View large version63)

If a device’s RAM is higher than 512 MB, then the device will crash approximately 10% of the time. That is statistically significant.

Key Findings Related to RAM
  • The median of error was lowest with RAM of 1024 MB (1%), then 1536 MB (3%) and next 768 MB (16%). It was highest with RAM of 336 (45%) and 168 MB (44%).
  • Approximately 10% of apps run on devices with more than 512 MB crash due memory-related issues.
  • Many OEMs do not give their devices the 512 MB of RAM that Google recommends as the minimum. Such devices are 87% more likely to have problems than devices with more memory.
  • The probability of failure drops 41% for devices that contain more than 576 MB of memory.

The difference in performance between silicon chipsets64 (CPU, GPU, etc.) is pretty amazing. This is not necessarily obvious to end users. Some people pay too much attention to the CPU’s clock rate, rather than the chipset and other factors that affect the performance of the device.

Imagine developing something that is targeted at high-end devices but that runs on low-end hardware. It simply wouldn’t work. The user experience would obviously suffer because a high-end app running on a low-end chipset with a low clock-frequency rate would suffer in performance. Many apps suffer severely because the activities on screen are synced with the clock, and the UI can’t refresh quickly enough to keep up with it. For users, this translates into poorly implemented graphics, blinking screens and general slowness.

65Failure rate of apps by device clock rate. (Image credit: Testdroid75726966625349433128) (View large version67)

Let’s first look at the clock rate of devices that we tested.

To compare chipsets more easily, we categorized them based on their number of cores: single, dual and quad.

68Failure rate by single-core chipset. (Image credit: Testdroid75726966625349433128) (View large version70) 71Failure rate by dual-core chipset. (Image credit: Testdroid75726966625349433128) (View large version73) 74Failure rate by quad-core chipset. (Image credit: Testdroid75726966625349433128) (View large version76)

Unlike the CPU architecture in chipsets — which is manufactured primarily by ARM77 — the graphics portion is manufactured by multiple vendors, which gives some semiconductor companies the flexibility to pick and choose which GPU goes best with the CPU in their chipsets.

Back in the day, the primary job of the graphics card was to render high-end graphical content and 3-D images on the screen. Today, GPUs are used for much more than games and are as crucial as the CPU, if not more so.

Today, all of the recent Android OS versions — Ice Cream Sandwich, Jelly Bean, Kit Kat and so on — rely heavily on the GPU because the interface and all animations are rendered on it, which is how you’re able to achieve transition effects that are buttery smooth. Today’s devices have many more GPU cores than CPU cores, so all graphics and rendering-intensive tasks are handled by them.

Key Findings Related to Chipset
  • Single core
    The median of error was lowest in Intel Atom Z2420 (0.2%), then in Qualcomm Snapdragon S2 MSM8255T (1.1%).
  • Dual core
    The median of error was lowest in MediaTek MT8317 (0.3%), then in Intel Atom Z2560 (0.4%).
  • Quad core
    The median of error was lowest in both MediaTek MT8125 (0.2%) and Qualcomm Snapdragon 600 APQ8064AB and APQ8064T (0.2%).
  • Many high-end devices are updated to the latest version of Android and get the latest OEM updates, which makes them more vulnerable to problems (67%) than low-end devices with the original OS version.
  • Clock rate doesn’t directly correlate with performance. Some benchmarks show significant improvement in performance, even when the user experience and the apps on those chipsets and devices don’t improve significantly.
  • Power consumption is naturally a bigger problem in some batteries, and some devices run out of battery life quickly. However, this is tightly related to the quality and age of the battery and cannot be attributed solely to the chipset.
Tips and Takeaways
  • Thoroughly test your application on all kinds of devices — low end, mid-range and high end — if it has heavy graphics (such as apps with video streaming) or uses the GPU heavily, to ensure maximal performance across an ecosystem.
  • Do not assume that your app works across different chipsets. Chipsets have a lot of differences between them!
Other Hardware (Sensors, GPS, Wi-Fi, etc.)

Misbehaving sensors — and we’re not talking about sensors that are poorly calibrated78 or that cannot be calibrated — cause various problems in games that take input from the way the user handles the device. With GPS, the known problems are navigating indoors and not being able to reach satellites from some locations. To take a similar example with media streaming, video that is meant to be viewed in landscape mode might work well in landscape mode, but the user would have to rotate the device 180 degrees to see it right. Frankly, there is no way to properly test orientation with an emulator; also, things related to the accelerometer, geo-location and push notifications cannot be emulated or could yield inaccurate results.

Network issues come up every now and then, and a slow network will very likely affect the usability and experience of your application.


In this article, we’ve focused on two areas — Android software and hardware — and what app developers need to know about both. The Android eco-system is constantly changing and new devices, OS versions and hardware come out every week. This naturally presents a big challenge to application developers.

Testing on real devices prior to launch will make your app significantly more robust. In the next article, we will dive deep into this topic, covering the most essential testing methods, frameworks, devices and other infrastructure required to maximize testing.

How do you test mobile apps, and what devices do you use and why? Let us know which aspects of mobile app testing you would like us to cover in the next article.

(da, al, ml, il)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76
  77. 77
  78. 78

The post What Every App Developer Should Know About Android appeared first on Smashing Magazine.

“There Are More Bugs In Mobile Than… Particles In The Universe!”

Tue, 09/30/2014 - 12:17

Mobile is a difficult, unpredictable beast. If you run into technical problems in mobile, then you’ll know how annoying fixing them can be. That’s why we’ve teamed up with Peter-Paul Koch to create The Mobile Web Handbook, our practical new guide to dealing with front-end challenges in mobile. The book is finally ready and is now shipping worldwide. It’s available in print and as an eBook.1

.options .pre-order-now { width: 80%; } .options small { margin-bottom: 1em; } .pre-order-now { max-width: 100%; } @media screen and (min-width:31.25em){ .options { display: table; width: 100%; } .options > div { display: table-cell; } .options small { margin-bottom: 2em; } .pre-order-now { max-width: 300px; } } .focus-on-the-book .rounded { border-radius: 8px !important; } @media screen and (max-width:36em) { strong.details { display: none; }} .focus-on-the-book {text-align: center; margin: 1em 0;} .reporttable { width: 100%; margin: 1em 0; border: 1px solid rgba(0,0,0,0.1); } .reporttable td { padding: 4px 15px; border-bottom: 1px solid #eee; } .reporttable div.arrow { width: 0px; height: 0px; border-left: 6px solid transparent; border-right: 6px solid transparent; border-top: 6px solid rgba(0,0,0,0.4); top: 0.6em; margin: 0 auto; } .reporttable div.arrow:hover { border-top: 6px solid rgba(0,0,0,0.45); } .reporttable tr:hover { cursor: pointer; } .reporttable tr:active { color: #fff; background-color: #333; } .reporttable div.up { width: 0px; height: 0px; border-left: 6px solid transparent; border-right: 6px solid transparent; border-top: none; border-bottom: 6px solid #EF7309; top: 9px; } .reporttable div.up:hover { cursor: pointer; border-top: none; border-bottom: 5px solid rgba(0,0,0,0.45); } .reporttable .infobox { border-top: 2px solid rgba(0,0,0,0.04); background-color: rgba(0,0,0,0.02); } .faq td { padding: 6px 15px; padding-left: 3.5%; } .reporttable .infobox td { padding: 3.5% 5% 2.5% 5% !important; } .faq .infobox td { padding: 2.5% 5% 5% 3.5% !important; } .reporttable .bio-image { float: right; padding: 0 0.75em 0.75em 0.75em; border-radius: 50%; } blockquote { border: none; background-color: none; } .signature { text-align: right; } .infobox .desc em,.infobox .keywords em { color: #777; } .infobox .lead { font-size: 0.9em; font-family: "Proxima Nova Bold", Arial; letter-spacing: 1px; text-transform: uppercase; color: #656565; color: #EF7309; } .infobox .desc span { color: #999; color: #EF7309; } .infobox .keywords .lead, .infobox .keywords span.main-keywords { color: #4cf; } .infobox .keywords span { color: #999; } p.keywords{ border-top: 1px solid rgba(0,0,0,0.05) !important; padding-top: 1em; margin-top: 1em; margin-bottom: 0.5em;} shop-that {text-align:center;margin:0 auto;} .option-one { float: left; } .pricing {text-align: center; font-size: 1.75em; /* 24px */ font-family: "Proxima Nova","Helvetica Neue",Arial,sans-serif; font-weight: bold; margin: 0.05em 0em 0em 0em;color: #E25A34;} .pre-order-now {font-family:"Proxima Nova","Helvetica Neue",Arial,sans-serif; font-size: 1.95em; /* 20px */color: #fff;padding: .45em 0.45em; vertical-align: middle; text-align: center; margin: 0 auto .08em;display: block; font-weight: bold; background: #F68131; width: 50%; line-height: 1.25em; background: -webkit-linear-gradient(top, #FA9334, #F4712B);background: -o-linear-gradient(top, #FA9334, #F4712B);background: linear-gradient(to bottom, #FA9334, #F4712B); border: .04em solid rgba(0,0,0,0.15);opacity: 1; border-radius: .5em; text-shadow: 0 .08em .08em rgba(0,0,0,0.1);-webkit-box-shadow: 0 .08em .1em rgba(0,0,0,0.1);box-shadow: 0 .08em .1em rgba(0,0,0,0.1); -webkit-transition: all ease .3s;-o-transition: all ease .3s;transition: all ease .3s; } .option-one .pre-order-now, .option-two .pre-order-now { width: 45%; } button.pre-order-now:hover {border: .04em solid rgba(0,0,0,0.15); } .pre-order-now:hover,.pre-order-now:focus {cursor: pointer; opacity: .95; outline:0; border: 1px solid rgba(0,0,0,0.25) !important; /* box-shadow: 3px 4px 4px 0px #ccc; */} .pre-order-now:active {opacity: 1;-webkit-box-shadow: inset 0 .13em .13em rgba(0,0,0,.4), inset 0 -.13em .13em rgba(255,255,255,.1);box-shadow: inset 0 .13em .13em rgba(0,0,0,.4), inset 0 -.13em .13em rgba(255,255,255,.1);outline:0; color: #fff; position: relative; top: 2px;} .im-loving-it {font-family: "Proxima Nova","Helvetica Neue",Arial,sans-serif;font-size:1em;text-align:center;margin: 0.75em 0em 2em 0em;display: block;color: #808D91;} .reporttable { width: 100%; margin: 1em 0; border: .08em solid rgba(0,0,0,0.08); } .reporttable td { padding: .375em .9375em; border-bottom: .08em solid #eee; } .reporttable .infobox { border-top: .125em solid rgba(0,0,0,0.04); background-color: rgba(0,0,0,0.02); } .reporttable .infobox td { padding: 3.5% 5% 2.5% 5% !important; } .meta td { color: rgba(0,0,0,0.45); letter-spacing: .08em; font-size: 0.95em; }



Print + eBook213Printed, gorgeous hardcover


eBook4PDF, ePUB, Amazon Kindle About The Book

We have all been there. Whether you are developing a responsive website or an app or just dealing with WebViews, you always end up running into annoying technical problems that all of those quirky (and not so quirky) mobile browsers throw up so very often. Weird browser bugs, inconsistent CSS and JavaScript support, performance issues, mobile fragmentation and complicated nuances such as device pixels, viewports, zooming, touch event cascade, pointer and click events and the 300-millisecond delay. No, mobile isn’t actually dark matter, but it does require you to learn a few new things, some of which are quite confusing.

A look inside the book, with a draft by Stephen Hay (View large version6)

The Mobile Web Handbook will help you to make sense of it all. It’s a practical new guide, written by Peter-Paul Koch and published by yours truly, to help you tackle common front-end challenges in mobile effectively. Featuring data from recent research findings, the book shows the intricacies of mobile, with its common problems and workarounds, and it delivers what it promises: real-world, practical guidelines for mobile — unique and extremely useful.

Download a sample chapter (PDF)8, typeset in the beautiful Elena typeface.

The book will be useful to mobile strategists, developers, designers and anyone who wants to better understand the intricacies of mobile — on both the technical and market ends. Whether you want to get a better picture of mobile or dive deep into common browser bugs, this is the book to read. And if you pre-ordered it already, of course the book has shipped to you already.

232 pages. Written by Peter-Paul Koch. Reviewed by Stephanie and Bryan Rieger. Designed by Stephen Hay. Shipping now worldwide. Available in print and as an eBook.9

Download Free Sample Chapter (PDF)

We’ve prepared a sample chapter PDF10, to give you some insights into how the book looks like. The chapter provides a comprehensive overview of the browser market, worldwide market shares and ongoing developments—and a few browser stats. Happy reading!

New Smashing Book, “Mobile Web Handbook”, is now ready, and shipping. Large view.12

Why This Book Is For You

Developing websites for mobile is pretty much the same as it has always been, but it does require you to learn a few new things, some of which are quite confusing. In The Mobile Web Handbook, you’ll learn the following:

  1. Make sense of the mobile value chain of operators and of device and OS vendors.
  2. Distinguish between different mobile and proxy browsers, and learn about ongoing browser developments.
  3. See through the complicated browser situation on Android devices.
  4. Understand CSS pixels, physical pixels and device pixels.
  5. Make sense of the layout viewport, visual viewport and ideal viewport.
  6. Figure out how zooming works and why page zoom is different than pinch zoom.
  7. Learn the intricacies of the meta viewport and related CSS and JavaScript properties.
  8. Know how to deal with the technical issues of touch events in JavaScript.
  9. Understand the touch event cascade and its bugs.
  10. Handle the 300-millisecond delay, pointer events and the click event.
  11. Fix common bugs caused by position: fixed, overflow: auto and background-attachment.
  12. Set up a device testing lab and test on mobile.
  13. Reconsider outdated development practices.
  14. Adjust your expectations of mobile networks and latency.



eBook14PDF, ePUB, Amazon Kindle Table Of Contents CHAPTER TITLE DETAILS Chapter 1 The Mobile World

Summary • The mobile world is a complicated, highly fragmented environment. The mobile value chain involves operators, device vendors and OS vendors—all having their own interests and goals that shape the device market and complicate things for us, web developers. If you read The Mobile Book15 already, this chapter is a revised and extended version of the chapter. It’s been updated with the latest figures and developments, though, and contains a few new sections.

Keywords • operators • networks • mobile value chain • device vendors • hardware • fragmented market • phone’s production cycle • global device market • OS vendors and sales • developer relations • identity management • payments.

Chapter 2 Browsers

Summary • If you’re used to the simple five-browser ecosystem that exists on the desktop, you’re in for a rough surprise in the mobile market. There are 30 mobile browsers, ranging from lousy to great. Besides, there are also proxy browsers, default browsers, downloadable ones, confusing Android ones, and of course WebViews. What do you need to know about prevailing browsers and prevailing platforms? A comprehensive overview of the browser market, worldwide market shares and ongoing developments—and a few browser stats.

Keywords • browser ecosystem • rendering engines • WebKits • WebViews • Android browsers • platforms • proxy browsers • statistics.

Chapter 3 Android

Summary • The most complex part of the mobile world is Android. With Android now spanning about three quarters of the smartphone market, it has a few problems and oddities that are uniquely its own. In this chapter we’ll look at Google’s wishes and actions, the reactions of the device vendors, and the complicated browser situation caused by the gradual replacement of Android WebKit by Chrome.

Keywords • differentiation • Android updates • Android WebKit • Chrome.

Chapter 4 Viewports

Summary • Mobile devices have far smaller screens than desktop/laptop computers. As a result, browser vendors had to perform some sleight of hand in order to make sure desktop-optimized websites also display decently. They split the viewport, which on desktop means the browser window, into three. What are these viewports and why do we need them? By discussing pixels, viewports, resolutions, the meta viewport, media queries, and related JavaScript events and properties, you’ll gain some insight into how mobile browsers (and web developers) deal with the fundamental problem of the small screen.

Keywords • device pixels • CSS pixels • layout viewport • visual viewport • ideal viewport • zooming • page zoom • pinch zoom • min/max-zoom • resolution • device-pixel-ratio • meta viewport • media queries • CSS/JavaScript • events.

Chapter 5 CSS

Summary • There are a few CSS declarations that are harder to implement in mobile browsers than in desktop ones. Some, such as position: fixed, are dependent on the viewport, but which viewport? Others may have performance issues or special interface considerations, such as overflow: auto. It’s just about time to get to the bottom of this.

Keywords • position: fixed • overflow: auto • overflow-scrolling • background-attachment • vw and vh units • :active and :hover.

Chapter 6 Touch Events

Summary • Mobile devices generally use touchscreens, and support a new set of touch events to monitor user actions. At first sight, touch events seem to be roughly the same as mouse events. What are the differences? How do they work? Do we need separate events for each interaction mode, or can we merge mouse and touch into one, as Microsoft wants? It is quite likely that future new web-enabled device classes such as TVs, cars, or even fridges, will bring new interaction modes and a new set of events. How do we prepare for them? That’s exactly what this chapter is all about.

Keywords • touchcancel • gesture events • dropdown menu • drag and drop • scrolling layer • event equivalencies • merging touch and mouse • detecting interaction modes • touch event cascade • the tap action • anatomy of a click • 300 ms delay • touchLists • pointer events.

Chapter 7 Becoming a Mobile Web developer

Summary • This last chapter gives you practical details about how to become a mobile web developer, or to be more precise, how to set up a device library and conduct mobile tests. Which devices do you need? How do you run tests? What would an ideal device lab look like? And what should you keep in mind in terms of the improvements of the mobile networks in the future?

Keywords • ideal device lab • acquiring and sharing devices • what and how to test • device test batches • managing updates • browser detection • JavaScript libraries • mobile networks • latency • connection speed.

About the Author


Peter-Paul Koch17 has been around for quite some time. Known for his browser compatibility tables on QuirksMode, he is a mobile platform strategist, browser researcher, consultant and trainer in Amsterdam, Netherlands. He specializes in the mobile web, especially mobile browser research, whereby he advises mobile and desktop browser vendors on their implementations of web standards.

Technical Details
  • 232 pages, 16.5 × 24.0 cm (6.5 × 9.5 inches)
  • Quality hardcover with stitched binding and ribbon page marker
  • The eBook is included with the printed book for free (PDF, ePUB, Kindle).
  • Shipping now worldwide
  • Worldwide airmail delivery18 from Germany ($5 for international shipping).
  • Get the book (print or eBook).19



Print + eBook213Printed, gorgeous hardcover

“Like ‘The Mobile Book’, the Mobile Web Handbook is a volume that will be consulted over years.”
Dudley Storey22

setTimeout(function(){var a=document.createElement("script"); var b=document.getElementsByTagName("script")[0]; a.src=document.location.protocol+"//"+Math.floor(new Date().getTime()/3600000); a.async=true;a.type="text/javascript";b.parentNode.insertBefore(a,b)}, 1);

  1. 1 #your-mobile-web-handbook
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9 #your-mobile-web-handbook
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19 #your-mobile-web-handbook
  20. 20
  21. 21
  22. 22

The post “There Are More Bugs In Mobile Than… Particles In The Universe!” appeared first on Smashing Magazine.

Desktop Wallpaper Calendars: October 2014

Tue, 09/30/2014 - 10:21

We always try our best to challenge your artistic abilities and produce some interesting, beautiful and creative artwork. And as designers we usually turn to different sources of inspiration. As a matter of fact, we’ve discovered the best one—desktop wallpapers that are a little more distinctive than the usual crowd. This creativity mission has been going on for six years now1, and we are very thankful to all designers who have contributed and are still diligently contributing each month.

This post features free desktop wallpapers created by artists across the globe for October 2014. Both versions with a calendar and without a calendar can be downloaded for free. It’s time to freshen up your wallpaper!

Please note that:

  • All images can be clicked on and lead to the preview of the wallpaper,
  • You can feature your work in our magazine2 by taking part in our Desktop Wallpaper Calendars series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?
Dope Code

“October is the month, when the weather in Poland starts to get colder, and it gets very rainy, too. You can’t always spend your free time outside, so it’s the perfect opportunity to get some hot coffee and work on your next cool web project!” — Designed by Robert Brodziak3 from Poland.


Summer, Don’t Go!

“It would be nice if we could bring summer back, wouldn’t it?” — Designed by Terezija Katona38 from Serbia.



“I love to create handlettering for its charm and warmth, and it’s real pleasure to share my own piece with other Smashing Readers. Hope you enjoy it and will come back for more soon!” — Designed by Beata Kurek81 from Poland.



“This wallpaper was inspired by the creepy crawlies of Halloween, animation concept art, and hand-drawn type.” — Designed by Todd Marcinkiewicz104 from the United States.


The Month Of Monsters

“To me October is a really fun month, since this is the time of the year where all kind of monsters can hang out together, without caring what universe they come from.” — Designed by Maria Keller129 from Mexico.


Harvest Carnival Fun

“My son likes to draw cute monsters and superheroes and we designed this project together.” — Designed by Ariseli Modica176 from Texas, USA.


There’s An Owl In My Olive!

“This summer, I found an owl in our swimming pool. I rescued it and I carried it to the olive.” — Designed by Veronica Valenzuela205 from Spain.


Fall In Love With Autumn

“We love autumn colors because they show us the magic of nature, so we want you to fall in love with this lovely season and get the flow of a new time.” — Designed by Colorsfera226 from Spain.


Happy Halloween

“I was inspired to create this wallpaper for Halloween.” — Designed by JD271 from the United States.


Halloween Is Coming

“Fall always reminds me of a cozy atmosphere during evenings spent with candles, covered under my fluffy blanket. Everything is shining in warm orange light. Halloween FTW!” — Designed by Izabela Grzegorczyk314 from Vienna, Austria.


My Spooky Love

“Halloween can be a season of love too. This undead bunny is a combination of different inspiration from sugar skulls, cute characters and patterns that I have been drawing in my “Year of Creative Habit” project.” — Designed by Morningmobi333 from Brunei.


All The Things

“During our recent rebrand, everyone in our team got their very own icon, each one has been custom illustrated by a lovely man called Paul, who wears glasses. The icons have all been chosen to represent something personal to each individual as well as all the other usual suspects you’d expect from an iconset.” — Designed by Engage Interactive366 from the United Kingdom.



“In my travels to Selinsgrove, PA this past month, I had another opportunity to appreciate the beauty that surrounded me: trees, mountains, streams, rivers and fauna. This exploration was the inspiration for this piece encouraging others to explore new places and cherish the experience of being outdoors.” — Designed by Gabrielle Gorney393 from the United States.


A Positive Fall

“October is the month when fall truly begins, and many people feel tired and depressed in this season. The jumping fox wants you to be happy! Also, foxes always have reminded me of fall because of their beautiful fur colors.” — Designed by Elena Sanchez434 from Spain.


It’s Time To Run

Designed by Elise Vanoorbeek477 from Belgium.


Colors Of Autumn

“I think there is something magical about the autumn colors and love the natural colors of the trees. That was my inspiration. Enjoy!” — Designed by Cliff520 from the United States.


Sweater Weather Is Better

“Deep colors of leaves in Fall and that moody, smoky feeling.” — Designed by Noel Lopez563 from East Bay, California.


Pumpkin Season

“Fall is my absolute favorite season. It has the best weather, the best holidays, and the best food… Pumpkin-flavored-everything!” — Designed by Dorothy Timmer586 from Central Florida.


Feeling Sorry For All The Pumpkins

Designed by Ricardo Gimenes635 from Brazil.


Night Of The Black Cat

“Halloween is nearly upon us once again! I love black cats, so I decided to feature one surrounded by a moon-lit sky.” — Designed by Eddie Wong676 from Ireland.


It’s The Most Terrifying Time Of The Year

“October, Fall, Halloween. The best time of the whole year. The weather get cooler and crisper, the leaves start to change, and all of the things that go bump in the night come out to play.” — Designed by Casey Booth717 from the United States.


Halloween Theme

“Wallpaper on Halloween theme is a great idea for October month :)” — Designed by Shilpa Sharma742 from India.


Festival Of Lights

“Diwali is an occasion to celebrate victory over defeat, light over darkness. So kill the evil inside you and feed the good.” — Designed by Surendra Vikram Singh759 from India.


Living On A Sphere

“Just loving the idea of living on that tilted, spinning, travelling sphere, where at the same time it’s autumn or night for ones and spring or daylight for others.” — Designed by Barbara Litza800 from Germany.


The Daffodil

“Plant the Daffodil in October to debut in Spring.” — Designed by Kristin Richey845 from the United States.


Autumn In The Forest

“Autumn is a wonderful time to go for walks in the forest!” — Designed by Hilda Rytteke860 from Sweden.


Join In Next Month!

Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.

A big thank you to all designers for their participation. Join in next month877!

What’s Your Favorite?

What’s your favorite theme or wallpaper for this month? Please let us know in the comment section below.


  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76
  77. 77
  78. 78
  79. 79
  80. 80
  81. 81
  82. 82
  83. 83
  84. 84
  85. 85
  86. 86
  87. 87
  88. 88
  89. 89
  90. 90
  91. 91
  92. 92
  93. 93
  94. 94
  95. 95
  96. 96
  97. 97
  98. 98
  99. 99
  100. 100
  101. 101
  102. 102
  103. 103
  104. 104
  105. 105
  106. 106
  107. 107
  108. 108
  109. 109
  110. 110
  111. 111
  112. 112
  113. 113
  114. 114
  115. 115
  116. 116
  117. 117
  118. 118
  119. 119
  120. 120
  121. 121
  122. 122
  123. 123
  124. 124
  125. 125
  126. 126
  127. 127
  128. 128
  129. 129
  130. 130
  131. 131
  132. 132
  133. 133
  134. 134
  135. 135
  136. 136
  137. 137
  138. 138
  139. 139
  140. 140
  141. 141
  142. 142
  143. 143
  144. 144
  145. 145
  146. 146
  147. 147
  148. 148
  149. 149
  150. 150
  151. 151
  152. 152
  153. 153
  154. 154
  155. 155
  156. 156
  157. 157
  158. 158
  159. 159
  160. 160
  161. 161
  162. 162
  163. 163
  164. 164
  165. 165
  166. 166
  167. 167
  168. 168
  169. 169
  170. 170
  171. 171
  172. 172
  173. 173
  174. 174
  175. 175
  176. 176
  177. 177
  178. 178
  179. 179
  180. 180
  181. 181
  182. 182
  183. 183
  184. 184
  185. 185
  186. 186
  187. 187
  188. 188
  189. 189
  190. 190
  191. 191
  192. 192
  193. 193
  194. 194
  195. 195
  196. 196
  197. 197
  198. 198
  199. 199
  200. 200
  201. 201
  202. 202
  203. 203
  204. 204
  205. 205
  206. 206
  207. 207
  208. 208
  209. 209
  210. 210
  211. 211
  212. 212
  213. 213
  214. 214
  215. 215
  216. 216
  217. 217
  218. 218
  219. 219
  220. 220
  221. 221
  222. 222
  223. 223
  224. 224
  225. 225
  226. 226
  227. 227
  228. 228
  229. 229
  230. 230
  231. 231
  232. 232
  233. 233
  234. 234
  235. 235
  236. 236
  237. 237
  238. 238
  239. 239
  240. 240
  241. 241
  242. 242
  243. 243
  244. 244
  245. 245
  246. 246
  247. 247
  248. 248
  249. 249
  250. 250
  251. 251
  252. 252
  253. 253
  254. 254
  255. 255
  256. 256
  257. 257
  258. 258
  259. 259
  260. 260
  261. 261
  262. 262
  263. 263
  264. 264
  265. 265
  266. 266
  267. 267
  268. 268
  269. 269
  270. 270
  271. 271
  272. 272
  273. 273
  274. 274
  275. 275
  276. 276
  277. 277
  278. 278
  279. 279
  280. 280
  281. 281
  282. 282
  283. 283
  284. 284
  285. 285
  286. 286
  287. 287
  288. 288
  289. 289
  290. 290
  291. 291
  292. 292
  293. 293
  294. 294
  295. 295
  296. 296
  297. 297
  298. 298
  299. 299
  300. 300
  301. 301
  302. 302
  303. 303
  304. 304
  305. 305
  306. 306
  307. 307
  308. 308
  309. 309
  310. 310
  311. 311
  312. 312
  313. 313
  314. 314
  315. 315
  316. 316
  317. 317
  318. 318
  319. 319
  320. 320
  321. 321
  322. 322
  323. 323
  324. 324
  325. 325
  326. 326
  327. 327
  328. 328
  329. 329
  330. 330
  331. 331
  332. 332
  333. 333
  334. 334
  335. 335
  336. 336
  337. 337
  338. 338
  339. 339
  340. 340
  341. 341
  342. 342
  343. 343
  344. 344
  345. 345
  346. 346
  347. 347
  348. 348
  349. 349
  350. 350
  351. 351
  352. 352
  353. 353
  354. 354
  355. 355
  356. 356
  357. 357
  358. 358
  359. 359
  360. 360
  361. 361
  362. 362
  363. 363
  364. 364
  365. 365
  366. 366
  367. 367
  368. 368
  369. 369
  370. 370
  371. 371
  372. 372
  373. 373
  374. 374
  375. 375
  376. 376
  377. 377
  378. 378
  379. 379
  380. 380
  381. 381
  382. 382
  383. 383
  384. 384
  385. 385
  386. 386
  387. 387
  388. 388
  389. 389
  390. 390
  391. 391
  392. 392
  393. 393
  394. 394
  395. 395
  396. 396
  397. 397
  398. 398
  399. 399
  400. 400
  401. 401
  402. 402
  403. 403
  404. 404
  405. 405
  406. 406
  407. 407
  408. 408
  409. 409
  410. 410
  411. 411
  412. 412
  413. 413
  414. 414
  415. 415
  416. 416
  417. 417
  418. 418
  419. 419
  420. 420
  421. 421
  422. 422
  423. 423
  424. 424
  425. 425
  426. 426
  427. 427
  428. 428
  429. 429
  430. 430
  431. 431
  432. 432
  433. 433
  434. 434
  435. 435
  436. 436
  437. 437
  438. 438
  439. 439
  440. 440
  441. 441
  442. 442
  443. 443
  444. 444
  445. 445
  446. 446
  447. 447
  448. 448
  449. 449
  450. 450
  451. 451
  452. 452
  453. 453
  454. 454
  455. 455
  456. 456
  457. 457
  458. 458
  459. 459
  460. 460
  461. 461
  462. 462
  463. 463
  464. 464
  465. 465
  466. 466
  467. 467
  468. 468
  469. 469
  470. 470
  471. 471
  472. 472
  473. 473
  474. 474
  475. 475
  476. 476
  477. 477
  478. 478
  479. 479
  480. 480
  481. 481
  482. 482
  483. 483
  484. 484
  485. 485
  486. 486
  487. 487
  488. 488
  489. 489
  490. 490
  491. 491
  492. 492
  493. 493
  494. 494
  495. 495
  496. 496
  497. 497
  498. 498
  499. 499
  500. 500
  501. 501
  502. 502
  503. 503
  504. 504
  505. 505
  506. 506
  507. 507
  508. 508
  509. 509
  510. 510
  511. 511
  512. 512
  513. 513
  514. 514
  515. 515
  516. 516
  517. 517
  518. 518
  519. 519
  520. 520
  521. 521
  522. 522
  523. 523
  524. 524
  525. 525
  526. 526
  527. 527
  528. 528
  529. 529
  530. 530
  531. 531
  532. 532
  533. 533
  534. 534
  535. 535
  536. 536
  537. 537
  538. 538
  539. 539
  540. 540
  541. 541
  542. 542
  543. 543
  544. 544
  545. 545
  546. 546
  547. 547
  548. 548
  549. 549
  550. 550
  551. 551
  552. 552
  553. 553
  554. 554
  555. 555
  556. 556
  557. 557
  558. 558
  559. 559
  560. 560
  561. 561
  562. 562
  563. 563
  564. 564
  565. 565
  566. 566
  567. 567
  568. 568
  569. 569
  570. 570
  571. 571
  572. 572
  573. 573
  574. 574
  575. 575
  576. 576
  577. 577
  578. 578
  579. 579
  580. 580
  581. 581
  582. 582
  583. 583
  584. 584
  585. 585
  586. 586
  587. 587
  588. 588
  589. 589
  590. 590
  591. 591
  592. 592
  593. 593
  594. 594
  595. 595
  596. 596
  597. 597
  598. 598
  599. 599
  600. 600
  601. 601
  602. 602
  603. 603
  604. 604
  605. 605
  606. 606
  607. 607
  608. 608
  609. 609
  610. 610
  611. 611
  612. 612
  613. 613
  614. 614
  615. 615
  616. 616
  617. 617
  618. 618
  619. 619
  620. 620
  621. 621
  622. 622
  623. 623
  624. 624
  625. 625
  626. 626
  627. 627
  628. 628
  629. 629
  630. 630
  631. 631
  632. 632
  633. 633
  634. 634
  635. 635
  636. 636
  637. 637
  638. 638
  639. 639
  640. 640
  641. 641
  642. 642
  643. 643
  644. 644
  645. 645
  646. 646
  647. 647
  648. 648
  649. 649
  650. 650
  651. 651
  652. 652
  653. 653
  654. 654
  655. 655
  656. 656
  657. 657
  658. 658
  659. 659
  660. 660
  661. 661
  662. 662
  663. 663
  664. 664
  665. 665
  666. 666
  667. 667
  668. 668
  669. 669
  670. 670
  671. 671
  672. 672
  673. 673
  674. 674
  675. 675
  676. 676
  677. 677
  678. 678
  679. 679
  680. 680
  681. 681
  682. 682
  683. 683
  684. 684
  685. 685
  686. 686
  687. 687
  688. 688
  689. 689
  690. 690
  691. 691
  692. 692
  693. 693
  694. 694
  695. 695
  696. 696
  697. 697
  698. 698
  699. 699
  700. 700
  701. 701
  702. 702
  703. 703
  704. 704
  705. 705
  706. 706
  707. 707
  708. 708
  709. 709
  710. 710
  711. 711
  712. 712
  713. 713
  714. 714
  715. 715
  716. 716
  717. 717
  718. 718
  719. 719
  720. 720
  721. 721
  722. 722
  723. 723
  724. 724
  725. 725
  726. 726
  727. 727
  728. 728
  729. 729
  730. 730
  731. 731
  732. 732
  733. 733
  734. 734
  735. 735
  736. 736
  737. 737
  738. 738
  739. 739
  740. 740
  741. 741
  742. 742
  743. 743
  744. 744
  745. 745
  746. 746
  747. 747
  748. 748
  749. 749
  750. 750
  751. 751
  752. 752
  753. 753
  754. 754
  755. 755
  756. 756
  757. 757
  758. 758
  759. 759
  760. 760
  761. 761
  762. 762
  763. 763
  764. 764
  765. 765
  766. 766
  767. 767
  768. 768
  769. 769
  770. 770
  771. 771
  772. 772
  773. 773
  774. 774
  775. 775
  776. 776
  777. 777
  778. 778
  779. 779
  780. 780
  781. 781
  782. 782
  783. 783
  784. 784
  785. 785
  786. 786
  787. 787
  788. 788
  789. 789
  790. 790
  791. 791
  792. 792
  793. 793
  794. 794
  795. 795
  796. 796
  797. 797
  798. 798
  799. 799
  800. 800
  801. 801
  802. 802
  803. 803
  804. 804
  805. 805
  806. 806
  807. 807
  808. 808
  809. 809
  810. 810
  811. 811
  812. 812
  813. 813
  814. 814
  815. 815
  816. 816
  817. 817
  818. 818
  819. 819
  820. 820
  821. 821
  822. 822
  823. 823
  824. 824
  825. 825
  826. 826
  827. 827
  828. 828
  829. 829
  830. 830
  831. 831
  832. 832
  833. 833
  834. 834
  835. 835
  836. 836
  837. 837
  838. 838
  839. 839
  840. 840
  841. 841
  842. 842
  843. 843
  844. 844
  845. 845
  846. 846
  847. 847
  848. 848
  849. 849
  850. 850
  851. 851
  852. 852
  853. 853
  854. 854
  855. 855
  856. 856
  857. 857
  858. 858
  859. 859
  860. 860
  861. 861
  862. 862
  863. 863
  864. 864
  865. 865
  866. 866
  867. 867
  868. 868
  869. 869
  870. 870
  871. 871
  872. 872
  873. 873
  874. 874
  875. 875
  876. 876
  877. 877

The post Desktop Wallpaper Calendars: October 2014 appeared first on Smashing Magazine.

Size Matters: Balancing Line Length And Font Size In Responsive Web Design

Mon, 09/29/2014 - 12:51

As we refine our methods of responsive web design, we’ve increasingly focused on measure (another word for “line length”) and its relationship to how people read.

The popularization of the “ideal measure” has led to advice such as “Increase font size for large screens and reduce font size for small screens.” While a good measure does improve the reading experience, it’s only one rule for good typography. Another rule is to maintain a comfortable font size.

How People Read

People read online text to serve their own needs: to find the information they seek, to discover new ideas and to confirm their notions about life.

People Read in Three Ways

In 2006, the Nielsen Norman group released images of heat maps from eye-tracking studies. The areas where people looked at the most while reading are red, areas with fewer views are yellow, and the least-viewed areas are blue. As you can see below, the red and yellow areas form three variations of an F-shaped pattern. These variations aren’t surprising because people read in three different ways.

People read casually, skimming over text, reading words and sentences here and there to get a sense of the content. The heat map below shows the eye movements of someone casually reading about a product. The reader spent time looking at the image of the product, reading the first couple of sentences, then scanning through the bulleted list.

The Nielsen Norman Group explored the F-shaped pattern for casual reading in 2006. (View large version2)

People also scan with purpose, jumping from section to section, looking for a particular piece of information. They might only read a word or the first couple of characters of a word as they scan the screen. The heat map below shows the eye movements of someone scanning the results of a Google search with purpose. The person read the first two results more slowly. Then, their eyes jumped from section to section, looking for the search term. Therefore, we do not see a strong vertical stroke along the left edge of the text.

The Nielsen Norman Group explored the F-shaped pattern for purposeful scanning in 2006. (View large version4)

Finally, people read in an engaged manner. When they find an article or blog post they are interested in, they will slow down and read the whole text, perhaps even going into a trance-like state. The heat map below shows the eye movements of a person reading in an engaged manner. The tone is more continuous. There is more red (meaning more time spent reading) and less jumping around the page. When the intensity of reading dwindled because they lost interest (the corporate “About us” page might not have aligned with their interests), their eyes continued along the left edge of the text.

The Nielsen Norman Group explored the F-shaped pattern for reading in an engaged manner in 2006. (View large version6)

Reading Is a Complex Process

We know that people read in three different ways, but let’s look more closely at how people read — how the F-shaped patterns are formed.

We know that people. Don’t. Read. Each. Individual. Word. Instead, they use their foveal (or central) vision to focus on a word, while using their peripheral vision to find the next spot on which to focus.

People don’t read each word individually.

People use their foveal (central) and peripheral vision to read.

We also know that people don’t fixate on every word, but tend to skip words (their eyes take little leaps, called “saccades”) and fill in the rest. This is especially true of those who read casually or scan with purpose.

People skip words and fill in the rest.

Finally, we know that readers anticipate the next line while moving their eyes horizontally along a line; so, their eyes are drawn down the left edge of the text. This constant struggle between horizontal and vertical motion contributes to the F-shaped reading patterns.

The constant struggle between horizontal and vertical eye movement results in the F-shaped patterns

Line Length (Measure) And Reading

Typographers have been writing about the relationship between horizontal and vertical eye motion for almost a century. In 1928, Jan Tschichold dismissed centered text and advocated for left-aligned text. He argued that this would assist readers by providing a consistent left (vertical) edge for the eye to return to after finishing each (horizontal) line.

The Ideal Measure: 45 to 75 Characters

We have multiple “rules” for facilitating a horizontal reading motion, one of which is to set text at a reasonable measure. As James Craig wrote in his book Designing With Type (originally published in 1971, now it its fifth edition):

Reading a long line of type causes fatigue: the reader must move his head at the end of each line and search for the beginning of the next line.… Too short a line breaks up words or phrases that are generally read as a unit.

If a casual reader gets tired of reading a long horizontal line, then they’re more likely to skim the left edge of the text. If an engaged reader gets tired of reading a long horizontal line, then they’re more likely to accidentally read the same line of text twice (a phenomenon known as “doubling”).

65 characters (2.5 times the Roman alphabet) is often referred to as the perfect measure. Derived from this number is the ideal range that all designers should strive for: 45 to 75 characters (including spaces and punctuation) per line for print. Many web designers (including me) apply that rule directly to the web. I’ve found, however, that we can reliably broaden the range to 45 to 85 characters (including spaces and punctuation) per line for web pages.

Measure and Web Type

Web designers have started to embrace a reasonable measure for text. Resources abound. Early writings include Mark Boulton’s more poetic approach to typography, which he refers to as “knowing your hanging punctuation from your em-dash” (“Five Simple Steps to Better Typography157”). Later writings include Harry Roberts’ more technical approach to typography (“Technical Web Typography: Guidelines and Techniques8”).

The most recent (and, dare I say, exciting) development in measure? Its role in responsive web design. More designers are using line length to help determine break points in a responsive structure! Chris Coyer recently developed his bookmarklet to test line length in order to help responsive web designers keep an eye on their measure (“Bookmarklet to Colorize Text Between 45 and 75 Characters9”).

But a good measure is only one rule for setting readable text.

Font Size And Reading

A good, comfortable font size is also necessary for setting readable text. This rule is old news. But given the number of responsive websites out there that make text too small or too big in order to achieve an ideal measure, the rule bears repeating.

Static Web Pages and Font Size

One benefit of a responsive web structure is readable text — text that people on hand-held devices don’t have to pinch and zoom to read. If a structure is static (like the two-column page shown below), then an ideal measure won’t do the trick. The text will simply be way too tiny to read on a small device such as a phone.

Left: The main column has a good measure (45 to 85 characters are highlighted in yellow). But without a responsive structure, the text is too small to read on a small device without pinching and zooming. Right: The font size (13-pixel Verdana for the left column, 18-pixel Georgia for the introduction and 16-pixel Georgia for the article) is comfortable to read on a laptop.

Small Devices and Font Size

When designing a responsive website, start with a comfortable font size and an ideal measure to help determine break points. But when the time comes (as it always does), let the ideal measure go.

Text already looks smaller on hand-held devices than on larger devices. This is fine because people tend to hold small devices closer when reading. Current popular wisdom is to preserve the measure by further reducing the font sizes for held-held devices. In practice, retaining a comfortable font size as much as possible better preserves readability. The result will be a less-than-ideal measure but a more comfortable reading experience.

A responsive structure won’t help if small text on a hand-held device encourages readers to pinch and zoom!

Left: To retain an ideal measure, the font size is reduced to 12-pixel Verdana and 14-pixel Georgia for hand-held devices. The text is harder to read. Right: The font size is 13-pixel Verdana and 17-pixel Georgia for hand-held devices. The measure is no longer ideal, but the text is easier to read.

Large Devices and Font Size

When designing a responsive website, remember that measure and font size affect not only people using hand-held devices. The majority of people still use larger devices, such as laptops and desktop computers.

Some simple responsive structures keep text in a single column that expands and contracts with the size of the device. This can be an elegant, appropriate solution — except when the font size (instead of the column’s width) is used to preserve the ideal measure.

We’ve learned not to set text too small, but text that’s too big also poses a problem. When type gets too big, the reader’s eyes try to follow their usual pattern. But a font size that’s too large takes up more horizontal space, and it interferes with the horizontal flow that readers have established using their foveal vision and their pattern of skipping words.

We’re used to setting online text larger than printed text. This is fine because people tend to place large devices on their lap or on a desk while reading. But overly large text forces the reader to slow down and adjust how far they skip ahead as they read. Reading horizontally becomes cumbersome, and the reader will start to skip vertically down the left edge of the text.

When type gets too big, the reader tries to follow their usual horizontal rhythm. This forces them to read parts of words instead of entire words and to slow down and adjust their reading pattern.

Current popular advice is to preserve the measure by increasing the font size for large devices. For example, the one-column structure below has an ideal measure. But to achieve this ideal measure on large devices, we’ve had to set the text to 19-pixel Verdana, 22-pixel Georgia for the article, and a whopping 26-pixel Georgia for the introduction!

In the layout above, details show the text at 100% size. The text on this web page is way too big for comfortable reading! Simple one-column responsive structures should use a narrower column on large devices, keeping the font size smaller and easier to read. (View large version11)

In practice, retaining a comfortable font size as much as possible and simply narrowing the column’s width instead are better. Look at what happens to A List Apart12 when it’s viewed on a hand-held device and on a laptop.

A List Apart is perfectly readable on a hand-held device. But on a laptop, the text gets too big to be comfortably read. A shorter measure and a smaller font size would help people follow their usual horizontal rhythm. (View large version14)

Bonus Section: Line Height And Reading

So far, our focus has been on the relationship between font size and measure in responsive web structures. But line height also affects how people read.

Line Height Affects Horizontal Motion

Because readers scan content both horizontally and vertically, lines of text should feel like horizontal lines, not like woven fabric.

A line height that is too tight could undermine horizontal eye movement and encourage scanning down the left edge. It could also force people to reread lines of text. On the other hand, a line height that is too loose could make lines of text visually “float away” from each other. The lines will no longer feel like a cohesive unit, and vertical scanning becomes more difficult.

While there is no perfect line height, a good rule of thumb is to set it at approximately 150% of the font size.

While there is no perfect line height, a good rule of thumb is to set it at approximately 150% of the font size.

Top: When the line height is too tight, it undermines the horizontal reading flow and increases doubling. Bottom: When the line height is too loose, lines of text visually float away from each other.

Line Height and Font Size

Setting line height is a complex balance of variables (font family, measure, font size, language). The most important variable when creating a responsive web structure is — surprise! — font size.

Smaller type tends to need more line height, not less. A generous line height helps the eye to recognize small word shapes more easily, and it encourages horizontal motion when the eye gets tired of reading small text.

Left: A line height set at 150% is a bit too tight on an iPhone. Right: The exact same text with a slightly looser line height promotes horizontal movement and helps the reader to recognize word shapes.

Look Closely, Break Rules

When we design a responsive structure, testing it on a large device is easy; we can change a desktop browser’s size quickly. But designing on a desktop or laptop browser means that we are spending most of our time at an arm’s length from the text, and we don’t spend much time seeing how the text renders on small devices.

If you’re using measure to find break points in your responsive website, then you probably care about type and reading. Keep using measure! It’s a great starting point. But to see whether your type truly works, spend some time looking at it closely, on a smaller device. Balance measure, line height and font size as needed.

Remember that all rules are meant to be broken. Heck, Jan Tschichold broke his own rule and used centered text for much of his career. When the time comes, sacrifice measure for a comfortable font size. A good font size (not too small) is readable. A good font size (not too big) promotes horizontal eye motion. A good font size with the proper line height will help your readers find what they’re looking for.

Further Resources

(il, al)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20

The post Size Matters: Balancing Line Length And Font Size In Responsive Web Design appeared first on Smashing Magazine.


Secure Login

This login is SSL protected