Tags: design

131

sparkline

Someday

In the latest issue of Justin’s excellent Responsive Web Design weekly newsletter, he includes a segment called “The Snippet Show”:

This is what tells all our browsers on all our devices to set the viewport to be the same width of the current device, and to also set the initial scale to 1 (not scaled at all). This essentially allows us to have responsive design consistently.

<meta name="viewport" content="width=device-width, initial-scale=1">

The viewport value for the meta element was invented by Apple when the iPhone was released. Back then, it was a safe bet that most websites were wider than the iPhone’s 320 pixel wide display—most of them were 960 pixels wide …because reasons. So mobile Safari would automatically shrink those sites down to fit within the display. If you wanted to over-ride that behaviour, you had to use the meta viewport gubbins that they made up.

That was nine years ago. These days, if you’re building a responsive website, you still need to include that meta element.

That seems like a shame to me. I’m not suggesting that the default behaviour should switch to assuming a fluid layout, but maybe the browser could just figure it out. After all, the CSS will already be parsed by the time the HTML is rendering. Perhaps a quick test for the presence of a crawlbar could be used to trigger the shrinking behaviour. No crawlbar, no shrinking.

Maybe someday the assumption behind the current behaviour could be flipped—assume a website is responsive unless the author explicitly requests the shrinking behaviour. I’d like to think that could happen soon, but I suspect that a depressingly large number of sites are still fixed-width (I don’t even want to know—don’t tell me).

There are other browser default behaviours that might someday change. Right now, if I type example.com into a browser, it will first attempt to contact http://example.com rather than https://example.com. That means the example.com server has to do a redirect, costing the user valuable time.

You can mitigate this by putting your site on the HSTS preload list but wouldn’t it be nice if browsers first checked for HTTPS instead of HTTP? I don’t think that will happen anytime soon, but someday …someday.

The imitation game

Jason shared some thoughts on designing progressive web apps. One of the things he’s pondering is how much you should try make your web-based offering look and feel like a native app.

This was prompted by an article by Owen Campbell-Moore over on Ev’s blog called Designing Great UIs for Progressive Web Apps. He begins with this advice:

Start by forgetting everything you know about conventional web design, and instead imagine you’re actually designing a native app.

This makes me squirm. I mean, I’m all for borrowing good ideas from other media—native apps, TV, print—but I don’t think that inspiration should mean imitation. For me, that always results in an interface that sits in a kind of uncanny valley of being almost—but not quite—like the thing it’s imitating.

With that out of the way, most of the recommendations in Owen’s article are sensible ideas about animation, input, and feedback. But then there’s recommendation number eight: Provide an easy way to share content:

PWAs are often shown in a context where the current URL isn’t easily accessible, so it is important to ensure the user can easily share what they’re currently looking at. Implement a share button that allows users to copy the URL to the clipboard, or share it with popular social networks.

See, when a developer has to implement a feature that the browser should be providing, that seems like a bad code smell to me. This is a problem that Opera is solving (and Google says it is solving, while meanwhile penalising developers who expose the URL to end users).

Anyway, I think my squeamishness about all the advice to imitate native apps is because it feels like a cargo cult. There seems to be an inherent assumption that native is intrinsically “better” than the web, and that the only way that the web can “win” is to match native apps note for note. But that misses out on all the things that only the web can do—instant distribution, low-friction sharing, and the ability to link to any other resource on the web (and be linked to in turn). Turning our beautifully-networked nodes into standalone silos just because that’s the way that native apps have to work feels like the cure that kills the patient.

If anything, my advice for building a progressive web app would be the exact opposite of Owen’s: don’t forget everything you’ve learned about web design. In my opinion, the term “progressive web app” can be read in order of priority:

  1. Progressive—build in a layered way so that anyone can access your content, regardless of what device or browser they’re using, rewarding the more capable browsers with more features.
  2. Web—you’re building for the web. Don’t lose sight of that. URLs matter. Accessibility matters. Performance matters.
  3. App—sure, borrow what works from native apps if it makes sense for your situation.

Jason asks questions about how your progressive web app will behave when it’s added to the home screen. How much do you match the platform? How do you manage going chromeless? And the big one: what do users expect?

Will people expect an experience that maps to native conventions? Or will they be more accepting of deviation because they came to the app via the web and have already seen it before installing it?

These are good questions and I share Jason’s hunch:

My gut says that we can build great experiences without having to make it feel exactly like an iOS or Android app because people will have already experienced the Progressive Web App multiple times in the browser before they are asked to install it.

In all the messaging from Google about progressive web apps, there’s a real feeling that the ability to install to—and launch from—the home screen is a real game changer. I’m not so sure that we should be betting the farm on that feature (the offline possibilities opened up by service workers feel like more of a game-changer to me).

People have been gleefully passing around the statistic that the average number of native apps installed per month is zero. So how exactly will we measure the success of progressive web apps against native apps …when the average number of progressive web apps installed per month is zero?

I like Android’s add-to-home-screen algorithm (although it needs tweaking). It’s a really nice carrot to reward the best websites with. But let’s not carried away. I think that most people are not going to click that “add to home screen” prompt. Let’s face it, we’ve trained people to ignore prompts like that. When someone is trying to find some information or complete a task, a prompt that pops up saying “sign up to our newsletter” or “download our native app” or “add to home screen” is a distraction to be dismissed. The fact that only the third example is initiated by the operating system, rather than the website, is irrelevant to the person using the website.

