Tags: icon

8

sparkline

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

Icon fonts, unicode ranges, and IE8’s compatibility mode

While doing some browser testing this week, Mark come across a particularly wicked front-end problem. Something was triggering compatibility mode in Internet Explorer 8 and he couldn’t figure out what it was.

Compatibility mode was something introduced in IE8 to try not to “break the web”, as Microsoft kept putting it. Effectively it makes IE8 behave like IE7. Why would you ever want to do that? Well, if you make websites exactly the wrong way and code for a specific browser (like, say, IE7), then better, improved browsers are something to be feared and battled against. For the rest of us, better, improved browsers are something to be welcomed.

Shockingly, Microsoft originally planned to have compatibility mode enabled by default in Internet Explorer 8. It was bad enough that they were going to ship a browser with a built-in thermal exhaust port, they also contemplated bundling a proton torpedo with it too. Needless to say, right-minded people were upset at that possibility. I wrote about my concerns back in 2008.

Microsoft changed their mind about the default behaviour, but they still shipped IE8 with the compatibility mode “feature”, which Mark was very much experiencing as a bug. Something in the CSS was triggering compatibility mode, but frustratingly, there was no easy way of figuring out what was doing it. So he began removing chunks of CSS, reducing until he could focus in on the exact piece of CSS that was triggering IE8’s errant behaviour.

Finally, he found it. He was using an icon font. Now, that in itself isn’t enough to give IE8 its conniptions—an icon font is just a web font like any other. The only difference is that this font was using the private use area of the unicode range. That’s the default setting if you’re creating an icon font using the excellent icomoon service. There’s a good reason for that:

Using Latin letters is not recommended for icon fonts. Using the Private Use Area of Unicode is the best option for icon fonts. By using PUA characters, your icon font will be compatible with screen readers. But if you use Latin characters, the screen reader might read single, meaningless letters, which would be confusing.

Well, it turns out that using assigning glyphs to this private use area was causing IE8 to flip into compatibility mode. Once Mark assigned the glyphs to different characters, IE8 started behaving itself.

Now, we haven’t tested to see if this is triggered by all of the 6400 available slots in the UTF-8 private use range. If someone wants to run that test (presumably using some kind of automation), ’twould be much appreciated.

Meantime, just be careful if you’re using the private use area for your icon fonts—you may just inadvertently wake the slumbering beast of compatibility mode.

Iconic imagery

There’s been some fantastic collaborative work done recently on the tricky issue of responsive images. Witness the community group and its attendant website, complete with logo.

Meanwhile, there’s been some great research into dealing with high-DPI displays (which the world and its dog have decided to label “retina”). There’s the in-depth analysis by Daan Jobsis which looks at what you can get away with when it comes to compression and quality for “retina” displays: quite a lot, as it turns out.

In fact, you may well be able to double the dimensions of an image while simultaneously bringing down its quality and end up with an image that is smaller in file size than the original, while still looking great on high-DP..“retina” displays. The guys over at Filament group have labelled this Compressive Images. Nice.

I like that approach. No JavaScript polyfills. No lobbying of standards bodies.

I’m generally fan of solutions that look for ways of avoiding the problem in the first place. Hence my approach to image optimisation for all devices, widescreen or narrow.

Of course this whole issue of responsive (or compressive) images should really only apply to photographic imagery. If you’re dealing with “text as images” …don’t. Use web fonts. If you’re dealing with logos or icons, there are other options, like SVG.

Then there’s the combination of web fonts and iconography. Why not use a small web font containing just the icons you need?

I tried this recently, diligently following Josh’s excellent blog post detailing how to get icon shapes out of Fireworks, into a font editor, and then into an actual font. It works a treat, although I concur with Josh’s suggestion that the technique should really only be implemented using the ::before and ::after pseudo-elements in combination with base-64 encoding the font file. That means it won’t work in every single browser, but that’s the point: these icons should be an enhancement, not a requirement.

Having gone through the tortuous steps required to get my Mac all set up with the software required to follow Josh’s tutorial, I then spotted the note at the end of his article that pointed to Icomoon. That turns out to be a fantastic service. You can pick and choose from the icons provided or you can upload your own vector shapes. Then you can assign the unicode slots you want to use for the icons and you can get the resulting font file base-64 encoded. Very, very cool!

