Skip directly to content

Smashing Magazine

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

“There Are More Bugs In Mobile Than… Particles In The Universe!”

9 hours 34 min ago

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

11 hours 30 min ago

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.

Sci-Fi, Frustrations, Flash And Forms: The Typeform Story

Fri, 09/26/2014 - 13:15

Take any new interface design or display technology, and chances are that someone somewhere has already compared it to Minority Report. The 2002 dystopian film, with its see-through screens and gesture-driven interfaces, is remembered more for its futuristic tech than for the insidiousness of the technology — pre-crime prediction — that was its actual focus. It continues to be the standard by which we judge new interfaces.

But inspiration doesn’t only come in the form of flashy, futuristic interfaces. At Typeform, we were inspired to simplify online forms by a movie that’s decidedly a blast from the past: the 1983 film WarGames, which centers around a student who remotely logs into a research computer and, through its terminal interface, nearly sparks a nuclear war. Its computers are hardly state of the art, yet the computers’ question-driven interface inspired us to reinvent forms. Instead of a list of questions, how much better would it be if forms presented one easy-to-answer question at a time?

Stripping forms down to their basics and building them back up into something better took four years of work, but that core idea guided us all along: questions are better than lists. Here’s the story of our crazy idea to reimagine how forms could work, and how we turned that idea into a product that’s helped companies of all sizes get a 55% completion rate on their forms.

Dismembering A Form

“Everything should be made as simple as possible, but no simpler.”

– attributed to Albert Einstein

You’ve filled out plenty of online forms, from the standard surveys that you get in emails to checkout forms and more. Forms have been with us since the earliest days of the Internet, and they largely look the same today as they did in the ’90s. They’re filled with lists of questions and tiny bullet points that are hard enough to fill out on a PC and are an exercise in extreme frustration on mobile.

Forms have turned into one of the most annoying things about the Internet, right along with popup ads and auto-playing audio. They’re a necessary evil — no one would say that they love filling out forms, but we all have to fill them out anyway.

Traditional online forms can be overwhelming.

Crowded with information, forms feel like the on-screen equivalent of questions being screamed at you — something you’d walk away from in real life. If your form makes people feel like they’re completing a tax return in a crowded room, chances are they’ll click away, too.

Questions themselves don’t have to be unpleasant, though. They are the foundation of small talk and are an important and even fun part of life when used in moderation. If that’s all they are, then surely we can make a better form by emulating conversation, with just one question at a time.

That’s the genius of the console in WarGames2. It asks a question, waits for an answer, then follows up with another question. Without any more logic than your average form, it feels more lifelike simply because asking one question at a time feels like a conversation. It’s not overwhelming, and yet it gets the same result as a form would.

That, we knew, had to be the future of a more human form. One question at a time, presented in a way that would make people want to respond.

To Build a More Conversational Form

Simplifying forms, though, took more than just inspiration. It took us on a four-year journey, starting with a showroom Flash application for a client in 2010. That application was built to run full-screen on large monitors at an exhibition, complete with video, animations and a way to collect information from visitors to the booth in a modern (for the time), interactive experience. A typical Web form would have been impossible to use on such a large screen and would have looked terrible alongside the other elements. We quickly saw that it was time to reinvent the form.

There’s ways to make traditional forms better3, by including more whitespace, separating forms into sections, and more. There’s standards behind the way forms look and feel, which have kept them far more similar to a paper form than something imagined just for screens. We wanted to experiment and see what a form could be like if it was removed from those linear constraints, redesigned around questions.

It wouldn’t be a traditional form, and it would even break conventions—much in the same way the iPhone’s software keyboard broke the standard real-button keyboard conventions—but the WarGames form had given us the idea that perhaps there was another way to gather info than the traditional form, and perhaps it could be better. We wanted to start out with a clean slate, and reimagine what a form could be with an entirely new product.

The design has come a long way since those early days. But the principles remain the same.

Our original solution was Quickyform, a Flash-based contact form that ran on an iMac in the exhibition space. (You can still try it out today4 to get a feel of our first shot at re-imagining online forms.) It embodied the essence of the WarGames form even as a rough early prototype. Only one question was shown in focus at a time, and once a visitor filled it out and pressed “Enter,” the next question came into focus, ready for them to enter the next answer without having to click anywhere. This, we knew, was the first step in the right direction for the future of forms.

When we built Quickyform, Flash was still prevalent online, and there was lingering hope that Apple and others would adopt it for their mobile platforms. Flash has its uses, but it had quickly become obvious that it wasn’t the best tool for our needs. We quickly shifted to the modern languages of HTML, CSS and JavaScript, and got to work designing a better UI that would work everywhere — ultimately, realizing our dream and even recreating the part of WarGames that had initially inspired us.

Click here to try the game6

Starting With The Basics

Our basic idea was to find the perfect way to display one question at a time, to reflect natural human conversation. To do that, we had to entirely declutter the UI, removing everything that might take the user’s attention away from the one question at hand. At the same time, we still wanted to retain a global view of the entire form to make it easy to navigate and see the remaining questions.

The solution wasn’t apparent at first. For example, an early version opened and closed each question as you went through them. That took care of showing only one question at a time, but the animations were too jarring and made it difficult to navigate the entire form. We took many such detours into the land of strange animations and interactions that just don’t feel natural in our quest to discover what would work best. The final simple solution of putting the active question in the center of the screen while showing the preceding and following questions faded out above and below seems obvious in retrospect but took a lot of experimenting to perfect.

Putting the active question in the center helped out other parts of our UI. It helped our large typography to make sense, which in turn freed us to make use of Web fonts. We use 24-pixel fonts on the desktop, and between 16- and 20-pixel fonts on mobile, depending on the device. Very few Web fonts work well at sizes below 16 pixels, so focusing on one question at a time enabled us to drastically improve the UI’s design.

In turn, the UI influences the UX. Large typography in our form designer forces you to shorten questions because there is less space per line. You have to make every word count in the questions you put in your form, and that precision makes the resulting questions far more likely to be answered by respondents.

Design Is How It Works

After deciding on the basics of our UI, we tackled interaction design as the next challenge. Our focus was a computer without a touchscreen, accelerometer, webcam or even a mouse. All that is needed to interact is a keyboard. After all, if you’re just answering questions, what more should you need?

Traditionally, a typical form forces you to move back and forth between the mouse and keyboard. You’ll click in a text box to type something in, and then reach for your mouse or squint to tap on your smartphone’s screen to fill in a multiple-choice question. If the form doesn’t already look bad enough, then the rows of tiny bullet points should be enough to get respondents screaming for the hills.

As dated as it might sound in the age of smartphones and tablets, we decided that keyboard navigation would be central to our redesigned forms. Users have to use a keyboard for questions that need a typed answer anyway, so we added keyboard shortcuts for all other types of questions. For “Yes” or “No” questions, you would tap “y” for yes and “n” for no. For multiple-choice questions, each answer is assigned a letter. For ratings, respondents would tap the number corresponding to their rating, from 1 to 0 (ten).

Click here to test8

Navigation between questions raised a new issue: the “Enter” key or the “Tab” key? How would these two buttons work in the context of Typeforms? At first, we allowed “Tab” and “Enter” to be used interchangeably to move to the next question, but assigning two buttons to do exactly the same thing seemed weird. So, we asked ourselves, what could we learn from what’s been done before?

In every other app or website, the “Tab” key is most commonly used to move between elements. You use it to jump between fields in a traditional form and to move between parts of a Web page. It is a non-committal way to move around. The “Enter” key, on the other hand, is most commonly used to commit to a decision. It’s the button we press to take an action or to submit a traditional form.

So, in learning from those who came before us, we decided to assign “Tab” for jumping between questions without setting off any validation checks. This way, you can move around the form without having to use the mouse. Pressing “Tab” brings the next question into view, ready to be filled out; “Shift” + “Tab,” in the same way, take you back to the previous question; and the arrow keys let you move up and down in the form as you’d expect.

Our next choice in keys was much harder to make: how to use the “Enter” key. It’s widely used in many apps to complete an action, but is also used to add a line break to text. In a form, we feel it’s far more common to need to quickly complete an action than it is to need to write multiple paragraphs of text, so we chose to use the “Enter” key to validate and submit responses. If an answer does not validate, then the user is asked to correct their answer; otherwise, they’ll move onto the next question. Then, we used the common “Shift” + “Enter” shortcut for line breaks when writing multiple paragraphs of text, the same shortcut commonly used in chat apps like Facebook Messenger.

Ideally, though, users shouldn’t have to use “Tab” or manually scroll to navigate forms at all, even though the forms show only one question at a time. That’s why we designed the forms to auto-scroll to the next question as soon as the current question is answered. Most forms require you to scroll through to see all of the questions, or even click to other pages to continue the survey. Our approach keeps respondents focused on the conversation and makes it far quicker to fill in the form.

Iterate, Iterate, Iterate

Even though Typeform’s UX and controls were in place, a lot of wiggle room was left in our UI. When we drafted the style guide for our UI, the world was shifting from skeuomorphic to flat design. We didn’t want to trap our design in a particular trend, so we embraced the best of both worlds.

Multiple-choice questions proved to be the hardest. Our original designs for them still felt like traditional forms, listing possible answers with radio buttons to their left. We wanted to keep the standard parts of forms intact, but that didn’t feel quite right — we hadn’t come this far to leave the most annoying part of forms alone.

So, we decided to turn multiple-choice answers into glass-like elements. Our first try put the standard round radio buttons on the left, albeit with translucency that made them better fit the form’s background. It looked nicer, but the original usability problem was still there because radio buttons are still relatively hard to select, especially on a touchscreen. To solve this, we expanded the size of the button, turning it into a glass panel that overlays the answer. This gives a far larger target to click or tap, perfect for mobile and desktop. We removed the radio buttons entirely because their presence automatically makes you think you’ll need to tap that smaller areas to select the option—we wanted people instead to feel free to tap anywhere on the button.

From fiddly radio buttons, to nice big touch targets.

This “glassification” brought with it another challenge: making sure that the buttons look great on a wide range of background colors. After extended experimentation, we finally landed on the solution of categorizing background colors into five levels of luminosity. We then add different CSS that adjusts the color of the button, shadows, border, highlights and a range of other factors based on the background. LESS10 turned out to be the perfect solution for getting the right balance of color every time.

Buttons react to the background they’re on.