Getting the “add to home screen” prompt for https://huffduffer.com/ on Android Chrome.

My hunch is that the majority of people will still interact with your progressive web app via a regular web browser view. If, then, only a minority of people are going to experience your site launched from the home screen in a native-like way, I don’t think it makes sense to prioritise that use case.

The great thing about progressive web apps is that they are first and foremost websites. Literally everyone who interacts with your progressive web app is first going to do so the old-fashioned way, by following a link or typing in a URL. They may later add it to their home screen, but that’s just a bonus. I think it’s important to build progressive web apps accordingly—don’t pretend that it’s just like building a native app just because some people will be visiting via the home screen.

I’m worried that developers are going to think that progressive web apps are something that need to built from scratch; that you have to start with a blank slate and build something new in a completely new way. Now, there are some good examples of these kind of one-off progressive web apps—The Guardian’s RioRun is nicely done. But I don’t think that the majority of progressive web apps should fall into that category. There’s nothing to stop you taking an existing website and transforming it step-by-step into a progressive web app:

  1. Switch over to HTTPS if you aren’t already.
  2. Use a service worker, even if it’s just to provide a custom offline page and cache some static assets.
  3. Make a manifest file to point to an icon and specify some colours.

See? Not exactly a paradigm shift in how you approach building for the web …but those deceptively straightforward steps will really turbo-boost your site.

I’m really excited about progressive web apps …but mostly for the “progressive” and “web” parts. Maybe I’ll start calling them progressive web sites. Or progressive web thangs.

Why do pull quotes exist on the web?

There you are reading an article when suddenly it’s interrupted by a big piece of text that’s repeating something you just read in the previous paragraph. Or it’s interrupted by a big piece of text that’s spoiling a sentence that you are about to read in subsequent paragraphs.

There you are reading an article when suddenly it’s interrupted by a big piece of text that’s repeating something you just read in the previous paragraph.

To be honest, I find pull quotes pretty annoying in printed magazines too, but I can at least see the justification for them there: if you’re flipping through a magazine, they act as eye-catching inducements to stop and read (in much the same way that good photography does or illustration does). But once you’re actually reading an article, they’re incredibly frustrating.

You either end up learning to blot them out completely, or you end up reading the same sentence twice.

You either end up learning to blot them out completely, or you end up reading the same sentence twice. Blotting them out is easier said than done on a small-screen device. At least on a large screen, pull quotes can be shunted off to the side, but on handheld devices, pull quotes really make no sense at all.

Are pull quotes online an example of a skeuomorph? “An object or feature which imitates the design of a similar artefact made from another material.”

I think they might simply be an example of unexamined assumptions. The default assumption is that pull quotes on the web are fine, because everyone else is doing pull quotes on the web. But has anybody ever stopped to ask why? It was this same spiral of unexamined assumptions that led to the web drowning in a sea of splash pages in the early 2000s.

I think they might simply be an example of unexamined assumptions.

I’m genuinely curious to hear the design justification for pull quotes on the web (particularly on mobile), because as a reader, I can give plenty of reasons for their removal.

Animating

I’ve noticed a few nice examples of motion design on the web lately.

The Cloud Four gang recently redesigned their site, including a nice little animation on the home page.

Malcolm Gladwell has a new podcast called Revisionist History. The website for the podcast is quite lovely. Each episode is illustrated with an animated image. Lovely!

If you want to see some swishy animations triggered by navigation, the waaark websites has them a-plenty. Personally I find the scroll-triggered animations on internal pages too much to take (I have yet to find an example of scrolljacking that doesn’t infuriate me). But the homepage illustrations have some lovely subtle movement.

When it comes to subtlety in animation, my favourite example comes from Charlotte. She recently refactored the homepage of the website for the Leading Design conference. It originally featured one big background image. Switching over to SVG saved a lot of bandwidth. But what I really love is that the shapes in the background are now moving …ever so gently.

It’s like gazing at a slow-motion lava lamp of geometry.

A web for everyone

I gave the closing talk at the Render conference in Oxford a few weeks back. It was a very smoothly-run event, the spiritual successor to jQuery UK.

In amongst the mix of talks there were a few emerging themes. Animation was covered from a few different angles by Val and Sara. Bruce, Jake, Ola, and I talked about Service Workers and offline functionality. But there were also some differences of opinion.

In her great talk—I’m Offline, Cool! Now What?—Ola outlined the many and varied offline use cases that drove the creation and philosophy of Hoodie. She described all the reasons why people need the web; for communication, for access to information, for empowerment, and for love. “Hell, yes!” I thought.

But then she said:

So since when is helping people to fulfil a basic need, progressive enhancement?

And even more forcefully:

This is why I think, putting offline first in the progressive enhancement slot is pure bullshit.

Strong words indeed! And I have to say I was a little puzzled by them.

Ola had demonstrated again and again just how fragile the network could be. That is absolutely correct. All too often, we make the assumption that people using our sites have a decent network connection. That’s not a safe assumption to make.

But the suggested solution—to rely on technologies like local storage, Service Workers, or other APIs—assumes a certain level of JavaScript capabilities in the devices and browsers out there. That’s an unsafe assumption to make.