There’s a whole slew of icon-font services like that out there now: Pictos, Web Symbols, and Symbolset with its ingenious use of ligatures to allow for an accessible fallback.

Jenn is currently casting a critical eye over each of these service over on the Nerdary: part one, part two, and part three are all deserving of your time and attention.

Navicon

Daniel recently asked a question on Twitter:

It was this article by Malarkey that he was looking for. Andy did a great job of comparing the iconography used for navigation in mobile apps and responsive sites. His conclusion:

Unless our navigation’s arranged in a grid (and so we should use a grid icon), I’m putting my weight behind three lines because I think it’s most recognisable as navigation to the average person.

The three-lines icon is certainly very popular, as can be seen in this collection of mobile navigation icons I gathered together on Dribbble.

But Tom has some reservations:

Andy Davies points out another potential issue:

I noticed this in the more recent versions of Android too. It does indeed look a little odd to see the same icon used in the browser chrome and in the document within the browser.

Double navigation (BUT WHAT DOES IT MEAN!?!?)

But I still think it’s a good shorthand for revealing a list of items.

The unicode character ☰ ☰ (U+2630) is the Chinese trigram for sky (or heaven)—one of the eight bagua. It consists of three horizontal lines. Now that could be a handy resolution-independent way of representing navigation.

Dribbble — Mobile First

Alas, when I tested this on a range of mobile devices, some of them just showed the square box of unicode disappointment. I had much better luck with the unicode symbol for black down-pointing triangle▼ (U+25BC).

Dribbble — Navigation link

Mind you, with a combination of @font-face and sub-setting we’re not limited to what the browser ships with—we can provide our own icons in a font file, like what Pictos is doing.

One Web, transcribed

I spoke at the DIBI conference back in June. It was a really good event, despite its annoying two-track format.

My talk was entitled One Web:

The range of devices accessing the web is increasing. We are faced with a choice in how we deal with this diversity. We can either fracture the web by designing a multitude of device-specific silos, or we can embrace the flexibility of the web and create experiences that can adapt to any device or browser.

The video has been online for a while now and I finally got ‘round to getting it transcribed. You can pop on over to the articles section and read One Web. I should really re-name that section of my site: “articles” isn’t the most accurate label for a lot of the stuff there.

If you prefer listening to reading, the audio is available for your huffduffing pleasure.

Adactio: Articles—One Web on Huffduffer

I also put the slides on Speakerdeck so you play along with the presentation.

I reprised this talk in Italy recently at the From The Front gathering. The audio from that is also online if you want to compare and contrast.

Jeremy Keith at From The Front 2011: One Web on Huffduffer

DIBI 2011

Farewell to June

June was a busy month.

July is looking a lot calmer. I’m going to be in Brighton for the whole month. I will, however, be using the time to prepare for the onslaught of events in the coming months. In September alone, Brighton will play host to a whole slew of events falling under the banner of the Brighton Digital Festival:

I’m going to be spending my non-travelling time this month preparing a workshop to precede dConstruct. Keep an eye on the site for more details very soon.

Oh, and remember: tickets for dConstruct go on sale this Tuesday, July 5th.

Newcastling

Usually when I go to a conference it involves crossing a body of water to arrive on foreign shores, often in Europe or America. But the last two events I attended were much closer to home.

Two weeks ago there was Web Directions @media in London. Thank you to everyone who provided questions for the Hot Topics Panel. It went swimmingly, thanks to the eloquence and knowledge of the panelists: Brian, Relly, Bruce and Douglas Fucking Crockford. There was a surprising lack of contentiousness on the panel but I made up for it by arguing with the audience instead. Once the audio is available I’ll be sure to get it transcribed like I did last year.

I just got back from another conference that didn’t involve crossing any international boundaries: DIBI in Newcastle.

Tyneside

It was an excellent event …with just one exception. It bills itself as “the two-track web conference” and that’s the problem. As with Web Directions, I found myself torn between the “design” and “development” talks (a fairly arbitrary distinction for me). The first thing I had to do was choose between Yaili in one room and Jake in another. An impossible choice! I went for Jake in the end and he was absolutely bloody brilliant (as usual) but I’m sure Yaili’s talk was also excellent …and I missed it.

