I really enjoyed hanging out with Paul at Indie Web Camp in Nuremberg last weekend. And I like the iconography he’s proposing:
This design attempts to bring together a set of icons that share the concept of a node – a line and a point – and use this to add counters to each letter shape.
I love how easy it is to use these icons: you can copy and paste the SVG or even get it encoded as a data URL.
I don’t know about you, but it seems like everyone I follow on Twitter is playing Wordle. Although I don’t play the game myself, I think it’s pretty great.
Not only does Wordle have a very sweet backstory, but it’s also unashamedly on the web. If you want to play, you go to the URL powerlanguage.co.uk/wordle. That’s it. No need to download an app.
That hasn’t stopped some nefarious developers trying to trick people into downloading their clones of Wordle from app stores. App stores, which are meant to be curated and safe, are in fact filled with dodgy knock-offs and scams. Contrary to popular belief, the web is quite literally a safer bet.
Wordle has a web app manifest, which means you can add it to your home screen and it will behave just like a native app (although I don’t believe it has offline support). That’s great, but the process of adding a web app to your home screen on iOS is ludicrously long-winded.
Macworld published an article detailing how to get the real Wordle app on your iPhone or iPad. On the one hand it’s great to see this knowledge being spread. On the other hand it’s dispiriting that it’s even necessary to tell people that they can do this, like it’s a hidden nerdy secret just for power users.
At this point I’ve pretty much given up on Apple ever doing anything about this pathetic situation. So what can I do instead?
Well, taking my cue from that Macworld article, the least I can do is inform people how they can add a progressive web app to their home screen.
That’s what I’ve done on thesession.org. I’ve published a page on how to install The Session to your home screen.
On both Android and iPhone the journey to installing a progressive web app begins with incomprehensible iconography. On Android you must first tap on the unlabeled kebab icon—three vertical dots. On iOS you must first tap on the unlabeled share icon—a square with an arrow coming out of it.
When it comes to mobile operating systems, consumer choice means you choose which kind of mystery meat to eat.
I’ve included screenshots to help people identify these mysterious portals. For iOS I’ve also included a video to illustrate the quest to find the secret menu item buried beneath the share icon.
I’ve linked to the page with the installation instructions from the site’s “help” page and the home page.
Handy tip: when you’re adding a start_url value to your web app manifest, it’s common to include a query string like this:
start_url: "/?homescreen"
I’m guessing most people to that so they can get analytics on how many people are starting from an icon tap. I don’t do analytics on The Session but I’m still using that query string in my start_url. On the home page of the site, I check for the existence of the query string. If it exists, I don’t show the link to the installation page. So once someone has installed the site to their home screen, they shouldn’t see that message when they launch The Session.
If you’ve got a progressive web app, it might be worth making a page with installation instructions rather than relying on browsers to proactively inform your site’s visitors. You’d still need to figure out the right time and place to point people to that page, but at least the design challenge would be in your hands.
Should you decide to take a leaf out of the Android and iOS playbooks and use mystery meat navigation to link to such a page, there’s an emoji you could potentially use: 📲
It’s still worse than using actual words, but it might be better than some random combination of dots, squares and arrows.
(I’m not really serious about using that emoji, but if you do, be sure to use a sensible aria-label value on the enclosing a element.)
How do we tell our visitors our sites work offline? How do we tell our visitors that they don’t need an app because it’s no more capable than the URL they’re on right now?
Remy expands on his call for ideas on branding websites that work offline with a universal symbol, along the lines of what we had with RSS.
What I’d personally like to see as an outcome: some simple iconography that I can use on my own site and other projects that can offer ambient badging to reassure my visitor that the URL they’re visiting will work offline.
This is an interesting push by Remy to try to figure out a way we can collectively indicate to users that a site works offline.
Well, seeing as browsers have completely dropped the ball on any kind of ambient badging, it’s fair enough that we take matters into our own hands.
A brief history of the manicule, illustrated with some extreme examples.
The ellipsis is the new hamburger.
It’s disappointing that Apple, supposedly a leader in interface design, has resorted to such uninspiring, and I’ll dare say, lazy design in its icons. I don’t claim to be a usability expert, but it seems to me that icons should represent a clear intention, followed by a consistent action.
From the days of Xerox PARC:
In your garage organization, there’s always a bucket for miscellaneous. You’ve got nuts and bolts and screws and nails, and then, stuff, miscellaneous stuff. That’s kind of what the hamburger menu button was.
Same as it ever was.
When in doubt, label your icons.
When not in doubt, you probably should be.
The fascinating story of Charles K. Bliss and his symbolic language:
The writing system – originally named World Writing in 1942, then Semantography in 1947, and finally Blissymoblics in the 1960s – contains several hundred basic geometric symbols (“Bliss-characters”) that can be combined in different ways to represent more complex concepts (“Bliss-words”). For example, the Bliss-characters for “house” and “medical” are combined to form the Bliss-word for “hospital” or “clinic”. The modular structure invites comparison to the German language; the German word for “hospital ” – “krankenhaus” – translates directly to “sick house”.
A profile of Susan Kare, icon designer extraordinaire.
I loved the puzzle-like nature of working in sixteen-by-sixteen and thirty-two-by-thirty-two pixel icon grids, and the marriage of craft and metaphor.
An illustrated history of digital iconography.
Here you go: a free book on icon design in three parts, delivered via email.
Andy’s been playing Devil’s 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:
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…
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:
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.
@andybudd Adding the word “menu” next to it goes a long way, and would help with teaching aspect to help it become more familiar in time.
— Paul Annett (@PaulAnnett) January 16, 2016Don’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.
@andybudd FWIW, I know some people in their 60s who couldn’t tell you what the two line pause icon would do on a web video player.
— Paul Annett (@PaulAnnett) January 16, 2016I think there are two good rules of thumb when it comes to using icons:
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):
So there you go. The answer to the question “Is the hamburger icon good or bad?” is a resounding and clear “It depends.”
This looks like a terrific presentation from Alla on iconography, semiotics, and communication.
The controversial hamburger icon goes mainstream with this story on the BBC News site.
It still amazes me that, despite clear data, many designers cling to the belief that the icon by itself is understandable (or that users will “figure it out eventually”). Why the aversion to having a label for the icon?
Typeset In The Future is back with another cracking analysis. This time—following on from 2001 and Moon—we’ve got Alien.
In her final recorded message before hypersleep, Ripley notes that she is the sole survivor of the Nostromo. What she forgets to mention is that she has not once in the past two hours encountered any Eurostile Bold Extended.
I really like Mark’s idea of standardised “sparkicons” …for a while there, reading this, I was worried he was going to propose something like Snap Preview. shudder
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.
This is a great free service for generating small subsetted icon fonts. Launch the app and have a play around — you can choose from the icons provided or you can import your own SVG shapes.
Nice touch: you can get the resulting font (mapped to your choice of unicode characters) base-64 encoded for your stylesheet.