I remember discussing this with Alex from Hoodie a while back. I was confused by the cognitive dissonance I was observing. It seems to me that, laudable as Hoodie’s offline-first goals are, they are swapping out one unstable dependency—the network—for a different unstable dependency—a set of JavaScript APIs.

(I remember Alex pointed out that Hoodie was intended primarily for web apps rather than web sites, and my response—predictably enough—was to say “Define web app”.)

I think I understand why Ola reacted so strongly to the suggestion that offline functionality should be added as an enhancement. I’ve seen the same reaction when I’ve said that beautiful typography on the web is an enhancement. I think that when I say something is an enhancement, what people hear is that something is just an enhancement. It sounds belittling. That’s not my intention, but I can understand how it could come across like that. Perhaps this is one reason why some people have a real issue with the term “progressive enhancement”.

I wish we could make offline functionality a requirement. But the reality is that not everyone is using a browser that supports the necessary technology. I wish we could make beautiful typography a requirement. But, again, the reality is that there will always be some browsers or devices that won’t be capable of executing that typography. Accepting these facets of reality might seem like admissions of defeat, but I actually find it quite liberating.

In her brilliant talk at Render, Ashley G. Williams channeled Carl Sagan, quoting from his book The Demon-Haunted World:

It is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring.

That’s how I feel we should approach building for the web. Let’s accept that network connections are unevenly distributed. Let’s also accept that browser features are unevenly distributed. Pretending that millions of Opera Mini users don’t exist isn’t a viable strategy. They too are people who want to communicate, to access information, to be empowered, and to love.

Pointing out that you can’t always rely on client-side JavaScript shouldn’t be taken as an admonishment. It’s an opportunity.

Karolina Szczur wrote a wonderful piece on Ev’s blog called The Web Isn’t Uniform. She noticed how many sites—Facebook, AirBnB, Basecamp—failed to even render some useful information if the JavaScript fails to load. It’s a situation that many of us—with our fast connections, capable browsers, and modern devices—might never even notice.

It’s a privilege to be able to use breaking edge technologies and devices, but let’s not forget basic accessibility and progressive enhancement. Ultimately, we’re building for the users, not for our own tastes or preferences.

Karolina asks that we, as makers of the web, have a little more empathy. If the comments on her article are anything to go by, that’s a tall order. All the usual tropes are rolled out—there’s the misunderstanding that progressive enhancement means making sure everything works without JavaScript (it doesn’t; it’s about the core functionality), and the evergreen argument that as soon as you’re building a web “app”, that best practices, good engineering, and empathy can go out the window…

I strongly disagree that this has anything to do at all about empathy. Instead, it’s all about resources and priorities. Making a JS app is already hard enough, duplicating all that work so that it also works without JS is quite often just not practical.—Sacha Greif

But requiring that a site be functional when JavaScript is disabled, may not be a valid requirement anymore. HTML and CSS were originally created and designed for documents, not applications. Many websites these days should be considered apps rather then docs.—Dan Shappir

What you’re suggesting is that all these companies should write all their software twice, once in javascript and again in good ol’ html with forms, to cater to that point-whatever-percentage that has decided to break their own web browser by turning one of the three fundamental web technologies off. In what universe is this a reasonable request?—Erlend Halvorsen

JavaScript is as important as HTML. This is modern internet. If someone doesn’t have JavaScript, they should not be using the new applications that were possible because of JavaScript.—HarshaL

I am a web developer. I build web applications not web sites. What you say may be true for web sites with static pages displaying images and text.—R. Fancsiki

Ah, Medium! Where the opinions of self-entitled dudes flow like rain from the tech heavens.

While they were so busy defending the lack of basic functionality in all the examples that Karolina listed, they failed to notice the most important development:

Let’s build a web that works for everyone. That doesn’t mean everyone has to have the same experience. Let’s accept that there are all sorts of people out there accessing the web with all sorts of browsers on all sorts of devices.

What a fantastic opportunity!

Sparklining

I was in Nuremberg last weekend for Indie Web Camp. It was great.

At some point I really should stop being surprised by just how much gets done in one weekend, but once again, I was blown away by the results.

On the first day we had very productive BarCamp-like discussion sessions, and on the second day it was heads-down hacking. But it was hacking with help. Being in the same room as other people who each have their own areas of expertise is so useful. It really turbo-charges the amount that you can get accomplished.

For example, I was helping Tom turn his website into a progressive web app with the addition of a service worker and a manifest file. Meanwhile Tom was helping somebody else get a Wordpress site up and running.

Actually, that was what really blew me away: two people began the second day of Indie Web Camp Nuremberg without websites and by the end of the day, they both had their own sites up and running. For me, that’s the real spirit of the indie web—I know we tend to go on about the technologies like h-card, h-entry, webmentions, micropub, and IndieAuth, but really it’s not about the technologies; it’s about having your own place on the web so that you have control over what you put out in the world.

For my part, I was mostly making some cosmetic changes to my site. There was a really good discussion on the first page about home pages. What’s the purpose of a home page? For some, it’s about conveying information about the person. For others, it’s a stream of activity.

My site used to have a splash-like homepage; just a brief bio and a link to the latest blog post. Then I changed it into a stream a few years ago. But that means that the home page of my site doesn’t feel that different from sections of the site like the journal or the link list.