Apart from that heavy dose of FOMO it really was superb. The venue was gorgeous, the quality of the talks was really, really high, the attendees were super friendly and the organisers did a fantastic job of looking after everyone and making sure everything ran like clockwork. I doff my hat to Gavin and his gang.

Jake Mike Faruk Brian Jared Jeffrey

I was nervous about my talk. It was material I hadn’t presented before. But once I got on stage I just reverted to ranting, which people seemed to enjoy. I had fun anyway. Again, once the audio or video is available I’ll be sure to get it transcribed.

It was also my first time in Newcastle …or Gateshead, whichever. It was certainly showing its best side. It really is quite a lovely place.

My next destination is bit further afield. I’m off to Atlanta for An Event Apart which kicks off on Monday. If you’re going too, be sure to say hello.

And debate goes on

The RSS vine is humming with point and counterpoint this week.

Adobe revealed their new range of icons, based on mashing up a colour wheel with the periodic table of the elements. Lots of people don’t like ‘em: Stan doesn’t; Dave doesn’t. Some people do like ‘em: Veerle does. I can’t say I’m all that keen on them but I honestly can’t muster up much strength of conviction either way.

Let us leave the designers for a moment and cast our gaze upon the hot topic amongst the techy crowd…

Dave Winer looked at JSON and didn’t like what he saw:

Gotta love em, because there’s no way they’re going to stop breaking what works, and fixing what don’t need no fixing.

James Bennet wrote an excellent response:

Of course, this ignores the fact that the Lisp folks have been making the same argument for years, wondering why there was this great pressing need to go out and invent XML when s-expressions were just dandy.

The debate continues over on Scripting.com, where the best comment comes from Douglas Crockford:

The good thing about reinventing the wheel is that you can get a round one.

The discussion continues. Be it icons or data formats, the discourse remains remarkably civil. Perhaps it’s the seasonal spirit of goodwill. Whatever happened to the good ol’ “Mac vs. Windows”-style flame wars?

In contrast, Roger has posted a refreshingly curmudgeonesque list entitled Six things that suck about the Web in 2006. He had me nodding my head in vigourous agreement with point number six:

Over-wide, fixed width layouts. Go wide if you must. Use a fixed width if you don’t know how to make a flexible layout. But don’t do both. Horizontal scrolling, no thanks.

Perhaps I should post my own list of things about the Web that suck, but I fear it would be a never-ending roster. Instead I’ll restrict myself to one single thing, specifically related to blogs:

Ads on blogs. They suck. I find them disrespectful; like going into somebody’s house for a nice cup of tea only to have them try to flog you a nice set of encyclopedias.

Just to be clear: ads on commercial sites (magazines, resources, whatever) I understand. But on a personal site, they bring down the tone far more than any use of typography, colour or layout could ever offset.

I used to wonder why people put those “Digg this” or “Delicious this” links on their blog posts. I couldn’t see the point. But combined with google ads, I guess they make sense. They’re a way of driving traffic, eyeballs, click-through and by extension, filthy lucre. That’s fine… as long as you don’t mind being a whore.

Remember the term “Cam whore?”:

A Cam whore is a term for people who expose themselves on the Internet with webcam software in exchange for goods, usually via enticing viewers to purchase items on their wishlists or add to their online accounts.

I think it’s high time we coined the term “Blog whore” to describe people who slap google ads all over a medium intended for personal expression.

Alas, most of my friends, colleagues and co-workers are Blog whores. Scrivs manages to be Blog whore, Digg whore and pimp all at the same time with his 9 Rules bitches. In his recent round-up of blog designs, he says of Shaun’s site:

In a perfect world there are no ads, but we don’t live in that kind of world yet for the time being we can escape to the land of make believe when visiting Inman’s site.

Well, I see no reason why we can’t all live in that perfect world. In the style of Robert’s ludicrously provocative hyperbole, I hereby declare that a blog with ads isn’t really a blog. So there.

Ah, that’s better. There’s nothing like a good rant to counteract all that civilised discourse.

Happy holidays, Blog whores!