You can see the change most obviously with the border. On a black background (#000000), the borders are a light color to offset the button. As the background gets lighter, the borders change to a darker color to give more contrast and better offset the button. We spent a lot of time getting the formula just right, and it paid off with a UI design that looks great no matter how our users want their forms to look.

See full preview13

That left us with one final UX problem: the “Next” button after a multiple-choice question. We needed a way for people to select choices — again, using the keyboard or mouse — and then easily jump to the next question with our auto-scroll. If we auto-scrolled as soon as someone had made a selection, then they’d have no chance to change their mind, but we didn’t want multiple-choice questions to have the friction they do in normal forms.

Our solution was to add an “OK” button that’s activated by pressing “Enter.” We assigned standard alphabet keys to each multiple-choice item, and we check mark an item once the user has selected it. A bit of extra text is added to questions that list multiple options, to help people understand. Once the user has made their selection, they just have to tap “Enter” to proceed to the next question.

Leave the mouse at home. Just tap or use your keyboard!

Working Everywhere

We designed Typeform’s UX to work great with just a keyboard, but then tweaked its UI to be perfect on touch screens, too. Designing it as a responsive app from the start would seem obvious, then, using media queries and breakpoints to render the same code on any screen size.

This isn’t how Typeform works, though. We experimented with delivering the same UI to a mobile device and a PC. That would work, but it created two problems:

  1. The whole form has to be rendered at the same time. This impairs performance on devices with limited RAM, especially if the form includes much multimedia content.
  2. It’s a poor use of limited screen space, with valuable room taken up by unnecessary elements.

The goal of responsive design is to deliver the same content and experience everywhere, and we still wanted that, even if using the same code wouldn’t achieve that goal for us. Our solution was to move to page- and slide-based navigation. On mobile, each question is rendered on its own, giving the form a small resource footprint and using the smaller screen more efficiently.

To do this, Typeform delivers different code to the browser depending on what device is being used. You’ll notice this if you open the same form on a PC and a smartphone. On a PC, we use the larger display to faintly show the previous and next questions. On a smartphone, we show only the current question in order not to waste any space. Respondents can easily swipe up and down on their phone to navigate questions, just as PC users would press the up and down arrows, but no space is wasted with the previews of previous and next questions. That’s one of the many tweaks we had to make in order to make our forms work perfectly on both desktop and mobile.

We then have a even simpler fallback mode15 on every form, that’s even faster to load on any device. These options were the ways we balanced between a rich web app on desktops and laptops, an equally polished mobile experience, and a faster option for lower internet speeds.

Test Everything

Typeform is a direct result of our own testing and tweaking of the idea that blossomed from WarGames’ inspiration and our client project in 2010, but we had very little user feedback in the beginning. It was just a side project, worked on in spare moments here and there. Decisions were based on intuition and hunches, and we had no idea what the lean methodology even was.

What we did know is that we had stumbled upon an entirely new way of interacting with online forms, not just an evolution of the interfaces that we’re all used to. If we had asked people what they wanted, we would have designed a normal form builder. Like Henry Ford, we needed to show people what they want. We had to invent the future—to discover the story hidden on the blank page, or uncover Michelangelo’s David in a block of marble as Ed Catmull describes the creative process of inventing the new in “Creativity, Inc.”

So, rather than rapidly release features in the wild and iterate based on feedback from our users, as lean methodology would dictate, we worked with our own controlled test group to find what was and wasn’t working before releasing it. If we had launched a public beta earlier, perhaps we would have thrown out the closing and opening animation between questions earlier on. But then we would have missed the subsequent iterations that guided us to our current solution of fading out the preceding and following questions. By iterating and working on intuition and experience, we were able to greatly improve an experience that might have been thrown out if we had asked users.

This isn’t to say that the lean methodology is bad or that it wouldn’t work for us now, but it couldn’t have worked for testing our initial concepts and finding our ground. Only when we had almost finished building the app and opened our beta program did we start getting a lot of feedback from our user base. The app was finished enough that people understood our vision and were able to help us find the rough edges that needed fixing. Feedback is important, but make sure that your vision is defined and apparent in your app before inviting the opinions of others; otherwise, you might miss the stages in the development of an app when you learn the most.

Never Stand Still

We turned our vision of a new type of form into a product, but we’re not done working. Breaking down forms into their basics opens up a lot of opportunities, because you can do so much with a format that asks one question at a time. We’ve finally realized our dream of recreating WarGames’ terminal in a form that captures the simplicity of the original, and we have found a ton of uses16 for Typeforms that go far beyond the traditional form. What other format would let you make anything from a Stripe-powered purchase form to an interactive storybook17?

Typeform’s simplicity gives us a platform on which to build and do more with the basic elements of a form. Designers can focus on things that make each question better and perhaps more visual and interactive, while still ensuring that all of the questions work together as a form. It’s already ready for large high-resolution screens and can just as easily be scaled down to a watch screen or whatever new displays the future will bring us.

Our core technology platform isn’t standing still, either. Typeform’s current technology stack consists of Symfony 218 and PHP that loads data from Redis19 and MySQL databases on the back end, and CoffeeScript20 and Backbone.js21 on the front end, all running on Amazon’s AWS platform. If that’s not enough, we’re currently refactoring parts of the application, using Node.js22 and NoSQL databases to improve performance and make it easier to implement new features.

More Human Forms Work

What will stay the same are modern, question-driven forms. We’re not the only ones on this journey of exploring how a redesigned form could work. Stripe has redesigned its checkout forms23 to be as simple as possible, asking just for the user’s email address, credit-card number, expiration date and CSV number, in a sleek form that would hardly intimidate anyone. PageLanes24 uses a question-driven form to collect contact information, and CoDrops25 was inspired by that to make a basic CSS- and Javascript-powered question-driven toolkit that you can use to design your own forms.

A typeform in its native habitat, ready to be filled in.

Question-driven forms get results. Quartz’s team recently got 940 C-level executives to respond to its executive study26. Its careful wording got Quartz a 34% open rate, and over 55% of those who opened its interactive survey (powered by Typeform, incidentally) actually finished it. That number is consistent with the average response rate we see from all of the more than 9 million unique Typeform form visits we’ve seen so far. Those results and the new unique ways you can use forms with Typeform—along with the results those forms bring—have been enough to get industry leaders from Adobe, Uber, MailChimp and more to use our forms to get results. That’s an exciting confirmation of what we’ve believed all along: People will want to fill out forms if the forms are driven by questions and simple enough to answer.

We’ve destroyed the traditional form — literally, in a joke game27 that we made recently — but much more can be done with forms. That’s what keeps us working on Typeform and what makes us excited to see new developments from others. But forms aren’t the only part of the web that could use some new design ideas. All it takes is breaking things down to their basics, figuring out what’s really important, and then building back up around that. If that approach can change forms this much, imagine how much it could change the things you’re working on.

You may have to break some conventions, and your final product might be fully new instead of just an updated version of the old—the app version of the motor vehicle versus the old horse-and-carriage. It might not even work. But you’ll be sure to discover something new and exciting along the way, something that just might let you make a better product.

(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

The post Sci-Fi, Frustrations, Flash And Forms: The Typeform Story appeared first on Smashing Magazine.

The Ultimate Guide To Choosing A WordPress Host

Thu, 09/25/2014 - 13:13

These days you have an awful lot of options for hosting your website, so many that it’s easy to get lost. How much should you pay? Is support important to you, or are you a tinkerer who likes to do your own thing?

Put in different terms, are you a master chef who can cook a delicious meal with the right assortment of ingredients, or would you rather go to a nice restaurant and just sit back and enjoy the experience?

Let’s dive in.

An Overview Of Hosting Categories

A couple of years ago, choosing a hosting company was a lot simpler. Shared hosting providers had relatively low prices (between $5 and $15 a month), while other companies rented out dedicated servers from $500 a month up to as much as tens of thousands of dollars a month. If you knew your budget, then the decision was easy. Today, not so much.

At the entry level, we still have shared hosting providers and managed hosting services, which are still technically “shared” but which add a lot of value and specialization. We have virtual private servers (VPS), nowadays usually called “cloud servers”. They differentiate themselves based on the virtualization technology that they use and how much computational power and memory are included in their packages.

Finally, we have the option to rent a dedicated server — also known as co-location, whereby you place your own box in a data center. This hasn’t really changed that much, except that data centers have become a lot more sophisticated and computers have become smarter than they were three to five years ago.

(See large version2)

Page Speed Matters. A Lot.

Before your head spins with hosting jargon, let’s talk a bit about page speed. Back in 2010, Google stated that the loading time of your website would factor into your ranking. So, if you care about search engine optimization and free traffic from Google, then you should care about your website’s performance.

Forrester Consulting found3 that about 47% of Internet users expect a website to load in under 2 seconds. Aberdeen Group has data4 that shows that a 1-second delay in page-loading time can result in a 7% loss in conversions. All of these studies were conducted a couple of years ago, and since then the web has only sped up! Or has it?

Look at your website’s loading speed with a tool such as Pingdom5 or WebPagetest6. If it’s above 2 seconds, then you could get a massive increase in revenue just by switching to a better performing hosting package or maybe even switching hosting companies altogether.

How big of an increase? Tagman has the answer7: “Let’s say a website’s average ticket size is $75 and conversion rate is 5%. So if it takes their pages an additional second to load then for every 400,000 unique visits each month, there would be a loss of $1.3m in revenue per year.” As you can see, performance affects the bottom line in a huge way.

Don’t forget, though, that a good hosting service will help your website only so much. If your WordPress installation has dozens of plugins activated or if your theme is bloated or poorly written, then you could have serious performance issues no matter where you’re hosted.

Let’s dissect the different types of hosting solutions, then.

1. Shared Hosting

If you’ve ever had a website, then you’ve come across shared hosting providers, which offer packages from as low as $1.99. They are considered the “public transportation” of the hosting world: extremely low fees, yet little flexibility and a lot of overcrowding. As soon as your website grows, you can expect a lot of problems, such as bandwidth limiting and slow response times. Slow response times happen because the only way that hosting companies can offer packages for such a low price is by putting a lot of websites on the same server.

For example, if a hosting provider puts you on a computer that costs them $400 to run every month, then they would need 200 clients on that machine just to break even. And to get the maximum profit out of each server, they would need to add hundreds upon hundreds of clients to it, overloading the otherwise good configuration.

Think of the difference between a dedicated server that an online business doesn’t share with anyone, thus ensuring the highest possible performance, and a machine that has a couple hundred websites on it.

Shared hosting providers are often overloaded with support questions as well. Hours, if not days, can pass before you receive an answer to your question, and most of the time the answer won’t be of any help because the provider does not employ WordPress specialists. Most hosts provide only basic support, at the level of the operating system. On top of that, you are literally just one out of thousands of customers — per server!

However, there are advantages — the rock-bottom price obviously being one of them. If you’re starting a business, this is a very cost-effective solution. In addition, you can run all kinds of scripts on these accounts; you’re not limited to WordPress. You can use the space to test different projects. And if your website gets low traffic (a couple of hundred visitors per month), then you can host it very affordably and not have to worry about system administration or anything else.

Who Is This For?

If your revenue doesn’t depend much on your website or if you have a hobby blog, then an affordable shared hosting package is a good choice.

Several well-known examples are GoDaddy8, Bluehost9, HostGator10, DreamHost11 and NameCheap12, among many others.

2. Managed Hosting

In the past, managed hosting meant one thing: hardware and operating system management for separate boxes (either virtual or “bare metal”). You would hire an expert or team of experts to look after your server, and they would install an operating system on it, install security patches, change the hard drives when they break and perform other tasks. We’ll discuss this in detail later.

Relative newcomers to the hosting scene are application-level managed hosts. Companies that specialize in hosting one or another application are popping up almost every day. WordPress is one such application — and no wonder: WordPress has become the go-to content management system (and, lately, the go-to web application platform) for many people.

This hosting category is similar to shared hosting, but you could think of it as a new generation of shared hosting. It’s like a local grocery store that specializes in few but high-quality products, one that knows you by name and that is unlike those huge everything-for-cheap supermarkets.

Instead of allowing (and supporting) all kinds of scripts, these companies build their infrastructure around one — usually open-source — product. These companies know their product very well, they have fine-tuned their machines and operating systems for it, and they have a dedicated support team that knows the ins and outs of it.

Considering that roughly 23%13 of all websites online today run on WordPress, you can imagine that there is a lot of demand for hosting services custom-tailored to WordPress and only WordPress.

Managed WordPress hosts deal with all of the back-end tasks of running a WordPress blog so that you don’t have to. This frees you to focus on what truly matters: selling your product to customers. Beyond hosting your website, the providers also offer WordPress-specific experience that will help you optimize your web presence in many ways: speed, security, uptime, core and plugin updates, and theme and plugin compatibility.

Although this solution is more expensive than shared hosting — prices start at around $10 and go up to as much as $3,000 per domain — the benefits are usually worth it, even for relatively small websites. Many of the features — including customizable backup options, one-click staging areas, integrated CDN support and much more — cannot be found in packages anywhere else. Let’s look at some of the most common benefits of managed WordPress hosting.


Support is not limited to basic problems with your hosting account. These hosts provide advice on WordPress plugins, themes, settings, updates and so on. Many of their employees are active contributors to WordPress’ core or have published plugins and themes for WordPress. They know the ins and outs!


Fine-tuning your hosting environment (both software and hardware) will make your WordPress website or application as optimized as it can be, thus making it quick to load and to respond. Security is another important aspect, and that’s where the word “managed” comes in. Managed hosts keep your WordPress instances up to date for you. They also keep an eye out for malicious plugins and themes, and they work with you to prevent hacks of your website through known security holes.

If you have to optimize the environment of just one open-source package, then hardening the server and securing the system become a lot easier. At the level of the operating system, administrators don’t have to install a hundred different packages in order to enable customers to run Magento, Joomla, Dolphin, WordPress and many other platforms at the same time! Having fewer packages frees up a lot of resources for other important processes, and the system will naturally have many fewer entry points for malicious attacks.

Speaking of entry points, did you know that WordPress’ core is extremely safe? The biggest vulnerability occurs when someone is running a version of WordPress that is out of date by several years. Too many people simply do not update their core files, despite it truly being a one-click affair. Managed hosting providers make sure that core files are always up to date, and they’ll even update for you if needed!


Most of the time, managed WordPress hosts have their own caching system that is custom built for WordPress and that is a lot faster than any plugin-based ones! That’s why most don’t allow plugins such as W3 Total Cache and WP Super Cache. If you’ve had trouble setting up either of those in the past, then you’ll be thankful for this. Not having to worry about any of the technical mumbo jumbo is a blessing when you have a business to run!

Caching can be done in many different ways. First, there is object caching, which is accomplished by running Memcached or, lately, a Redis-based in-memory datastore service and a WordPress plugin counterpart. You would have to activate this for your website (or the host would do it for you). This will take a load off the database and the PHP interpreter, thus speeding up your website a lot.

In addition, modern configurations take advantage of the so-called reverse proxy wherever possible. This could be the immensely popular Varnish or something like the built-in FastCGI Cache of the Nginx web server. These essentially take a snapshot of your website, saving a full copy of the final WordPress-generated HTML pages. By default, these usually break dynamic parts of the page, such as the “Hey, Joe” part of the navigation bar once the user is logged in, the “Latest comments” section, and the shopping cart.

But with a good amount of tweaking, you can get the configuration right. And the speed is unbeatable. Instead of at least three software modules working on each request from each visitor (those modules being the PHP interpreter, the MySQL database server and the web server’s software itself), you can have only one: the reverse proxy. Less computation means much faster page-loading times!

These cannot be used on general shared hosting accounts because there’s no way that a hosting provider could write a configuration for all of the open-source PHP scripts out there! This is where dedicated hosts excel: creating configurations that work extremely well for WordPress and only WordPress.


Regularly backing up your website might not seem important, until your server’s hard drive gives up and your data is not recoverable! Or perhaps your website will get infected so badly that restoring it from a clean backup point would be easier than manually cleaning up everything.

Managed WordPress hosts back up your website regularly (usually daily). So, if the worst happens, you’re covered. Be sure to read the fine print, though. Some companies do not back up the wp-content or uploads folders, in which case you could lose all of your images, which would make the backup not worth much!

The disadvantages of managed hosts are the heftier prices and the lack of support for any other web applications. WPEngine, for example, lets you run other PHP scripts on its servers, but it doesn’t support them in any way. Other companies actively discourage customers from running anything else on their machines, meaning that customers would have to get an account with a general hosting provider to run something alongside their WordPress installation. These hosts dedicate their entire infrastructure to WordPress on the assumption that you can do almost anything with WordPress nowadays, including complete forum systems, complex CRM solutions, social networking websites, and crowdfunding marketplaces — the list is long.

Who Is This For?

Managed hosts are good for people who run their business on WordPress. These hosts deliver great performance, fine-tuned servers, a lot of exclusive services custom tailored to WordPress users, and affordable prices.

Given how important your online business is, a managed hosting account for $30 a month is probably a great deal, especially if you take into account the extra income that an optimized environment will bring in.

Some companies that offer WordPress-specific hosting are Kinsta14WPEngine15Synthesis16, Flywheel17 and Pagely18.

3. Virtual Private Servers

If you know your way around Unix-based operating systems, then you might want to look into building a custom stack on a VPS or a bare-metal dedicated server. Digital Ocean’s price for an entry-level virtual server, which can serve a couple of low-traffic websites, is only $5 a month. You can also get a free node with Amazon AWS, with specifications similar to those of Digital Ocean’s droplet. As cloud computing has become more and more popular, these virtualized servers have become popular, too. For a fraction of the cost of a dedicated server, you can get your own (virtual) machine, and tune it to your exact needs.

The downside is that you usually don’t get any support, and you will have to do several things yourself: keep an eye on system components, install web and database server software, keep everything updated and, of course, configure all of the applications in a (mostly) Linux-based environment. There is also the “bad neighbor” problem: Because hardware resources are shared between many virtual machine users, poor performance is possible if someone else is overusing the resources of the machine that your account is located on.

VPS’ have different tiers, based on the service level, from absolutely no support to fully managed. A fully managed VPS will usually install all of the required software, keep it (and the operating system) updated and proactively monitor the server to minimize downtime. Obviously, the monthly price goes up with your requirements.

Who Is This For?

All in all, VPS is a cheap way to get as much flexibility as you need, with the option to deploy popular software packages (including WordPress) in one click. Don’t forget, though, that you will need to be very familiar with installing Linux via the command line in order to run a VPS and resolve problems.

Notable VPS players are Linode19, Digital Ocean20, Amazon AWS21, Microsoft Azure22 and Google Cloud23.

4. Dedicated “Bare Metal” Servers

Having your own dedicated server is almost the same as a VPS, but instead of sharing a massive pool of hardware resources with others via virtualization, you get to use “all the metal” of the computer for your website only. Prices usually start at $100 a month, but the sky is the limit. Packages for thousands of dollars a month are not rare either, although those machines serve really large applications that draw millions of visitors each month or that require unusually high computational power.

The downside (other than the price tag) is that you have to deal with occasional hardware failures. This is different from the other categories we’ve looked at because if, for example, a hard drive fails and you don’t have another one mirrored, then you’ll face hours (perhaps even days) of downtime. If you don’t have any backups whatsoever, then you’re out of luck completely. A faulty CPU or RAM unit can cause serious headaches, too!

Who Is This For?

A dedicated server is definitely not for everyday website owners. This is getting into the enterprise end of hosting solutions. However, if you prefer to drive a Ferrari just because you can, then this is the one to get.


As promised in the introduction, you have quite a lot of options to choose from! Hopefully, having read this article, you now have a clearer picture of the different packages available, and you will be able to make a decision based on your website, requirements and budget!

Did I leave out something important? I’d love to hear your thoughts.

(dp, 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

The post The Ultimate Guide To Choosing A WordPress Host appeared first on Smashing Magazine.

Applying Participatory Design To Mobile Testing

Wed, 09/24/2014 - 09:00

People use their mobile devices everywhere: on the train, while waiting in line, sitting on the couch. As much as we aim to design our mobile apps and websites for contextual use, testing their usability in context can be challenging.

While getting out in the field for user testing is not always realistic, simulating much of that contextual experience in a lab is possible. One approach to mobile testing is participatory design.

A participatory design test session typically takes about an hour and has four parts:

  1. Uncover the user’s mental model.
  2. Enable the user to document their entire experience.
  3. Have the user sketch their ideal experience.
  4. Ask for the user’s feedback on designs from previous sessions.

I’ve conducted this type of study while researching how visitors to’s app use their mobile device while purchasing a car on a dealer’s lot. The artifacts from this study are included in the steps below.

1. Immersed And Aware

A usability test typically starts with warm-up questions. A participatory design session is no different, although the questions are a lot more in-depth. This portion is meant to uncover the participants’ actual usage of your app or website and any pain points they experience.

The goal is to bring awareness to the participant and to put them in the context of how they would be using the product. Start broadly and then narrow the focus. You might want to break down questions into the following categories:

  • When do they use the app or website? Is it when a need arises? Is it based on timing?
  • Where are they typically during the usage? Is it location-based?
  • How long do they use the product in one session?
  • What tasks do they usually accomplish in one session?
  • How satisfied are they overall with their interaction with the product, and how would they rate the product and how well it enables them to accomplish what they need?

For example, we first asked participants general questions about the duration of their car search and about other cars they’ve test-driven. We then focused on their visit to the dealership to purchase a car. They were asked to assess their satisfaction with the process, as well as their mobile usage. The purpose of the interview here is to place the participant in the right mental context. It also helps the moderator to create awareness of the steps that follow.

2. Document And Express

Once the stage is set and the participant is immersed in the context, the next step is to chart a timeline of their entire journey with the product. This exercise is particularly helpful if it encompasses not just when the participant used the app or website, but the actual goal they were trying to accomplish when using this product as a tool. For example, if the goal was to book a flight on an app, then the timeline would begin with the need to book a flight and would end with the completed transaction.

Here are the items you might need for this portion of the session:

  • a timeline drawn on paper and marked with a beginning and an end,
  • a pen,
  • stickers in two or more colors.

Draw boundaries on the timeline to mark the beginning and end for the user. In the car shopping study, the timeline initially looked like this:

The timeline given to participants in the car shopping study.

Participants then filled in the steps. This process enabled us to see patterns across all dealership visits, and it triggered the participants’ recollection of details that might have been forgotten with oral recounting.

Once the user has drawn out the timeline, use colored stickers to overlay emotions. The simplest approach is to use two colors, one for negative emotions and one for positive. However, you could get more granular and have participants indicate particular emotions. This enables them to indicate any frustration they felt during the process and at what point the app fell short of solving their problems. Capturing emotion in this way gives you a quantitative measure of a qualitative aspect of the user’s interaction with your product.

After multiple sessions, place the participants’ timelines side by side. The patterns that emerge will tell a story of how people are using the product, where their pain points are and what’s working well. To synthesize the results, create an aggregate timeline based on the number of responses and the frequency of repeated emotions.

Here is the aggregate timeline from the car shopping study:

Aggregate timeline from car shopping study.

All users followed a similar progression from the time they entered the dealership to the time they drove off the lot in their new car. They also felt similar frustrations during the negotiating and financing phases. The third color in the timeline, yellow, indicates their mobile usage on the car lot. This was helpful because the exercise shows not only when they used their phone as an aid to buying a car, but also when they would have liked to have used their phone to relieve a frustration. Such an exercise is also useful in planning future features.

3. Create Aspiration

After the timeline exercise, the participant is as in-context as they’re going to be in a lab. They have now recalled not only what they did, but how they felt while doing it. Now, have them create a design or feature that they would have liked to have had to solve the problems that arose in either part 1 or 2.

For this portion, have the following items on hand:

  • blank sheet of paper with a phone outline;
  • writing and drawing utensils;
  • cutouts of certain features you’re considering (even if they’re just portions of wireframes);
  • stencils, such as form buttons and icons;
  • tape and scissors.

This exercise is great for discovering new approaches to a design or new features. As with the timeline, draw boundaries. By cutting out certain features, stencils or shapes, you are giving the participant a starting point. The design at the end of this portion could be a mixture of features that are hand-drawn and taped onto the page.

If the participant has trouble getting started, revisit the timeline from part 2 and have them list a set of features they would have liked to have had. Use this list as a springboard to focus on one feature in particular. If the participant still hesitates to sketch anything, have them work with materials you provide. Using the cutouts of possible features, they can prioritize which features they’d like by taping them to the blank sheet of paper with a phone outline. An alternative is to have them simply write a list. In the car shopping study, several participants who had trouble getting started were prompted to write a list of features they would have liked and then to rank that list in order of priority or interest.

Synthesize the output from this exercise in the same way you did for the timeline in part 2. If most participants used stencils or cutouts to depict possible features, place them side by side to pick out patterns.

Here is what the synthesis of the cutouts looked like after the car shopping study:

Synthesized results from participatory design session. 4. Provide Feedback

This last step is a good way to wrap up the session. If you are already considering certain designs, have participants provide feedback on them. By this step, the participant will have essentially become your co-designer. You could also show them designs from previous sessions to get an unbiased perspective. In the car shopping study, we sought the opinions of participants on various designs we were considering. We also asked what they thought of various aspects of the test, so that we could refine our methodology.


When we design new features, we usually get our information in one of two ways. One common way is to fall back on broad assumptions about our users or to rely heavily on large-scale research. The other way is to design a feature and then test it in a very specific setting. Participatory design bridges the gap between the two ways, and it provides context that’s typically absent in a usability lab. This approach accomplishes several things:

  • It enables us to uncover the user’s mental model.
  • It establishes how the user would interact with the feature in context.
  • It gives the user an opportunity to provide feedback on what features would be useful to them.
  • It allows participants to flex their creative muscles and to be a co-designer on a product they’ve used before.
  • And it gives you a fresh point of view.

(al, ml)

The post Applying Participatory Design To Mobile Testing appeared first on Smashing Magazine.

Designing A Rocket Icon In Adobe Fireworks

Tue, 09/23/2014 - 09:00

Many people know that Fireworks is a great tool for web design1, prototyping2 and UI design3. But what about icon design? Icon design is a very specific skill that overlaps illustration, screen design and, of course, visual design. An icon designer needs to understand lighting, proportions and, most importantly, the context of the icon itself.

The BBC published an interesting article about icon design and skeuomorphism4 one year ago, titled “What Is Skeuomorphism?5” It’s definitely worth reading because it explains why icons often reflect the real world and the thinking behind it.

Another pretty interesting read is “What We Can Learn From Early Icon Design?6” It is a quick retrospective of icon design and mentions, among other things, one of the most famous icon designers ever, Susan Kare7.

I remember reading an article a few years ago that definitely influenced my career as a designer. Some points in the article were obvious, but they made me think about icons in a different way. Sometimes, the best way to learn is from mistakes you make or from mistakes that people more experienced than you have made. “10 Mistakes in Icon Design8” is a good read and a useful resource for anyone who wants to learn more about icons and icon design. It is relatively old, dating back to 2008, but some of the examples are still pretty sound. The article stresses the importance of consistency in an icon set and how composition works (i.e. how many elements to use in an icon), and it gives important tips on dealing with metaphors, with practical examples. This is key in our job.

Is the icon you are designing going to be used on the web? Perhaps in a mobile app? In a toolbar? Somewhere else? These are the questions that icon designers must asks themselves before starting work on a project. The answer will affect the icon’s details, reflections, shadows, background and many other features.

1. Fireworks And Icon Design Why Fireworks?

I have been using Fireworks now for nine long years, creating work that ranges from web design to complex UI design and, in the last few years, icon design as well. Fireworks has proved to be excellent software for all of these tasks because it combines powerful vector and bitmap editing tools.

I am not going to revisit the long-running debate9 about what is the best tool for UI design (which usually comes down to Photoshop and Fireworks). Above all, I am not a Fireworks evangelist. Ideas matter most — the choice of tool is up to the designer. Nevertheless, I’ve noticed that many people underestimate the power of Fireworks, dismissing it as second-tier software. Having a vast amount of experience with both Photoshop and Fireworks, I can only respond that, for speed and pixel-perfection, Fireworks is faster for screen design. It’s precise, easy to use and straightforward. That’s why I have picked it as the main tool in this step-by-step tutorial on icon design.

A Word About Icon Design

My dissertation back in university was on symbols, icons and pictograms. This subject was one of my favorites back then (and still is). What utterly fascinated me was that you could convey a message with an icon or symbol. Words aren’t needed for an icon to be understood by the majority of cultures in the world (at least, if the icon is relevant). Designing for the future means exactly that. I’ve always found the idea of a memorable metaphor to be interesting. Designing icons requires a lot of planning and thinking: As in drawing and illustration, the designer is responsible for choosing elements that will make the metaphor more or less relevant. Good icons turn different aspects of culture into something comprehensible in many cultures and countries.

One of the most successful icon metaphors in modern history is the desktop10, used in operating systems, where the desktop is treated like a place to hold documents, folders, archives, pictures and files. (We’ll talk about icon design in detail in the following paragraphs. If you like the topic, you’ll find some useful links in the “Further Reading” section at the bottom of this article.)

Note: In this tutorial, we will explore some general principles that relate more to skeuomorphic design than to flat design (light, shadow, size and proportion, etc.). I will also cover some general techniques that I follow in icon design. So, by all means, pick up your favorite tool to follow along, whether it’s Illustrator, Sketch or Photoshop. I’ll be using Fireworks to show its core potential and to draw parallels with other vector tools. (This is my first tutorial for Smashing Magazine. I plan to write a couple of more articles that explore icon design and the features of two other popular tools, Illustrator11 and Sketch12.)

Files for This Tutorial

To follow this tutorial fully, download the icon we will be designing:

This layered Fireworks PNG file will help you follow the process step by step. The file is meant for reference. I encourage you to replicate the steps in a new file, with a blank canvas. Have fun!


Let’s get started!

All Vector? Yes!

We won’t be using any raster (i.e. bitmap) images. Everything will be created with vector shapes and live filters. This means you will be able to easily adapt the final image to different sizes and resolutions.

Fireworks supports screen illustrations of up to 6000 × 6000 pixels (actually, even up to 10,000 × 10,00015), which is more than enough for the super-large HD displays of today’s mobile and desktop devices. And it also exports files to SVG16 format (with the help of a free extension17 that was covered in a recent article18 on Smashing Magazine). Using SVG as an exporting format gives you a lot of flexibility. You can use the resulting image right on the web or edit it further with pretty high fidelity in many other graphic design tools, including Adobe Illustrator CS6 and CC.

Scale your vector illustrations in Fireworks to any size, while maintaining quality and detail.

  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 Designing A Rocket Icon In Adobe Fireworks appeared first on Smashing Magazine.

Design Principles: Connecting And Separating Elements Through Contrast And Similarity

Mon, 09/22/2014 - 13:04

Similarity and contrast, connection and separation, grouped and ungrouped are all ways to describe the varying sameness and difference between elements. Based on the information they carry, we’ll want some elements to look similar, to indicate that they are related in some way. We’ll also want to show that some elements are different and belong to different groups.

Key to showing both is the visual characteristics of elements and their relationships. If two elements are related in some way, then they should show similar visual characteristics. If the elements are different, then they should look different.

Note: This is the third post in a series on design principles. You’ll find the first two posts here:

Primitive Features

How do you show contrast and similarity between elements? The answer lies in the primitive features of the elements.

Primitive features3 are the intrinsic characteristics or attributes that an element might have. For example, what color is the element? How big is it? What shape is it?

These elements have different primitive features — in this case, of shape, color and texture.

Each of these things communicates something about the element. If one heading is bigger than another, then we assume the bigger heading is more important. We might view an element with a shape that’s jagged and sharp as being dangerous.

Sometimes, an element’s attributes need to be compared to the same attributes of another element in order to have meaning. The headings from the previous paragraph are a good example. A heading should only be bigger than another heading or another piece of text. The comparison is necessary for bigger to mean anything. It’s through comparisons like these that we communicate similarity and contrast.

By giving visually similar characteristics to multiple elements, we communicate that something is similar about the elements. If two elements on a web page are both red circles, it’s natural for a viewer to ask why. Why are both red? Why are both circles? The likely conclusion is that the elements are related in some way beyond how they look. The elements’ similarity implies that they carry a similar message.

Likewise, by applying visually different characteristics to multiple elements, we communicate that something is different about the elements and the messages they carry.

Any characteristic of an element4 that can be varied can be used to make elements look the same or different. A few characteristics, however, are most often used to show similarity and contrast. In no particular order, these are:

  • size,
  • shape,
  • color,
  • value,
  • texture,
  • position,
  • orientation.

A rectangle and a circle contrast in shape. Two red items are similar in color. A red rectangle and a red circle contrast in shape and show similarity in color. How you balance the similarity and contrast of elements through their visual characteristics will determine much about what those elements communicate to the viewer.

Note: While primitive features are the primary way to visually show contrast and similarity, we have other ways to show both — for example, the actual content that the elements carry. The words “stop” and “go” contrast. The words “stop” and “cease” are similar. Images contrast with text; long paragraphs contrast with short paragraphs; and so on.


Human beings are wired to notice difference. It’s a survival mechanism to quickly differentiate a friend from something that wants to eat us. Being able to quickly determine that was vital to returning safely home to the cave at night.

Our ability to quickly notice differences is what makes contrast so powerful. Contrast attracts attention. It draws the eye. It gets noticed. By giving an element characteristics that are visually different from the elements that immediately surround it, we can create points of interest and emphasis. In fact, because the contrast of an element with its surroundings is so good at drawing attention to the element, it’s perhaps the most effective way to add interest and excitement to a design.

Contrast does more than attract attention. It establishes boundaries between elements, too. For example, contrasting the background color of the main content and that of a sidebar is one way to show where one ends and the other begins.

Differences that stand out can provide emphasis5, highlighting important elements and information. The greater the difference, the greater the contrast will be. The greater the contrast, the more important the element will appear.

For example, two ways to set off text are bolding and italicizing. Boldness typically shows more contrast and, thus, stands out more. Spotting bold text at a glance or from a distance is easier than spotting italicized text.

If two elements are meant to be different, go big with the contrast. You don’t want viewers to wonder whether the difference is intentional. Make sure the contrast is obvious and clearly intentional. Leave no room for misunderstanding. Don’t contrast text that’s 16 pixels with text that’s 15 pixels. People won’t notice the difference immediately and, once they do, it will appear to be more of a mistake than a conscious decision.

Be careful not to overdo it. Use contrast sparingly.6 If everything contrasts and tries to draw attention to itself, then nothing will stand out. You’ll end up with visual noise that causes confusion.

Too much contrast can break the harmony and unity in a design, leading to chaos and confusion. This might be what you’re after in a certain design, but more often than not it isn’t. Decide which few elements need to stand out, and make them look very different from everything else.

Contrast and Gestalt

While every gestalt principle is about showing similarity and contrast in some way, I want to point out two of them. Contrast is critical to determining the figure-ground relationship and showing dominance and focal points7.

  • Figure-ground
    One of the first things we do when viewing a composition is to determine what’s the figure and what’s the background8. This relationship helps to set context for everything else in the composition. Figure and ground need to contrast with each other or else the viewer will have difficulty determining which is which.
  • Focal points
    These are elements of attraction and interest. They’re designed to look different from their immediate surroundings. The contrast is what helps them stand out and draw attention. The element that stands out the most in the composition is the dominant element. Elements that stand out in a composition but to a lesser degree are focal points.

Contrast and similarity at work: The green circles and orange bars are similar to other green circles and orange bars, but they contrast with each other.


The same survival mechanism that enables us to quickly see difference also helps us to see when things are the same. It points us to who or what we can trust and to what might be dangerous. Being able to recognize similarity is why human beings are excellent at finding patterns9. Patterns help us understand the world around us, provide context and make learning quicker, to the point of something becoming intuition or instinct.

When we design two or more elements to look similar, we are indicating that what’s true about one is true about the other. If one of the elements is important, then the other one is likely important, too. If one element is clickable, then other elements that are visually similar will probably be clickable, too. It’s how we can quickly recognize links in a block of text. Visual contrast shows that links are different from the rest of the text, while the visual similarity among links tells us, once we’ve discovered what one does, that all of the links are clickable.

Similarity is about showing connection and showing that multiple items are related in some way. It brings familiarity and consistency to a design.

Similarity complements our natural strategies for processing information10. When we take in our visual surroundings and attempt to make sense of it all, we naturally group objects into chunks in order to hold more information in our working memory. We further group, organize and structure everything before it becomes part of our long-term memory.

Designing similar information to be visually similar helps the user to process and comprehend the information, which are two critical goals of design.

The more that primitive features of elements look the same, the more similar they’ll look and the more viewers will think they’re the same. They’ll appear grouped and related11 in some way, even if just one characteristic is shared; and the more they look the same visually, the more they’ll be perceived as being the same.

We use similarity to build structure12 and pattern. Any similarity between two elements in a composition implies a structure. Additional similarity fills out the structure and leads to pattern, texture and rhythm.

Not all signals that show similarity are equal. In the image below, would you group the objects by shape or color? Do you see a group of circles and one of squares, or do you see one red group and one blue group?

You probably noticed color first, grouping the elements as red and blue. This suggests that color is a stronger communicator of similarity than shape. This is not absolute, however. For example, someone with red-green color blindness wouldn’t likely notice the difference between red and green objects before noticing the shapes of those objects.

Similarity and Gestalt

Again, every gestalt principle13 is about how we perceive the similarity or difference between objects. Many of them can be read as tips to show similarity.

  • closure
    different elements that may be part of a similar whole
  • symmetry and order
    mirrored elements that appear to belong together
  • uniform connectedness
    similarity through visually connecting elements
  • common regions
    similar items enclosed together
  • proximity
    similarity through enclosures in space
  • continuation
    similarity through rhythms in space
  • common fate
    similarity through movement
  • parallelism
    similarity through orientation
The Relationship Between Similarity And Contrast

Contrast and similarity show the relationships between elements. Nothing has meaning in isolation.14 An element needs to be shown in context with other elements.

What does one large element cornering a smaller element in a design imply? What does one block of text being indented more than others with light gray suggest?

A large circle cornering a small circle

Contrast and similarity are really just opposite ends of a scale. On one end of the scale, objects look entirely different; on the other end, they look exactly the same.

Most of the time, we’re somewhere in between the extremes, and the things we design will share some but not all characteristics. Similarity and contrast are expressions of where along the scale objects lie relative to each other.

Even though I haven’t been explicit about it, everything I’ve said about either similarity or contrast applies to the other. Having one is impossible without also having the other. Contrast is a lack of similarity, and similarity is a lack of contrast. It’s all about where it lies on the scale.

Thinking about them together makes them more impactful. You can use a single feature, such as color, to show that several elements are related, and then use a different color to show that several other elements are related but different from the first group. With just two colors, we can create two distinct groups of connected elements.

Color coding15 in this way is an effective way to categorize information so that the viewer can discover and understand at a glance.

When everything is the same, you get tedium. When everything is different, you get noise. The best designs have a healthy mix of similarity and contrast and show a clear understanding of what they’re trying to communicate.

Examples Of Contrast And Similarity

Contrast and similarity can be found on every website. Both need to be present. Imagine a website having no contrast. We’d all have a hard time reading text if it and the background were the same color. Just as difficult would be each word or phrase having a different style.

I’ll point out some of the contrast and similarity on the websites below. There’s more of each than what I’ll mention. I want to offer enough examples to get you thinking and then let you take over. Look at and study different designs, and work at truly improving your skill in balancing contrast and similarity.

David Simon

One of the first things you’ll notice on David Simon’s website16 is the contrast between background colors, which makes it easy to distinguish one part of the page from another. The logo stands out as a dark object against a light background of space.


The image contrasts with everything to draw the eye. The background of the posts’ dates, the full uppercase used for the meta data for comments, and the background color of the menu item for the current page are also examples of contrast drawing the eye and communicating something meaningful.

Links in the menu are all styled the same, as are the links to recent posts. Both are separated with horizontal lines. Each menu contrasts with the other to signal difference. Fonts are consistent throughout. The headings and body text contrast in typeface, but their difference is consistent across the website.

Links in the body could stand out more to make clear they’re links, although the designer might have deliberately made them less obvious in order not to interrupt the flow of reading. Headings could also have been made to stand out better, although it is pretty clear that they are not a part of the main text.

Mike Kus

The home page of Mike Kus’ website18 focuses on different projects that Mike’s worked on. Most of the page is empty, but notice how that makes each element stand out. The text contrasts with the background, as do the paintings against the background wall texture.

Note: Mike has changed his home page since I wrote this. What you see in the screenshot below is the previous version.


The paintings also contain the only color variety on the page. All other information is in the same dark gray.

Also, notice how the paintings are framed, indicating that they have something in common. In this case, they represent projects. Note, too, that the background shows similarity through its pattern of bricks. It’s clear what is figure and what is ground.

On Mike’s “About” page, below, the lone image of Mike contrasts with everything else. The blue button to “Get in touch” is the only element with color. You might not contact Mike, but it won’t be because you don’t know how. Buttons across the website have the same blue.


Mike’s name as the logo is repeated as the main heading on the page. The header contrasts with the background, as do the backgrounds of the various sections of the page below. Links in the menu share the same uppercase styling. Social icons at the top are repeated along the bottom.

Fonts are also used consistently, with headings in a sans-serif and body text in a serif, contrasting with each other.

Electric Pulp

The logo on Electric Pulp’s website21 is a red circle of moderate size. It contrasts well with everything else that is immediately visible. Notice how the color is repeated in the main navigation to indicate the current page.


Headings across the website are big, bold and set in all caps. Headings and body text also contrast consistently across the website, with the former in a sans-serif and the latter in a serif.

Click into the “Notes” section and you’ll see previous and next links with background colors that contrast with the main background. Background color is also used to distinguish different sections of the page.

Most buttons on the website are a contrasting red (a color often used to set off elements) and change to blue on hover. However, on the “Work” page, the first button reverses this (it’s blue and changes to red on hover). Whether this is deliberate or accidental is hard to tell. Nevertheless, the principle of contrast is maintained.


One last website to consider is Lowdi’s23. The screenshot below is of the home page. Notice how color is used for both contrast and consistency.


Color clearly delineates the start and end of sections. And the repetition of color creates a rhythm throughout the page. Notice how the yellow background of the price stands out, while also drawing the visitor’s eye down to the picture of the product.


Contrast and similarity have different functions. They are used in varying degree and in combination. You’ll always see some of both because neither exists without the other. Changing one means also changing the other.

Showing that some things are the same and some are different is the first step in visual communication25. It’s the primary way that viewers derive meaning.

Contrast and similarity are clues to design elements. Differences draw our attention, and similarity transfers what we know about one element to another.

Ultimately, the goal is to contrast similar layers: making the elements in one group look similar to each other, but different from another like group of elements. The way we structure contrasting and similar elements creates hierarchy, flow and compositional balance, topics we’ll get to later in this series.

(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

The post Design Principles: Connecting And Separating Elements Through Contrast And Similarity appeared first on Smashing Magazine.

Prototyping For Better Products, Stronger Teams And Happier Clients

Fri, 09/19/2014 - 13:26

As mobile designers, we have a stark decision to make: do we spend time learning new tools and changing our design processes to create our own transitional interfaces, or are the tools that we’ve been using good enough?

There’s an old writing adage that advises writers, whenever possible, to “show, don’t tell” when bringing characters to life. The goal is to reveal the story through the character’s experiences instead of the author’s.

When designing mobile products, we share a similar burden. Dammed up inside our heads are creative waterfalls of fresh interactions, transitions, and animations. But how are we supposed to communicate them to our teams, our developers? How do we get them out of our heads? Through a game of charades?

I’m guilty of that last one.

Not being able to “show” — in an efficient way — the interactions and animations that bring our designs to life is one of the common struggles plaguing our industry. The static mockups favored in our past are no longer good enough. They simply don’t do the job. Even relative newcomer Sketch — for all of its strength over Photoshop, the Goliath — can only create static screens that must be strung together, struggling to tell our product’s stories.

Exacerbating the urgency of this challenge is the simple fact that we now design for screens that can be tapped, pinched, swiped, zoomed, and more. There’s no way around the fact that our interfaces must become transitional, alive, and reactive to fingers. The mouse is becoming a relic of the past.

For the first time ever, a generation of people starting as babies are using the touch-based apps we create. Let’s just say touch-based interactions aren’t going anywhere anytime soon. (Image credit2, see GIF3)

Below, we’ll explore:

  • How prototyping has, of late, become an essential ingredient for creating the next generation of mobile apps
  • How two prototyping veterans use this in their daily workflows for their products teams and clients
  • The benefits prototyping provides
  • Ways you can incorporate this skill into your design workflow
Mobile Designers Are Hungry For A Better Way

Over the past year, there’s been a growing hunger in the design community to find a better way to “show” design interactions instead of “telling” them. Furthering this trend are large organizations like Airbnb, Evernote, Facebook, Google, and HubSpot. Many of them have been surprisingly benevolent by showing how they’ve started to include prototyping in their product workflows and the practical results of doing so.

The most organized, highest-profile effort in these endeavors has been Facebook’s, through its open-sourcing of Origami4. A set of tools and extensions built on top of Apple’s Quartz Composer5 (QC), these are the same tools used by the Facebook Creative Labs team that created Paper, Home, Slingshot, and more. Even renowned design firm IDEO released its own tools for QC called Avocado6.

Quartz Composer and Origami in action. (Image credit8)(View large version9)

It’s also been a poorly kept secret for some time now that Apple has a set of its own advanced prototyping tools. Rumored to be called “Mica,”10 it’s a tool Apple created for its UI designers to craft interactive interfaces more easily. Mica is allegedly Quartz Composer’s internal replacement, and has been used to create everything from interfaces to Final Cut Pro plugins. I wouldn’t be surprised if Mica had a role to play in the creation of iOS 7 and 8.

That’s Nice, But What About My Problems?

You might be thinking that prototyping is just some corporate fad — like something akin to transparent glass whiteboards or Six Sigma. Or it’s something that only elitist organizations with lots of time and money can afford to do.

But here’s the simple truth: prototyping can help all of us who are building mobile products create better products. And if that wasn’t enough, it’ll bring your team together and make your clients — or “stakeholders,” if you must use that word — happier, more in the loop, and more apt to buy into what you’re building.

Sounds like the Holy Grail to me.

Our Cast of Characters

It should be pointed out that I was, previously, a prototyping skeptic. I saw it as a frivolous luxury that took my time away from creating pixel-perfect, static mockups.

For years, my process was the same:

  • I’d create every possible state imaginable in pixel-perfection, and then spend countless words writing out how the app was supposed to work in a narrative format.
  • Our team would then sit through countless debates about what each of us had envisioned as the “right” functionality.
  • After our debates, we’d finally sit down to building what we agreed on in our heads. I’d spend countless hours trying to explain what I actually envisioned for the project’s interactions once we had something to work with.

This process worked for a time. We were building solely for the web with few responsive requirements. But the process became increasingly painful as we started to develop mobile apps. The cost and time required to backtrack after ideas didn’t pan out created unnecessary sink costs and mental overhead. Because we spent so much time building something, we felt compelled to use it.

We realized there had to be another way. And that’s when prototyping entered my world. I realized that my inability to move up the chain and contribute to creating the interactions I designed slowed us down. It hindered my team’s efforts to move quickly and to realize the success or failure of our product decisions faster.

So I set out both to learn how to prototype and learn where to incorporate it into my workflow. I also went into the field both to find and to learn from designers who are prototyping veterans: Steve Meszaros11, product designer at Wildcard12 and Pauly Ting13, Head of User Experience for Tigerspike14.

Meszaros works at Wildcard with Khoi Vinh15, former design director at the New York Times and named by Fast Company one of the fifty most influential designers in America. With Vinh, Meszaros is responsible for the interface design and interactivity for the not-yet-launched startup, which aims to combine the performance and experience of native apps with the breadth of the entire internet.

Ting is head of user experience at Tigerspike, a design firm that builds apps and mobile sites for Fortune 500 clients, from big-box retailers to internet giants. His work must operate at a massive scale from day one to satisfy not only his clients, but his client’s bosses and his client’s customers.

The following is what I learned about prototyping, both from my own practice and from a number of in-depth interviews with both of them. I’ll explore the benefits of prototyping and how you can incorporate prototyping into your workflow, today.

Prototyping: Best Served With A Healthy Dose Of Focus

Rapid prototyping’s primary purpose is to focus your already limited time. You’re cutting out fluff, tangents, and feature-creep to bring to life a very specific use case or workflow. Your job is to identify that:

  • You’re building the right thing.
  • This piece of your product solves the right problem.
  • This interaction is something your team is capable of building within a reasonable timeframe.

The first goal of prototyping is to test, prove, or conceptualize an idea that’s in your head within a limited timeframe or budget.

“It’s much like a hackathon,” says Ting.

The entire purpose here is to get your ideas out of your head as quickly as possible, and at a fidelity that presents the concepts in your head clearly enough.

All the time and frustration you spend trying to communicate rough interactions can be cut out by simply showing what you mean. A prototype serves as the seed and showcase of your ideas.

Many designers who start prototyping begin by trying to do too much. But the entire purpose of prototyping isn’t to design the interactions of your entire product at once, or to just make pretty things. It’s to demonstrate bite-sized pieces of interaction or specific workflows.

Choose The Right Tool For The Job

That being said, a successful prototype speaks directly to its audience. That means that before you start, you need to understand:

  • Who’s involved in the design process.
  • Who needs to be able to use it and provide feedback.
  • How soon it must be delivered.
  • The complexity of the idea you need to communicate.

Depending on how these factors are configured, a prototype can take on different forms. You might, for example, be able to get away with an unpolished, ugly, hacked-up HTML and CSS combo. Or sketches and wireframes might do. But in some cases, you’ll need to create more polished, accessible prototypes to really understand if an interaction will work.

If you’re on a product team and developing or refining new features, your job is to determine the product and features your team needs to build. You need to understand, define and communicate this as quickly and as thoroughly as you can. The product you define and design must solve the right problem and be something your team is capable of building within a reasonable timeframe.

Start by understanding the purpose of the product you’re building. Never lose sight of that as you move through the process. You also need to be aware of the team involved (whether it’s yours or includes a client), the timeframe, and the required deliverables.

“A prototype can serve many purposes. It can be just for demonstrating an idea, it can be for exploring and testing an idea, it can be for selling an idea, or it can be to build an MVP,” says Ting.

If you need to prototype a user flow, make sure that it tells a story. This can be more powerful than simply prototyping a single interaction, since single interactions are best understood by dedicated product teams. They’ll better understand where in the flow the interaction sits, how it’s different than any existing interactions, and how it will make an improvement.

Consequently, prototyping a single flow helps anybody using the prototype become more emotionally connected to the product. It enables one to get lost in the experience and better illustrates any differences or improvements to old or competitive flows.

These factors determine the tools you should choose to build your prototype. Overall, you should stick to this rule of thumb: if most of the time you spend prototyping is using the tool itself versus on the thought behind the design, you may be using the wrong tool for the job.

Prototyping Tools in Action: An Example Using InVision

Meszaros, Ting, and myself have Quartz Composer/Origami and Framer.js16 in our prototyping toolboxes. Lately, though, Ting has found that he throws down basic user flows first with InVision17, then homes in on specific interactions when necessary.

“InVision is my first go-to prototyping tool, largely because it’s so fast and simple to set up, with the added benefit of being able to share it seamlessly,” says Ting. “It requires no technical knowledge, which means when working with non-technical stakeholders, there’s an easy and low barrier for them to collaborate, participate, and more constructively contribute to the design process. It’s easily the fastest tool to use to create a polished-feeling experience.”

InVision can help piece together a series of static mockups quickly, providing somebody without technical knowledge the feeling of actually moving between screens. It can immerse people inside or outside your organization in the product, quickly selling an idea with basic segues and transitions.

Here’s an example of an InVision prototype Ting used to win a hackathon put on by the rental car giant Hertz. Ting’s task was to come up with a product strategy for what a “connected car” experience could look like for Hertz customers. Within 24 hours, Ting’s team of three researched the use case, created user stories, and constructed the prototype.

Pauly Ting’s prototype for a Hertz Gold mobile app. Built with InVision. (Image credit19, see GIF20)

With this prototype, Ting was able to tell a story about how a mobile app could improve the overall experience of renting a car. It included real-world experiences typically faced by rental car customers, and prototyped how push notifications, GPS navigation, and in-app commerce could be combined to create a compelling flow.

You can see how easy it is to get started with InVision by checking out this short video21.

The Power of Advanced Prototyping Tools

Limited to basic transitions and animations, InVision trades personality for expediency. More advanced tools like Quartz Composer or Framer.js could unlock interactions you otherwise wouldn’t be able to represent with InVision. These tools, while sometimes difficult to adopt, are the key to creating wholly original interactions tailored to your product and visual style.

“Prototyping [with advanced tools] has taught me more about design and usability than I had imagined,” says Meszaros. “It’s a fun way to learn a new language or application and is critical to building and articulating interaction. I’d recommend taking an hour a day to play with a new prototyping application or language such as Framer.js. Download example files off GitHub and dissect them, tweak them, adjust them.”

Advanced prototyping tools like Quartz Composer are almost a requirement for you to create interactions and animations that have never before been seen. And they’re a must if you need fine-grained control over every aspect of your creation.

In my own experience, getting through the initial learning curve of Quartz Composer and Origami wasn’t the epic struggle it’s been advertised to be. After only a few hours, I was able to create complete flows with wholly original interactions and present them to my team for testing, feedback, a few iterations, and implementation in Xcode. It was both creatively satisfying and expedient, as it saved my team countless hours of vague back-and-forth to get interactions and animation timing exactly right.

To neutralize this perceived learning curve, I co-created a video crash course22 that specifically helps mobile designers master the basics of Quartz Composer and Origami in five days or less. You can start creating prototypes right away at your own pace. Jay Thrash also has a great series of videos23 for Quartz Composer beginners, and I’ve also enjoyed the work of the Pra Brothers24.

Test Your Prototype As Soon As Possible

Once the prototype is ready for consumption, it should immediately be used to drive discussion toward the eventual decision about how to proceed.

Beyond speed, this is another huge benefit of prototyping. It allows for greater buy-in across your organization and even among your clients. The prototype becomes a common language that can be experienced and understood by everyone.

It’s here that your goal is to understand where your interaction or flow falls short. What parts are implausible to build or too over-the-top? Where do people get confused? What parts could use more personality or ingenuity? How could these changes inform other parts of your product? Get it in front of your developers, decision makers, customers and clients and you’ll have quick answers to these questions.

“Visualizing [and experiencing] interactions allows us to have more constructive conversations with the larger team,” says Meszaros. “Prototypes have been instrumental in bringing together and facilitating feedback across all areas of the team from strategy, to engineering and design. By developing prototypes, we have greater control of our consequences. At Wildcard, discovering whether or not a build may be expensive is critical to staying on target,” he continues. “That’s why I strongly advocate designing and prototyping in context whenever possible. I find it best to build with all attributes of the UI in place as it would be in the final product.”

Prototyping in Action: A Example from Wildcard

To illustrate this, let’s look at a prototype Meszaros built for Wildcard using Quartz Composer and Origami. This also happens to be the first time the company has released anything to the public about how the Wildcard product looks and works.

“This is an early example of what we built with Quartz Composer and Origami while defining our interaction paradigms,” says Meszaros. “The prototype highlights a key problem: notice that the old ‘cards’ transition by falling off of the screen, while new cards ‘spawn’ from beneath the parent card.”

One of many prototypes built by Stephen Meszaros to fine-tune how old content is dismissed and new content loaded in Wildcard. (Image credit26, see GIF27)

“It quickly became apparent [in user testing] that this may confuse someone as to the location of the old cards. Some questions we asked ourselves were ‘where do I find my old cards?’ ‘Are they lower on the screen?’ and the like. With this, we were able to identify some key concerns in developing this prototype and quickly built alternative prototypes with more confidence.”

This confusion was uncovered in one of Wildcard’s prototype review sessions, led by Meszaros and Vinh.

This small example highlights the importance of taking the time to perform unbiased user tests with the prototypes you’ve built. It’s not enough to create a prototype and informally perform over-the-shoulder review sessions. Prototypes require dedicated segments of time with potential customers, your clients, and team members to see how they respond.

After each session is over, take notes about how you can improve the prototype while it’s fresh in your mind. Sometimes, the problems identified in a prototype can even be remedied within minutes or seconds by making on-the-fly changes. The effect of this speed is immeasurable, because it affects so many areas of the organization — it increases the creativity and originality of a designer, it prevents code from being wasted (and, subsequently, keeps the code base cleaner), it unifies the team, and it brings the product closer to what your customers actually want.

A Typical Timeframe

So how long should the typical prototyping cycle take? On average, the three of us found that the entire loop of prototype creation, testing, iteration, and readying for implementation took about a week. The most each of us had seen was two weeks — mostly due to communication lulls.

One to two weeks allows enough time to come up with ideas and deliver them without fluff, tangents, or politics. It’s a forcing function to prevent wasted cycles. But it’s long enough to stop, breathe, and be able to make smart decisions.

But it’s important to note that there’s no defined scale for this time period. That’s to say, we’ve each been able to prototype everything from a very specific effect (i.e. the effect a user sees when a camera takes a photo), a user flow (how a user sends another user a photo), to the basics of how an entire app works. The scope depends on the level of polish you need, what phase of development you’re in, and who the audience is. Remember, though, that the longer the “sprint,” the more difficult it becomes to maintain momentum.

For many small product teams, the typical turnaround of this process could be as fast as a a typical business day.

“The biggest thing I’ve learned about rapid prototyping is that it’s a great equalizer,” said Ting. “Using tools like InVision or Quartz Composer really puts the onus on UI, UX, PMs, and engineers to understand each other’s disciplines and thus work together. We’ve had little conflict, everyone feels informed and it’s very organic in feeling. Rapid prototyping allows that. It’s not just a tool or even a methodology, it’s a culture.”

Ensuring A Repeatable Process

Once the prototype has been vetted by your team and, ideally, your customers or clients, it’s your job to make it easy for an engineer to implement.

Depending on your tools of choice, this can take many forms. For some, it might be just handing off code you wrote in Framer.js, or sharing your Xcode Storyboards28. It doesn’t matter if your code is messy — it only matters that your developers know the experience you’re trying to achieve, the logic required to get there, and specific values for timing, speed, bounciness, tap areas, and other particulars.

If you used Quartz Composer and Origami, share your composition files and extract key values, such as transition and animation timing. Include the type of easing curve, such as “Quadratic In-Out,” if applicable. Providing as much information up front about how to implement your ideas will increase the speed at which you can ship your product.

Bleed as much into the development process as you can, and hone this skill over time. The amount of effort and care you invest in this handoff phase will have a direct effect on your organizaton’s process. Since it makes it easier on your engineering team to implement your ideas, it’ll help to solidify prototyping as a staple of your development efforts.

Weaving prototyping into your process may seem daunting if there are many separate teams handling pieces of the app’s design. You might, for example, have separate user interface and wireframing teams. Remember that for prototyping to be successful, it has to be an inclusive — and highly-collaborative — process. Wherever possible, separate teams need to work side-by-side to eliminate the rudimentary boundaries of departments and even physical space.

In the end, prototyping brings everybody who’s involved in the process of building a product closer to the end goal: making something that your customer wants. Embracing this means changing how your team works.

A Challenge: Approach Your Design Goals from Now On with a Prototyping Mind

In the end, you’ll be amazed at what you can accomplish through prototyping. Not only is it a great unifier for your team and your customers, it builds excitement for what you’re building and makes everyone feel like they’re a part of the design process. It brings joy and momentum to design reviews. And it helps your team make better decisions.

“Prototyping helps us to make more deliberate and calculated decisions as a group, and that is what may be most important aspect of prototyping,” says Meszaros. “It’s an engaging way to review new features or updates and brings a bit of joy to our design reviews. Don’t be intimidated to prototype, you’ll be amazed by what you can accomplish.”

But perhaps the most powerful side effect is that it can make you a better designer. You’ll become both more productive and more creative. When you’re building rapid prototypes, you begin to create feedback loops that improve your designs. You’ll stumble upon ideas as you work through the core problem you’re trying to solve.

“There are regular situations where I would literally change a design in front of everyone mid-discussion and ask, ‘is that what you mean?’” recalls Ting. “And then we’d test and discuss that. It saved hours and days of emails, meetings, side conversations, politics and debate.”

Next Steps
  • Learn a prototyping tool, ideally one that you can use to create designs meant for touch manipulation, like Quartz Composer29 or Framer.js. You’ll be investing in your own future.
  • Spend time hanging out in communities — online or offline — where you can learn from others with more prototyping experience. Understand their common struggles, how they’ve tackled them, and learn how they stay fresh. QC Designers30 is one of my go-to communities for Quartz Composer questions.
  • Collect videos (I use Reflector31) or animated GIFs of app interactions that you like. Replicate them with your new prototyping skills.
  • Set a date for when you want to start using interactive prototypes in your daily work. Present to key co-workers and let them manipulate your designs on their own. Smile when they have a look of amazement on their face.

(ml, og, 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

The post Prototyping For Better Products, Stronger Teams And Happier Clients appeared first on Smashing Magazine.

Efficiently Simplifying Navigation, Part 3: Interaction Design

Thu, 09/18/2014 - 13:13

Having addressed the information architecture1 and the various systems2 of navigation in the first two articles of this series, the last step is to efficiently simplify the navigation experience — specifically, by carefully designing interaction with the navigation menu.

When designing interaction with any type of navigation menu, we have to consider the following six aspects:

  • symbols,
  • target areas,
  • interaction event,
  • layout,
  • levels,
  • functional context.

It is possible to design these aspects in different ways. Designers often experiment with new techniques3 to create a more exciting navigation experience. And looking for new, more engaging solutions is a very good thing. However, most users just want to get to the content with as little fuss as possible. For those users, designing the aforementioned aspects to be as simple, predictable and comfortable as possible is important.


Users often rely on small visual clues, such as icons and symbols, to guide them through a website’s interface. Creating a system of symbolic communication throughout the website that is unambiguous and consistent is important.

The first principle in designing a drop-down navigation menu is to make users aware that it exists in the first place.

The Triangle Symbol

A downward triangle next to the corresponding menu label is the most familiar way to indicate a drop-down menu and distinguish it from regular links.

A downward triangle next to the menu label is the most reliable way to indicate a drop-down. (Source: CBS5) (View large version6)

If a menu flies out, rather than drops down, then the triangle or arrow should point in the right direction. The website below is exemplary because it also takes into account the available margin and adjusts the direction in which the menu unfolds accordingly.

A triangle or arrow pointing in the right direction is the most reliable way to indicate a fly-out menu. (Source: Currys8) (View large version9)

The Plus Symbol

Another symbol that is used for opening menus is the plus symbol (“+”). Notice that the website below mixes symbols: an arrow for the top navigation menu and a “+” for the dynamic navigation menu to the left (although an arrow is used to further expand the dynamic menu — for example, to show “More sports”).

Some websites use a “+” to drop down or fly out menus. (Source: Nike11) (View large version12)

Mixing symbols can be problematic, as we’ll see below. So, if you ever add functionality that enables users to add something (such as an image, a cart or a playlist), then “+” would not be ideal for dropping down or flying out a menu because it typically represents adding something.

The Three-Line Symbol

A third symbol often used to indicate a navigation menu, especially on responsive websites, is three horizontal lines.

Three horizontal lines is frequently used for responsive navigation menus. (Source: Nokia14) (View large version15)

Note a couple of things. First, three lines, like a grid16 and a bullet list17 icon, communicate a certain type of layout — specifically, a vertical stack of entries. The menu’s layout should be consistent with the layout that the icon implies. The website below, for example, lists items horizontally, thus contradicting the layout indicated by the menu symbol.

Three lines do not work well if the menu items are not stacked vertically. (Source: dConstruct 201219) (View large version20)

The advantage of the more inclusive triangle symbol and the label “Menu” is that they suit any layout, allowing you to change the layout without having to change the icon.

Secondly, even though three lines are becoming more common, the symbol is still relatively new, and it is more ambiguous, possibly representing more than just a navigation menu. Therefore, a label would clarify its purpose for many users.

An accompanying label would clarify the purpose of the three lines. (Source: Kiwibank22) (View large version23)

Consistent Use Of Symbols

While finding symbols that accurately represent an element or task is important, also carefully plan their usage throughout the website to create a consistent appearance and avoid confusion.

Notice the inconsistent use of symbols in the screenshot below. The three lines in the upper-right corner drop down the navigation menu. The three lines in the center indicate “View nutrition info.” The “Location” selector uses a downward triangle, while the “Drinks” and “Food” menus, which drop down as well, use a “+” symbol.

Inconsistent symbols lead to confusion. (Source: Starbucks25) (View large version26)

While using multiple symbols for a drop-down menu is inconsistent, using arrows for anything other than a drop-down menu causes problems, too. As seen below, all options load a new page, rather than fly out or drop down a menu.

Using a triangle or arrow for anything other than a drop-down or fly-out menu can cause confusion. (Source: Barista Prima28) (View large version29)

This leads to a couple of problems. First, using arrows for regular links — whether to create the illusion of space30 or for other reasons — puts pressure on you to consistently do the same for all links. Otherwise, users could be surprised, not knowing when to expect a link to load a simple menu or a new page altogether. Secondly, a single-level item, such as “Products”, could conceivably be expanded with subcategories in the future. A triangle could then be added to indicate this and distinguish it from single-level entries, such as the “About” item.

Users generally interpret an arrow to indicate a drop-down or fly-out menu. And they don’t have any problem following a link with no arrow, as long as it looks clickable. It is best not to mix these two concepts.

  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

The post Efficiently Simplifying Navigation, Part 3: Interaction Design appeared first on Smashing Magazine.

Why Companies Need Full-Time Product Managers (And What They Do All Day)

Wed, 09/17/2014 - 12:54

What is a product manager? What do product managers do all day? Most importantly, why do companies need to hire them? Good questions.

The first confusion we have to clear up is what we mean by “product.” In the context of software development, a product is the website, application or online service that users interact with. Depending on the size of the company and its products, a product manager could be responsible for an entire system (such as a mobile app) or part of a system (such as the checkout flow on an e-commerce website across all devices).

This is confusing because, in most contexts, a product is a thing you sell to people. Particularly in e-commerce, product managers often get confused with category managers, which are the team that sources and merchandises the products sold on an e-commerce website. So, yes, “product” probably isn’t the best word for it. But it’s what we’ve got, and it’s the word we’ll refer to in exploring this role.

To define the role of a product manager, let’s start by looking at Marc Andreessen’s view of the only thing that matters in a startup1:

The quality of a startup’s product can be defined as how impressive the product is to one customer or user who actually uses it: How easy is the product to use? How feature rich is it? How fast is it? How extensible is it? How polished is it? How many (or rather, how few) bugs does it have?

The size of a startup’s market is the the number, and growth rate, of those customers or users for that product.…

The only thing that matters is getting to product-market fit. Product-market fit means being in a good market with a product that can satisfy that market.

Even though Andreessen wrote this for startups, the importance of that last sentence about product-market fit holds truth for every organization — whether the organization is getting a new product to market or redesigning an existing experience or anything in between. It is a universal road map to success, and it is the core of what product managers are responsible for.

With that as the backdrop, my definition of the role of a product manager would be to achieve business success by meeting user needs through the continual planning and execution of digital product solutions.

This definition summarizes all of the things that a product manager needs to obsess over: the target market, the intricacies of the product, what the business needs in order to succeed, and how to measure that success. It also encapsulates the three things that a product manager should never lose sight of:

  • The ultimate measure of success is the health of the business and, therefore, the value that the product provides to users.
  • Everything starts with a solid understanding of the target market and its needs, so that the focus remains on the quality of the product experience.
  • A continual cycle of planning and execution is required to meet these market needs in a sustainable way.

So, how does this translate to what a product manager does every day? That question is way too big to answer here, but as an introduction, Marty Cagan has a great list of common tasks that product managers are responsible for in his ebook Behind Every Great Product2 (PDF). The tasks include:

  • identifying and assessing the validity and feasibility of product opportunities,
  • making sure the right product is delivered at the right time,
  • developing a product strategy and road map for development,
  • leading the team in executing the product’s road map,
  • evangelizing the product internally to the executive team and colleagues,
  • representing customers through the product development process.

But before a product manager is able to do these things, a couple of awkward questions have to be asked. First, do companies really need product managers? And, if we can agree on that, what are the characteristics of a good one? Also, where does this role fit in an organization’s structure? Let’s explore these questions.

Why Companies Need Product Managers

The role of product manager can be a hard sell for some companies. Common objections to it include:

  • “We have various people in the organization whose roles fulfill each of these functions.”
  • “I don’t see how the role would make us more money.”
  • “Product managers would just slow us down.”
  • “I don’t want to relinquish control of the product to someone else.” (OK, this one is not usually said out loud.)

These appear to be valid concerns, but only if the role is not well understood — or if the organization has bad product managers who perpetuate these perceptions.

The truth is that, to be effective, the role of a manager for a particular product or area must not be filled by multiple people. It is essential for the product manager to see the whole picture — the strategic vision as well as the details of implementation — in order to make good decisions about the product. If knowledge of different parts of the process resides in the heads of different people, then no one will have that holistic view, and all value will be drained of the role.

Let’s look at two major benefits that product managers bring.

Product Managers Ensure a Market-Driven Approach

The key argument in favor of product managers is that they help companies to be driven by the needs and goals of the target market, not the forces of technology or fads. As Barbara Nelson puts it in “Who Needs Product Management?”3:

It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.

If done right, a market-driven focus results in long-term, sustainable, profitable business, because the company will remain focused on solving market problems, as opposed to looking for things to do with the latest technologies. A market-driven focus is important because companies that have one are proven to be more profitable than those driven by other factors (31% more profitable, according to George S. Day and Prakash Nedungadi4).

This doesn’t mean focusing on incremental change to the exclusion of product innovation. Identifying market problems is about not only finding existing issues to improve (for example, “60% of users drop off on this page, so let’s fix that”), but also about creating new products to satisfy unmet needs (“Cell phones suck — let’s make a better one”).

Product Managers Improve Time-to-Everything

The second major benefit of product managers is that they reduce the time an organization takes to reach its goals. A well-defined and appropriate product development process run by effective managers will improve both the time-to-market as well as the time-to-revenue.

The reason for the faster turnaround time is that a product manager is responsible for figuring out what’s worth building and what’s not. This means less time spent on the spaghetti approach to product development (throwing things against the wall to see what sticks) and more time spent on building products that have been validated in the market. This approach also sharpens the organization’s focus, enabling the organization to dedicate more people to products that are likely to succeed, instead of spreading people too thin on projects that no one is sure will have a product-market fit.

Characteristics Of A Good Product Manager

Now that we’ve covered the importance of product managers, the next question is, “Who are these people?”

Most of us are familiar with the idea of T-shaped people: those who have deep knowledge in one or two areas, with a reasonable understanding of a variety of disciplines related to their main field of focus. In 2009, Bill Buxton wrote an interesting article for Businessweek in which he calls for more “I-shaped” people5:

These have their feet firmly planted in the mud of the practical world, and yet stretch far enough to stick their head in the clouds when they need to. Furthermore, they simultaneously span all of the space in between.

This is a good description of the unique blend of skills that product managers need. First, they need to have their head in the clouds. They need to be leaders who can look into the future and think strategically. They need to be able to develop a vision of where a product should go, and they need to be able to communicate that vision effectively. Furthermore, product managers need to show their teams how they plan to get to that vision. And I do mean show: through sketches, prototypes, storyboards, whatever it takes to get the message across. They also need to be flexible and be able to change course when needed; for example, when market needs or expectations shift substantially or a great business opportunity presents itself.

But a good product manager also has their feet on the ground. They pay attention to detail, and they know the product inside out. They are the product’s biggest user — its biggest fan and critic. They understand every aspect of the complexity that needs to be worked through in each product decision. And they’re able to make those decisions quickly, based on all of the information at their disposal.

Most importantly, a product manager knows how to ship. They know how to execute and rally a team to get products and improvements out into the world, where the target market can use it and provide feedback.

I-shaped people (View large version7)

In short, a product manager is a visionary as well as a doer, a manager as well as a maker. And they need to move seamlessly between those extremes, sometimes at a moment’s notice. Sound difficult? That’s only the beginning. Let’s look at some more characteristics of a good product manager.

Leader and Collaborator

Being a leader and a collaborator at the same time is a difficult balance to strike. The first challenge is that collaboration is often mistaken for consensus. That’s not the case. Consensus cultures often produce watered-down, unexciting products, products whose endless rounds of give-and-take have worn down the original idea to a shadow of what it was. Consensus cultures also wear down the teams working on the product, because they don’t really get what they want, only some of it.

Collaboration is different. In collaboration cultures, people understand that, even though everyone has a voice, not everyone gets to decide. People are free to air their opinions, argue passionately for how things should be done, and negotiate compromises. But that certainly doesn’t mean that everyone has to agree with every decision.

The first step to building a collaboration culture is to have a good leader. As you’ve probably surmised by now, the product manager is the ultimate decision-maker. But that only works if they are a trusted and respected leader in the organization, someone who can get the team excited about the vision, as well as make decisions that are best for the company and its customers. A good leader also readily admits when they have made a wrong decision, and they own up to it and do whatever they can to fix the mistake.

This isn’t a post about leadership — there are plenty of those to go around. But I’ll still share one piece of leadership advice8 from French writer and aviator Antoine de Saint Exupéry that has helped me over the years:

If you want to build a ship, don’t drum people up together to collect wood, and don’t assign them tasks and work. Rather teach them to long for the endless immensity of the sea.

What does “the endless immensity of the sea” mean in your context? Instead of telling people to build a bunch of features, how can you inspire them to think about how the product will help users accomplish their goals? That’s how you’ll be able to unite teams around a common vision.

So, how does a good leader foster this kind of collaboration culture? By creating an environment and creating processes that allow collaboration to feed on itself, and by understanding that every person is different and will react unpredictably at some point.

To create the right environment and processes for collaboration, focus on the physical environment first. Make sure that physical workspaces allow team members both to have impromptu discussions with each other and to shut out all distractions and focus on work for a period of time. The MailChimp office is a great example of this. The team created a collaborative workspace9 based on the following principles:

  • Commingle and cross-pollinate
    Instead of segregating teams, mix people up according to their personalities and the projects they’re working on. This will lead to valuable discussions that might not have happened if everyone was stuck in their own silo.
  • Facilitate movement
    Open desks, couches, standing tables: these are all elements that encourage people to move around and work together when needed.
  • Ideas everywhere
    Cover walls and whiteboards with sketches, designs, prioritization lists and road maps. This will not only contribute to better communication, but also leave the door open for anyone to improve ideas that others are working on.
  • Create convergence
    A common space for lunch (and coffee!) is important because it will allow people to run into each other, even people who don’t normally work together on projects. Again, this can lead to great ideas and perspectives.
  • Create retreats
    The hustle and bustle of collaboration spaces has great energy, but it is sometimes distracting. Individuals and teams occasionally need a quiet space to work, so make sure they have meeting rooms or quiet retreats that prevent any interruption.

Workspaces are more important than we might think. We went to great lengths to create a welcoming, creative space at the studio I used to work at, and the effort is paying off. Most clients prefer to come to us for meetings, and they cite two reasons: the excellent coffee (we went a little overboard on the coffee) and the great atmosphere to work in.

Steve Jobs understood the value of physical spaces very well. He is quoted in Walter Isaacson’s biography as saying this about the design of Pixar’s new campus:

If a building doesn’t encourage [collaboration], you’ll lose a lot of innovation and the magic that’s sparked by serendipity. So we designed the building to make people get out of their offices and mingle in the central atrium with people they might not otherwise see.

Of course, physical space is only one part of the equation. A lot of work happens remotely now, and we have enough tools at our disposal to make that an effective and rewarding experience for everyone involved. From communication tools like Campfire, HipChat and Slack to collaborative project-management tools like Trello, Basecamp and Jira to source-code repositories like GitHub and Bitbucket, we have no excuse anymore to force everyone to be in the same physical space at all times. There is still much value in talking face to face and in collaborating during certain stages of the process, but even that can happen in digital spaces.

So, what’s next after you’ve worked on the physical and digital environments? Next is a feared word. Many people think “process” is synonymous with “things I have to do instead of working.” But a lot of appropriate, or “right-fidelity,” processes are possible. To quote Michael Lopp10: “Engineers don’t hate process. They hate process that can’t defend itself.” When it comes to creating a culture of collaboration, several processes — defendable processes — can make life easier for the whole team.

One essential process to get right is regular feedback sessions on design, development and business decisions. The challenge is that feedback sessions can get out of hand quickly, because we’re just not very good at providing (or getting) feedback. We are prone to seeing the negative elements of someone’s ideas first, so we often jump right into the teardown. This puts the person on the receiving end in a defensive mode right away, which usually begins a spiral down into unhelpful arguments and distrust.

There is a better way. In an interview on criticism and judgment, French philosopher Michel Foucault laid out the purpose of any good critique11. In his view, criticism should focus not on what doesn’t work, but on how to build on the ideas of others to make them better:

I can’t help but dream about a kind of criticism that would try not to judge but to bring an oeuvre, a book, a sentence, an idea to life; it would fight fires, watch grass grow, listen to the wind, and catch the sea foam in the breeze and scatter it. It would multiply not judgements but signs of existence; it would summon them, drag them from their sleep. Perhaps it would invent them sometimes — all the better. Criticism that hands down sentences sends me to sleep; I’d like a criticism of scintillating leaps of the imagination. It would not be sovereign or dressed in red. It would bear the lightning of possible storms.

Keeping this purpose in mind, let’s turn to the process used by Jared Spool12 and his team at User Interface Engineering. The team uses this process specifically for design critiques, but it could be applied to any kind of feedback session:

  1. The person presenting their idea or work describes the problem they are trying to solve.
  2. If everyone agrees on the problem, the team moves on. If there is not agreement on the problem to be solved, some discussion is needed to clarify. Hopefully, this step isn’t needed, though.
  3. Next, the presenter communicates their idea or shows their work to the team. The goal is not only to show the finished product, but to explain the thought process behind it. The presenter should remain focused on how the idea will solve the problem that everyone has agreed on.
  4. The first step in giving feedback is for the people in the room to point out what they like about the idea. This isn’t a ruse to deliver a crap sandwich (you know, start and end with something positive and eviscerate in the middle). Rather, this step highlights which approach to the problem is desirable.
  5. Critique ensues, not as direct attacks or phrases such as “I don’t like…,” but as questions about the idea. Team members will ask whether a different solution was considered, what the reason was for a particular choice and so on. This gives the presenter a chance to respond if they’ve thought through the issue already, or else to make a note to address it for the next iteration.
  6. At the end of the meeting, the team reviews the notes, especially what everyone liked and what questions they had. The presenter then goes away to work on the next iteration of the idea.

As the product manager, you are responsible for making sure that feedback sessions happen and that they are respectful and useful.

The goal of collaboration is for participants to make ideas better by building on the best parts of different thoughts and viewpoints. As long as people trust that the decision-maker (that’s you, dear product manager) has the best interests of the product and company at heart, then they won’t have a problem not getting their way every once in a while. Be confident, trustworthy and decisive — and make sure that everyone feels comfortable raising their opinion with the team.

All of this is much easier said than done, of course. Product managers need to steer the team through the collaboration process, and sometimes the trust just won’t be there in the beginning. That’s OK — trust takes time. Live these values, lead by example, and the culture will come.

Communicator and Negotiator

A more accurate label for this section might be “Overcommunicator and Negotiator,” because if there’s one thing a product manager never gets tired of, it’s telling people what’s happening. But instead of sending a ton of email, a better way is to work in the open as much as possible. Make sure that notes, sketches, plans and strategies are all accessible to everyone in the company at all times. This could take the form of whiteboards that are placed across the office or in a company wiki or in project spaces. Working out in the open has the added benefit of giving context to conversations: All comments and decisions will be in one place, instead of spread out over multiple emails (or, worse, in meetings where no one remembers to take notes).

Being a product manager sometimes feels like you’re being torn limb from limb. Most stakeholders have only their own department’s interests at heart (as they should — they’re paid to fight for what they care about). In contrast, a product manager needs to negotiate the best solution from all of the different directions that stakeholders want to take, and then communicate that decision effectively and without alienating people who don’t get their way. That’s not an easy job.

What product management sometimes feels like (Image: central panel of “Martyrdom of St Hippolyte” triptych, Dieric Bouts, c1468)

The design community has a phrase to refer to the difficult process of managing the expectations (and assertions) of a variety of stakeholders: design by committee. Like consensus culture, decision-by-committee cultures are pervasive, particularly in large organizations. I’ve always liked the approach that Speider Schneider proposes in his article “Why Design-By-Committee Should Die13”:

The sensible answer is to listen, absorb, discuss, be able to defend any design decision with clarity and reason, know when to pick your battles and know when to let go.

This is not as easy as it sounds. So, over time, I’ve developed the following guidelines to deal with decision-by-committee in a systematic way.

Respond to Every Piece of Feedback

Responding to every demand, criticism, question and idea takes time. But failing to respond will waste even more time and energy down the road. Someone listening to another person’s idea and deciding not to use it is one thing. Someone not even listening is something else entirely. Instead of dealing with the political ramifications of not hearing people out, take the time to respond thoughtfully whenever someone offers feedback or an idea (no matter how unfeasible).

Note What Feedback Is Incorporated

When you implement a good idea, don’t do it quietly. It’s an opportunity to show that you’re flexible and open to good feedback. Let people know when and how their ideas are being used. Also, this should go without saying, but don’t take credit for someone else’s idea.

When Feedback Is Not Incorporated, Explain Why

Most of the feedback you’ll receive can’t realistically be incorporated into the product. Don’t sweep those decisions under the rug. By forcing yourself to be clear and straightforward about which feedback won’t be incorporated, you’ll also force yourself to think through the decision and defend it properly. Sometimes you’ll even realize that what you initially dismissed as a bad idea would be an improvement after all. People are generally OK with their feedback not being used, as long as they know that they’ve been heard and that there’s a good reason for the decision.

Use a Validation Stack to Defend Decisions

In their book Undercover User Experience Design14, Cennydd Bowles and James Box explain the user experience validation stack, yet another method that can be used to defend product decisions. When defending a decision, always try to cite user data as evidence, such as usability testing and website analytics. If you don’t have direct access to user data, look for research — either research you’ve done or third-party research into related areas. If all else fails, fall back on theory. The principles of visual perception, persuasion, psychology and so on could be very handy in explaining why you’ve made certain decisions.

These guidelines should make it easier to negotiate different needs and requests from internal stakeholders. But remember Speider’s recommendation in his article: Pick your battles, and know when to let go. That’s the art of being a good negotiator and communicator.

Passionate and Empathetic

Product managers love and deeply respect well-designed, well-made products, both physical and digital. And they live to create such products. They are the people who go to parties and can’t shut up about a new website or app or, more likely, can’t shut up about how cool what they’re working on is.

They’re passionate not only about product, but about users, too. They understand the market well: their customers’ values, priorities, perceptions and experiences. Passion for product is useless without empathy for its users. Building a great product is not possible without geting into the minds of the people who will use it. If we want to anticipate what people want and guide them along that path, then empathy is non-negotiable.

Qualified and Curious

Product managers usually come from specialist backgrounds, such as user experience design, programming and business analysis. To apply their specialized knowledge to this new field — in other words, to become more I-shaped — they will need to be able to learn new skills very quickly (and under great pressure). Insatiable curiosity is a prerequisite for this ability to learn quickly. Why? Cap Watkins puts it well15:

If you’re intensely curious, I tend to worry less about those other skills. Over and over I watch great designers acquire new skills and push the boundaries of what can be done through sheer curiosity and force of will. Curiosity forces us to stay up all night teaching ourselves a new Photoshop technique. It wakes us up in the middle of the night because it can’t let go of the interaction problem we haven’t nailed yet. I honestly think it’s the single most important trait a designer (or, hell, anyone working in tech) can possess.

A good product manager does whatever it takes to make a product successful. They constantly worry about the tiniest of details, as well as the biggest of strategy questions. Rather than feeling overwhelmed by the sheer amount of what needs to be done, their curiosity pushes them to remain committed and to become as qualified as possible to make the right decisions.

Trustworthy and Ethical

A good product manager inspires trust in their team with every decision they make. To be trustworthy, they need to be fair (more on this later) and consistent, and they need to always take responsibility for their decisions. They also have to admit when they’re wrong, which is difficult at the best of times.

On the one hand, a product manager needs to be confident in the decisions they make. They need to constantly learn and grow and hone their craft. Theory and technique need to become so ingrained that they become second nature, the cornerstone of everything they do.

On the other hand, they need to be open to the fact that some of their decisions will be wrong. In fact, they need to welcome it. They should hang on to a measure of self-doubt every time they present a solution to the team or to the world. Admitting that someone else’s idea is better than yours and making changes based on good criticism will do wonders for improving the product — and it will build trust among the team. John Lilly phrases what should be a mantra for all product managers: “Design like you’re right; listen like you’re wrong.16

The best product managers are those who are guided by a strong and ethical perspective on the world. An discussion of ethics will only get me into trouble here, but it would be wrong not to at least touch on the subject. In short, we’re not just making products; we are putting a stamp on the world, and we have an opportunity to make the world a better place. Perhaps no one says it better than Mike Monteiro in Design Is a Job17:

I urge each and every one of you to seek out projects that leave the world a better place than you found it. We used to design ways to get to the moon; now we design ways to never have to get out of bed. You have the power to change that.

How do we identify projects and problems that fit these criteria? One way is to watch out for what Paul Graham calls “schlep blindness18”: our inability to identify hard problems to solve, mostly because we’re just not consciously looking for them. Paul’s advice to combat this? Instead of asking what problem you should solve, ask what problem you wish someone else would solve for you.

Another great source of ideas for worthy projects is the field of social entrepreneurship (i.e. pursuing innovative solutions to social problems). Meagan Fallone has a great overview19 of the nature and importance of this type of work:

We in turn can teach Silicon Valley about the human link between the design function and the impact for a human being’s quality of life. We do not regard the users of technology as “customers,” but as human beings whose lives must be improved by the demystification of and access to technology. Otherwise, technology has no place in the basic human needs we see in the developing world. Sustainable design of technology must address real challenges; this is non-negotiable for us. Social enterprise stands alone in its responsibility to ensuring sustainability and impact in every possible aspect of our work.

The book Wicked Problems20 is a great source of ideas on how to put our effort towards meaningful work.

Of course, people define socially important work differently. That’s OK — what’s important is to think it through and to clearly delineate the work you want to be involved in.

Responsible and Flexible

To garner sympathy from others, product managers like to say that the most difficult part of their job is that they have all of the responsibility but none of the authority. In other words, even though product managers are responsible for the success and failure of their products, no one normally reports to them. This is why good communication and collaboration skills are so crucial.

The danger of all having all of the responsibility for a product is rigidity: not letting go of tasks that could easily be delegated and stubbornly sticking to the plan when circumstances have changed. That’s why product managers must remain flexible. Planning is critical, and an essential part of planning is allowing for the right information to change the plan if needed.

This need for flexibility can unnerve some product managers, but it’s a necessary part of the process of building a great product. So, get comfortable with ambiguity. This job has a lot of it.

In Fairness

This one is the most important characteristic of a product manager — the one that rules them all. I once had a discussion with a colleague in our development team about the development process for new products that we had rolled out a few months before. One of the words he used to describe the new process is “fair.”

It was a passing comment, and I didn’t really think much of it at the time, but since then I’ve kept going back to that conversation and the importance of fairness in product management. All of the characteristics I’ve talked about are great, but fairness is the one that a product manager simply cannot do without.

Let’s look at one definition of the word and consider what it means in product management:

fair (adjective)

free from favoritism or self-interest or bias or deception.

Free From Favoritism

One of the fastest ways for a product manager to become ineffective is to play favorites with a team, product line or user base. As soon as people sense that you are not looking at all ideas equally and fairly, their trust in you will inevitably erode. And without trust, you’ll have to work a lot harder (and longer) to get people to follow your road map.

Free From Self-Interest

If you start doing things purely for reasons like “Because I want to” or “Because my performance is being measured this way,” then trust will erode again. You cannot be effective by nursing your pet projects and ignoring the needs around you.

Free From Bias

This often happens when product managers receive news they don’t want to hear, especially from the user research or analytics teams. If something doesn’t test well, don’t make up reasons why you are right and users are wrong. Do the right thing and realign the design.

One of the hardest skills for a product manager to learn is to take their own emotions and feelings out of the equation when making decisions. Yes, a lot of gut feeling goes into a product vision, but that should not be based on personal preference or preconceived ideas. This is much easier said than done, but it’s something to strive for and to be aware of at all times.

Free From Deception

This one seems obvious, but you see it often, especially with metrics and assessment. Don’t ignore or distort negative data or blame a problem on someone else. Your job is to own the product, and this means owning its successes and its failures. You’ll gain trust and respect only if you acknowledge the failures as much as the successes and commit to doing better next time.

A product manager is often referred to as “the great diplomat,” and with good reason. Our responsibility is to balance the variety of needs from inside and outside the company and to somehow turn that into a road map that generates business value and meets user needs. A focus on fairness will help to accomplish that goal:

  • Fairness to users
    Approach users with respect, openness and transparency. Understand their needs, and explain to them why you might need to do something that will make it more difficult for them to meet those needs.
  • Fairness to the company
    Do everything you can to understand the needs of marketing, merchandising, customer support and other departments. Pull them into the planning process; be clear about how projects are prioritized; and help them adjust to that process so that they can define their project goals in a way that gets them on the road map.
  • Fairness to technology
    Don’t try to force the development team to make the product’s technology do things it’s not capable of doing. Understand the technical debt in the organization, and work actively to make those improvements a part of regular development cycles.

A lot of this comes naturally with good product managers, but we need to be conscious of it every day. Fairness is a prerequisite to building great products. If you’re not fair, you’ll be dead in the water, working with a team that has no reason to trust that you’re doing the right thing.

A Prerequisite For Success

One last topic needs to be addressed. An organization can hire the best product managers in the world and implement the best development processes, but it will still fail if one prerequisite for success is not met. There needs to be an executive mandate and company-wide understanding that, even though everyone has a voice, decisions about product ultimately rest with the product manager.

This one is hard to swallow for many companies. When I mention this part in training courses on product management, the mood in the room often changes. This is when people start complaining that, even though they see the value in the role, it would never work at their company because team leaders aren’t willing to give up that ultimate control over the product. The strategies for dealing with this warrant another article. For now, here’s what Seth Godin reportedly once said: “Nothing is what happens when everyone has to agree.” The product manager is there to make sure things happen — the right things.

When everyone has a say (Image: Dilbert, 1 July 2010) (View larger version22)

Executive teams and individual contributors have to buy into this role. If they don’t, then the product manager will become impotent and a frustrated bystander to a process that continues to spiral out of control. And they’ll end up going somewhere where their value is appreciated.

What Now?

We’ve covered a bunch of what might be considered “soft issues” in product management: what product managers are like, how they work with other people, what differentiates a good one from a bad one. It’s tempting to skim over these issues to get to the how — the processes and day-to-day activities of the role. But that would be a mistake. I haven’t seen a role in product development that relies more on these soft skills than that of the product manager. A product manager could have the best strategy and could execute brilliantly, but if they’re not able to work well with people and rally them around a cause, they will fail. So, if you’ve skipped over any of those sections, consider going back and reading them.

We can’t stop here, of course. Now that the foundation is in place, it’s time to move on to how product managers spend their day. If you’d like to read more about product planning (how to prepare for and prioritize product changes) and product execution (how to ship those changes), then check out my book Making It Right23!


  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

The post Why Companies Need Full-Time Product Managers (And What They Do All Day) appeared first on Smashing Magazine.

Essential Visual Feedback Tools For Web Designers

Tue, 09/16/2014 - 12:27

The creative process takes a lot of time, and web designers know it. When you factor in feedback from clients, the process takes even longer: numerous emails, revision notes, chats and meetings — that’s what it normally takes to find out precisely what the client wants.

Fortunately, today’s web provides various solutions to optimize the communication process. The first web services that allow users to report bugs on web pages appeared several years ago. Since then, tools and technologies have emerged to make the process more convenient and user-friendly. Today’s market offers several useful products for visual bug-tracking, each with its pros and cons.

We have selected our top five tools and compared their features, functionality and pricing. We hope that this review will simplify your workflow and speed up communication between your team and clients.
InVision LiveCapture

Invision1 is a prototyping tool that enables designers to easily collaborate on design projects and to showcase their work. Quite recently, the company announced the release of a new tool, InVision LiveCapture192. It grabs full-length snapshots of live websites and helps users provide feedback during the design process.

3InVision enables designers to collaborate and to showcase their work. (View large version4) User Experience

Getting started with InVision is easy. Just add your first project and install the extension for Google Chrome. To start commenting on a web page, click on the extension icon and select the project.

InVision LiveCapture extension.

When someone adds a comment, feedback appears on the normal screen in InVision, which would already be familiar to the designer.

InVision LiveCapture extension.

The service is targeted at web designers who are looking for an easy way to get feedback on their work in progress. Unfortunately, it cannot be used to comment on a live web page or integrated in a large team’s workflow or used as a bug-tracking tool. On the other hand, it’s free!

  • Easy to work with
  • Great for collecting inspirational ideas
  • Ideal for existing customers looking to get more out of Invision
  • Works with Google Chrome only
  • Browser extension required
  • Reporting bugs is difficult
Third-Party Integration
  • InVision
  • Doesn’t support third-party project-management or bug-tracking systems
Supported Browsers
  • Chrome

The free plan is available for individual use. A subscription plan for teams with up to five members and unlimited projects costs $100 per month.


TrackDuck5 is a visual feedback tool that is ideal for web designers and developers. Users can highlight issues on the page, comment and receive feedback in real time. Bug reports are sent directly to the dashboard, where you can chat with others, assign tasks and track progress.

With TrackDuck users can highlight issues on the page, comment and receive feedback in real time. User Experience

Immediately after you register, which takes about a minute, a simple wizard helps you to get started with your first project in three simple steps: enter a website address, install the extension for capturing high-quality screenshots, and invite colleagues to collaborate on the project. The website that you add then opens in a new tab, and you can start commenting right on the web page by selecting and dragging the mouse wherever you notice a bug. You can appoint a colleague to fix the issue and assign a priority to the task.

TrackDuck visual feedback 6It works even for responsive websites, and you can always check what a bug looks like on your smartphone. (View large version7) All tasks and bug reports are available in the dashboard. Issues are also visible as pins on the web page itself.

TrackDuck currently integrates with only a couple of systems: JIRA and Basecamp. The integration works both ways — tasks are sent and updated automatically in both systems, no double entry required.

  • Unlimited number of team members
  • Cross-browser
  • Technical details are collected automatically
  • Real time with WebSockets
  • No extensions needed
  • Anonymous feedback allowed
  • Extension required to capture high-quality screenshots
  • Few systems to integrate with
Third-Party Integration
  • Basecamp (both ways)
  • JIRA (both ways)
  • WordPress plugin
  • Modx plugin
Supported Browsers
  • Chrome
  • Internet Explorer
  • Safari
  • Firefox
  • bookmarklet (for other browsers)

You can get a free 14-day trial of the fully functional version. The free version allows for one project and unlimited contributors. Paid subscription plans start at $19 per month. Custom enterprise plans are also available.


Bugmuncher8 is a handy web application allows you to highlight problems on a website. Users can make notes on specific areas of a website where they notice issues. BugMuncher will automatically take a screenshot of the area where the highlight was made and send it to you.

9BugMuncher allows you to highlight problems on a website. User Experience

Installing and getting started with BugMuncher isn’t complicated. All you have to do is embed the code on your website. Anyone who has ever set up Google Analytics could handle it. There is no onboarding tour, which could be a problem for inexperienced users. Also, when you embed the code on your website, a small shortcut appears for all visitors to the page, allowing them to highlight or (if they need to hide personal data) to black out certain parts of the page. However, you cannot add separate text comments to the web page.

All tasks and bug reports are available in the dashboard. Issues are also visible as pins on the web page itself.

When testing this tool, I couldn’t scroll down the page and was confined to working within the visible area, which is a bit odd.

After you have highlighted an area of the page, you will be prompted to enter your email address, describe the bugs you’ve found and submit them. You can access all reports, configure email alerts and set up integration in the dashboard.

  • Cross-browser
  • Automatically attaches technical details
  • No extension needed
  • Allows for anonymous feedback
  • Not real time
  • Cannot select a particular area of a page
  • No way to comment on dynamic elements on the page
Third-Party Integration
  • GitHub
  • activeCollab
  • Bitbucket
  • Trello
  • Zendesk
Supported Browsers
  • Chrome
  • FireFox
  • Safari

A free 30-day trial is available. After that, pricing starts at $19 per month for a personal subscription with one account. If your team has five members, you would pay $199 per month.


BugHerd10 is a simple bug-tracking and collaboration tool for web designers and their clients. It allows users to flag issues on web pages using a simple point-and-click interface and to submit reports of problems.

11BugHerd allows users to flag issues using a simple point-and-click interface and to submit reports of problems. (View large version12) User Experience

You don’t need a credit card to sign up. Registration is pretty simple: You can try the tool by installing a browser extension or by adding JavaScript code to your website. Once you’ve done one of these two things, you’ll be able to add websites to work with. Don’t forget to include the http:// or https://, or else it won’t work.

After completing the short onboarding process, you’ll be all set and can pin issues and bugs directly to web pages. You can’t highlight random areas of the page; the tool is tied to DOM elements — a useful but questionable solution. We particularly had problems selecting big areas of the page.

While not a major issue, the indicator can be hard to notice on light and gray backgrounds, so you might have to refer to the task list to find it sometimes.

Another drawback is the size and location of the side panel, which occupies a big part of the page, hiding your pins and most of the page.

The side panel is a bit too big.

BugHerd offers quite a lot of integration (we tried Basecamp and JIRA). Unfortunately, integration seems to work only one way for now — tasks created in Bugherd are sent to Basecamp, but if you update them directly in Basecamp, you won’t be notified of the changes in Bugherd.

13Bugherd’s toolbar. (View large version14)

Overall, the product is very good. The UX is questionable in places — as mentioned, the side panel is just too big. Prices are a little steep, too; prepare to pay almost $100 for a team of five.

  • Highlight bugs directly on the web page
  • Anonymous comments allowed
  • Screenshot automatically sent with every bug report
  • A lot of third-party integration
  • Sidebar is too big
  • Integration with third-party systems is one way
  • Quite expensive
  • Extension required to capture screenshots
  • Expensive for teams
Third-Party Integration
  • JIRA
  • Basecamp
  • GitHub
  • Redmine
  • Zendesk
  • Pivotal Tracker
Supported Browsers
  • Chrome
  • FireFox
  • Safari
  • Internet Explorer

Pricing starts at $19 per month. A short free trial is available, after which you’ll have to pay for each user on the account.


Notable2315 is a web-based application for sharing feedback on images, mockups and live website designs. The user takes a screenshot of any interface, draws a box around the area they want to comment on and then types in their feedback.

16Notable is a web-based application for sharing feedback on images, mockups and live website designs. User Experience

You start the registration process by entering your payment details, even if you’ve selected a trial account. If you want to skip this step, then you just have to watch a demo video of the service on YouTube and then install the required extension. Then, when you click the extension’s icon, the app automatically takes a screenshot and uploads it to the server. After the upload, you are redirected to the saved screenshot, where you can highlight any area and add comments.

17Notable in action. (View large version18)

It also saves HTML and CSS from the page, including meta tags, in text format. This separation of code, styles and images seems less useful than BugHerd and TrackDuck’s method, but it might appeal to some users.

  • Export custom PDFs
  • Unlimited team members
  • Ability to comment on source code
  • Credit card is required
  • Browser extension is required
  • Cannot mark up dynamic elements of web pages
Third-Party Integration
  • No information found
Supported Browsers
  • Chrome
  • Internet Explorer
  • Safari
  • Firefox
  • bookmarklet (for other browsers)

Pricing starts at $19 per month, and a 30-day trial is available. A credit card is required for all plans.

Our Choice

Before visual feedback tools, it was difficult to imagine a project manager’s daily workflow without the endless emails and chats between designers and developers. Email was the primary means of communication, and it felt like a big waste of time.

A colleague of ours introduced us to BugHerd, which is an awesome tool for collaborating on web projects, and we started using it. Later, we switched to TrackDuck for a few reasons. First, the service is relatively new and takes advantage of modern web technology. It also offers the same functionality but is significantly more affordable for medium and large teams. In addition, we use Basecamp to manage projects, and the two apps integrate nicely. As a bonus, TrackDuck offers two-way integration, with updates being sent to both systems automatically.


Visual-feedback and bug-tracking services are becoming ever more popular, and integrating one of them into their workflow would simplify the communication process of any web developer. Taking the five that we’ve identified and that we think are the most useful, we’ve laid out the advantages of each in the table below to help you determine which is right for you.

Service Advantages Pricing InVision LiveCapture192
  • Easy to work with
  • Great for collecting inspirational ideas
  • Ideal for existing customers looking to get more out of Invision
  • Free for InVision users
  • Unlimited number of team members
  • Cross-browser
  • Technical details are collected automatically
  • Real time with WebSockets
  • No extension needed
  • Anonymous feedback allowed
  • $0 – $49
  • 14-day trial
  • Free plan forever
  • Export custom PDFs
  • Unlimited team members
  • Ability to comment on source code
  • $19 – $199
  • 30-day trial
  • Highlight problems directly on web page
  • Anonymous comments allowed
  • Screenshot sent automatically with each bug report
  • A lot of third-party integration
  • $29 – $180
  • 14-day trial
  • Export custom PDFs
  • Unlimited team members
  • Ability to comment on source code
  • $19 — $99
  • 30-day trial
  • Credit card required

If you have experience using visual feedback services, please let us know in the comments below.

(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

The post Essential Visual Feedback Tools For Web Designers appeared first on Smashing Magazine.

Making Modal Windows Better For Everyone

Mon, 09/15/2014 - 11:23

To you, modal windows1 might be a blessing of additional screen real estate, providing a way to deliver contextual information, notifications and other actions relevant to the current screen. On the other hand, modals might feel like a hack that you’ve been forced to commit in order to cram extra content on the screen. These are the extreme ends of the spectrum, and users are caught in the middle. Depending on how a user browses the Internet, modal windows can be downright confusing.

Modals quickly shift visual focus from one part of a website or application to another area of (hopefully related) content. The action is usually not jarring if initiated by the user, but it can be annoying and disorienting if it occurs automatically, as happens with the modal window’s evil cousins, the “nag screen” and the “interstitial.”

However, modals are merely a mild annoyance in the end, right? The user just has to click the “close” button, quickly skim some content or fill out a form to dismiss it.

Well, imagine that you had to navigate the web with a keyboard. Suppose that a modal window appeared on the screen, and you had very little context to know what it is and why it’s obscuring the content you’re trying to browse. Now you’re wondering, “How do I interact with this?” or “How do I get rid of it?” because your keyboard’s focus hasn’t automatically moved to the modal window.

This scenario is more common than it should be. And it’s fairly easy to solve, as long as we make our content accessible to all through sound usability practices.

For an example, I’ve set up a demo of an inaccessible modal window2 that appears on page load and that isn’t entirely semantic. First, interact with it using your mouse to see that it actually works. Then, try interacting with it using only your keyboard.

Better Semantics Lead To Better Usability And Accessibility

Usability and accessibility are lacking in many modal windows. Whether they’re used to provide additional actions or inputs for interaction with the page, to include more information about a particular section of content, or to provide notifications that can be easily dismissed, modals need to be easy for everyone to use.

To achieve this goal, first we must focus on the semantics of the modal’s markup. This might seem like a no-brainer, but the step is not always followed.

Suppose that a popular gaming website has a full-page modal overlay and has implemented a “close” button with the code below:

<div id="modal_overlay"> <div id="modal_close" onClick="modalClose()"> X </div> … </div>

This div element has no semantic meaning behind it. Sighted visitors will know that this is a “close” button because it looks like one. It has a hover state, so there is some visual indication that it can be interacted with.

But this element has no inherit semantic meaning to people who use a keyboard or screen reader.

There’s no default way to enable users to tab to a div without adding a tabindex attribute to it. However, we would also need to add a :focus state to visually indicate that it is the active element. That still doesn’t give screen readers enough information for users to discern the element’s meaning. An “X” is the only label here. While we can assume that people who use screen readers would know that the letter “X” means “close,” if it was a multiplication sign (using the HTML entity &times;) or a cross mark (&#x274c;), then some screen readers wouldn’t read it at all. We need a better fallback.

We can circumvent all of these issues simply by writing the correct, semantic markup for a button and by adding an ARIA label for screen readers:

<div id="modal_overlay"> <button type="button" class="btn-close" id="modal_close" aria-label="close"> X </button> </div>

By changing the div to a button, we’ve significantly improved the semantics of our “close” button. We’ve addressed the common expectation that the button can be tabbed to with a keyboard and appear focused, and we’ve provided context by adding the ARIA label for screen readers.

That’s just one example of how to make the markup of our modals more semantic, but we can do a lot more to create a useful and accessible experience.

Making Modals More Usable And Accessible

Semantic markup goes a long way to building a fully usable and accessible modal window, but still more CSS and JavaScript can take the experience to the next level.

Including Focus States

Provide a focus state! This obviously isn’t exclusive to modal windows; many elements lack a proper focus state in some form or another beyond the browser’s basic default one (which may or may not have been cleared by your CSS reset). At the very least, pair the focus state with the hover state you’ve already designed:

.btn:hover, .btn:focus { background: #f00; }

However, because focusing and hovering are different types of interaction, giving the focus state its own style makes sense.

.btn:hover { background: #f00; } :focus { box-shadow: 0 0 3px rgba(0,0,0,.75); }

Really, any item that can be focused should have a focus state. Keep that in mind if you’re extending the browser’s default dotted outline.

Saving Last Active Element

When a modal window loads, the element that the user last interacted with should be saved. That way, when the modal window closes and the user returns to where they were, the focus on that element will have been maintained. Think of it like a bookmark. Without it, when the user closes the modal, they would be sent back to the beginning of the document, left to find their place. Add the following to your modal’s opening and closing functions to save and reenable the user’s focus.

var lastFocus; function modalShow () { lastFocus = document.activeElement; } function modalClose () { lastFocus.focus(); // place focus on the saved element } Shifting Focus

When the modal loads, focus should shift from the last active element either to the modal window itself or to the first interactive element in the modal, such as an input element. This will make the modal more usable because sighted visitors won’t have to reach for their mouse to click on the first element, and keyboard users won’t have to tab through a bunch of DOM elements to get there.

var modal = document.getElementById('your-modal-id-here'); function modalShow () { modal.setAttribute('tabindex', '0'); modal.focus(); } Going Full Screen

If your modal takes over the full screen, then obscure the contents of the main document for both sighted users and screen reader users. Without this happening, a keyboard user could easily tab their way outside of the modal without realizing it, which could lead to them interacting with the main document before completing whatever the modal window is asking them to do.

Use the following JavaScript to confine the user’s focus to the modal window until it is dismissed:

function focusRestrict ( event ) { document.addEventListener('focus', function( event ) { if ( modalOpen && !modal.contains( ) ) { event.stopPropagation(); modal.focus(); } }, true); }

While we want to prevent users from tabbing through the rest of the document while a modal is open, we don’t want to prevent them from accessing the browser’s chrome (after all, sighted users wouldn’t expect to be stuck in the browser’s tab while a modal window is open). The JavaScript above prevents tabbing to the document’s content outside of the modal window, instead bringing the user to the top of the modal.

If we also put the modal at the top of the DOM tree, as the first child of body, then hitting Shift + Tab would take the user out of the modal and into the browser’s chrome. If you’re not able to change the modal’s location in the DOM tree, then use the following JavaScript instead:

var m = document.getElementById('modal_window'), p = document.getElementById('page'); // Remember that <div id="page"> surrounds the whole document, // so aria-hidden="true" can be applied to it when the modal opens. function swap () { p.parentNode.insertBefore(m, p); } swap();

If you can’t move the modal in the DOM tree or reposition it with JavaScript, you still have other options for confining focus to the modal. You could keep track of the first and last focusable elements in the modal window. When the user reaches the last one and hits Tab, you could shift focus back to the top of the modal. (And you would do the opposite for Shift + Tab.)

A second option would be to create a list of all focusable nodes in the modal window and, upon the modal firing, allow for tabbing only through those nodes.

A third option would be to find all focusable nodes outside of the modal and set tabindex="-1" on them.

The problem with these first and second options is that they render the browser’s chrome inaccessible. If you must take this route, then adding a well-marked “close” button to the modal and supporting the Escape key are critical; without them, you will effectively trap keyboard users on the website.

The third option allows for tabbing within the modal and the browser’s chrome, but it comes with the performance cost of listing all focusable elements on the page and negating their ability to be focused. The cost might not be much on a small page, but on a page with many links and form elements, it can become quite a chore. Not to mention, when the modal closes, you would need to return all elements to their previous state.

Clearly, we have a lot to consider to enable users to effectively tab within a modal.


Finally, modals should be easy to dismiss. Standard alert() modal dialogs can be closed by hitting the Escape key, so following suit with our modal would be expected — and a convenience. If your modal has multiple focusable elements, allowing the user to just hit Escape is much better than forcing them to tab through content to get to the “close” button.

function modalClose ( e ) { if ( !e.keyCode |s| e.keyCode === 27 ) { // code to close modal goes here } } document.addEventListener('keydown', modalClose);

Moreover, closing a full-screen modal when the overlay is clicked is conventional. The exception is if you don’t want to close the modal until the user has performed an action.

Use the following JavaScript to close the modal when the user clicks on the overlay:

mOverlay.addEventListener('click', function( e ) if ( == modal.parentNode) modalClose( e ); } }, false); Additional Accessibility Steps

Beyond the usability steps covered above, ARIA roles, states and properties3 will add yet more hooks for assistive technologies. For some of these, nothing more is required than adding the corresponding attribute to your markup; for others, additional JavaScript is required to control an element’s state.


Use the aria-hidden attribute. By toggling the value true and false, the element and any of its children will be either hidden or visible to screen readers. However, as with all ARIA attributes, it carries no default style and, thus, will not be hidden from sighted users. To hide it, add the following CSS:

.modal-window[aria-hidden=”true”] { display: none; }

Notice that the selector is pretty specific here. The reason is that we might not want all elements with aria-hidden="true" to be hidden (as with our earlier example of the “X” for the “close” button).


Add role="dialog" to the element that contains the modal’s content. This tells assistive technologies that the content requires the user’s response or confirmation. Again, couple this with the JavaScript that shifts focus from the last active element in the document to the modal or to the first focusable element in the modal.

However, if the modal is more of an error or alert message that requires the user to input something before proceeding, then use role="alertdialog" instead. Again, set the focus on it automatically with JavaScript, and confine focus to the modal until action is taken.


Use the aria-label or aria-labelledby attribute along with role="dialog". If your modal window has a heading, you can use the aria-labelledby attribute to point to it by referencing the heading’s ID. If your modal doesn’t have a heading for some reason, then you can at least use the aria-label to provide a concise label about the element that screen readers can parse.

What About HTML5’s Dialog Element?

Chrome 37 beta and Firefox Nightly 34.0a1 support the dialog element, which provides extra semantic and accessibility information for modal windows. Once this native dialog element is established, we won’t need to apply role="dialog" to non-dialog elements. For now, even if you’re using a polyfill for the dialog element, also use role="dialog" so that screen readers know how to handle the element.

The exciting thing about this element is not only that it serves the semantic function of a dialog, but that it come with its own methods, which will replace the JavaScript and CSS that we currently need to write.

For instance, to display or dismiss a dialog, we’d write this base of JavaScript:

var modal = document.getElementById('myModal'), openModal = document.getElementById('btnOpen'), closeModal = document.getElementById('btnClose'); // to show our modal openModal.addEventListener( 'click', function( e ) {; // or modal.showModal(); }); // to close our modal closeModal.addEventListener( 'click', function( e ) { modal.close(); });

The show() method launches the dialog, while still allowing users to interact with other elements on the page. The showModal() method launches the dialog and prevents users from interacting with anything but the modal while it’s open.

The dialog element also has the open property, set to true or false, which replaces aria-hidden. And it has its own ::backdrop pseudo-element, which enables us to style the modal when it is opened with the showModal() method.

There’s more to learn about the dialog element than what’s mentioned here. It might not be ready for prime time, but once it is, this semantic element will go a long way to helping us develop usable, accessible experiences.

Where To Go From Here?

Whether you use a jQuery plugin or a homegrown solution, step back and evaluate your modal’s overall usability and accessibility. As minor as modals are to the web overall, they are common enough that if we all tried to make them friendlier and more accessible, we’d make the web a better place.

I’ve prepared a demo of a modal window4 that implements all of the accessibility features covered in this article.

(hp, il, al, ml)

  1. 1
  2. 2
  3. 3
  4. 4

The post Making Modal Windows Better For Everyone appeared first on Smashing Magazine.

Are Your Internal Systems Damaging Your Business?

Fri, 09/12/2014 - 13:59

The internal systems of many organizations have shocking user interfaces. This costs companies in productivity, training and even the customer experience.

Fortunately, we can fix this.

“How come I can download an app on my phone and instantly know how to use it, yet need training to use our content management system? Shouldn’t our system be intuitive?”

This was just one of the comments I heard in a recent stakeholder interview. People are fed up with inadequate internal systems. Many of those I interviewed had given up on the official software. Instead, they use tools like Dropbox, Google Docs and Evernote.

The problem seems to exist across the board. I am hearing the same thing from employees across many companies and sectors. I am also hearing it about almost all types of internal systems, from ones for customer relationship management (CRM) to ones for procurement. They are all painful to use.

Frustration will only increase as millennials enter the workforce. These people are digital natives, and they expect a certain standard of software. They expect software to adapt to them, not the other way around.

The result of this frustration is that employees are abandoning these systems. People use email instead of a CRM and put documents in Dropbox rather than on the intranet. This leads to systems being out of date and, thus, irrelevant to the organization.

How have things gotten to this state? Why is enterprise software so bad?

One Size Does Not Fit All

I think technology is often oversold. “A content management system is the solution to content!” “An intranet is the answer to improving efficiency!” “A CRM system will manage the customer relationship!” But that is just not true.

Unfortunately, in the eyes of senior management, once a piece of software is purchased, the problem is solved. Job done, move on to the next challenge.

One size rarely fits all. Organizations rarely work in the same way, even within the same sector. Even if a law firm purchases an intranet designed for the legal sector, the system won’t necessarily work well out of the box for that firm.

People work in different ways. The functionality required by the secretary to the CEO will be different from the functionality required by someone in accounting or HR. Yet many enterprise systems do nothing to streamline the experience for different groups. (Image source: opensourceway1)

Many of these systems could be tailored to the needs of individual organizations or employees, but they are not so out of the box. They need to be configured and optimized, which usually does not happen — or else the wrong system is purchased to begin with.

There must be a better way.

Starting With Users’ Needs

The procurement process for these systems too often begins with a list of desired features. This is the wrong starting point. We should approach internal software in the same way that we develop external applications: starting with users’ needs.

Regardless of whether you already have a system in place, identify your different user groups. Who will be using each system? Once you know that, shadow them for a while. Understand how they work. What do they do each day, and what system do they already use to get their work done?

Look for pain points in that system, and talk to them about where they get frustrated. Identify the information they need to do their job, and be aware of any clutter that gets in the way.

Finally, identify your users’ top tasks. Which tasks do your different user groups do again and again. These need to be super-accessible.

You might think that you now have enough information to buy a system. But just because something has the functionality you need does not mean it is easy to use. Before leaping for expensive software, design the user experience. We can do that with some simple prototyping.

Prototype Your Perfect System

Creating a prototype of how your ideal system would work does not need to be time-consuming or particularly expensive. Best of all, it could replace a long-winded and abstract specification of functions.

Using nothing but a bit of HTML, CSS and JavaScript, we can build a working prototype that can be tested with real users. Does this prototype match their workflow? Does it give them quick access to key tasks? Does it accommodate the differences between groups? Which parts of the prototype are having the biggest impact on productivity, and which are just nice to have?

We can iterate on the prototype based on user feedback until it offers the optimal experience.

With that vision in place, you can compromise intelligently.

Informed Compromise

A working prototype is a good standard by which to measure different software — much better than a specification.

Could your existing system be set up to mirror the prototype? If it can’t exactly, then which areas would you have to compromise on? Based on your user testing, are these compromises acceptable?

If your existing system cannot replicate the key functionality of the prototype, look at alternatives. Talk to other vendors and show them your prototype. Ask whether their system can replicate it, and once again, decide on areas of compromise based on user feedback.

Do you see the difference here? The experience is designed around the user, not around what the software provides. Also, if you cannot find software that meets the needs of your users, consider building a bespoke system.

Buying software off the shelf makes no sense if no one will use it or if it provides no business value. (Image source: opensourceway2)

I know what you’re thinking. This makes sense, but senior management won’t go for it. They won’t pay for a prototype or a bespoke system. Well, that depends on how you sell it.

Selling The Need For A User-Centric System

Convincing management to spend money on a prototype can be hard. It’s hard enough when a clever salesperson says that their software will solve all of the company’s problems — harder still if management has already paid for a fancy system. Nevertheless, solid business arguments can be made for this approach.

If your company has a system that is not fit for its purpose, you should be able to prove this. Collect data on how users interact with the system. Combine this with user testing and stakeholder interviews. This should be enough to establish a compelling case — at least compelling enough to justify some limited prototyping of an alternative approach.

Remember that you are not asking them to replace the system. You just want to prototype a potentially better solution and see whether the current software could be set up to match it. When managers see a better way, they will usually be open to change.

If the company does not already own a system, then your position is even stronger. Enterprise software is expensive, and so ensuring the right fit is important. Getting it wrong could mean hundreds or thousands of dollars wasted. A prototype will prove more effective than a specification at measuring the suitability of different products. It will also make it easier to compare software.

Of course, management could take the position that employees will just need to get used to what they have. This argument has some merit. Given time, users would adapt to even the most archaic of systems. But at what cost?

The Cost Of Failure

Poor user interfaces require more training and support. Both are a cost borne by the organization, not to mention the frustration it causes. Even more significant is the cost in lost productivity. Organizations are keen to maximize efficiency, and systems that are easy to use go a long way towards this.

Unfortunately, some managers seem to care little about internal processes. But they do care about customer satisfaction, which is becoming one of the most popular factors for organizations to measure. We now live in a world of consumers who are connected and have a voice through social media. That makes organizations sensitive to negative comments and experiences.

Internal systems weigh heavily on the performance of your employees. And they have a massive impact on the customer experience. These systems ensure timely responses; they help deliver the product; and they facilitate customer relationships. This is why internal systems are becoming the next big competitive advantage.

Are you struggling to implement an effective digital strategy? Do you need help bringing about a digital transformation? The Digital Adaptation4 book can help you prepare and adapt your company for the new digital landscape, and teach you everything you need to know. — Ed.

(al, il)

  1. 1
  2. 2
  3. 3
  4. 4

The post Are Your Internal Systems Damaging Your Business? appeared first on Smashing Magazine.

Dropbox’s Carousel Design Deconstructed (Part 2)

Thu, 09/11/2014 - 13:34

Many of today’s hottest technology companies, both large and small, are increasingly using the concept of the minimum viable product (MVP) as way to iteratively learn about their customers and develop their product ideas. This two-part series, looks into the product design process of Dropbox’s Carousel.

Part 11 covered the core user, their needs and Dropbox’s business needs, and broke down existing photo and video apps. This second part is about Carousel’s primary requirements, the end product, its performance and key learnings since the launch.

Primary User Requirements

In a Wired article2 covering Carousel’s launch, Gentry Underwood, CEO and cofounder of Mailbox (which was acquired by Dropbox) and lead designer of Carousel, detailed some of the key requirements that his team prioritized.

Below is a list of some of them, as well as some requirements highlighted in media coverage of Carousel’s launch3 and from our evaluation of existing products and design patterns in part 1.

Back up all photos and videos

The app has to save not only the photos that users want to see in the gallery, but also ones they don’t want to see yet but might want to at a later date. Not to mention, this takes up more storage, which is ideal for Dropbox’s business. Most photo apps allow you only to delete photos, not hide them. “It’s a 100% destructive thing,” Underwood says. And the permanence of deleting photos requires a heavy two-step process of hitting the trash button and confirming the action. Underwood claims that this leads to users not deleting media and, ultimately, to sloppy media galleries with misfires, blurry selfies and many imperfect versions of the same shot.

Display all photos and videos

According to Underwood, another big problem with media gallery apps is that they seem to start from the last time you bought a smartphone. This is especially true for stock apps like Apple’s Photos. However, even with photo stream and other apps that sync a portion of your photos locally while saving the rest in the cloud, users can never see their entire media history — they have to go to their computer or the web for that.

Show the best photos and videos

The most obvious solution for this is to make it easy to manually hide undesired media, presumably with some quick swiping action. However, the app could also surface media that users would most likely want to see, like ones with faces or, more importantly, smiling faces. Beyond finding the best media, the app could also highlight one or more thumbnails of media that seem most interesting.

Enable quick navigation

Media should be automatically sorted in events based on common attributes such as time and location. The groupings should also show just a sample of the photos from that event in order to save space while navigating through a long list. Finally, users should have multiple ways to scroll through media (for example, slowly or quickly).

Feel native

Making it seem like everything is stored locally would set this application apart from the competition. After all, that snappy feeling is what makes Apple’s Photos more appealing than Facebook, Flickr, Instagram, Dropbox and the like. Among other things, fine-tuning the caching and other back-end tricks could help dramatically. But some clever perceptual tricks could also be done. For example, multiple thumbnails of each media file could be saved at various resolutions and be dynamically deployed based on how fast the user is scrolling through the gallery. Faster scrolling would trigger lower-resolution thumbnails so that they load instantly and make the app feel native. Moreover, adding, moving, changing and deleting media files from Carousel or Dropbox should happen lightning-fast.

Enable public and private sharing

Users should be able to share videos and photos with others easily without having to use platforms with storage limitations, such as email. Also, they should be able to easily select between public sharing (i.e. on social networks) and private sharing through email, SMS and private in-app chat. “Carousel’s sharing tools can be utilized through any email address or phone number, whether the recipient has a Dropbox account or not,” says Underwood.

Enable public and private discussion

Although in-app discussion is an option when media is shared privately, as mentioned above, it’s not necessary. However, allowing for focused discussion on a set of photos — particularly after an event, when users want to congregate and compare photos — can be valuable. As an alternative to Facebook Messenger, SMS and email, where many other conversations go on, offering a dedicated set of chat threads for users’ personal media and nothing else would be beneficial. It would also be a great way to acquire new users for Dropbox.

What Do Users Get?

Basically, users get a camera roll for Dropbox. As Federico Viticci from MacStories eloquently puts it4, the app is a clean and imaginative “alternative Camera Roll and Photo Stream based on Dropbox storage with built-in sharing for individual or group conversations.”

Carousel’s MVP is effectively two things for most users: a Dropbox uploader for backing up local photos and videos, and an enhanced version of Apple’s native Photos app, with improved viewing, sharing and discussion functionality. The app doesn’t let users take, edit or manage photos, other than hiding them (or deleting them, if they can find that feature), or view in anything other than chronological order.

For now, if users want to take and edit photos, then their mobile camera, Instagram or Camera+ are great options. To organize photos into folders, they’ll need to use Dropbox directly. And to view them in anything other than chronological order, they would sync Dropbox with a more advanced media gallery such as iPhoto, Picasa or Unbound. You will understand Carousel’s MVP much more easily by testing it out than by listening to me explain it ad nauseam. Below are four screenshots of what you can expect. To help you along, MacStories thoughtfully runs through5 what you can expect in your first experience.

Carousel mobile app (View large version7) Results And Learning

Mills Baker, a product design analyst at Mokriya, paints a rather dismal picture of Carousel in “Designer Duds: Losing Our Seat at the Table8”:

It’s honestly hard to determine what should be interesting about it, even in theory; it takes mostly standard approaches to organization, display, and sharing, and seems to do little to distinguish itself from the default iOS Photos app + iCloud Photo Sharing, let alone apps and services like Instagram, VSCO Cam, Snapchat, iMessage, Facebook Messenger, and so on.

To get an idea of why Mills feels so strongly about Carousel’s shortcomings, let’s look at the results since its launch.


Since topping the charts on and around launch day, Carousel has steadily lost attention, now ranking 456th in the “Photo and Video” category of Apple’s App Store and falling off in the overall rankings across all categories. It has basically been buried in the crowded photo and video app market, and Dropbox will need to make some non-trivial changes in subsequent iterations to make it bounce back to the top.

9Carousel’s ranking has steadily declined since launch. (Image: AppAnnie25211310) (View large version11)

Upon launching in April 2014, the app certainly didn’t increase downloads of Dropbox’s main app, suggesting that Carousel’s main impact was on revenue or engagement, if anything.

Dropbox’s ranking hasn’t been affected by Carousel. (Image: AppAnnie25211310) (View large version14) Downloads

As of 16 July 2014, Carousel appears to have been downloaded 174,000 times15 globally. If Dropbox currently has 300 million users16, then it has managed to get a paltry .06% of its total customer base to adopt Carousel. Clearly, it needs to make some improvements to increase adoption.

Carousel downloads are sufficient for testing the app, not for claiming mass adoption. (Image: XYO18) (View large version19) Ratings

If we look at reviews in Apple’s App Store, non-target users almost unanimously consider Carousel to be a failure. “Not what I wanted,” “MASSIVE oversight” and “Completely useless” smatter the reviews section — all valid complaints if people are using it professionally. Meanwhile, average consumers like Owen and Nora have mixed reviews, ranging from “Amazing app!!!! This app is the best way to back up and privately share my photos on iOS!!!” to “Bring back Loom! Complete downgrade from Loom… Sad.”

While it wasn’t a runaway success upon launch, Carousel drew user reviews in the US and internationally that at least skew favorably. In fact, the reviews are as good as the ones for Dropbox and even Mailbox, both excellent standards for any productivity app.

Reviews for the first version of Carousel globally (left) and in the US (right). (Image: AppAnnie25211310) (View large version22)

While these reviews make it difficult to dispute Baker about the lackluster adoption of Carousel upon launch, 174,000 downloads is more than enough to learn about how people use Carousel, what needs to be improved and how well various features help Dropbox achieve its business goals.

In-App Purchases

While these statistics are highly coveted and, thus, kept very private, you can at least generalize that Carousel is achieving its primary objective of upselling existing users to premium accounts. However, many details suggest that Dropbox will need to make some major improvements to scale downloads and usage for new and existing users.

With Dropbox charging roughly ten times the price of Google’s popular cloud storage alternative, Drive, it will be interesting to see how much price has stunted adoption of and engagement with Carousel. If we’re being realistic, anyone who wasn’t born yesterday would know that Carousel requires Dropbox’s Pro Plan23 to work reliably. Dropbox will certainly have to address this as companies continue to compete on price in building up their cloud-based apps on top of virtually free cloud storage.

Top in-app purchases for Carousel (left) and Dropbox (right). (Image: AppAnnie25211310) (View large version26) Looking Forward To The Next Iteration

As expected, this MVP is far from being a full photo and video manager. It lacks some features that hold users back from adopting it, including:

  • better meta data and a better organizational structure for navigating photos,
  • more granular syncing options to reduce clutter,
  • a web viewer for making sharing easier,
  • lower pricing.

However, if you look closely at everything Dropbox has done with Carousel, it has been extremely disciplined in prioritizing many of the most important features for its business and its users. It has drawn from the best relevant design patterns that I could find, many of which are not to be found in the closest alternatives, including Apple’s Photos and Instagram Direct. And while most mobile photos galleries aren’t that complex, Dropbox has managed to edit out features that are less important, such as a camera, editing features, heavy organization options, chat outside of sharing, and friend lists.

It still has a ton of work to do on the web and mobile. Considering how much people wish Loom was still around, many of its features will probably be included. Additionally, well-designed and robust apps such as Picturelife offer a great deal of inspiration for a dramatically simplified alternative to Carousel.

And while Dropbox might have done better to wait for what Rand Fishkin, cofounder of Moz, calls an EVP27 — an exceptional viable product — Carousel has a promising future. Dropbox just needs to tweak what it’s got to get more people to download and use the app.

(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

The post Dropbox’s Carousel Design Deconstructed (Part 2) appeared first on Smashing Magazine.

Creating Clickthrough Prototypes With Blueprint

Wed, 09/10/2014 - 13:10

In a previous article1, I discussed using POP2 to create sketch-based clickthrough prototypes in participatory design exercises. These prototypes capture well the flow and overall layout of early design alternatives.

The same piece briefly mentioned another category of clickthrough prototypes: widget-based mockups that are designed on the target device and that expand on sketches by introducing user interface (UI) details and increased visual fidelity. These prototypes can be used to pitch ideas to clients, document interactions and even test usability. In this article, I will teach you how to use the iPad app Blueprint to put together such prototypes in the form of concept demos, which help to manage a client’s expectations when you are aligning your visions of a product.

Given the software’s rich feature set, I will cover the most useful functionality that helps designers get up and running with the tool. To make the exercise more realistic, I will reuse the earlier POP scenario. A link to the Blueprint work file is shared in the “Resources” section at the bottom. An exciting exploration lies ahead of us, so let’s jump right in!

The completed Blueprint project shows the complexity of widget-based clickthrough prototypes. (View large version4)

Where Do Concept Prototypes Fit In The Design Process? Clients as Knowledge Ambassadors

Stakeholders and user experience designers (UXers) come to participatory design meetings with experience from other projects, research knowledge and background information. Many clients bring a fresh perspective by offering specific ideas, but some need extra help from designers to translate business requirements into usable experiences. To do so, designers need to learn about the client’s domain. This is where stakeholders’ expertise becomes an invaluable resource for clarifying problematic aspects of the product.

Stakeholders and designers come together to make the end product even better.

Stakeholders will also gain insight into the design process and will feel that their voices are being heard. Regardless of their level of enthusiasm or participation, however, many will be ill-equipped to understand the activity’s outcomes: How many times have you been met with blank stares when explaining flow diagrams and UI layouts?

Don’t Just Explain: Tell a Story

To more clearly communicate the design direction of a project, you must revisit the communication from the perspective of a stakeholder: UXers must show how a concept will solve users’ problems and how it will do so by distinguishing itself from the competition through unique selling points. Storytelling, a very inclusive activity, welcomes the audience to the experience intended for end users.

Stories help an audience enter new worlds.

One approach is to use widget-based clickthrough prototypes to show off various user scenarios in a story: The interactivity of the design concepts paint a picture of the envisioned product. You can reinforce the narrative with highly polished prototypes, but their visual fidelity should be driven by the motivation of your audience and the goals of the project. Just as storytellers did around campfires, use visual aids: Present the prototypes on the target device for greater impact. The demo might be interrupted by feedback from stakeholders, but remember that you are there to present a vision, not a complete product, so unsolicited input won’t affect the throwaway concept.

Building Concept Prototypes Underlying Consideration

Personal experience has shown me that prototyping several key concept scenarios, which takes 45 minutes to 1 hour to walk through, leave the most lasting memory. If your delivery is longer, the audience will get uneasy. Show off a single flow with high interactivity or several more linear flows, but be cognizant of what you want to accomplish with the demo: Sometimes it is to sell the work, and other times to guide the team to the next design step.

Presenting an abundance of detail in a short period of time will block your participants’ understanding. Be brief!

Because concept prototypes communicate design vision, they must be of high fidelity. The fidelity, however, could become distracting: Stakeholders might grab onto less important details, such as a button’s color, rather than pay attention to the overall design. Avoid this situation by clearly setting their expectations for the demo up front: This is not a design critique. Rather, you are there to present a vision of the product. This will help to get agreement on the direction before you move to a large-scale evolutionary prototype as the final deliverable.

Designing Directly on the Device

Building concept designs directly on the target device has many benefits:

  • simulates UX of target device (for example, the platform’s input methods and the OS’ metaphors);
  • prototype is usable in different environments;
  • facilitates audience involvement;
  • easy to reproduce demo on external computers (wireless mirroring, wired video duplication, etc.);
  • easier access to visual assets (Dropbox, device’s photo gallery, etc.).

But it also has some inherent limitations:

  • Creating large widget-based clickthrough prototypes is not cost-effective.
  • Screen covers and enclosures can affect screen sensitivity.
  • A stylus is needed to avoid the fat-finger problem.
  • Neck and back fatigue can set in (leverage a stand to help).
  • Light reflection could also be a problem.
How Blueprint Fits In The Picture

Blueprint, a $20 app by groosoft5, enables you to create iPhone and iPad clickthrough prototypes on an iPad. The tool’s quality is best illustrated by building UIs with the ready-made widgets and the event model. The prototypes can be demoed in the application or via a free companion tool, Blueprint Viewer. There is also Blueprint Lite, but it limits the user to two projects and no external projects. Blueprint requires no user account because prototypes are distributed as a .blueprint file, a PDF specification or a series of PNG images. See the “Exploring the Export Options146” section below for more.

Create the Project’s Container

You are assigned to create a mobile news website! After meeting the stakeholders, you put some initial ideas for pages on paper, including the portal, individual articles and other ideas. Having heard about Blueprint, this new prototyping tool, you want to give it a shot! I will guide you by covering its main functionality, which we will use to build an interactive prototype. For detailed coverage of its features, feel free to browse groosoft’s “Tutorials7” section.

As with other design tools, you must store your project somewhere. To do this in Blueprint, you start by creating a project container first for all of your screens. In the “Home Screen,” tap the “+” (third icon in bottom toolbar). This will bring up a menu with two options (not shown here) to create a new project or duplicate an existing one. Duplicating an existing project is handy if you need to create different versions of the same project or to leverage assets in an existing prototype.

Options for importing, exporting, converting and deleting projects also appear on this screen. (View large version9)

Your stakeholders have data from Google Analytics showing an iPhone user base of over 30%! Upon selecting “New Project,” you have to select an iPhone app, mobile website or iPad app in portrait and landscape orientation. Given the large iPhone population, let’s select the entry for mobile website!

The top-right tab toggles between prototyping for iOS 6 and 7. As a good practice, pick the latest version of iOS because the majority of users upgrade quickly. For our example, let’s pick iOS 6, which will enable you to play with the iOS Converter later (a $10 add-on that updates the look and feel of iOS 6 projects to match iOS 7).

iOS 7’s look and feel are applied by default, but you can switch to iOS 6. (View large version11)

Once you select the target device, you will see the project’s first screen. Before we discuss it, let’s backtrack to the “Home Screen” for a second. Because you’re a designer, the quality of your deliverable speaks to your professionalism; therefore, you will need to provide details about the project. Tapping the “i” icon in the bottom-right corner reveals fields to capture the project’s title, a description, the author’s name and other information. It’s easy to forget to enter this data later on, so do this before you start to prototype. Tap the white checkmark to save.

Here you can also adjust the phone’s aspect ratio by selecting “iPhone 4” or iPhone 4 / 5.” (View large version13)

Import an Existing Project

As a first time user, you have no reusable assets. However, a colleague who is experienced with Blueprint has offered to share their .blueprint files with you. To view these files, you will need to import them. Go to the “Home Screen” and tap on the second icon: You can import .blueprint files from iTunes or Dropbox.

You must grant Blueprint access to your Dropbox account for this method. More on this is shared in the “Exploring the Export Options146” section near the end of this article. Once you’ve granted permission, you will find the folder containing your .blueprint files and, upon tapping a .blueprint file, it will be added to your list of projects. For more information on using Blueprint with iTunes, consult groosoft’s FAQ15 page. As long as your iOS mobile device is connected to the computer, you can drag a previously saved .blueprint file from the computer to Blueprint or to Blueprint Viewer in iTunes “Apps.”

Blueprint currently offers only two importing options. (View large version17)

Design Modes

You’re doing great! Let’s cover the design modes, which will help you to understand how Blueprint works. The app has two modes: the site map and the screen views. Both share functionality, including ways to center or view in full screen the workspace, to review the screen list and to take actions on items. You can toggle the views using the L13 icon in the “Local” toolbar (see the next section).

For most new projects, you will start in the screen view, with one working screen. At the screen level, you will be able to add widgets and cross-screen interactions. In contrast, the site map view enables you to organize screens spatially and to visualize the links (or paths) between screens in user flows.


Jumping to the screen design is easy, but a quick description of the controls will situate you in the application. Both views share the same toolbars, which have functionality specific to screens or their widgets. There are two of them: Global (named here “G”), which offers app-wide functionality, and Local (named “L”), which controls aspects of the current project. Throughout the prototype exercise, I will refer to entries from both toolbars. Notable entries in Global are “My Projects,” which returns you to “Home Screen” (G1), the self-explanatory “Add New Screen” (G3), and “Tools,” which contains help information and controls for on-screen guides (G5).

The controls are organized in two logical groupings, on either side of the project’s title. (View large version19)

The second toolbar lists tools associated with editing (some are disabled in site map view). A few less commonly used but practical features are the “Pen Tool” for drawing custom shapes in widgets (L1), the “Clock” to show the history of recently edited screens (L10), and the “Device Toggle” to change between iPhone 4S and 5 shells (L12).

The second tier of controls is organized in eight groups. (View large version21)

There is also the side panel, which is contextual. In the site map view, it shows screen links grouped by color (see the “Adding Interactivity22” section below). In the screen view, the panel updates with two tabs, “Widgets” and “Accessories.” The first displays configurable iOS components in the “Controls,” “Tables,” “Bars” and “Views” areas. The second shows annotation components, which are handy for capturing problems and questions.

Additionally, the side panel changes its contents according to whether the user is focused on a screen (in site map view) or a widget (in screen view). Two new tabs are revealed, “Properties” and “Actions.” The first includes configurable options for the selected screen or widget, while the second allows you to modify interactions. More on this in later sections!

Variations of the same side panel provide control of screens and individual widgets. (View large version24)

Using Images

Now that we have the project’s container, let’s create the individual screens and, lastly, layer on interactivity. Why do I say “create”? Are there no sketches from the earlier POP exercise? After meeting the stakeholders, you learn that you have additional time and so decide to improve the prototype by increasing its interactivity and visual fidelity (and not simply duplicate the POP sketches).

However, you can reuse the previously created images in Blueprint with a little trick. Paste the images into a background “View,” and layer transparent “Buttons” on top to link to other screens. This might be confusing now, but it will make sense when we build the first screen. Our prototype will have grayscale fidelity and (similar to POP) single-tap interactions. You can create colorful comp-like designs, and you are welcome to explore this as an exercise using the .blueprint file shared at the end of this article!

When using transparent “Buttons,” remember their placement because they will become hard to find. (View large version26)

Setting Up Your First Screen

Web experiences in Blueprint come with an initial empty screen, with the generic name “Screen.” For the experience you are designing, you will see a starting visitor portal. To navigate screens more easily, you’ll need to update their names to be human-readable. While in the site map view, under “Properties,” tap on “Title” and enter “1.0 Home.” To match the experience you are targeting, set how the status bar should be displayed by selecting “Black,” “White” or “None.” The “Start Screen” option is disabled because we have only one screen, but with multiple screens you can redefine the starting point.

Drag the workspace in the site map view to see all of its contents as you add more screens. (View large version28)

Populating the Screen With Widgets

You now know enough about Blueprint to start prototyping the concept! Let’s add some widgets to the screen. Double-tap the screen to enter the screen view. Add a background (the first entry in the “Views” collection) as the container for what’s to follow. This will give you control over the background color for the experience! Double-tap the widget in the panel or drag and drop it, thereby adding it to the screen.

A blue border highlights the container into which the widget is being dropped. (View large version30)

Don’t be confused by the updated side menu, which now shows the “Properties” and “Actions” tabs. What do I mean? We just dropped a “View” onto the “Screen.” You will notice that the side panel lists the options for “View,” then the options for “Screen.” This hierarchy helps when you’re deep-nesting widgets (for example, when building toolbars or list items).

Once you’ve dropped the widget onto the screen, you’ll see blue-dot handles to resize the widget. Tapping the widget again shows a flyout menu, with the options “Cut,” “Copy,” “Delete,” “Duplicate” and “Lock.” Your client is demanding, so these little features (especially “Select Subwidgets”) will help you to tackle changes. The folks behind Blueprint offer a shortcut to this via the gear icon, L9. For increased productivity, you can toggle between the “Properties” and “Actions” views by retapping a widget or the “i” icon, G4.

If you’re viewing the start screen of the prototype, its title will be in white. (View large version32)

I’ll let you in on a little secret! Backgrounds come with a hidden extra: When you resize a background, all child widgets get resized accordingly, thus saving you even more time and keeping your client happy! Earlier, I hinted at reusing sketch captures if you are pressed for time. To do this, just pick “Images” under “Properties” in the side menu. “Camera Roll” is one of the options, giving you access to all images on the device.

Under “Image” in the new window, you will find several preloaded icon libraries. (View large version34)

If you choose to show only the sketch on the screen, there is a way to hide the status bar. Turning it off is as easy as one, two, three: Go to “Properties” → “Screen” → “Status Bar” and voila! The sketch approach is limited because you are still locked to iOS’ resolution and aspect ratio. Use it wisely.

Blueprint has new popup screens for menu options. (View large version36)

You’ve just added your first widget, and now you want to create the remaining assets. Hold your horses, partner! Let’s first talk about a big problem. When you add closely positioned widgets, accurate placement becomes harder. Many a time I have tried to resize a widget only to end up moving it! Therefore, use a stylus to avoid the fat-finger problem. For extra precision, try the “Position” and “Size” adjustments under “Frame.”

“Position” and “Size” options are split into separate tabs. (View large version38)

Pinching in and out of “1.0 Home” will zoom in and out of details, a helpful technique to align widgets. Maintaining your workspace is a must in Blueprint: You can fit the screen within the workspace area again via L4, and you can reveal more vertical space by entering full screen via L5 (then double-tapping the screen to exit).

View the screen at maximum zoom by pinching out. (View large version40)

Awesome! You are fully armed to tackle the featured article’s hero space, the navigation toolbar and the month’s list of articles. First, change the color of the background to dark gray. Next — because we’ll want to show the client that rich imagery and meaningful titles will capture the visitor’s attention — drag an image widget, and resize it to fit the background widget, with gutter space of roughly 10 pixels. You can round the widget’s corners, or make it transparent if you are stacking layers of information. I will let you finish by adding the article’s title and the dot navigation. Refer to the .blueprint file for the completed widget!

The red line is a guideline, which was turned on via L4. (View large version42)

We anticipate a growing information architecture, so let’s select the side menu navigation pattern. To build the header toolbar that contains the hamburger toggle, drag another “View” and resize it to approximately 40 pixels in height. Then, drop a label widget on top of it for the title “News Site.” Next, add two text-free buttons with custom images. See whether you can figure out this part on your own. Here is a hint: Use the built-in icon libraries, and customize the images’ color to white!

After you’ve built the hero space and toolbar, you will want to move both of them at the same time via multi-selection. To add widgets with this method, tap and hold on the first widget and then, with another finger, tap on all following widgets. I recommend doing this with the tablet resting on a flat surface because you will need to use both hands. The tool has no alignment or distribution options — maybe in the next release!

You can change the alignment, style, font and many other options for each label. (View large version44)

The geek in me is tempted to cover the remaining steps here, but I will let you continue working on the project on your own. No fear! I am still here to guide you with best practices as you wrap up. For example, remember to duplicate reusable components, and expect to spent time building custom widgets. Blueprint offers many options, and you will keep finding useful functionality as you become comfortable with the tool (cool features are buried in submenus). Once you’ve dragged all widgets to the screen, you will end up on the final “1.0 Home” screen. Congratulations! You’ve just finished your first screen!

One screen down, a few more to go! (View large version46)

Maintaining Design Flexibility

You are ahead of schedule and want to finish the remaining screens, including the “Articles,” “Individual Article” and “Authors” views, but you notice that identifying a particular screen widget is hard. Blueprint nests widgets, and getting lost is easy if the widgets are of the same type. Before introducing any interaction and wowing your client, we should discuss features of the app that will make your design more flexible.

For example, the “Hierarchy” tool (L8) shows the nesting of a widget by using a top-down approach, with parent widgets shown on top. At each level, widgets are selectable and, when selected, are highlighted on the screen. You can also vary the depth of a widget via “Bring Forward” (L6) and “Send Backward” (L7). Lastly, it is worth reiterating L9, the gear icon and its “Select Subwidgets” option. This aids with copying multiple widgets without having to copy the parent. Phew, that was tiring!

Iterating Screens

Time is a wasting, and we don’t want to keep the client waiting. Let’s build the remaining screens already! Click the top “+” icon in the first toolbar (G3) to create a new screen or to duplicate the existing “1.0 Home” in either orientation. Unfortunately, Blueprint currently offer no master or template functionality. The duplication option will save you time because you won’t have to recreate the toolbar and background in other screens.

Duplicating an existing screen in landscape orientation rescales the screen’s widgets, as seen in the preview. (View large version48)

Designing clickthrough prototypes in Blueprint is iterative. You will complete one screen, then move on to the next, constantly switching between screen and site map view using the L13 icon. Upon finishing all screens, you will end up with a grid of thumbnails (as seen below) and with a sense of accomplishment for being closer to delivering a great presentation to the client. The screen’s layout may be modified to reflect the project’s flow(s). Making the design even more realistic is effortless: Toggle the device shell via the L2 icon for instantaneous results (in screen view only).

A grid layout helps with visualizing cross-screen links. (View large version50)

Adding Interactivity

The concept demo has many different paths and flows, so let’s add some interactivity. Key tasks include accessing an article from the home portal, accessing author information from anywhere on the website, and providing global access to the side menu navigation. With little time left, you decide to enable single-tapping with no transitions.

Double-tap “1.0 Home” to view all of its widgets. We want the user to be able to view an article’s details by tapping the list item. So, select the list item for the top article (a “View” widget). This will update the side menu to the “Properties” and “Actions” view. Select “Actions” and, under “Tap Action” (i.e. single-tap), tap on the target.

The actions available will vary from widget to widget. (View large version52)

This will bring up a screen with a site map view of all screens and existing clickthrough links. The triggering list item is highlighted in yellow in “1.0 Home,” identifying where the tap comes from. Here, you can assign a target for the interaction by tapping on a different screen, by tapping “New Screen” in the top left of the title toolbar or, if you’ve changed your mind, by tapping the “No Target” option. Go ahead and tap on “2.0 Article”!

The accordion menu on the right allows you to select a screen from the side panel. The top-right hamburger icon collapses it. (View large version54)

Your first interaction is almost complete. After you’ve selected a target, you will notice that “Link Style” and “Transition” are shown. The “Link Style” lets you choose the color and format of the link line (remember the site map’s side panel from earlier?). This helps with labeling inbound and outbound scenario paths.

Different colors and styles are available. (View large version56)

“Transition” allows you to select an effect for switching between screens. “Dissolve” is the default choice, and “None,” “Move,” “Reveal,” “Push,” “Curl” and “Flip” are also available. If you re-enter the “Target” screen, you will see both the UI trigger and the link arrow to the target screen highlighted in yellow. Select “None” for the transition. You can test other transitions later!

The list options are scrollable, revealing additional transitions. (View large version58)

Manipulating Links

The visibility of links can be modified both in the screen and site map views. Earlier, I covered how the side panel in the site map view can be used to hide and show groups of color links. In contrast, all links may be hidden in the screen view via L3. Surprisingly, links pointing to their parent screen are not shown at all. I hinted at using custom hotspots in the section on “Using Images59”: To do this, drop a “Button” and make it transparent via “Properties” → “Background.” Hide its border by setting the widget to “Custom” in “Properties” → “Type” to complete the look.

Playing the Prototype

Layering interactions is fun because it brings the prototype to life. After you’ve added the clickthrough interactions to the remaining screens, you will be ready to test the concept demo! Press the play icon (G6) to start the demo in full screen with the device shell shown. As seen below, a two-finger tap either exits the demo or backtracks in the flow. The app does not highlight active screen links, so know your prototype scenarios well.

Once the clickthrough demo is perfected, you can rock the audience! Presenting the concept directly on the device is best. Sometimes your viewership will be larger — in which case, to keep everyone engaged, you’ll want to mirror the tablet’s output either via software (such as Reflector60) or hardware (such as a Lightning-to-VGA adapter61).

The notification disappears shortly after the demo begins. (View large version63)

By default, “Undo Last Action” is unavailable. It activates as soon as you navigate to a new screen. (View large version65)

The presentation went off without a hitch! The demo clearly impressed the stakeholders because you received positive feedback and many relevant questions. Your client even asked to share the work with partners overseas. In this situation, you can prescribe the free Blueprint Viewer app and teach people how to load the sharable .blueprint source file. Let’s cover how to do that next!

The iPhone view is more compact. (View large version67)

Viewing the source file on an iPad allows you to browse projects while viewing the contents of the current project. (View large version69)

Exploring the Export Options

You are ready to share the work with the geographically distributed team. Luckily, unlike POP’s cloud-based distribution, Blueprint allows users to freely share assets via email, Dropbox and iTunes. To export a project, in the “Home Screen” of a project, tap the leftmost icon to access the options.

iTunes and Dropbox options are grouped separately. (View large version71)

The overseas team consists of several departments: marketing, development and product management. Your stakeholders ask to send the interactive demo to the product manager and developers, whereas the marketing representatives have requested large images. You can send marketing a PDF of all screens or a ZIP archive of individual PNG images. As for the developers, that’s easy! Just send them the .blueprint file.

If “Export to Dropbox” is selected, a “Sign Out” button will be added to the top right. (View large version73)

The PDF and PNG options are handy for capturing any documentation included in the file. However, this is rarely done for concept prototypes because of their fluid nature. Both have settings for adjusting the outputted deliverable.

You can adjust the paper size, number of screens per page and other options. (View large version75)

The only option available for PNG is selecting which screens to export. (View large version77)

Having learned about the exporting options, you are ready to send your work to the team. “Send via Mail” is the logical choice because the team is not familiar with Dropbox. Tap this option to create two messages, with the relevant deliverables attached in each draft. When you send the .blueprint file to the developers, a link to the free Blueprint Viewer is embedded in the message’s body. All you have to do is tell them to download the app!

The “Subject” field is populated with the project’s name. (View large version79)

In the future, you might be working with avid Dropbox users, so let’s cover that option as well! Blueprint will redirect you to the Dropbox application if you have it installed on your iPad. After you log in, Blueprint will ask for permission to access all folders and files. You must grant this in order to export files to Dropbox. Afterwards, you can select where in your Dropbox account to store the .blueprint file, the ZIP file of PNGs or the PDF.

Tapping “Allow” returns you to Blueprint. (View large version81)

Exporting to iTunes is best done for internal testing and for sharing with colleagues. Personally, I have used this feature also to back up .blueprint files on an external drive. For directions on how to use iTunes with Blueprint, read “How do I send a mockup to other people?” on groosoft’s FAQ82 page.

Related Solutions

You now have the basics down on how to put together a quick concept prototype with Blueprint. The tool can be used for larger, more complex prototypes, but these take much longer to create, and maintenance time must be factored in.

Other applications are on the market to help with creating iOS experiences directly on a tablet. Below, I’ll briefly discuss a couple of alternatives that I’ve come across! I am continuing my search for equivalent tools on other platforms, including Android.


AppCooker9183 is a $15 tool developed by Hot Apps Factory84. It lives in a similar ecosystem: The application is used to create experiences on an iPad that are viewable in AppCooker or the free AppTaster9285. The viewer is available for the iPhone and iPad, but tablet experiences are viewable on the iPad only.

AppCooker stands out with the following:

  • It includes an exporting option for Box, direct posting of projects to the viewer, and exporting to JPEG and PDF formats.
  • Each project includes features such as “Notepad” (to capture ideas), “Definition Statement” (to outline a project’s value proposition), “Revenue & Expenses Tracker” (to develop a distribution plan) and more.
  • The prototyping tool has support for taking multi-finger actions, customizing transitions, grouping widgets and specifying multiple link paths for a single hotspot.

Its advanced features make AppCooker a powerful tool for creating full app prototypes that illustrate complex interactions and that prove an app’s technical feasibility.

Interface HD

Interface HD9386, also known as Interface 3, is a $10 tool developed by LessCode87. Interface HD makes clickthrough prototypes for the iPad and iPhone. The app shares many of Blueprint’s features, but minor limitations exist. For example, the event model includes widget swipes and taps but no screen-level interactions (such as rotation); you have five transitions to choose from; and the software offers no way to visualize links between screens. The app is constantly being updated, so these features might be introduced soon!

Interface HD has many unique selling points:

  • It includes a “Stock Asset Manager” for downloading third-party icons and background patterns.
  • Password protection is built in, and web demonstrations require pin authentication.
  • The OS’ chrome can be customized in detail, including dynamic control of all aspects of the status bar (color, placement, icons, etc.).
  • Video tutorials are built in.

This tool is best suited for illustrating flows with light interaction and for designing UIs with customizable widgets. If you need to mock up a quick clickthrough prototype of high visual fidelity, then this is the tool for you!

Takeaways Pros of Blueprint
  • The collection of transitions and actions is rich.
  • Customizable widgets are included.
  • Blueprint Viewer allows anyone to view prototypes for free.
  • Viewing prototypes requires no Internet connectivity.
Cons of Blueprint
  • The learning curve is noticeable at first.
  • iOS is the only platform supported out of the box.
  • Multi-finger actions and third-party widgets are not supported (at least, not yet).
  • Dynamic states and master templates are not provided.
Closing Thoughts

Widget-based clickthrough prototypes are great for communicating design concepts that emerge from sketching exercises. These prototypes bridge the gap between what the stakeholders envision and what the UXers plan to create. Blueprint, one tool that handles the creation of such prototypes, provides an effective way to capture UI details, while allowing for higher visual fidelity. Furthermore, it introduces a way to design directly on the device, allowing stakeholders to be more intimately involved in demos. If you have $20 lying around, then spend a weekend exploring this tool. It could bring many benefits to your design process. Prototype away, fellow designers!

Useful Resources

Here are the iPad prototyping tools we’ve discussed:

(al, ml)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6 #export
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14 #export
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22 #interactivity
  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 #images
  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

The post Creating Clickthrough Prototypes With Blueprint appeared first on Smashing Magazine.

Improving Smashing Magazine’s Performance: A Case Study

Mon, 09/08/2014 - 12:13

Today Smashing Magazine turns eight years old. Eight years is a long time on the web, yet for us it really doesn’t feel like a long journey at all. Things have changed, evolved and moved on, and we gratefully take on new challenges one at a time. To mark this special little day, we’d love to share a few things that we’ve learned over the last year about the performance challenges of this very website and about the work we’ve done recently. If you want to craft a fast responsive website, you might find a few interesting nuggets worth considering. – Ed.

Improvement is a matter of steady, ongoing iteration. When we redesigned Smashing Magazine back in 2012, our main goal was to establish trustworthy branding that would reflect the ambitious editorial direction of the magazine. We did that primarily by focusing on crafting a delightful reading experience. Over the years, our focus hasn’t changed a bit; however, that very asset that helped to establish our branding turned into a major performance bottleneck.

Good Old-Fashioned Website Decay

Looking back at the early days of our redesign, some of our decisions seem to be quick’n’dirty fixes rather than sound long-term solutions. Our advertising constraints pushed us to compromises. Legacy browsers drove us to dependencies on (relatively) heavy JavaScript libraries. Our technical infrastructure led us to heavily customized WordPress plugins and complex PHP logic. With every new feature added, our technical debt grew, and our style sheets, markup and JavaScript weren’t getting any leaner.

Sound familiar? Admittedly, responsive web design as a technique often gets a pretty bad rap for bloating websites and making them difficult to maintain. (Not that non-responsive websites are any different, but that’s another story.) In practice, all assets on a responsive website will show up pretty much everywhere1: be it a slow smartphone, a quirky tablet or a fancy laptop with a Retina screen. And because media queries merely provide the ability to respond to screen dimensions — and do not, rather, have a more local, self-contained scope — adding a new feature and adjusting the reading experience potentially means going through each and every media query to prevent inconsistencies and fix layout issues.

“Mobile First” Means “Always Mobile First”

When it comes to setting priorities for the content and functionality on a website, “mobile first” is one of those difficult yet incredibly powerful constraints that help you focus on what really matters, and identify critical components of your website. We discovered that designing mobile first is one thing; building mobile first is an entirely different story. In our case, both the design and development phases were heavily mobile first, which helped us to focus tightly on the content and its presentation. But while the design process was quite straightforward, implementation proved to be quite difficult.

Because the entire website was built mobile first, we quickly realized that adding or changing components on the page would entail going through the mobile-first approach for every single (minor and major) design decision. We’d design a new component in a mobile view first, and then design an “extended” view for the situations when more space is available. Often that meant adjusting media queries with every single change, and more often it meant adding new stuff to style sheets and to the markup to address new issues that came up.

Shortly after the new SmashingMag redesign went live, we ran into performance issues. An article by Tim Kadlec from 20123 shows just that.

We found ourselves trapped: development and maintenance were taking a lot of time, the code base was full of minor and major fixes, and the infrastructure was becoming too slow. We ended up with a code base that had become bloated before the redesign was even released — very bloated4, in fact.

Performance Issues

In mid-2013, our home page weighed 1.4 MB and produced 90 HTTP requests. It just wasn’t performing well. We wanted to create a remarkable reading experience on the website while avoiding the flash of unstyled text (FOUT), so web fonts were loaded in the header and, hence, were blocking the rendering of content (actually it’s correct behaviour according to the spec5, designed to avoid multiple repaints and reflows.) jQuery was required for ads to be displayed, and a few JavaScripts depended on jQuery, so they all were blocking rendering as well. Ads were loaded and rendered before the content to ensure that they appeared as quickly as possible.

Images delivered by our ad partners were usually heavy and unoptimized, slowing down the page further. We also loaded Respond.js and Modernizr to deal with legacy browsers and to enhance the experience for smart browsers. As a result, articles were almost inaccessible on slow and unstable networks, and the start rendering time on mobile was disappointing at best.

It wasn’t just the front-end that was showing its age though. The back-end wasn’t getting any better either. In 2012 we were playing with the idea of having fully independent sections of the magazine — sections that would live their own lives, evolving and growing over time as independent WordPress installations, with custom features and content types that wouldn’t necessarily be shared across all sections.

Yes, we do enjoy a quite savvy user base, so optimization for IE8 is really not an issue. Large view.7

Because WordPress multi-install wasn’t available at the time, we ended up with six independent, autonomous WordPress installs with six independent, autonomous style sheets. Those installs were connected to 6 × 2 databases (a media server and a static content server). We ran into dilemmas. For example, what if an author wrote for two sections and we’d love to show their articles from both sections on one single author’s bio page? Well, we’d need to somehow pull articles from both installs and add redirects for each author’s page to that one unified page, or should we just be using one of those page as the “host”? Well, you know where this is going: increasing complexity and increasing maintenance costs. In the end, the sections didn’t manage to evolve significantly — at least not in terms of content — yet we had already customized technical foundation of each section, adding to the CSS dust and PHP complexity.

(Because we had outsourced WordPress tasks, some plugins depended on each other. So, if we were to deactivate one, we might have unwittingly disabled two or three others in the process, and they would have to be turned back on in a particular order to work properly. There were even differences in the HTML outputted by the PHP templates behind the curtains, such as classes and IDs that differed from one installation to the next. It’s no surprise that this setup made development a bit frustrating.)

The traffic was stagnant, readers kept complaining about the performance on the site and only a very small portion of users visited more than 2 pages per visit. The visual feedback when browsing the site was visible and surely wasn’t instant, and this lag has been driving readers away from the site to Instapaper and Pocket — both on mobile and desktop. We knew that because we asked our readers, and the feedback was quite clear (and a bit frustrating).

It was time to push back — heavily, with a major refactoring of the code base. We looked closely under the hood, discovering a few pretty scary (and nasty) things, and started fixing issues, one by one. It took us quite a bit of time to make things right, and we learned quite a few things along the way.

Switching Gears

Up until mid-2013, we weren’t using a CSS preprocessor, nor any build tools. Good long-term solutions require a good long-term foundation, so the first issues we tackled were tooling and the way the code base was organized. Because a number of people had been working on the code base over the years, some things proved to be rather mysterious… or challenging, to say the least.

We started with a code inventory, and we looked thoroughly at every single class, ID and CSS selector. Of course, we wanted to build a system of modular components, so the first task was to turn our seven large CSS files into maintainable, well-documented and easy-to-read modules. At the time, we’d chosen LESS, for no particular reason, and so our front-end engineer Marco8 started to rewrite CSS and build a modular, scalable architecture. Of course, we could very well have used Sass instead, but Marco felt quite comfortable with LESS at the time.

With a new CSS architecture, Grunt9 as a build tool and a few10 time-saving11 Grunt12 tasks13, the task of maintaining the entire code base became much easier. We set up a brand new testing environment, synced up everything with GitHub, assigned roles and permissions, and started digging. We rewrote selectors, reauthored markup, and refactored and optimized JavaScript. And yes, it took us quite some time to get things in order, but it really wouldn’t have been so difficult if we hadn’t had a number of very different stylesheets to deal with.

The Big Back-End Cleanup

With the introduction of Multisite, creating a single WordPress installation from our six separate installations became a necessary task for our friends at Inpsyde14. Over the course of five months, Christian Brückner and Thomas Herzog cleaned up the PHP templates, kicked unnecessary plugins into orbit, rewrote plugins we had to keep and added new ones where needed. They cleared the databases of all the clutter that the old plugins had created — one of the databases weighed in at 70 GB (no, that’s not a typo; we do mean gigabytes) — merged all of the databases into one, and then created a single fresh and, most importantly, maintainable WordPress Multisite installation.

The speed boost from those optimizations was remarkable. We are talking about 400 to 500 milliseconds of improvement by avoiding sub-domain redirects and unifying the code base and the back-end code. Those redirects15 are indeed a major performance culprit, and just avoiding them is one of those techniques that usually boost performance significantly because you avoid full DNS lookups, improve time to first byte and reduce round trips on the network.

Thomas and Christian also refactored our entire WordPress theme according to the coding standard of their own theme architecture, which is basically a sophisticated way of writing PHP based on the WordPress standard. They wrote custom drop-ins that we use to display content at certain points in the layout. Writing the PHP strictly according to WordPress’ official API felt like getting out of a horse-drawn carriage and into a race car. All modifications were done without ever touching WordPress’ core, which is wonderful because we’ll never have to fear updating WordPress itself anymore.

We’ve also marked a few millions spam comments across all the sections of the magazine. And before you ask: no, we did not import them into the new install.

We migrated the installations during a slow weekend in mid-April 2014. It was a huge undertaking, and our server had a few hiccups during the process. We brought together over 2500 articles, including about 15,000 images, all spread over six databases, which also had a few major inconsistencies. While it was a very rough start at first — a lot of redirects had to be set up, caching issues on our server piled up, and some articles got lost between the old and new installations — the result was well worth the effort.

Our editorial team, primarily Iris16, Melanie17 and Markus18, worked very hard to bring those lost articles back to life by analyzing our 404s with Google Webmaster Tools. We spent a few weekends to ensure that every single article was recovered and remains accessible. Losing articles, including their comments, was simply unacceptable.

We know well how much time it takes for a good article to get published, and we have a lot of respect for authors and their work, and ensuring that the content remains online was a matter of respect for the work published. It took us a few weeks to get there and it wasn’t the most enjoyable experience for sure, but we used the opportunity to introduce more consistency in our information architecture and to adjust tags and categories appropriately. (Ah, if you do happen to find an article that has gotten lost along the way, please do let us know19 and we’ll fix it right away. Thanks!)

Front-End Optimization

In April 2014, once the new system was in place and had been running smoothly for a few days, we rewrote the LESS files based on what was left of all of the installs. Streamlining the classes for posts and pages, getting rid of all unneeded IDs, shortening selectors by lowering their specificity, and rooting out anything in the CSS we could live without crunched the CSS from 91 KB down to a mere 45 KB.

Once the CSS code base was in proper shape, it was time to reconsider how assets are loaded on the page and how we can improve the start rendering time beyond having clean, well-structured code base. Given the nightmare we experienced with the back-end previously, you might assume that improving performance now would have been a complex, time-consuming task, but actually it was quite a bit easier than that. Basically, it was just a matter of getting our priorities right by optimizing the critical rendering path.

The key to improving performance was to focus on what matters most: the content, and the fastest way for readers to actually start reading our articles on their devices. So over a course of a few months we kept reprioritizing. With every update, we introduced mini-optimizations based on a very simple, almost obvious principle: optimize the delivery of content, and defer the rest — without any compromises, anywhere.

Our optimizations were heavily influenced by the work done by Scott Jehl20, as well as The Guardian21 and the BBC22 teams (both of which open-sourced their work). While Scott has been sharing valuable insight23 into the front-end techniques that Filament Group was using, the BBC and The Guardian helped us to define and refine the concept of the core experience on the website and use it as a baseline. A shared main goal was to deliver the content as fast as possible to as many people as possible regardless of their device or network capabilities, and enhance the experience with progressive enhancement for capable browsers.

However, historically we haven’t had a lot of JavaScript or complex interactions on Smashing Magazine, so we didn’t feel that it was necessary to introduce complex loading logic with JavaScript preloaders. However, being a content-focused website, we did want to reduce the time necessary for the articles to start displaying as far as humanly possible.

Performance Budget: Speed Index <= 1000

How fast is fast enough?24 Well, that’s a tough question to answer. In general, it’s quite difficult to visualize performance and explain why every millisecond counts—unless you have hard data. At the same time, falling into trap of absolutes and relying on not truly useful performance metrics is easy. In the past, the most commonly cited performance metric was average loading time. However, on its own, average loading time isn’t that helpful because it doesn’t tell you much about when a user can actually start using the website. This is why talking about “fast enough” is often so tricky.

A nice way of visualizing performance is to use WebPageTest to generate an actual video of the page loading and run a test between two competing websites. Besides, the Speed Index metric26 often proves to be very useful.

Different components require different amounts of time to load, yet some components of the page are more important than others. E.g. you don’t need to load the footer content fast, but it’s a good idea to render the visible portion of the page fast. You know where it’s heading: of course, we are talking about the “above the fold” view here. As Ilya Grigorik once said27, “We don’t need to render the entire page in one second, [just] the above the fold content.” To achieve that, according to Scott’s research and Google’s test results, it’s helpful to set ambitious performance goals:

What does it mean and why are they important? According to HCI research, “for an application to feel instant, a perceptible response to user input must be provided within hundreds of milliseconds30. After a second or more, the user’s flow and engagement with the initiated task feels broken.” With the first goal, we are trying to ensure an instant response on our website. It refers to the so-called Speed Index metric for the start rendering time — the average time (in ms) at which visible parts of the page are displayed, or become accessible. So the first goal basically reflects that a page starts rendering under 1000ms, and yes, it’s a quite difficult challenge to take on.

Ilya Grigorik’s book High Performance Browser Networking32 is a very helpful guide with useful guidelines and advice on making websites fast. And it’s available as a free HTML book, too.

The second goal can help in achieving the first one. The value of 14 KB has been measured empirically33 by Google and is the threshold for the first package exchanged between a server and client via towers on a cellular connection. You don’t need to include images within 14 Kb, but you might want to deliver the markup, style sheets and any JavaScript required to render the visible portion of the page in that threshold. Of course, in practice this value can only realistically be achieved with gzip compression.

By combining the two goals, we basically defined a performance budget that we set for the website — a threshold for what was acceptable. Admittedly, we didn’t concern ourselves with the start rendering time on different devices on various networks, mainly because we really wanted to push back as far as possible everything that isn’t required to start rendering the page. So, the ideal result would be a Speed Index value that is way lower than the one we had set — as low as possible, actually — in all settings and on all connections, both shaky and stable, slow and fast. This might sound naive, but we wanted to figure out how fast we could be, rather than how fast we should be. We did measure start rendering time for first and subsequent page loads, but we did that much later, after optimizations had already been done, and just to keep track of issues on the front-end.

Our next step would be to integrate Tim Kadlec’s Perf-Budget Grunt task34 to incorporate the performance budget right into the build process and, thus, run every new commit against WebPagetest’s performance benchmark. If it fails, we know that a new feature has slowed us down, so we probably have to reconsider how it’s implemented to fit it within our budget, or at least we know where we stand and can have meaningful discussions about its impact on the overall performance.

Prioritization And Separation Of Concerns

If you’ve been following The Guardian‘s work recently, you might be familiar with the strict separation of concerns that they introduced35 during the major 2013 redesign. The Guardian separated36 its entire content into three main groups:

  • Core content
    Essential HTML and CSS, usable non-JavaScript-enhanced experience
  • Enhancement
    JavaScript, geolocation, touch support, enhanced CSS, web fonts, images, widgets
  • Leftovers
    Analytics, advertising, third-party content

A strict separation of concerns, or loading priorities, as defined by The Guardian team. Large view.38

Once you have defined, confirmed and agreed upon these priorities, you can push performance optimization quite far. Just by being very specific about each type of content you have and by clearly defining what “core content” is, you are able to load Core content as quickly as possible, then load Enhancements once the page starts rendering (after the DOMContentLoaded event fires), and then load Leftovers once the page has fully rendered (after the load event fires).

The main principle here of course is to strictly separate the loading of assets throughout these three phases, so that the loading of the Core content should never be blocked by any resources grouped in Enhancement or Leftovers (we haven’t achieved the perfect separation just yet, but we are on it). In other words, you try to shorten the critical rendering path that is required for the content to start displaying by pushing the content down the line as fast as possible and deferring pretty much everything else.

We followed this same separation of concerns, grouping our content types into the same categories and identifying what’s critical, what’s important and what’s secondary. In our case, we identified and separated content in this way:

  • Core content
    Only essential HTML and CSS
  • Enhancement
    JavaScript, code syntax highlighter, full CSS, web fonts, comment ratings
  • Leftovers
    Analytics, advertising, Gravatars

Once you have this simple content/functionality priority list, improving performance is becoming just a matter of adding a few snippets for loading assets to properly reflect those priorities. Even if your server logic forces you to load all assets on all devices, by focusing on content delivery first, you ensure that the content is accessible quickly, while everything else is deferred and loaded in the background, after the page has started rendering. From a strategic perspective, the list also reflects your technical debt, as well as critical issues that slow you down. Indeed, we had quite a list of issues to deal with already at this point, so it transformed fairly quickly into a list of content priorities. And a rather tricky issue sat right at the top of that list: good ol’ web fonts.

Deferring Web Fonts

Despite the fact that the proportion of Smashing Magazine’s readers on mobile has always been quite modest (just around 15%—mainly due to the length of articles), we never considered mobile as an afterthought, but we never pushed user experience on mobile either. And when we talk about user experience on mobile, we mostly talk about speed, since typography was pretty much well designed from day one.

We had conversations during the 2012 redesign about how to deal with fonts, but we couldn’t find a solution that made everybody happy. The visual appearance of content was important, and because the new Smashing Magazine was all about beautiful, rich typography, not loading web fonts at all on mobile wasn’t really an option.

With the redesign back then, we switched to Skolar for headings and Proxima Nova for body copy, delivered by Fontdeck. Overall, we had three fonts for each typeface — Regular, Italic and Bold — totalling in six font files to be delivered over the network. Even after our dear friends at Fontdeck subsetted and optimized the fonts, the assets were quite heavy with over 300 KB in total, and because we wanted to avoid the frequent flash of unstyled text (FOUT), we had them loaded in the header of every page. Initially we thought that the fonts would reliably be cached in HTTP cache, so they wouldn’t be retrieved with every single page load. Yet it turned out that HTTP cache was quite unreliable: the fonts showed up in the waterfall loading chart every now and again for no apparent reason, both on desktop and on mobile.

The biggest problem, of course, was that the fonts were blocking rendering39. Even if the HTML, CSS and JavaScript had already loaded completely, the content wouldn’t appear until the fonts had loaded and rendered. So you had this beautiful experience of seeing link underlines first, then a few keywords in bold here and there, then subheadings in the middle of the page and then finally the rest of the page. In some cases, when Fontdeck had server issues, the content didn’t appear at all, even though it was already sitting in the DOM, waiting to be displayed.

In his article, Web Fonts and the Critical Path41, Ian Feather provides a very detailed overview of the FOUT issues and font loading solutions. We tested them all.

We experimented with a few solutions before settling on what turned out to be perhaps the most difficult one. At first, we looked into using Typekit and Google’s WebFontLoader42, an asynchronous script which gives you more granular control of what appears on the page while the fonts are being loaded. Basically, the script adds a few classes to the body element, which allows you to specify the styling of content in CSS during the loading and after the fonts have loaded. So you can be very precise about how the content is displayed in fallback fonts first, before users see the switch from fallback fonts to web fonts.

We added fallback fonts declarations and ended up with pretty verbose CSS font stacks, using iOS fonts, Android fonts, Windows Phone fonts and good ol’ web-safe fonts as fallbacks — we are still using these font stacks today. E.g. we used this cascade for the main headings (it reflects the order of popularity of mobile operating systems in our analytics):

h2 { font-family: "Skolar Bold", AvenirNext-Bold, "Avenir Bold", "Roboto Slab", "Droid Serif", "Segoe UI Bold", Georgia, "Times New Roman", Times, serif; }

So readers would see a mobile OS font (or any other fallback font first), and it probably would be a font that they are quite familiar with on their device, and then once the fonts have loaded, they would see a switch, triggered by WebFontLoader. However, we discovered that after switching to WebFontLoader, we started seeing FOUT way too often, with HTTP cache being quite unreliable again, and that permanent switch from a fallback font to the web font being quite annoying, basically ruining the reading experience.

So we looked for alternatives. One solution was to include the @font-face directive only on larger screens by wrapping it in a media query, thus avoiding loading web fonts on mobile devices and in legacy browsers altogether. (In fact, if you declare web fonts in a media query, they will be loaded only when the media query matches the screen size. So no performance hit there.) Obviously it helped us improve performance on mobile devices in no time, but we didn’t feel right with having a “simplified” reading experience on mobile devices. So it was a no-go, too.

What else could we do? The only other option was to improve the caching of fonts. We couldn’t do much with HTTP cache, but there was one option we hadn’t looked into: storing fonts in AppCache or localStorage. Jake Archibald’s article on the beautiful complexity of AppCache43 led us away from AppCache to experiment with localStorage, a technique44 that The Guardian’s team was using at the time.

Now, offline caching comes with one one major requirement: you need to have the actual font files to be able to cache them locally in the client’s browser. And you can’t cache a lot because localStorage space is very limited45, sometimes with just 5Mb available per domain. Luckily, the Fontdeck guys were very helpful and forthcoming with our undertaking, so despite the fact that font delivery services usually require you to load files and have a synchronous or asynchronous callback to count the number of impressions, Fontdeck has been perfectly fine with us grabbing WOFF-files from Google Chrome’s cache and setting up a “flat” pricing based on the number of page impressions in recent history.

So we grabbed the WOFF files and embedded them, base64-encoded, in a single CSS file, moving from six external HTTP-requests with about 50 KB file each to at most one HTTP request on the first load and 400 KB of CSS. Obviously, we didn’t want this file to be loaded on every visit. So if localStorage is available on the user’s machine, we store the entire CSS file in localStorage, set a cookie and switch from the fallback font to the web font. This switch usually happens once at most because for the consequent visits, we check whether the cookie has been set and, if so, retrieve the fonts from localStorage (causing about 50ms in latency) and display the content in the web font right away. Just before you ask: yes, read/write to localStorage is much slower than retrieving files from HTTP cache46, but it proved to be a bit more reliable in our case.

Yes, localStorage is much slower than HTTP cache48, but it’s more reliable. Storing fonts in localStorage isn’t the perfect solution, but it helped us improve performance dramatically.

If the browser doesn’t support localStorage, we include fonts with good ol’ link href and, well, frankly just hope for the best — that the fonts will be properly cached and persist in the user’s browser cache. For browsers that don’t support WOFF49 (IE8, Opera Mini, Android <= 4.3), we provide external URLs to fonts with older font mime types, hosted on Fontdeck.

Now, if localStorage is available, we still don’t want it to be blocking the rendering of the content. And we don’t want to see FOUT every single time a user loads the page. That’s why we have a little JavaScript snippet in the header before the body element: it checks whether a cookie has been set and, if not, we load web fonts asynchronously after the page has started rendering. Of course, we could have avoided the switch by just storing the fonts in localStorage on the first visit and have no switch during the first visit, but we decided that one switch is acceptable, because our typography is important to our identity.

The script was written, tested and documented by our good friend Horia Dragomir50. Of course, it’s available as a gist on GitHub51:

<script type="text/javascript"> (function () { "use strict"; // once cached, the css file is stored on the client forever unless // the URL below is changed. Any change will invalidate the cache var css_href = './web-fonts.css'; // a simple event handler wrapper function on(el, ev, callback) { if (el.addEventListener) { el.addEventListener(ev, callback, false); } else if (el.attachEvent) { el.attachEvent("on" + ev, callback); } } // if we have the fonts in localStorage or if we've cached them using the native browser cache if ((window.localStorage && localStorage.font_css_cache) || document.cookie.indexOf('font_css_cache') > -1){ // just use the cached version injectFontsStylesheet(); } else { // otherwise, don't block the loading of the page; wait until it's done. on(window, "load", injectFontsStylesheet); } // quick way to determine whether a css file has been cached locally function fileIsCached(href) { return window.localStorage && localStorage.font_css_cache && (localStorage.font_css_cache_file === href); } // time to get the actual css file function injectFontsStylesheet() { // if this is an older browser if (!window.localStorage || !window.XMLHttpRequest) { var stylesheet = document.createElement('link'); stylesheet.href = css_href; stylesheet.rel = 'stylesheet'; stylesheet.type = 'text/css'; document.getElementsByTagName('head')[0].appendChild(stylesheet); // just use the native browser cache // this requires a good expires header on the server document.cookie = "font_css_cache"; // if this isn't an old browser } else { // use the cached version if we already have it if (fileIsCached(css_href)) { injectRawStyle(localStorage.font_css_cache); // otherwise, load it with ajax } else { var xhr = new XMLHttpRequest();"GET", css_href, true); on(xhr, 'load', function () { if (xhr.readyState === 4) { // once we have the content, quickly inject the css rules injectRawStyle(xhr.responseText); // and cache the text content for further use // notice that this overwrites anything that might have already been previously cached localStorage.font_css_cache = xhr.responseText; localStorage.font_css_cache_file = css_href; } }); xhr.send(); } } } // this is the simple utitily that injects the cached or loaded css text function injectRawStyle(text) { var style = document.createElement('style'); style.innerHTML = text; document.getElementsByTagName('head')[0].appendChild(style); } }()); </script>

During the testing of the technique, we discovered a few surprising problems. Because the cache isn’t persistent in WebViews, fonts do load asynchronously in applications such as Tweetdeck and Facebook, yet they don’t remain in the cache once the window is closed. In other words, with every WebViews visit, the fonts are re-downloaded. Some old Blackberry devices seemed to clear cookies and delete the cache when the battery is running out. And depending on the configuration of the device, sometimes fonts do not persist in mobile Safari either.

Still, once the snippet was in place, articles started rendering much faster. By deferring the loading of Web fonts and storing them in localStorage, we’ve avoided around 700ms delay, and thus shortened the critical path significantly by avoiding the latency for retrieving all the fonts. The result was quite impressive for the first load of an uncached page, and it was even more impressive for concurrent visits since we were able to reduce the latency caused by Web fonts to just 40 to 50 ms. In fact, if we had to mention just one improvement to performance on the website, deferring web fonts is by far the most effective.

At this point, we haven’t even considered using the new WOFF2 format52 for fonts just yet. Currently supported in Chrome and Opera, it promises a better compression for font files and it already showed remarkable results. In fact, The Guardian was able to cut down on 200ms latency and 50 KB of the file weight53 by switching to WOFF2, and we intend to look into moving to WOFF2 soon as well.

Of course, grabbing WOFFs might not always be an option for you, but it wouldn’t hurt just to talk to type foundries to see where you stand or to work out a deal to host fonts “locally.” Otherwise, tweaking WebFontLoader for Typekit and Fontdeck is definitely worth considering.

Dealing With JavaScript

With the goal of removing all unnecessary assets from the critical rendering path, the second target we decided to deal with was JavaScript. And it’s not like we particularly dislike JavaScript for some reason, but we always tend to prefer non-JavaScript solutions to JavaScript ones. In fact, if we can avoid JavaScript or replace it with CSS, then we’ll always explore that option.

Back in 2012, we weren’t using a lot of scripts on the page, yet displaying advertising via OpenX depended on jQuery, which made it way too easy to lazily approach simple, straightforward tasks with ready-to-use jQuery plugins. At the time, we also used Respond.js to emulate responsive behaviour in legacy browsers. However, Internet Explorer 8 usage has dropped significantly between 2012 and 2014: with 4.7% before the redesign, it was now 1.43%, with a dropping tendency every single month. So we decided to deliver a fixed-width layout with a specific IE8.css stylesheet to those users, and removed Respond.js altogether.

As a strategic decision, we decided to defer the loading of all JavaScripts until the page has started rendering and we looked into replacing jQuery with lightweight modular JavaScript components.

jQuery was tightly bound to ads, and ads were supposed to start displaying as fast as possible, so to make it happen, we had to deal with advertising first. The decision to defer the loading of ads wasn’t easy to get agreement on, but we managed to make a convincing argument that better performance would increase click rates because users would see the content sooner. That is, on every page, readers would be attracted by the high-quality content and then, when the ads kick in, would pay attention to those squares in the sidebar as well.

Florian Sander54, our partner in crime when it comes to advertising, rewrote the script for our banner ads so that banners would be loaded only after the content has started rendering, and only then the advertising spots would be put into place. Florian was able to get rid of two render-blocking HTTP-requests that the ad-script normally generated, and we were able to remove the dependency on jQuery by rewriting the script in vanilla JavaScript.

Obviously, because the sidebar’s ad content is generated on the fly and is loaded after the render tree has been constructed, we started seeing reflows (this still happens when the page is being constructed). Because we used to load ads before the content, the entire page (with pretty much everything) used to load at once. Now, we’ve moved to a more modular structure, grouping together particular parts of the page and queuing them to load after each other. Obviously, this has made the overall experience on the site a bit noisier because there are a few jumps here and there, in the sidebar, in the comments and in the footer. That was a compromise we went for, and we are working on a solution to reserve space for “jumping” elements to avoid reflows as the page is being loaded.

Deferring Non-Critical JavaScript

When the prospect of removing jQuery altogether became tangible as a long-term goal, we started working step by step to decouple jQuery dependencies from the library. We rewrote the script to generate footnotes for the print style sheet (later replacing it with a PHP solution), rewrote the functionality for rating comments, and rewrote a few other scripts. Actually, with our savvy user base and a solid share of smart browsers, we were able to move to vanilla JavaScript quite quickly. Moreover, we could now move scripts from the header to the footer to avoid blocking construction of the DOM tree. In mid-July, we removed jQuery from our code base entirely.

We wanted full control of what is loaded on the page and when. Specifically, we wanted to ensure that no JavaScript blocks the rendering of content at any point. So, we use the Defer Loading JavaScript55 script to load JavaScript after the load event by injecting the JavaScript after the DOM and CSSOM have already been constructed and the page has been painted. Here’s the snippet that we use on the website, with the defer.js script (which is loaded asynchronously after the load event):

function downloadJSAtOnload() { var element = document.createElement("script"); element.src = "defer.js"; document.body.appendChild(element); } if (window.addEventListener) window.addEventListener("load", downloadJSAtOnload, false); else if (window.attachEvent) window.attachEvent("onload", downloadJSAtOnload); else window.onload = downloadJSAtOnload;

However, because script-injected asynchronous scripts are considered harmful56 and slow (they block the browser’s speculative parser), we might be looking into using the good ol’ defer and async attributes instead. In the past, we couldn’t use async for every script because we needed jQuery to load before its dependencies; so, we used defer, which respects the loading order of scripts. With jQuery out of the picture, we can now load scripts asynchronously, and fast. Actually by the time you read this article, we might already be using async.

Basically, we just deferred the loading of all JavaScripts that we identified previously, such as syntax highlighter and comment ratings, and cleared a path in the header for HTML and CSS.

Inlining Critical CSS

That wasn’t good enough, though. Performance did improve dramatically; however, even with all of these optimizations in place, we didn’t hit that magical Speed Index value of under 1000. In light of the ongoing discussion about inline CSS and above-the-fold CSS, as recommended by Google57, we looked into more radical ways to deliver content quickly. To avoid an HTTP request when loading CSS, we measured how fast the website would be if we were to load critical CSS inline and then load the rest of the CSS once the page has rendered.

Scott Jehl’s article59 explains how exactly to extract and inline critical CSS.

But what exactly is critical CSS? And how do you extract it from a potentially complex code base? As Scott Jehl points out60, critical CSS is the subset of CSS that is needed to render the top portion of the page across all breakpoints. What does that mean? Well, you would decide on a certain height that you would consider to be “above the fold” content — it could be 600, 800 or 1200 pixels or anything else — and you would collect into their own style sheet all of the styles that specify how to render content within that height across all screen widths.

Then you inline those styles in the head, and thus give the browser everything it needs to start render that visible portion of the page — within one single HTTP request. You’ve heard it a few times by now: everything else is deferred after the first initial rendering. You avoid an HTTP-request, and you load the full CSS asynchronously, so once the user starts scrolling, the full CSS will (hopefully) already have loaded.

Visually speaking, content will appear to render more quickly, but there will also be more reflowing and jumping on the page. So, if a user has followed a link to a particular comment below the “fold”, then they will see a few reflows as the website is being constructed because the page is rendered with critical CSS first (there is just so much we can fit within 14 KB!) and adjusted later with the complete CSS. Of course, inline CSS isn’t cached; so, if you have critical CSS and load the complete CSS on rendering, it’s useful to set a cookie, so that inline styles aren’t inlined with every single load. The drawback of course is that you might have duplicate CSS because you would be defining styles both inline and in the full CSS, unless you’re able to strictly separate them.

Because we had just refactored our CSS code base, identifying critical CSS wasn’t very difficult. Obviously, there are smart61 tools62 that analyze the markup and CSS, identify critical CSS styles and export them into a separate file during the build process, but we were able to do it manually. Again, you have to keep in mind that 14 Kb is your budget for HTML and CSS, so in the end we had to rename a few classes here and there, and compress CSS as well.

We analyzed the first 800px, checking the inspector for the CSS that was needed and separating our style sheet into two files – and actually that was pretty much it. One of those files, above-the-fold.css, is minified and compressed, and its content is placed inline in the head of our document as early as possible – not blocking rendering. The other file, our full CSS file, is then loaded with JavaScript after the content has loaded, and if JavaScript isn’t available for some reason or the user is on a legacy browser, we’ve put a full CSS file inside noscript tag at the end of the head, so they don’t get an unstyled HTML page.

Was It All Worth It?

Because we’ve just implemented these optimizations, we haven’t been able to measure their impact on traffic, but we’ll publish these results later as well. Obviously, we did notice a quite remarkable technical improvement though. By deferring and caching web fonts, inlining CSS and optimizing the critical rendering path for the first 14Kb, we were able to achieve dramatic improvements in loading times. The start rendering time started circling around 1s for an uncached page on 3G and was around 700ms (including latency!) on subsequent loads.

We’ve been using WebPageTest6428 a lot for running tests. Our waterfall chart was becoming better over time and reflected the priorities we had defined earlier. Large view.65

On average, Smashing Magazine’s front page makes 45 HTTP-requests and has 440 KB in bandwidth on the first uncached load. Because we heavily cache everything but ads, subsequent visits have around 15 HTTP requests and 180 KB of traffic. The First Byte time is still around 300–600ms (which is a lot), yet Start Render time is usually under 0.7s66 on a DSL connection in Amsterdam (for the very first, uncached load), and usually under 1.7s on a slow 3G67. On a fast cable connection, the site starts rendering within 0.8s68, and on a fast 3G, within 1.1s69. Obviously, the results vary significantly depending on the First Byte time which we can’t improve just yet, at the time of writing. That’s the only asset that introduces unpredictability into the loading process, and as such has a decisive impact on the overall performance.

Just by following basic guidelines by our colleagues mentioned above and Google’s recommendations, we were able to achieve the 97–99 Google PageSpeed score70 both on desktop and on mobile. The score varies depending on the quality and the optimization level of advertising assets displayed randomly in the sidebar. Again, the main culprit is the server’s response time — not for long, though.

After a fewoptimizations, we achieved a Google PageSpeed score of 99 on mobile72.

We got a Google PageSpeed score of 99 on the desktop74 as well.

By the way, Scott Jehl has also published a wonderful article on the front-end techniques75 FilamentGroup uses to extract critical CSS and load it inline while loading the full CSS afterwards and avoid downloading overheads. Patrick Hamann’s talk on “Breaking News at 1000ms”76 explains a few techniques that The Guardian is using to hit the SpeedIndex 1000 mark. Definitely worth reading and watching, and indeed quite similar to what we implemented on this very site as well.

Work To Be Done

While the results we were able to achieve are quite satisfactory, there is still a lot of work to be done. For example, we haven’t considered optimizing the delivery of images just yet, and are now adjusting our editorial process to integrate the new picture element and srcset/sizes with Picturefill 2.1.077, to make the loading even faster on mobile devices. At the moment, all images have a fixed width of 500px and are basically scaled down on smaller views. Every image is optimized and compressed, but we don’t deliver different images for different devices — and no, we aren’t delivering any Retina images at all. That is all about to change soon.

While Smashing Magazine’s home page is well optimized, some pages and articles still perform poorly. Articles with many comments are quite slow because we use a Gravatar78 for comments. Because each Gravatar URL is unique, each comment generates one HTTP request, slowing down the loading of the overall page. We are going to defer the loading of Gravatars and cache them locally with a Gravatar Cache WordPress plugin79. We might have already done it by the time you read this.

We’re playing around with DNS prefetching and HTML5 preloading to resolve DNS lookups way ahead of time (for example, for Gravatars and advertising). However, we are being careful and hesitant here because we don’t want to create a loading overhead for users on slow or expensive connections. Besides, we’ve added third-party meta data80 to make our articles a bit easier to share. So, if you link to an article on Facebook, Facebook will pull optimized images, a description and a title from our meta data, which is crafted individually for each article.

Yes, we can use SPDY today82. We just need to install SPDY Nginx Module83 or Apache SPDY Module84. This is what we are going to tackle next.

Despite all of our optimizations, the main issue still hasn’t been resolved: very slow servers and the First Byte response times. We’ve been experiencing difficulties with our current server setup and architecture but are tied with a long-term contract, yet we will be moving to a new server soon. We’ll take that opportunity to also move to SPDY85 on the server, a predecessor of HTTP 2.0 (which is well supported in major browsers86, by the way), and we are looking into using a content delivery network as well.

Performance Optimization Strategy

To sum up, optimizing the performance of Smashing Magazine was quite an effort to figure out, yet many aspects of optimization can be achieved very quickly. In particular, front-end optimization is quite easy and straightforward as long as you have a shared understanding of priorities. Yes, that's right: you optimize content delivery, and defer everything else.

Strategically speaking, the following could be your performance optimization roadmap:

  • Remove blocking scripts from the header of the page.
  • Identify and defer non-critical CSS and JavaScript.
  • Identify critical CSS and load it inline in the head, and then load the full CSS after rendering. (Make sure to set a cookie to prevent inline styles from loading with every page load.)
  • Keep all critical HTML and CSS to under 14 KB, and aim for a Speed Index of under 1000.
  • Defer the loading of Web fonts and store them in localStorage or AppCache.
  • Consider using WOFF2 to further reduce latency and file size of the web fonts.
  • Replace JavaScript libraries with leaner JavaScript modules.
  • Avoid unnecessary libraries, and look into options for removing Respond.js and Modernizr; for example, by “cutting the mustard87” to separate browsers into buckets. Legacy browsers could get a fixed-width layout. Clever SVG fallbacks88 also exist.

That’s basically it. By following these guidelines, you can make your responsive website really, really fast.


Yes, finding just the right strategy to make this very website fast took a lot of experimentation, blood, sweat and cursing. Our discussions kept circling around next steps and on critical and not-so-critical components and sometimes we had to take three steps back in order to pivot in a different direction. But we learned a lot along the way, and we have a pretty clear idea of where we are heading now, and, most importantly, how to get there.

So here you have it. A little story about the things that happened on this little website over the last year. If you notice any issues, please let us know on Twitter @smashingmag89 and we'll hunt them down for good.

Ah, and thanks for keeping us reading throughout all these years. It means a lot. You are quite smashing indeed. You should know that.

A big "thank you" to Patrick Hamann and Jake Archibald for the technical review of the article as well as Andy Hume and Tim Kadlec for their fantastic support throughout the years. Also a big "thank you" to our front-end engineer, Marco, for his help with the article and for his thorough and tireless front-end work, which involved many experiments, failures and successes along the way. Also, kind thanks to the Inpsyde team and Florian Sander for technical implementations.

A final thank you goes out to Iris, Melanie, Cosima and Markus for keeping an eye out for those nasty bugs and looking after the content on the website. Without you, this website wouldn’t exist. And thank you for having my back all this time. I respect and value every single bit of it. You rock.

(al, vf, il)

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

The post Improving Smashing Magazine’s Performance: A Case Study appeared first on Smashing Magazine.

Internal Developer Training: Doing It Right

Fri, 09/05/2014 - 13:39

Successful developers all have something in common: the desire to create. To fully realize that creativity, they need to continually improve their skills. The web industry has grown from this desire to learn. You only need to look at the unwavering demand for conferences, workshops and training days for evidence of this.

For many companies, however, these sources of training require time and money that simply might not be available — especially when you consider that technologies evolve all the time. The cost of continually sending your team to workshops and training days can quickly become unsustainable.

People in the web industry in particular believe in sharing what they’ve learned and helping others to improve their skills. This is the perfect premise on which to develop an internal training program. Within your team lies a wealth of skills, knowledge and experience that can be shared and developed further. With a little effort and using resources freely available on the web, you can increase the technical competence of the team organically, with much lighter demands on time and cost.

Why Bother?

Good developers will teach themselves anyway, right? Well, yes. But significant benefits are to be gained from formalizing and actively championing training within the company.

Developers who excel in a particular technology can teach it to others, gaining morale-boosting recognition and a reputation for being the go-to person for that skill. Junior members of the team will learn what the team is capable of and who they should query with specific questions. This is much more valuable than you might realize — knowing exactly where to go when a problem arises can quickly prevent bottlenecks in a project and make the team much more responsive.

As developers spend structured time together, they will learn the strengths and weaknesses of the team and form a more cohesive unit. They will be more able and willing to innovate and push boundaries if they know the full capabilities of their colleagues.

Most importantly, regular well-executed training will make developers better at their job and probably much happier. They will understand more, be challenged more and be significantly more productive.

Developers will always be more committed when value is put on their current skills and when their potential is invested in. In an industry that has so many attractive and flexible places to work, training can be a significant perk that helps to retain and attract talent.

Let’s Get Started Already!

The first challenge you will likely face in implementing regular training sessions is getting the company to buy into what you are trying to achieve. Explain the aforementioned benefits to aid your cause. However, you might have to get creative if your work environment is less flexible. For example, consider reducing the investment of time by proposing a “brown bag” approach. Get team members to bring their own food and make the training session an informal lunch meeting.

Management is much more likely to offer its full support if it can see evidence of the benefits. Clearly explain that not only are you looking for their approval, but you want to keep them in the loop as the training progresses. Showing a comprehensive plan and clear metrics for how the team will improve will go a long way to convincing management that the investment of time will benefit the company.

The Training Plan

To formulate the plan, look through the most recent projects that your team has worked on. Analyze the skill sets that were used. Talk to project managers about any issues that may have arisen. Keep an eye on developments in the wider industry and how they might bear on future projects.

Most importantly, look at the developers’ personal development plans and see how training could facilitate their goals. This will also help you to identify senior members of the team and those with specific expertise who would benefit from leading the training sessions themselves. Senior members in particular will have a wealth of development and commercial experience.

Of course, make sure that the senior members of the team are on board and would be comfortable leading training sessions. Give them enough time to prepare, and provide guidance on what is expected, while still allowing them sufficient freedom to make the session their own.

Keep the training plan simple. List the specific sessions you wish to include, briefly describe them, and assign them to developers who have the skills to lead them.

Order the training sessions by importance, but don’t feel you have to attach dates. Depending on the size of the team, you might find that key members will be absent for some of them and that you will need to reschedule.

At the end of each session, date it and mark it as completed in the training plan. Write any relevant notes next to the entry, such as problems, areas not covered and new avenues to explore in future sessions. Make the document a collaborative spreadsheet to make it easier to share internally.

Measuring Skill Level

Exactly measuring a developer’s skill level is difficult, but a generalized indication will help.

One way is to use a skills matrix, listing each team member down the left column, languages and skills along the top, and a scale of 0 to 10 as measurements:

  • 0
    no experience
  • 1–3
    understands the basics
  • 4–7
    competent with practical experience
  • 8–10
A sample skills matrix (View large version2)

Adapt the scale to your needs. You could make it more general, with terms such as beginner, intermediate and expert. Or make it more complex, depending on the skills required by your team. Review it when training sessions are completed and after significant projects.

A matrix that is up to date makes for a useful tool to allocate resources, schedule work and inform the wider company of the development team’s capabilities.

Stick To Your Principles

Before planning the content of the training sessions, consider some underlying principles.


Due to the nature of development, finding a regular time when all members of the development team can step away from their work is tricky. Avoid standard release dates and the preceding and succeeding days.

Aim for once a week. Greater frequency could threaten deadlines and meet with resistance from management. Keep the sessions consistent; too much rescheduling or skipping of sessions will devalue the importance of the training in the eyes of the developers.

Friday is often a good time, especially in the afternoon. Most of the company will be winding down at this time, and disruption will probably be minimal. If homework is assigned, this also gives developers the opportunity to dabble with it on the weekend.

Plan the sessions in advance. Keep them short and sweet, no longer than an hour to keep everyone engaged.


A meeting room with a large screen and wireless Internet would be ideal. Ensure that there is enough comfortable seating so that everyone can participate easily.

Such rooms are usually designed for client presentations, which can make them difficult to book. Again, scheduling the training sessions for a slow period of the week and booking in advance should help with that. Send out calendar invitations so that the team blocks out that time, too.

Let any potentially disruptive colleagues know that training sessions should not be interrupted. Once everyone has arrived, close the door. Shut out everything (and everyone) that could be a distraction.

Don’t forget about off-site members of the team. Being included will give them the benefit of the training and also remind them that they are considered part of the team. Use Skype or Google Hangouts to include them. Ensure that their supervisor knows about the training session so that they can allocate the time and, ideally, a quiet, comfortable environment.


To protect the time, both the company and the team need to agree that attendance at training sessions is mandatory. Exceptions and rescheduling should happen only in extreme circumstances.

Phones and laptops are distractions and should be discouraged. Attention should be focused on the presenter and their material.


When planning the sessions, try to align the individual developers’ targets with the company’s goals for growth. Focus on technologies and techniques that will not only benefit the team, but increase the company’s expertise.

The skill-level matrix mentioned above can be distributed to other departments to help them understand the development team’s capabilities.


Without practical application, training will be quickly forgotten. To achieve real progress, assign a task for the participants to practice the skills they’ve learned in the session.

The assignment should be small enough to achieve in the downtime between projects or outside of normal working hours if necessary. More importantly, it should be interesting enough that a developer would want to do it, especially if it needs to be completed in their spare time.

Reviewing an assignment could be the focus of the subsequent session, in which you would explore different approaches and techniques, as well as identify and reward those who have excelled.

Homework is, of course, optional. Not everyone will want to do it, and, despite their best intentions, developers won’t always have the time to tackle it.

But if the training sessions are aligned with both the company’s goals and their personal development plans, you might be surprised by how willing the developers are to complete homework. They’ll be inspired by the chance to show off their skill, gain recognition from colleagues and maybe even win a prize.


Not everyone will make it to every training session. Developers take vacations, and urgent bugs and tight deadlines will sometimes intrude. Recording sessions is a good way to give those who miss one a chance to catch up.

Also, share the slides and links from each session with attendees. The best way to do this is to set up a Github Pages website using Jekyll3, and get everyone to contribute. The website could also be used as an internal knowledge base.


Keep it fun! If the training sessions become a chore, then they probably won’t be successful. A friendly, open and honest environment will create the right culture for growth, fostering connections between team members, and improving communication and cohesiveness.

Let’s Break It Down

So, how do you go about structuring a training session? As mentioned, this is highly subjective and depends on both the facilitator and the team. However, if you’re struggling to know where to begin, let’s make a meal out of it!

The Appetizer

Everyone likes to have a taste of what is going on, so start with a quick business update, detailing the company’s latest wins and the progress of work underway. If you have any other news about the company, including potential opportunities within, consider sharing it, too.

An update on the wider industry could also be beneficial. If any key developments have happened, discuss these and share links to relevant articles. The beginning of the session is also a good opportunity to review homework and single out the best solution with recognition (and a trophy if you’re feeling generous!).

Don’t dwell on any of these things for long. This section shouldn’t last longer than 20 minutes.

The Main Course

The meat of the session should focus on the designated topic.

The most common type of session will probably be a tutorial on a particular language or technique. Don’t assume anything. Introduce the technology, explaining its purpose and situations when it is best used, not forgetting its limitations. Ask for opinions and experiences from any team members who have experience with the technology.

Showing examples is the easiest way to demonstrate a technology. Prepare these carefully, especially if you plan to follow a similar approach in your development projects. Keep them succinct. Either use multiple small examples, or break down a single big example into digestible modules. Avoid live coding unless it is simple and prepared in advance.

Deposit all of the coding examples in your knowledge base or Github repository so that the team can examine them after the session.

With more complex, substantial areas, consider splitting the training into multiple sessions. Start with the basics, and increase the learning curve each week. Don’t rely on tutorials alone — mix things up. Plenty of different formats will give developers valuable knowledge and insight.

Deconstruct a project completed by the team. Identify successful approaches, and analyze any issues that arose. Review the techniques used, and get feedback from developers who worked on the project. This will help to account for contingencies if any changes need to be made and will demonstrate good ways to tackle future projects.

If your company is more creative and pioneering, consider devoting sessions to new hardware that has been acquired. Play around with it and inspire your developers.

Collaboration within the team and with other departments could also be incorporated into training sessions. Consider two speakers from different areas presenting the same technology — programmers and designers will often have very different views. Or venture even further and invite a project manager to lead a session, which could improve processes, communication and understanding between departments.

The Dessert

Finally, finish the session by mulling over what you’ve covered. Invite questions and encourage discussion.

Before everyone leaves, assign the homework. Choose it ahead of time, and clearly explain it. The assignment should relate to the material covered in the session — and perhaps extend it.

A sample training session schedule (View large version4) Continual Improvement

Continually review the effectiveness of the training sessions. Once they have become a regular fixture, solicit feedback.

Keep the training collaborative. Invite the development team to tell you what works for them and what doesn’t, and be prepared to alter the training plan. Also, look to the wider company to see what impact the training is having and whether particular areas might need more focus.

Every team and every company continually evolves. Training will help to keep both aligned and at the forefront of the industry, enabling them to shine.

(ml, al, il)

Front page image credits: The Next Web Photos5.

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

The post Internal Developer Training: Doing It Right appeared first on Smashing Magazine.

Animating Without jQuery

Thu, 09/04/2014 - 13:11

There’s a false belief in the web development community that CSS animation is the only performant way to animate on the web. This myth has coerced many developers to abandon JavaScript-based animation altogether, thereby (1) forcing themselves to manage complex UI interaction within style sheets, (2) locking themselves out of supporting Internet Explorer 8 and 9, and (3) forgoing the beautiful motion design physics that are possible only with JavaScript.

Reality check: JavaScript-based animation is often as fast as CSS-based animation — sometimes even faster. CSS animation only appears to have a leg up because it’s typically compared to jQuery’s $.animate(), which is, in fact, very slow. However, JavaScript animation libraries that bypass jQuery deliver incredible performance by avoiding DOM manipulation as much as possible. These libraries can be up to 20 times faster than jQuery.

So, let’s smash some myths, dive into some real-world animation examples and improve our design skills in the process. If you love designing practical UI animations for your projects, this article is for you.

Why JavaScript?

CSS animations are convenient when you need to sprinkle property transitions into your style sheets. Plus, they deliver fantastic performance out of the box — without your having to add libraries to the page. However, when you use CSS transitions to power rich motion design (the kind you see in the latest versions of iOS and Android), they become too difficult to manage or their features simply fall short.

Ultimately, CSS animations limit you to what the specification provides. In JavaScript, by the very nature of any programming language, you have an infinite amount of logical control. JavaScript animation engines leverage this fact to provide novel features that let you pull off some very useful tricks:

Note: If you’re interested in learning more about performance, you can read Julian Shapiro’s “CSS vs. JS Animation: Which Is Faster?5” and Jack Doyle’s “Myth Busting: CSS Animations vs. JavaScript6.” For performance demos, refer to the performance pane7 in Velocity’s documentation and GSAP’s “Library Speed Comparison8” demo.

Velocity and GSAP

The two most popular JavaScript animation libraries are Velocity.js9 and GSAP10. They both work with and without11 jQuery. When these libraries are used alongside jQuery, there is no performance degradation because they completely bypass jQuery’s animation stack.

If jQuery is present on your page, you can use Velocity and GSAP just like you would jQuery’s $.animate(). For example, $element.animate({ opacity: 0.5 }); simply becomes $element.velocity({ opacity: 0.5 }).

These two libraries also work when jQuery is not present on the page. This means that instead of chaining an animation call onto a jQuery element object — as just shown — you would pass the target element(s) to the animation call:

/* Working without jQuery */ Velocity(element, { opacity: 0.5 }, 1000); // Velocity, 1, { opacity: 0.5 }); // GSAP

As shown, Velocity retains the same syntax as jQuery’s $.animate(), even when it’s used without jQuery; just shift all arguments rightward by one position to make room for passing in the targeted elements in the first position.

GSAP, in contrast, uses an object-oriented API design, as well as convenient static methods. So, you can get full control over animations.

In both cases, you’re no longer animating a jQuery element object, but rather a raw DOM node. As a reminder, you access raw DOM nodes by using document.getElementByID, document.getElementsByTagName, document.getElementsByClassName or document.querySelectorAll (which works similarly to jQuery’s selector engine). We’ll briefly work with these functions in the next section.

Working Without jQuery

(Note: If you need a basic primer on working with jQuery’s $.animate(), refer to the first few panes in Velocity’s documentation.12)

Let’s explore querySelectorAll further because it will likely be your weapon of choice when selecting elements without jQuery:

document.querySelectorAll("body"); // Get the body element document.querySelectorAll(".squares"); // Get all elements with the "square" class document.querySelectorAll("div"); // Get all divs document.querySelectorAll("#main"); // Get the element with an id of "main" document.querySelectorAll("#main div"); // Get the divs contained by "main"

As shown, you simply pass querySelectorAll a CSS selector (the same selectors you would use in your style sheets), and it will return all matched elements in an array. Hence, you can do this:

/* Get all div elements. */ var divs = document.querySelectorAll("div"); /* Animate all divs at once. */ Velocity(divs, { opacity: 0.5 }, 1000); // Velocity, 1, { opacity: 0.5 }); // GSAP

Because we’re no longer attaching animations to jQuery element objects, you may be wondering how we can chain animations back to back, like this:

$element // jQuery element object .velocity({ opacity: 0.5 }, 1000) .velocity({ opacity: 1 }, 1000);

In Velocity, you simply call animations one after another:

/* These animations automatically chain onto one another. */ Velocity(element, { opacity: 0.5 }, 1000); Velocity(element, { opacity: 1 }, 1000);

Animating this way has no performance drawback (as long as you cache the element being animated to a variable, instead of repeatedly doing querySelectorAll lookups for the same element).

(Tip: With Velocity’s UI pack, you can create your own multi-call animations and give them custom names that you can later reference as Velocity’s first argument. See Velocity’s UI Pack documentation13 for more information.)

This one-Velocity-call-at-a-time process has a huge benefit: If you’re using promises14 with your Velocity animations, then each Velocity call will return an actionable promise object. You can learn more about working with promises in Jake Archibald’s article15. They’re incredibly powerful.

In the case of GSAP, its expressive object-oriented API allows you to place your animations in a timeline, giving you control over scheduling and synchronization. You’re not limited to one-after-the-other chained animations; you can nest timelines, make animations overlap, etc:

var tl = new TimelineMax(); /* GSAP tweens chain by default, but you can specify exact insertion points in the timeline, including relative offsets. */ tl .to(element, 1, { opacity: 0.5 }) .to(element, 1, { opacity: 1 }); JavaScript Awesomeness: Workflow

Animation is inherently an experimental process in which you need to play with timing and easings to get exactly the feel that your app needs. Of course, even once you think a design is perfect, a client will often request non-trivial changes. In these situations, a manageable workflow becomes critical.

While CSS transitions are impressively easy to sprinkle into a project for effects such as hovers, they become unmanageable when you attempt to sequence even moderately complex animations. That’s why CSS provides keyframe animations, which allow you to group animation logic into sections.

However, a core deficiency of the keyframes API is that you must define sections in percentages, which is unintuitive. For example:

@keyframes myAnimation { 0% { opacity: 0; transform: scale(0, 0); } 25% { opacity: 1; transform: scale(1, 1); } 50% { transform: translate(100px, 0); } 100% { transform: translate(100px, 100px); } } #box { animation: myAnimation 2.75s; }

What happens if the client asks you to make the translateX animation 1 second longer? Yikes. That requires redoing the math and changing all (or most) of the percentages.

Velocity has its UI pack16 to deal with multi-animation complexity, and GSAP offers nestable timelines17. These features allow for entirely new workflow possibilities.

But let’s stop preaching about workflow and actually dive into fun animation examples.

JavaScript Awesomeness: Physics

Many powerful effects are achievable exclusively via JavaScript. Let’s examine a few, starting with physics-based animation.

The utility of physics in motion design hits upon the core principle of what makes for a great UX: interfaces that flow naturally from the user’s input — in other words, interfaces that adhere to how motion works in the real world.

GSAP offers physics plugins that adapt to the constraints of your UI. For example, the ThrowPropsPlugin tracks the dynamic velocity of a user’s finger or mouse, and when the user releases, ThrowPropsPlugin matches that corresponding velocity to naturally glide the element to a stop. The resulting animation is a standard tween that can be time-manipulated (paused, reversed, etc.):

See the Pen Draggable “Toss” Demo18 by GreenSock (@GreenSock3319) on CodePen3431262320.

Velocity offers an easing type based on spring physics. Typically with easing options, you pass in a named easing type; for example, ease, ease-in-out or easeInOutSine. With spring physics, you pass a two-item array consisting of tension and friction values (in brackets below):

Velocity(element, { left: 500 }, [ 500, 20 ]); // 500 tension, 20 friction

A higher tension (a default of 500) increases the total speed and bounciness. A lower friction (a default of 20) increases ending vibration speed. By tweaking these values, you can separately fine-tune your animations to have different personalities. Try it out:

See the Pen Velocity.js – Easing: Spring Physics (Tester)21 by Julian Shapiro (@julianshapiro302522) on CodePen3431262320.

JavaScript Awesomeness: Scrolling

In Velocity, you can enable the user to scroll the browser to the edge of any element by passing in scroll as Velocity’s first argument (instead of a properties map). The scroll command behaves identically to a standard Velocity call; it can take options and can be queued.

Velocity(element, "scroll", { duration: 1000 };

See the Pen Velocity.js – Command: Scroll w/ Container Option24 by Julian Shapiro (@julianshapiro302522) on CodePen3431262320.

You can also scroll elements within containers, and you can scroll horizontally. See Velocity’s scroll documentation27 for further information.

GSAP has ScrollToPlugin28, which offers similar functionality and can automatically relinquish control when the user interacts with the scroll bar.

JavaScript Awesomeness: Reverse

Both Velocity and GSAP have reverse commands that enable you to animate an element back to the values prior to its last animation.

In Velocity, pass in reverse as Velocity’s first argument:

// Reverse defaults to the last call's options, which you can extend Velocity(element, "reverse", { duration: 500 });

Click on the “JS” tab to see the code that powers this demo:

See the Pen Velocity.js – Command: Reverse29 by Julian Shapiro (@julianshapiro302522) on CodePen3431262320.

In GSAP, you can retain a reference to the animation object, then invoke its reverse() method at any time:

var tween =, 1, {opacity:0.5}); tween.reverse(); JavaScript Awesomeness: Transform Control

With CSS animation, all transform components — scale, translation, rotation and skew — are contained in a single CSS property and, consequently, cannot be animated independently using different durations, easings and start times.

For rich motion design, however, independent control is imperative. Let’s look at the dynamic transform control that’s achievable only in JavaScript. Click the buttons at any point during the animation:

See the Pen Independent Transforms32 by GreenSock (@GreenSock3319) on CodePen3431262320.

Both Velocity and GSAP allow you to individually animate transform components:

// Velocity /* First animation */ Velocity(element, { translateX: 500 }, 1000); /* Trigger a second (concurrent) animation after 500 ms */ Velocity(element, { rotateZ: 45 }, { delay: 500, duration: 2000, queue: false }); // GSAP /* First animation */, 1, { x: 500 }); /* Trigger a second (concurrent) animation after 500 ms */, 2, { rotation: 45, delay: 0.5 }); Wrapping Up
  • Compared to CSS animation, JavaScript animation has better browser support and typically more features, and it provides a more manageable workflow for animation sequences.
  • Animating in JavaScript doesn’t entail sacrificing speed (or hardware acceleration). Both Velocity and GSAP deliver blistering speed and hardware acceleration under the hood. No more messing around with null-transform hacks.
  • You don’t need to use jQuery to take advantage of dedicated JavaScript animation libraries. However, if you do, you will not lose out on performance.
Final Note

Refer to Velocity35 and GSAP’s documentation36 to master JavaScript animation.

(al, il)

Front page image credits: NASA Goddard Space Flight Center 37.

  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

The post Animating Without jQuery appeared first on Smashing Magazine.

Testing Mobile: Emulators, Simulators And Remote Debugging

Wed, 09/03/2014 - 13:16

In the early days of mobile, debugging was quite a challenge. Sure, you could get ahold of a device and perform a quick visual assessment, but what would you do after discovering a bug?

With a distinct lack of debugging tools, developers turned to a variety of hacks. In general, these hacks were an attempt to recreate a given issue in a desktop browser and then debug with Chrome Developer Tools or a similar desktop toolkit. For instance, a developer might shrink the size of the desktop browser’s window to test a responsive website or alter the user agent to spoof a particular mobile device.

To put it bluntly, these hacks don’t really mean anything. If you’re recreating issues on the desktop, then you can’t be certain that any of your fixes will work. This means you’ll be constantly bouncing back and forth between the mobile device and the hacks in your desktop browser.

Fast forward to today, when we have a robust suite of debugging tools that provide meaningful debugging information directly from a physical device. Best of all, you can use the same desktop debugging tools that you know and love, all on an actual mobile device.

In this article, we’ll explore a variety of emulators and simulators that you can use for quick and easy testing. Then, we’ll look at remote debugging tools, which enable you to connect a desktop computer to a mobile device and leverage a rich debugging interface.

Emulators And Simulators

Testing on real physical devices always pays off. But that doesn’t mean you shouldn’t also test on emulators and simulators. These virtual environments not only expand your testing coverage to more devices, but also are a quick and easy way to test small changes on the fly.

iOS Simulator

To test iOS devices, such as the iPhone and iPad, you have a number of options, most notably Apple’s official iOS Simulator. Included as part of Xcode, this simulator enables you to test across different software and hardware combinations, but only from a Mac.

Viewing a website in iOS Simulator (Image: Jon Raasch2) (View large version3)

First, install and open Xcode. Then, in Xcode, right-click and select “Show Package Contents.” Go to “Contents” → “Applications” → “iPhone Simulator.”

Finding iOS Simulator in Xcode (View large version5)

Although iOS Simulator is difficult to find, using it is fortunately easy. Simply open up Safari in the simulator and test your website. You can switch between different iPhone and iPad devices, change the iOS version, rotate the viewport and more.

Note: If you’re not working on a Mac, you’ll have to find another option. You could look to iPadian6, a Windows-based iPad simulator. Beyond that, a handful of other simulators exist, including certain web-based offerings7. But, to be honest, none of these are very promising.

Android Emulator

Android also provides an emulator. Luckily, this one is cross-platform. Unfortunately, setting it up is a bit of a pain.

First, download the bundle8 that includes Android Development Tools (ADT) for Eclipse and the Android software development kit (SDK). Next, follow Google’s instructions9 to install the SDK packages, making sure to install the default selections as well as the “Intel x86 Emulator Accelerator (HAXM installer)”. You’ll also need to track down HAXM — search your Mac for IntelHaxm.dmg or your PC for IntelHaxm.exe, and run the file to install it.

Installing the Android SDK packages: HAXM improves the performance of the emulator. (View large version11)

Next, create an Android virtual device (AVD) for whichever device you’re testing. If you go into the AVD manager, you’ll see a list of preset devices in “Device Definitions.” These cover a variety of Google products and some generic devices. To get started, select one of these presets and click “Create AVD.”

The “Device Definitions” tab provides preset AVDs. Use one of them or create your own. (View large version13)

Set whatever you like for the CPU, and set “No skin“ and “Use host GPU.” Now you can run the virtual device and use Android’s browser to test your website.

Viewing a website in the Android emulator (Image: Smashing Magazine15) (View large version16)

Finally, you’ll probably want to learn some keyboard commands17 to better interact with the emulator.

Note: Manymo18 is an alternative, in-browser Android emulator. You can even embed it in a web page, which is pretty darn cool.

Other Simulators and Emulators Remote Testing

Emulators and simulators are useful, but they’re not 100% accurate. Always test on as many real devices as possible.

That doesn’t mean you need to buy a hundred phones and tablets. You can take advantage of remote testing resources, which provide a web-based interface to interact with real physical devices. You’ll be able to interact with a phone remotely and view any changes in the screencast that is sent back to your machine.

If you want to test a Samsung device, such as the Galaxy S5, you can do so for free using Samsung’s Remote Test Lab21, which enables you to test on a wide selection of Samsung devices.

Additionally, you can use the resources in Keynote Mobile Testing22. They’re not cheap, but the number of devices offered is pretty astonishing, and you can test a handful of devices for free.

Note: If you’re looking to get your hands on real devices, Open Device Lab23 can point you to a lab in your area, where you can test on a range of devices for free.

Remote Debugging

Remote debugging addresses a variety of the challenges presented by mobile debugging. Namely, how do you get meaningful debugging information from a small and relatively underpowered device?

Remote debugging tools provide an interface to connect to a mobile device from a desktop computer. Doing this, you can debug for a mobile device using the development tools on a more powerful, easier-to-use desktop machine.


With the release of iOS 6.0, Apple introduced a tool that enables you to use desktop Safari’s Web Inspector to debug iOS devices.

To get started, enable remote debugging on your iOS device by going to “Settings” → “Safari” → “Advanced” and enabling “Web Inspector.”

First, enable Web Inspector in “Settings” → “Safari” → “Advanced.” (View large version25)

Next, physically connect your phone or tablet to your machine using a USB cable. Then, open Safari (version 6.0 or higher), and in “Preferences” → “Advanced,” select “Show Develop menu in menu bar.”

Now, in the “Develop” menu you should see your iOS device, along with any open pages in mobile Safari.

Once your iOS device is connected, you’ll see it in the “Develop” menu. (View large version27)

Select one of these pages, and you’ll have a wide range of developer tools at your fingertips. For example, try out the DOM Inspector, which enables you to tap DOM elements on your mobile device and see debugging information on the desktop.

Web Inspector in desktop Safari is inspecting this iPhone. (View large version29)

The DOM Inspector is really just the beginning. iOS’ remote developer tools provide a ton of features, such as:

  • timelines to track network requests, layout and rendering tasks and JavaScript;
  • a debugger to set breakpoints and to profile the JavaScript;
  • a JavaScript console.

To learn more about what you can do, read through the documents in the “Safari Web Inspector Guide30.”

You don’t need a physical iOS device to use remote debugging. You can also debug instances of iOS Simulator. (View large version32)

Note: Much like iOS Simulator, you can only do remote debugging for iOS on Mac OS X.


Similar to iOS, Android has a remote debugging solution. The tools in it enable you to debug an Android device from a desktop machine using Chrome’s Developer Tools. Best of all, Android’s remote debugging is cross-platform.

First, go to “Settings” → “About Phone” on your Android 4.4+ phone (or “Settings” → “About Tablet”). Next, tap the “Build Number” seven (7) times. (No, I’m not joking. You’ll see a message about being a developer at the end.) Now, go back to the main settings and into “Developer Options.” Here, enable “USB debugging,” and you’re all set.

Left: Tap the “Build Number” seven times to enable developer mode. Right: Enable “USB debugging.”(View large version34)

Go into your desktop Chrome browser, and type about:inspect in the address bar. Enable “Discover USB devices,” and you’ll see your device in the menu.

Once you enable “Discover USB devices,” you’ll see a list of devices connected remotely to Chrome, along with a list of debuggable web pages or apps for each device. (View large version36)

You should also see any open tabs in your mobile browser. Select whichever tab you want to debug, and you’ll be able to leverage a ton of useful tools, such as:

  • a DOM Inspector,
  • a network panel for external resources,
  • a sources panel to watch JavaScript and to set breakpoints,
  • a JavaScript console.

To learn more about what’s possible, read HTML5 Rocks’ tutorial “Introduction to Chrome Developer Tools, Part One5037.”

Here, the DOM Inspector in the desktop browser is remotely inspecting a page on the Android device. (Image: Google39) (View large version40)

Note: You can also remotely debug with the Android emulator.


You now know how to remotely debug a variety of devices. But if you want to debug iOS on Windows or on Linux or debug other devices, such as Windows Phone or BlackBerry, then try Weinre, which works on any device.

Setting up Weinre is a bit more complicated because you have to install it on both the server and the page. To get started, install Node, and then install the Weinre module with the following command:

npm install –g weinre

Next, run the debugging server using your development machine’s IP:

weinre --boundHost

Note: Make sure to insert your own IP in the command above. You can find your IP on a Mac using the command ipconfig getifaddr en0 and on Windows using ipconfig.

Next, go to the development server that is outputted by Weinre in the console (in my case, it’s localhost:8080). Here, look at the “Target Script” section, and grab the <script> tag. You’ll need to include that on whichever pages you want to debug.

The Weinre development server gives you the client-side script to embed, along with a link to the debugging interface. (View large version42)

Finally, click on the link at the top of this page for the user interface for debugging clients (in my case, it’s http://localhost:8080/client/#anonymous). Now, once you open the page in your device, you should see it in the list of targets.

Note: If you’re having trouble connecting a device to your localhost, consider setting up a public tunnel with ngrok43.

Weinre’s debugging interface provides a link to each debuggable target. (View large version4745)

At this point, you can leverage a lot of WebKit Developer Tools to debug the page. You can use handy tools such as the DOM Inspector:

Here, Weinre is debugging iOS with the DOM Inspector. (View large version4745)

Once you get past the initial installation, Weinre lets you debug any device on any network. However, it’s not as powerful as the native solutions for iOS and Android. For example, you can’t use the “Sources” panel to debug JavaScript or take advantage of the profiler.

Note: Ghostlab48 is another remote testing option that supports multiple platforms.


In this article, we’ve learned how to set up a robust testing suite using a combination of physical devices, emulators, simulators and remote testing tools. With these tools, you are now able to test a mobile website or app across a wide variety of devices and platforms.

We’ve also explored remote debugging tools, which provide useful information directly from a mobile device. Hopefully, you now realize the benefits of remote debugging for mobile. Without it, we’re really just taking stabs in the dark.

Further Reading

(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

The post Testing Mobile: Emulators, Simulators And Remote Debugging appeared first on Smashing Magazine.


Secure Login

This login is SSL protected