During the discussion at Indie Web Camp, we started looking at how silos design their profile pages to see what we could learn from them. Looking at my Twitter profile, my Instagram profile, my Untappd profile, or just about any other profile, it’s a mixture of bio and stream, with the addition of stats showing activity on the site—signs of life.

I decided I’d add signs of life to my home page. Once again, I reached for my favourite little data visualisation helper: sparklines

A sparkline is a small intense, simple, word-sized graphic with typographic resolution.

I’ve already got sparklines on Huffduffer and on The Session so I suppose it was only a matter of time before they showed up here.

Small Screen Sparklines Large Screen Sparklines

I’ve been tweaking them ever since I got back from Germany. Now I’ve added in a little h-card bio as well.

Bio and sparklines Bio And Sparklines (large screen)

Initially I was using the fantastic little scripted SVG that Stuart made , the same one that I’m using on Huffduffer and The Session. But Kevin pointed out that a straightforward polyline would be more succinct. And in the case of my own site, there’s only four sparklines so it wouldn’t be a huge overhead to hard-code the values straight into the SVGs.

Yesterday was the first day of Render Conference in Oxford (I’ll be speaking later today). Sara gave a blisteringly great talk on (what else?) SVGs and I got so inspired I started refactoring my code right there and then. I’m pretty happy with how the sparklines are working now, although I’m sure I’ll continue to play around with them some more.

There’s another activity visualisation that I’m eager to play around with. I really like the calendar heatmap on my Github profile. I could imagine using something like that for an archive view on my own site.

Luckily for me, I’ll have a chance to play around with my website a bit more very soon. There’s going to be another Indie Web Camp in Germany very soon.

Indie Web Camp Düsseldorf will take place on May 7th and 8th, right before Beyond Tellerrand. Last year’s event was really inspiring. If there’s any chance you can make it, you should come along. You won’t regret it.

Moderating EnhanceConf 2016

Last year I met up with Simon McManus in a Brighton pub where he told me about his plan to run a conference dedicated to progressive enhancement. “Sounds like a great idea!”, I said, and offered him any help I could.

With the experience of organising three dConstructs and three Responsive Days Out, I was able to offer some advice on the practical side of things like curation, costs and considerations. Simon also asked me to MC his event. I was only too happy to oblige. After all, I was definitely going to be at the conference—wild horses wouldn’t keep me away—and when have I ever turned down an opportunity to hog the mic?

Simon chose a name: EnhanceConf. He found a venue: The RSA in London. He settled on a date: March 4th, 2016. He also decided on a format, the same one as Responsive Day Out: four blocks of talks, each block consisting of three back-to-back 20 minute presentations followed by a group discussion and questions.

With all those pieces in place, it was time to put together a line-up. I weighed in with my advice and opinions there too, but the final result was all Simon’s …and what a great result it was.

Yesterday was the big day. I’m happy to report that it was a most splendid event: an inspiring collection of brilliant talks, expertly curated like a mixtape for the web.

Nat got the day off to a rousing start. They gave an overview of just how fragile and unpredictable the World Wide Web can be. To emphasise this, Anna followed with detailed look at the many, many console browsers people are using. Then Stefan gave us a high-level view of sensible (and not-so-sensible) architectures for building on the web—a talk packed to the brim with ideas and connections to lessons from the past that really resonated with me.

Stefan, Nat and Anna

After that high-level view, the next section was a deep dive into strategies for building with progressive enhancement: building React apps that share code for rendering on the server and the client from Forbes; using Service Workers to create a delightful offline experience from Olly; taking a modular approach to how structure our code and cut the mustard from Stu.

Stu, Olly and Forbes

The after-lunch session was devoted to design. It started with good ol’ smackdown between Phil and Stephen, which I attempted to introduce in my best wrestling announcer voice. That was followed by a wonderfully thoughtful presentation by Adam Silver on Embracing Simplicity. Then Jen blew everyone away with a packed presentation of not just what’s possible with CSS now, but strategies for using the latest and greatest CSS today.

Adam, Stephen, Phil and Jen

Finally, the day finished with a look to the future. And the future is …words. Robin was as brilliant as ever, devising an exercise to get the audience to understand just how awful audio CAPTCHAs are, but also conveying his enthusiasm and optimism for voice interfaces. That segued perfectly into the next two talks. Stephanie gave us a crash course in crafting clear, concise copy, and Aaron tied that together with Robin’s musings on future interactions with voice in a great final presentation called Learn From the Past, Enhance for the Future (echoing the cyclical patterns that Stefan was talking about at the start of the day).

Closing panel

As the day wrapped up, I finished by pointing to a new site launched by Jamie on the very same day: progressiveenhancement.org. With that, my duties were fulfilled.

I thoroughly enjoyed listening to the talks and then quizzing the speakers afterwards. I really do enjoy moderating events. Some of the skills are basic (pronouncing people’s names correctly, using their preferred pronouns) and some are a little trickier (trying to quickly spot connections, turning those connections into questions for each speaker) but it’s very rewarding indeed.

I had a blast at EnhanceConf. I felt bad though; lots of people came up to me and started thanking me for a great day. “Don’t thank me!” I said, “Thank Simon.”

Thanks, Simon.

Design sprinting

James and I went to Ipswich last week for work. But this wasn’t part of an ongoing project—this was a short intense one-week feasibility study.

Leon from Suffolk Libraries got in touch with us about a project they’re planning to carry out soon: replacing their self-service machines with something more up-to-date. But rather than dive into commissioning the project straight away, he wisely decided to start with a one-week sprint to figure out exactly what the project would need to go ahead.

So that’s what James and I did. It was somewhat similar to the design sprint popularised by GV. We ensconced ourselves in the Ipswich library and packed a whole lot of work into five days. There was lots of collaboration, lots of sketching, lots of iterative design, and some rough’n’ready code. It was challenging, but a lot of fun. Also: we stayed in a pretty sweet AirBnB.

Our home for the week. This is a nice AirBnB.

You can read all about it in our case study. You can also read all about from Leon’s point of view on his blog:

I can’t recommend this kind of research sprint enough. We got a report, detailed technical validation of an idea, mock ups and a plan for how to proceed, while getting staff and stakeholders involved in the project – all in the space of 5 days.

I think this approach makes a lot of sense. By the end of the week, James and I felt pretty confident about estimating times and costs for the full project. Normally trying to estimate that kind of thing can be a real guessing game. But with the small of investment of one week’s worth of effort, you get a whole lot more certainty and confidence.

Have a look for yourself.

Enhance! Conf!

Two weeks from now there will be an event in London. You should go to it. It’s called EnhanceConf:

EnhanceConf is a one day, single track conference covering the state of the art in progressive enhancement. We will look at the tools and techniques that allow you to extend the reach of your website/application without incurring additional costs.

As you can probably guess, this is right up my alley. Wild horses wouldn’t keep me away from it. I’ve been asked to be Master of Ceremonies for the day, which is a great honour. Luckily I have some experience in that department from three years of hosting Responsive Day Out. In fact, EnhanceConf is going to run very much in the mold of Responsive Day Out, as organiser Simon explained in an interview with Aaron.

But the reason to attend is of course the content. Check out that line-up! Now that is going to be a knowledge-packed day: design, development, accessibility, performance …these are a few of my favourite things. Nat Buckley, Jen Simmons, Phil Hawksworth, Anna Debenham, Aaron Gustafson …these are a few of my favourite people.

Tickets are still available. Use the discount code JEREMYK to get a whopping 15% off the ticket price.

There’s also a scholarship:

The scholarships are available to anyone not normally able to attend a conference.

I’m really looking forward to EnhanceConf. See you at RSA House on March 4th!

New edition

Six years ago I wrote a book and the brand new plucky upstart A Book Apart published it.

Six years! That’s like a geological age in internet years.

People liked the book. That’s very gratifying. I’m quite proud of it, and it always gives me a warm glow when someone tells me they enjoyed reading it.

Jeffrey asked me a while back about updating the book for a second edition—after all, six years is crazy long time for a web book to be around. I said no, because I just wouldn’t have the time, but mostly because—as the old proverb goes—you can step in the same river twice. Proud as I am of HTML5 For Web Designers, I consider it part of my past.

“What about having someone else update it?” Well, that made me nervous. I feel quite protective of my six year old.

“What about Rachel Andrew?” Ah, well, that’s a different story! Absolutely—if there’s one person I trust to bring the up to date, it’s Rachel.

She’s done a fine, fine job. The second edition of HTML5 For Web Designers is now available.

I know what you’re going to ask: how much difference is there between the two editions? Well, in the introduction to the new edition, I’m very pleased to say that Rachel has written:

I’ve been struck by how much has remained unchanged in that time.

There’s a new section on responsive images. That’s probably the biggest change. The section on video has been expanded to include captioning. There are some updates and tweaks to the semantics of some of the structural elements. So it’s not a completely different book; it’s very much an update rather than a rewrite.

If you don’t have a copy of HTML5 For Web Designers and you’ve been thinking that maybe it’s too out-of-date to bother with, rest assured that it is now bang up to date thanks to Rachel.

Jeffrey has written a lovely new foreword for the second edition:

HTML5 for Web Designers is a book about HTML like Elements of Style is a book about commas. It’s a book founded on solid design principles, and forged at the cutting edge of twenty-first century multi-device design and development.

Hamburger, hamburger, hamburger

Andy’s been playing Devils Advocate again, defending the much-maligned hamburger button. Weirdly though, I think I’ve seen more blog posts, tweets, and presentations defending this supposed underdog than I’ve seen knocking it.

Take this presentation from Smashing Conference. It begins with a stirring call to arms. Designers of the web—cast off your old ways, dismiss your clichés, try new things, and discard lazy solutions! “Yes!”, I thought to myself, “this is a fantastic message.” But then the second half of the talk switches into a defence of the laziest, most clichéd, least thought-through old tropes of interface designs: carousels, parallax scrolling and inevitably, the hamburger icon.

But let’s not get into a binary argument of “good” vs. “bad” when it comes to using the hamburger icon. I think the question is more subtle than that. There are three issues that need to be addressed if we’re going to evaluate the effectiveness of using the hamburger icon:

  1. representation,
  2. usage, and
  3. clarity.

Representation

An icon is a gateway to either some content or a specific action. The icon should provide a clear representation of the content or action that it leads to. Sometimes “clear” doesn’t have to literally mean that it’s representative: we use icons all the time that don’t actually represent the associated content or action (a 3.5 inch diskette for “save”, a house for the home page of a website, etc.). Cultural factors play a large part here. Unless the icon is a very literal pictorial representation, it’s unlikely that any icon can be considered truly universal.

If a hamburger icon is used as the gateway to a list of items, then it’s fairly representative. It’s a bit more abstract than an actual list of menu items stacked one on top of the other, but if you squint just right, you can see how “three stacked horizontal lines” could represent “a number of stacked menu items.”

If, on the other hand, a hamburger icon is used as the gateway to, say, a grid of options, then it isn’t representative at all. A miniaturised grid—looking like a window—would be a more representative option.

So in trying to answer the question “Does the hamburger icon succeed at being representative?”, the answer—as ever—is “it depends.” If it’s used as a scaled-down version of the thing its representing, it works. If it’s used as a catch-all icon to represent “a bunch of stuff” (as is all too common these days), then it works less well.

Which brings us to…

Usage

Much of the criticism of the hamburger icon isn’t actually about the icon itself, it’s about how it’s used. Too many designers are using it as an opportunity to de-clutter their interface by putting everything behind the icon. This succeeds in de-cluttering the interface in the same way that a child putting all their messy crap in the cupboard succeeds in cleaning their room.

It’s a tricky situation though. On small screens especially, there just isn’t room to display all possible actions. But the solution is not to display none instead. The solution is to prioritise. Which actions need to be visible? Which actions can afford to be squirrelled away behind an icon? A designer is supposed to answer those questions (using research, testing, good taste, experience, or whatever other tools are at their disposal).

All too often, the hamburger icon is used as an excuse to shirk that work. It’s treated as a “get out of jail free” card for designing small-screen interfaces.

To be clear: this usage—or misusage—has nothing to do with the actual icon itself. The fact that the icon is three stacked lines is fairly irrelevant on this point. The reason why the three stacked lines are so often used is that there’s a belief that this icon will be commonly understood.

That brings us to last and most important point:

Clarity

By far the most important factor in whether an icon—any icon—will be understood is whether or not it is labelled. A hamburger icon labelled with a word like “menu” or “more” or “options” is going to be far more effective than an unlabelled icon.

Don’t believe me? Good! Do some testing.

In my experience, 80-90% of the benefit of usability testing is in the area of labelling. And one of the lowest hanging fruit is the realisation that “Oh yeah, we should probably label that icon that we assumed would be universally understood.”

Andy mentions the “play” and “pause” symbols as an example of icons that are so well understood that they can stand by themselves. That’s not necessarily true.

I think there are two good rules of thumb when it comes to using icons:

  1. If in doubt, label it.
  2. If not in doubt, you probably should be—test your assumptions.

Results

Now that we’ve established the three criteria for evaluating an icon’s effectiveness, let’s see how the hamburger icon stacks up (if you’ll pardon the pun):

  1. Representation: It depends. Is it representing a stacked list of menu items? If so, good. If not, reconsider.
  2. Usage: it depends. Is it being used as an excuse to throw literally all your navigation behind it? If so, reconsider. Prioritise. Decide what needs to be visible, and what can be tucked away.
  3. Clarity: it depends. Is the icon labelled? If so, good. If not, less good.

So there you go. The answer to the question “Is the hamburger icon good or bad?” is a resounding and clear “It depends.”

Notice

We’ve been doing a lot of soul-searching at Clearleft recently; examining our values; trying to make implicit unspoken assumptions explicit and spoken. That process has unearthed some activities that have been at the heart of our company from the very start—sharing, teaching, and nurturing. After all, Clearleft would never have been formed if it weren’t for the generosity of people out there on the web sharing with myself, Andy, and Richard.

One of the values/mottos/watchwords that’s emerging is “Share what you learn.” I like that a lot. It echoes the original slogan of the World Wide Web project, “Share what you know.” It’s been a driving force behind our writing, speaking, and events.

In the same spirit, we’ve been running internship programmes for many years now. John is the latest of a long line of alumni that includes Anna, Emil, and James.

By the way—and this should go without saying, but apparently it still needs to be said—the internships are always, always paid. I know that there are other industries where unpaid internships are the norm. I’ve even heard otherwise-intelligent people defend those unpaid internships for the experience they offer. But what kind of message does it send to someone about the worth of their work when you withhold payment for it? Our industry is young. Let’s not fall foul of the pernicious traps set by older industries that have habitualised exploitation.

In the past couple of years, Andy concocted a new internship scheme:

So this year we decided to try a different approach by scouring the end of year degree shows for hot new talent. We found them not in the interaction courses as we’d expected, but from the worlds of Product Design, Digital Design and Robotics. We assembled a team of three interns , with a range of complementary skills, gave them a space on the mezzanine floor of our new building, and set them a high level brief.

The first such programme resulted in Chüne. The latest Clearleft internship project has just come to an end. The result is Notice.

This time ‘round, the three young graduates were Chloe, Chris and Monika. They each have differing but complementary skill sets: Chloe is a user interface designer; Chris is a product designer; Monika is an artist who knows her way around hardware hacking and coding.

I’ll miss having this lot in the Clearleft office.

Once again, they were set a fairly loose brief. They should come up with something “to enrich the lives of local residents” and it should have a physical and digital component to it.

They got stuck in to researching and brainstorming ideas. At the end of each week, we’d all gather together to get a playback of what they were coming up with. It was at these playbacks that the interns were introduced to a concept that they will no doubt encounter again in their professional lives: seagulling AKA the swoop and poop. For once, it was the Clearlefties who were in the position of being swoop-and-poopers, rather than swoop-and-poopies.

Playback at Clearleft

As the midway point of the internship approached, there were some interesting ideas, but no clear “winner” to pursue. Something else was happening around this time too: dConstruct 2015.

Chloe, Monika and Chris at dConstruct

The interns pitched in with helping out at the event, and in return, we kidnapped some of the speakers—namely John Willshire and Chris Noessel—to offer them some guidance.

There was also plenty of inspiration to be had from the dConstruct talks themselves. One talk in particular struck a chord: Dan Hill’s The City Of Things …especially the bit where he railed against the terrible state of planning application notices:

Most of the time, it ends up down the bottom of the lamppost—soiled and soggy and forgotten. This should be an amazing thing!

Hmm… sounds like something that could enrich the lives of local residents.

Not long after that, Matt Webb came to visit. He encouraged the interns to focus in on just the two ideas that really excited them rather then the 5 or 6 that they were considering. So at the next playback, they presented two potential projects—one about biking and the other about city planning. They put it to a vote and the second project won by a landslide.

That was the genesis of Notice. After that, they pulled out all the stops.

Exciting things are afoot with the @Clearleftintern project.

Not content with designing one device, they came up with a range of three devices to match the differing scope of planning applications. They set about making a working prototype of the device intended for the most common applications.

Monika and Chris, hacking

Last week marked the end of the project and the grand unveiling.

Playing with the @notice_city prototype. Chris breaks it down. Playback time. Unveiling.

They’ve done a great job. All the details are on the website, including this little note I wrote about the project:

This internship programme was an experiment for Clearleft. We wanted to see what would happen if you put through talented young people in a room together for three months to work on a fairly loose brief. Crucially, we wanted to see work that wasn’t directly related to our day-­to-­day dealings with web design.

We offered feedback and advice, but we received so much more in return. Monika, Chloe, and Chris brought an energy and enthusiasm to the Clearleft office that was invigorating. And the quality of the work they produced together exceeded our wildest expectations.

We hereby declare this experiment a success!

Personally, I think the work they’ve produced is very strong indeed. It would be a shame for it to end now. Perhaps there’s a way that it could be funded for further development. Here’s hoping.

Out on the streets of Brighton Prototype

As impressed as I am with the work, I’m even more impressed with the people. They’re not just talented and hard work—they’re a jolly nice bunch to have around.

I’m going to miss them.

The terrific trio!

dConstruct 2015 podcast: Nick Foster

dConstruct 2015 is just ten days away. Time to draw the pre-conference podcast to a close and prepare for the main event. And yes, all the talks will be recorded and released in podcast form—just as with the previous ten dConstructs.

The honour of the final teaser falls to Nick Foster. We had a lovely chat about product design, design fiction, Google, Nokia, Silicon Valley and Derbyshire.

I hope you’ve enjoyed listening to these eight episodes. I had certainly had a blast recording them. They’ve really whetted my appetite for dConstruct 2015—I think it’s going to be a magnificent day.

With the days until the main event about to tick over into single digits, this is your last chance to grab a ticket if you haven’t already got one. And remember, as a loyal podcast listener, you can use the discount code ‘ansible’ to get 10% off.

See you in the future …next Friday!

dConstruct 2015 podcast: Brian David Johnson

The newest dConstruct podcast episode features the indefatigable and effervescent Brian David Johnson. Together we pick apart the futures we are collectively making, probe the algorithmic structures of science fiction narratives, and pay homage to Asimovian robotic legal codes.

Brian’s enthusiasm is infectious. I have a strong hunch that his dConstruct talk will be both thought-provoking and inspiring.

dConstruct 2015 is getting close now. Our future approaches. Interviewing the speakers ahead of time has only increased my excitement and anticipation. I think this is going to be a truly unmissable event. So, uh, don’t miss it.

Grab your ticket today and use the code ‘ansible’ to take advantage of the 10% discount for podcast listeners.

Building the dConstruct 2015 site

I remember when I first saw Paddy’s illustration for this year’s dConstruct site, I thought “Well, that’s a design direction, but there’s no way that Graham will be able to implement all of it.” There was a tight deadline for getting the site out, and let’s face it, there was so much going on in the design that we’d just have to prioritise.

I underestimated Graham’s sheer bloody-mindedness.

At the next front-end pow-wow at Clearleft, Graham showed the dConstruct site in all its glory …in Lynx.

http://2015.dconstruct.org in Lynx.

I love that. Even with the focus on the gorgeous illustration and futuristic atmosphere of the design, Graham took the time to think about the absolute basics: marking up the content in a logical structured way. Everything after that—the imagery, the fonts, the skewed style—all of it was built on a solid foundation.

One site, two browsers.

It would’ve been easy to go crazy with the fonts and images, but Graham made sure to optimise everything to within an inch of its life. The biggest bottleneck comes from a third party provider—the map tiles and associated JavaScript …so that’s loaded in after the initial content is loaded. It turns out that the site build was a matter of prioritisation after all.

http://2015.dconstruct.org/

There’s plenty of CSS trickery going on: transforms, transitions, and opacity. But for the icing on the cake, Graham reached for canvas and programmed space elevator traffic with randomly seeded velocity and size.

Oh, and of course it’s all responsive.

So, putting that all together…

The dConstruct 2015 site is gorgeous, semantic, responsive, and performant. Conventional wisdom dictates that you have to choose, but this little site—built on a really tight schedule—shows otherwise.

dConstruct 2015 podcast: Carla Diana

The dConstruct podcast episodes are coming thick and fast. The latest episode is a thoroughly enjoyable natter I had with the brilliant Carla Diana.

We talk about robots, smart objects, prototyping, 3D printing, and the world of teaching design.

Remember, you can subscribe to the podcast feed in any podcast software you like, or if iTunes is your thing, you can also subscribe directly in iTunes.

And don’t forget to use the discount code ‘ansible’ when you’re buying your dConstruct ticket …because you are coming to dConstruct, right?

Video video

Hey, remember Responsive Day Out 3: The Final Breakpoint? Remember all those great talks?

No?

Perhaps your memory needs refreshing.

Luckily for you, all the talks were recorded. The audio has been available for a while. Now the videos are also available for your viewing pleasure.

  1. Alice Bartlett
  2. Rachel Shillcock
  3. Alla Kholmatova
  4. Peter Gasston
  5. Jason Grigsby
  6. Heydon Pickering
  7. Jake Archibald
  8. Ruth John
  9. Zoe Mickley Gillenwater
  10. Rosie Campbell
  11. Lyza Gardner
  12. Aaron Gustafson

Thanks to Craig and Amie from Five Simple Steps for coming to Brighton to record the videos—really appreciate it. And thanks to Shopify for sponsoring the videos; covering the cost of the videos meant that we could keep the ticket price low.

What a day out! What a lovely responsive day out!

100 words 095

I’m not organising dConstruct this year—Andy is—but it’s still an exciting day for everyone when the website launches; we’ve got something of a tradition of having some fun with it.

This year Andy commissioned Paddy Donnelly to come up with a design direction, partly because we were slammed with client work, but mostly because he’s really talented. Graham then took that design and executed it beautifully.

Gorgeous. Responsive. Performant. These qualities don’t need to be mutually exclusive.

There’s room for improvement and there’s plenty more to be done, but I’m still blown away by the dConstruct 2015 site.

100 words 094

On the way into work this morning I listened to the first episode of Motion and Meaning—a new short-run podcast all about animation, hosted by Cennydd and Val.

When I got to work, I had a sneak peak of a site that Graham has been working on. If everything goes according to plan, it will launch tomorrow. It’s a gorgeous piece of work with some very subtle bits of animation.

At the end of the day, I sat in on the weekly roundtable design crit. Richard finished it by soliciting ideas for animation effects on another upcoming site launch.

The shape of Responsive Day Out 3: The Final Breakpoint

It’s less than two months now until Responsive Day Out 3: The Final Breakpoint. Fortunately there are still some tickets available so if you haven’t got yours yet, it’s not too late. Remember: it’s cheap as chips—just £80+VAT for a day jam-packed with knowledge bombs from twelve(!) fantastic speakers. You’d be crazy to miss it.

If you’ve already got your ticket, you might be wondering what awaits you. Well, if you’ve been to either of the previous days out, you’ll know what to expect: a medley of topics covering all areas of responsive design, from process and workflow through to visual design and code.

The day will be broken up into four segments. Each segment will feature three thematically-related 20 minute talks, back to back. Then those three speakers will join me for a joint chat, where we can take questions from the audience. Check out the videos from the first Responsive Day Out to get feel for the pace or have a listen to the podcast recordings from previous years.

Here’s my rough plan for the four segments this year…

  1. The day will start with some big picture thinking around workflows. There’ll be an emphasis on accessibility—something that can’t just be tagged on to the end of a project. There’s also be a case study of one of the hottest topics in the web designers’ workflow today; style guides and pattern libraries. And importantly, we want to make sure that the role of creativity isn’t forgotten in our new responsive world.
  2. The second segment will be like a mini conference on front-end technologies. There’ll be some deep diving into the latest in CSS techniques, including flexbox, as well as that thorny topic of responsive images. It’s hard to believe, but that’s a topic that hasn’t been covered in previous Responsive Days Out. Time to change that.
  3. After lunch, we’ll start to look beyond today and to the future of responsive design. That’ll begin with a segment on cutting-edge browser technologies. You can expect to be wowed with demos of the latest browser APIs and get your head around the much-hyped world of web components. We won’t shy away from asking how the web can compete with native experiences, like making our sites work offline.
  4. Finally, we’ll end the day—and indeed, the conference series—by taking a high level view of what the future might bring. There’ll be an examination of the skill sets that designers and developers should equip themselves with, and we’ll look beyond the screen to a future of new inputs and outputs.

So the day will have a bell-curved shape to it, starting out with a relatively high-level view, swooping down in the middle to get really stuck in with the technologies of today, before ascending at the end to look into the future.

Friday, June 19th—put that date in your diary. Registration is from 9-10am. There’ll be an hour and a half for lunch (and Street Diner will be on that day!) and everything will wrap up by 5:30pm. It’s going to be an action-packed day—bam! bam! bam!

If you don’t come along to the final Responsive Day Out, you’re going to regret it. So what are you waiting for?