The Old World Display

Maybe a decade ago, a web-designer and friend of mine told me a classic “client from hell” story. The details have since become fuzzy, but the crux of the story revolved around a particular design the client wouldn’t approve. There was this one detail that was off, a particular element that just wouldn’t center properly in the layout (it was insisted). Thankfully the client had come up with a seemingly simple fix: just draw half a pixel! Who would’ve guessed that just a decade later, “The Apple Retina Display” would herald the arrival of just that: the halfpixel?

While the term “retina” is mainly marketing chatter meant to imply that you can’t see the pixels on the screen, it’s not just about making sure the display is arbitrarily high resolution. In fact, it’s pixel-doubling. The 1024×768 iPad doubled to 2048×1536 when going retina, and while the implicit goal of this was clarity and crispness, the exact doubling of screen dimensions means UIs elements scale perfectly: 1 pixel simply becomes 4 pixels. It’s quite brilliant, and there’s only one pitfall.

For a designer it’s more than easy to get carried away with quadruple the canvas. In the plebean resolution of yore, tiny UI elements had little room for error: icons had to be perfectly aligned to even pixels, and ideally their stem weight would be a whole pixel-value. The atom of the display — the pixel — was the tiniest unit of information possible, and if it wasn’t mindfully placed it would blur and artifact under heavy antialiasing. In The Old World we had a term for this: pixel-perfect.

However inside the retina display lives the halfpixel siren, and her song is alluring. She’ll make you forget about The Old World. She’ll draw tiny tiny pixels for you and she’ll make your designs feel pixel-perfect, even when they’re not. It’s an irresistable New World.

David Pierce reviewing the new iMac 5K for The Verge:

I drove an Audi and never looked at my Saturn the same way again. Remember the first time you used a capacitive touchscreen, threw your 56k modem out the window and switched to broadband, or switched from standard-def TV to 1080p?

It only took about ten minutes of using Apple’s new iMac with Retina display to make me wonder how I’m ever supposed to go back. Back to a world where pixels are visible on any screen, even one this big.

It’s a good life in The New World. It’s a good life here in the first world. It’s so true: no-one should have to endure the pin-pricking misery of looking at old-world 1x screens! (Actually, my 35 year old eyes aren’t good enough to see pixels on my daughters etch-a-sketch, but I can still totally empathize with how completely unbearable the pain must be).

It gets worse — are you sitting down? Here it comes: most screens aren’t retina. One wild guess puts the population of non-retina desktop users (or old-worlders as I call them) at 98.9%.

That’s not good enough, and it’s time to fight for the halfpixel. We’re at a fateful crucible in history, and I can see only two possible paths going forward. Either we start a “retina displays for oil” program to bring proper high resolutions to the overwhelming majority of people who even have computers, or we just have to live with ourselves knowing that these old-worlders will have to endure not only disgustingly low resolutions, but indeed all of the added extra blur and artifacts that will result of future computer graphics being designed on retina screens and not even tested for crispness on 1x screens1.

Oh well, I suppose there’s a third option. I suppose we can all wake up from this retina-induced bong haze and maybe just once in a while take one damn look at our graphics on an old world display.

  1. Hey Medium… We need to talk.  []


The future of computing is mobile, they say, and they’re not referring to that lovely city in Alabama. Being a fan of smartphones and their UI design, I’ve considered myself mostly in the loop with where things were going, but recently it’s dawned on me I might as well have been lodged in a cave for a couple of years, only to just emerge and see the light. The future of computing is more mobile than I thought, and it’s not actually the future. (It’s now — I hate cliffhangers).

I had a baby a few years ago. That does things to you. As my friend put it, parenthood is not inaccurately emulated by sitting down and getting up again immediately. It’s a mostly constant state of activity. Either you’re busy playing with the child, caring for it, planning for how you’re going to care for the child next, or you’re worrying. There’s very little downtime, and so that becomes a valuable commodity in itself.

One thing parents do — or at least this parent — is use the smartphone. I put things in my calendar and to-do list because if it’s not in my calendar or to-do list I won’t remember it. I don’t email very much, because we don’t do that, but I keep Slack in my pocket. I take notes constantly. I listen to podcasts and music on the device, I control what’s on my television with it, and now I’m also doing my grocery shopping online. (I’d argue that last part isn’t laziness if you have your priorities straight, and having kids comes with an overwhelming sense that you do — it’s powerful chemistry, man.)

So what do I need my laptop for? Well I’m an interface designer, so I need a laptop for work. But when I’m not working I barely use it at all. To put it differently, when I’m not working, I don’t need a laptop at all, and if I were in a different business I’d probably never pick one up. There’s almost nothing important I can’t do on my phone instead, and often times the mobile experience is better, faster, simpler. By virtue of there being less realestate, there’s just not room for clutter. It requires the use of design patterns and a focus on usability like never before. Like when a sculptor chips away every little piece that doesn’t resemble, a good mobile experience has to simplify until only what’s important remains.

It’s only in the past couple of years that the scope of this shift has become clear to me, and it’s not just about making sure your website works well on a small screen. Computers have always been doing what they were told, but the interaction has been shackled by lack of portability and obtuse interfacing methods. Not only can mobile devices physically unshackle us from desks, but their limitations in size and input has required the industry to think of new ways to divine intent and translate your thoughts into bits. Speaking, waving at, swiping, tapping, throwing and winking all save us from repetitive injuries, all the while being available to us on our own terms.

I’m in. The desktop will be an afterthought for me from now on — and the result will probably be better for it. I joked on Twitter the other day about watch-first design. I’ve now slept on it, and I’m rescinding the joke part. My approach from now on is tiny-screen first and then graceful scaling. Mobile patterns have already standardized a plethora of useful and recognizable layouts, icons and interactions that can benefit us outside of only the small screens. The dogma of the desktop interface is now a thing of the past, and mobile is heralding a future of drastically simpler and better UI. The net result is not only more instagrams browsed, it’s more knowledge shared and learned. The fact that I can use my voice to tell my television to play more Knight Rider is just a really, really awesome side-effect.

Icon Fonts Are Ruining Your Markup

Icon fonts are great. They’re more scalable than PNGs, they’re re-colorable in CSS, and it’s easier than ever to create them. But most of us are using them wrong, and it’s ruining your markup. Recognize this?

<span class="icon icon-calendar"></span>

This is fast becoming the de-facto standard syntax for inserting icons in your webdesigns. No need to fiddle with weird glyphs. No CSS needed to insert icons, even.


Hold up. The promise of CSS was that we could separate presentation from markup. We could create standardized, semantic and sensible markup, that could then be completely re-skinned solely by replacing a stylesheet. That was the whole point of the CSS Zen Garden. By using nonsense spans with verbose classes, that’s out the window, all in the name of convenience. I too have been bitten by the icon-font bug. I’m into them. I think it’s so great that I can re-color icons with a line of CSS. I like how they zoom, and how they have broader support than SVGs.

But they’re not SVGs. They’re not images. We shouldn’t pretend they were, or that they could ever be as accessible as images are.

Theoretically an icon from a font could be inserted in a semi-accessible way by outputting the actual glyph in the code to ensure copy/paste-ability. You’d also have to make sure to only use an icon that already existed in the unicode-table so screen-readers could make sense of them, thus severely limiting your options as a designer. Need a hamburger menu icon? Sorry, doesn’t exist in the unicode table. Pretty much all the benefits of using an icon font would be out the window at this point.

Rewind for a bit. Take a deep breath and think. Why are you using an icon font in the first place? Easy HiDPI and CSS colorability? Easy to show at multiple sizes? Fair enough.

Now pretend icon fonts didn’t exist, what would you do instead? Use a PNG or GIF as a CSS background, right? You’d treat the graphics as presentational elements. Visual aids. You’d keep it separate from your markup. You’d be able to reskin your whole site with a single stylesheet. You’d keep the markup as simple and semantic as that of the CSS Zen Garden. Hopefully you’d be a good person and worry about accessability where it mattered most: in the structure of your markup.

You can still use icon-fonts and have sensible markup while keeping the presentation separate. But doing so means you can’t rely on those bundled CSS helper classes. You have to do it manually; put in the work. Don’t treat icon-fonts like images. Pretend they’re sprites and keep them in your stylesheet. You’ll thank me.

Good Decisions, Else Options

There’s a mantra in the WordPress development community: decisions, not options. It’s meant to be a standard to which you hold any interface design decision: if you make a decision for users it’ll ultimately be better than forcing them to make decisions themselves. It’s a decent mantra — if you’re not mindful you’ll end up with feature creep and UI complexity, and it’s orders of magnitude more difficult to remove an old option than it is to add one in the first place. Adding an option instead of making a decision for the user is almost always bad UI design.

Except when it’s not.

The problem with a mantra like this is that it quickly gets elevated to almost biblical status. When used by a disgruntled developer it can be used to shoot down just about any initiative. Like Godwins law for WordPress: once you drop the “decisions not options” bomb, rational discussion comes to a halt.

The thing about open source development is that it’s much like natural evolution: it evolves and adapts to changes in the environment. Unfortunately that also means features once useful can become vestigial once the problem they used to solve becomes obsolete. Baggage like this can pile up over years, and maintaining backwards compatibility means it can be very difficult to rid of. Sure, “decisions not options” can help cauterize some future baggage from happening, but it’s also not the blanket solution to it.

The problem is: sometimes the right decision is unfeasible, therefore beckoning an option in its absence. WordPress is many things to many people. Some people use it for blogging, others use it for restaurants, portfolios, photo galleries, intranets, you name it. Every use case has its own sets of needs and workflows and it’s virtually impossible to make a stock experience that’s optimal for everyone. Most bloggers would arguably have a better experience with a slew of WordPress features hidden or removed whereas site owners might depend on those very same features for dear life. By catering to many use-cases at once, user experiences across the board are bound to be unfocused in some way or other.

The “Screen Options” tab is an example of a feature that would probably not exist were “decisions not options” taken at face value. Screen Options exists on the idea that not everyone needs to see the “Custom Fields” panel on their Add New Post page, yet acknowledges that some users will find that feature invaluable. It is an option added in absence of a strong decision, for example, to limit WordPress to be a blogging-only tool. I consider it an example of an exception to the mantra for the good of the user. Sure, the UI could use some improvement, let’s work on that, but I really appreciate the ability to hide the “Send Trackbacks” panel.

I’m a fan of WordPress. I’m a fan of good decisions, and I’m a fan of good UI design. I believe that if we relieve ourselves of arbitrary straitjackets and approach each design objective with a sense of good taste and balance, we can make excellent open source software. Cauterizing entire avenues of UI simply because it adds options, however, negates the fact that sometimes those options exist in absence of a higher-up decision that just can’t be made for whatever reason.

Do’s and Don’ts of Icon Fonts

Having worked on icon fonts a lot in this past year, I’ve learned many things about them I did not know before. In some ways they’re more useful than I thought (yes, icons can actually be pixel-perfect), in other ways less so (pretend Firefox doesn’t exist until it reaches version 25). Since icon fonts are booming these days, I thought it useful to share some do’s and don’ts that I’ve picked up over the course.

An icon font is a font that contains symbols and graphics instead of letters and numbers. Remember Wingdings? These symbol fonts are incredibly useful because they allow webdesigners to do things they can’t do with PNG or GIF graphics:

  • it’s HiDPI out of the box
  • they scale well (more on that later)
  • it’s easy to pick colors using only CSS

They’re so pleasant to work with that it’s easy to get carried away by the obvious benefits over PNGs. Unfortunately there are a number of limitations to be mindful of. Most of these can be mitigated by using icon fonts properly.

Scalability at small sizes

Just because icon fonts are technically vector graphics, doesn’t mean they all look great at any size shown. Especially at small sizes, icon fonts start falling apart. This is why good icon fonts are designed according to a pixel grid.

A pixel grid is a minimum resolution at which embedded icons show up crisp. Typically such a resolution is 16x16px (which translates to font-size: 16px) or 20x20px (which translates to font-size: 20px;). If you use the icons outside of their intended grid, the icons will get blurred and details become fuzzy. If you show an icon intended for 16px at 17px, it will look positively atrocious.

We’re used to this from the Nintendo 8-bit days: there’s only so much resolution to work with. Unless you place your pixels precisely, your graphics won’t be clear. Being vector graphics doesn’t change this one bit: at 16x16px it doesn’t matter how scalable your icon is.

Remember, even if you’re used to being able to use many different font sizes for actual fonts, icons are a different thing. Not only are our brains trained to recognize letters, but fonts themselves are designed to render letters for maximum legibility. Fonts rely on the fact that we read horisontally, and hints letters so that subpixel antialiasing ensures horisontal crispness at many arbitrary sizes. This subpixel antialasing does not translate to icons. Icon fonts won’t ever look as good as normal fonts do at arbitrary sizes.

Let there be no doubt in anyones mind: using icon fonts for web graphics is a hack!

It is a glorious, wonderful hack. But it is a hack. We have to be mindful how we use it.

Crossdomain fonts

Firefox blocks a stylesheet from from loading a font hosted on It is an intended font piracy/hotlinking measure. The workaround is simple, but easy to forget when you’re pounding your head against the desk unsure why icons show up fine in Chrome but not Firefox.

The easiest workaround is to base64 encode the font file itself and embed it in the stylesheet. By being embedded directly in the stylesheet, no domain hops are necessary, and Firefox loads the font. Most icon font bundles (such as Genericons) come with base64 in tow, but if you’re making your own icon fonts, I recommend using FontSquirrel’s Webfont Generator which will optionally base64 encode for you.

Inserting icons

Because icon fonts are hacks, most icon font packs been through a rather lengthy process to make them as easy to use in webdesigns as possible. Ideally it’s a matter of referencing a stylesheet and copy/pasting a snippet of code.

But don’t get carried away. Behind the scenes numerous decisions have been made in order to make your icon fonts that simple to use. Some of those decisions have consequences outside of just the icons.

This is going to vary from icon font to icon font, but let me go through how the Genericons copy/paste tool works.


Right on the Genericons homepage, the third copy option next to the big icon preview is “Copy Glyph”. This is intended only for use in your Photoshop mockups. You download the icon font and install it on your system. Now in Photoshop you can paste the glyph in a textarea, set it to the Genericons font and the icon will show up.

It is not intended to paste in your actual HTML. Remember, icon fonts is a hack, and a screen-reader wouldn’t know what to do with a weird unicode symbol. Incidentally that means we can only rely on using CSS’s :before selector to insert the glyphs. That means using icon fonts in an accessible manner can never work on IE7.


For casual users who want to insert Genericons as they would smileys, the “Copy HTML” feature is provided. In effort to make it as easy as possible to get the ball rolling and an icon showing, some helper CSS is provided with Genericons where every icon is mapped to a preset of named classes, for example:

<div class="genericon genericon-calendar"></div>

That’s a lot of CSS classes inside a redundant empty div, don’t you think? Yep. It’s not great code. But it’s really easy to insert, so the casual user doesn’t have to worry about the CSS. It’s perfect if you mean to insert a star icon in the middle of that article you’re writing in your CMS of choice.

Copy CSS

This is the option non-casual webdesigners should use. While also the least easy way to insert an icon (since you’ll effectively be re-writing some of the bundled helper CSS), it’s not actually as hard as I may be presenting it here. You should be using this method because:

  • it’s the most accessible — screen readers don’t even attempt to read the icons aloud because they’re inserted using only CSS
  • it’s the cleanest — there are no extra CSS classes and no redundant markup
  • you have the most control: since you write all the CSS, you don’t have to unstyle some of the bundled Genericons helper CSS you don’t need

The process is to essentially manually attach the icons to the :before selector of the class needed:

.my-element:before {
	content: 'f408';
	display: inline-block;
	-webkit-font-smoothing: antialiased;
	font: normal 16px/1 'Genericons';
	vertical-align: top;

The content: 'f408'; part is what you get from the “Copy CSS” tool. You can structure your own CSS as you wish to minimize code duplication.

In summary

Using icon fonts is a wonderful hack that brings many convenient features, but unless you’re using them right, you’ll end up with fuzzy graphics. Knowing is half the battle, and here are the rules:

Rule #1: When showing icons small, do not stray from the font pixel-grid (unless you have a good reason). If the grid is 16×16, show the font at font-size: 16px exactly.

Rule #2: Don’t rely too heavily on the helper CSS, that is intended only for casual use.

Now go use some icon fonts.

Font Smoothing

If you’re really into icon fonts, which I have recently become, you may have noticed a tiny storm brewing in the suburbs of the internet. It’s about CSS-specified font smoothing. Quite a nichy topic, one you can live a perfectly good life without ever knowing all about. You may in fact sleep better by not reading on.

Still here? Alright, here’s the deal. WebKit — born of Safari, engine of Chrome — allows webdevelopers to specify how the edges of fonts are smoothed. The modern default font smoothing method is called subpixel antialiasing. It smoothes font edges using quite impressive means, and in nearly all cases it drastically improves the rendering of letters. If you look at the text in a magnifying glass, though, you’ll notice a nearly imperceptible blue haze on the left side of each letter, and a red haze on the right side. WebKit provides a means for webdevelopers to pick which type of font smoothing is applied: subpixel-antialiasing, antialiasing, or none. Handy. Right?

The controversy is the fact that a number of people — smart people — feel that this CSS property is damaging to the readability of text on the web. There are very long articles on the topic. In fact quite recently a Google employee removed the CSS property from Chrome, citing the notion that the browser should render text according to the operating system. There’s just one problem: icon fonts.

Icon fonts are custom-made webfonts that contain no letters, only icons. The purpose is to have fast access to a bunch of icons in a very lightweight and easy way in your webdesigns. Other benefits include the fact that the icons are infinitely scalable because they’re vector graphics, and you can easily apply any color, drop-shadow or even a gradient to each icon using plain CSS. Sounds brilliant, doesn’t it?

The only downside is that an icon font is still technically a font, so the computer thinks each icon is actually a letter, and by default will try to subpixel antialias it. While subpixel antialiasing does wonders to letters, it’ll fuzzy up your icons and make them look blurry. Which is why the -webkit-font-smoothing property was so welcome. Here’s an icon font without and with subpixel antialiasing:

As you can imagine, I’m strongly in favor of not only keeping the font-smoothing property, but in fact expanding it beyond WebKit to both Firefox and Internet Explorer. Icon fonts won’t be a truly viable webdesign technique until every icon looks great on all the platforms.

“But SVG is the future of vector graphics on the web, surely you know that!” — Yes I do. But pragmatically speaking, that future is not here yet. SVG support is still lacklustre, especially when used as CSS backgrounds. More importantly, you can’t easily change the color of an SVG icon using CSS only, or apply a drop-shadow. Yes, drop-shadows are on the road map for SVG, but the way it’ll happen is not pretty. Icon fonts, on the other hand, provide a real-world solution today, which is both flexible and infinitely scalable. So next time you see someone bad-mouthing -webkit-font-smoothing, pat them on the head and mention icon fonts. The more you know.

Honestly Flat

The authors of LayerVault blog about the flat design era — a move towards simpler UI design with fewer bevels and textures and more flatness. I endorse this movement too much to let this pass me by without comment.

While one side of the mouth yells “good design is how it works,” the other side mumbles that great aesthetics mean realism. It doesn’t need to be this way. Designing honestly means recognizing that things you can do with screens and input devices can’t be done with physical objects — more importantly that we shouldn’t try copying them. It takes too much for granted. Can you imagine your pristine iPhone built into the body of an antique telephone handset? Is that beautiful design?

I really can’t help but agree with these points, but I’m thinking perhaps they’re overthinking it. Having been in this business for over a decade now (yep, I’m old), I feel like I’ve arrived at a couple of simple truths. One of them I arrived at reluctantly, and it took a while to accept it. It’s the notion that there’s no such thing as good UI design, there’s only bad UI design.

To elaborate: when you see a good design, chances are you don’t notice it. Because it’s a good design, it’s already set you on your way to your next destination, offering a clean and simple path on your journey. On the flipside, a bad design has you stumble in your tracks, wondering — where’s the phone number for this restaurant? Whether the UI design is full of linen does not necessarily matter1, what matters is that you found what you were looking for with the least possible friction. The point is: good design is good design, no matter how you arrive at it.

Aside from good design and bad design, there’s also the design that creates an emotional connection within you. Not only does it step in the background when you have a specific goal, but it will reach inside you and shake something when you don’t know where you’re going. I’m not sure textures, bevels, or even glorious flatness does this. In my experience, only tone, can do this. The tone of your wording, phrasing, or even your kooky layout may incite a smile in your viewer, and your large personal photos may tug at a heartstring somewhere. So it’s about being personal, and the best way I know to do this is to let the content shine.

Because of these two lessons — design to help the user on with their journey, and let content shine — my love-affair with gloriously flat UI design is not so much a matter of being honest as it is a matter of getting to that point where you’re feeling the design you’re working on, as fast as possible. Any big design project is borne of agony and a feeling of insufficiency. The more pieces you put in play, the more functionality you sketch out, the faster those feelings subside until at some point they turn into pride.

If I start my process with a canvas of linen, I’ll have already limited my playing field into a very narrow path that’s needlessly hard to find and follow.

For me, keeping things flat for as long as possible is like leaving your body and seeing your project from high above. Suddenly the answer to the question: “should I put a linen texture here?” becomes easy. That answer is that it doesn’t matter. So I usually leave it out.

  1. I hate myself for actually saying that, because the linen texture is the worst []


Smartphones don’t have permanently visible scrollbars. Neither does OSX Lion (unless you’re using a mouse in which case they pop back in). On the phone, there’s a space issue, so the lack of scrollbars seems a good tradeoff. On the desktop, there’s no such space issue. So why the tradeoff?

If Microsoft’s vision for the future — Surface — is any kind of true (and that remains to be seen), soon there will be no desktop. Fine, but tablets do still have room for scrollbars, so why not enable them there?

Let’s look at the pros and cons. On the list of reasons why hiding the scrollbar is a good thing, I have this (and feel free to augment this in the comments):

  • It’s prettier. Less UI is often a good thing. If you don’t miss it, then you have a better experience for it.
  • It’s consistent with phones and tablets (from the same vendor) and gives a sense of coherence.
  • If the future is indeed touchbased (as in: your future desktop is a docked tablet or phone), developers should probably already now start to yank out hover-induced menus and make their scrollpanes indicate overflow when no scrollbar is visible. Having a desktop OS that mimics this, I suppose, is a helpful reminder of what may be coming.

Still, the scrollbar has been around for a while. In fact I would argue it’s a cornerstone in modern GUIs. Such a thing should not be buried willy-nilly. Here are reasons to keep the scrollbar visible at all times:

  • I can think of many ways to indicate that there’s more content to be seen, but none of them are as easy to understand as the scrollbar.
  • A scrollbar doesn’t have to be 18px wide, opaque, with a huge inset gutter, so long as it looks like a scrollbar. In fact, if only Lion scrollbars didn’t fade out completely, this post would probably not have been written.
  • A permanently visible scrollbar, by virtue of its relative height, will sit silently at the side of your view and cue you in how much content remains to be seen. No bottom shadow or clipped content will indicate that. It’s like a minimap of your document.

It’s not that I love scrollbars. Most of them are pretty ugly. Scrollbars, as we’ve grown to know them, can be especially hideous when shown on dark designs. Still, I’m not entirely convinced the solution to this challenge is to hide them. That sounds like mystery meat navigation to me.

9 violated usability conventions in 2010 and 2011 so far [Update: Gawker]

It’s been a couple of years since I summarized my personal qualms with the state of the web, but it’s time again. While some of the usability conventions in 2008 are still to this day very much in vogue, such as the inability to distinguish links from visited links and links that open new browser windows, other conventions such as styling push buttons and form elements have changed in recent years. More on that a different time, here’s what’s bad about the web today…

Mobile sites that don’t allow you to zoom.

Sometimes, no mobile site is better than a bad mobile site. Case in point, Flickr’s mobile, which has a reasonably mobile friendly layout. The problem? The viewport width is fixed so pinch-to-zoom is disabled. Worse yet, the Flickr image you’re likely to have clicked into from Twitter is smaller than Kim Jong Il’s sense of self-esteem. And there’s no “enlarge” to find.

Most common excuse: “Come on, it’s mobile! Who checks websites on their cellphones?”

AJAX sites with janky back/ forward navigation

That wonderful technology that allows developers to load new stuff in the background without refreshing the entire page also allows for loading entire sections of a website faster. These full-on AJAX websites can appear to load faster, and rids of that white flash of the screen that sometimes appear when you go from one “plain” URL to another. The problem is that due to the way AJAX websites are built, the navigation history needs to be tackled in JavaScript rather than by the browser. Which means most of these fancy new AJAX sites have super janky back-button reliability. Case in point: every Gawker site out there; specifically their galleries are terrible.

Most common excuse: “Hmm, it works fine for me when I navigate the site really slowly, and the gallery is a known issue”.

AJAX sites with the hashbang in the URL

Go visit the fancy #NewTwitter. If it loads for you (part of the problem), have a look at the URL in the addressbar. See that little #! that splits up the address? That’s the hashbang, and it not only makes addresses look cryptic and ugly, it breaks a great many things. Sometimes pages do not load and when they do load, they don’t always load what you expected them to load. The reload button gets janky, and the pages themselves are hard if not impossible to index for search engines. Add to that the fact that you can actually make a full-on AJAX site without using the hashbang in the URL due to advances in HTML5. Just try and click the tabs on my Google profile while keeping an eye on the URL. It’s doable.

Most common excuse: “Oh come on, it works fine. You’re just nitpicking.”

Okay, full disclosure, I both AJAX and the hashbang on my company website. My excuse: “I don’t use that site anymore, and besides nobody ever visits it anymore”.

Multiple consecutive redirects that break the back button navigation, on purpose or not

Ever clicked a search result in Google and wanted to go back to your search results only to find the back button doesn’t work and only “blinks” the page? Sometimes doubleclicking the back-button fast enough, or long-pressing it to step two items back in the history fixes this. But it’s completely user hostile. Sure, some sites do this on purpose — this article is likely to be lost on those sites anyway. Other sites do it for a variety of reasons; redirecting to a mobile view, showing an interstitial ad or whatever oddball reason they have.

What these sites don’t know is that they can keep their redirects, so long as they send the correct HTTP header redirection code; modern browsers will detect these codes and omit them from the history, allowing the back button to function as expected.

Most common excuse: “But we need to redirect to a mobile view! … Wait what? Header codes?”

Implementing a scroll behaviour without the scrollbar

Yes, it looks like the general direction for scrollbars is that of the dodo. In the future, there might not be a scrollbar, it might work opposite to what you expect it to, and so on, and so on. That’s all fine. Seriously, whatever usability improvements operating systems might do to make navigating this or that easier, I welcome.

But it’s too early for all you bleeding-edge websites to jump on this bandwagon. So many aspects of web-browsers rely intently on the scrollbar; that if you break it, or create some kind of fancy JavaScript scrollbar replacement (*cough* Gawker *cough*), things are likely to break in serious and unpredictable ways. My advice: love your scrollbar. You can have your fancy iPad scrolling even if the scrollbar remains there on your desktop.

Most common excuse: “We believe the direction websites are going is that of smartphones and tablets. That’s why we want to adopt these new paradigms to ride the golden wave of momentum that space has at the moment.”

Sites that use QuickTime or Flash for video, without providing a fallback video format

You think Flash sucks? Yeah, it does, but so does the QuickTime plugin. Any video plugin, in fact. It’s been this way for a decade, but we’ve dealt with it because it was impressive video on the web was possible at all. This has changed in recent years, however. Web-video is available on smartphones, set-top boxes and in reasonably high quality. Laymen users are no longer impressed when video plays in their browsers, they expect it. So when they encounter a puzzle piece or a blank area, I no longer think it’s unreasonable to call that bad usability. There should be fallback to other video formats. H.264 or WebM, I don’t care.

Most common excuse: “HTML5?”

Netbanking sites that break when using the back-button

Accessing your bank via the web is no longer a “nice-to-have”, it’s absolutely essential for an increasing share of the population. Considering this, it’s high time these netbanking systems get a usability overhaul. That includes building it in a way that doesn’t break your login authorisation when you click your large convenient back-button, requiring you to click an HTML “back” hyperlink instead.

Most common excuse: “It’s as simple as that huh? You will use the software we provide and be happy! What are you gonna do, switch banks over a hyperlink?”

Inflexible form widgets in surveys or profiles

Ever encountered a survey whose “age” field requires you to select a birth year between 1900 and 2010? How about a credit-card input field that wasn’t updated for newer credit cards that don’t expire until 2015? Even a gender radio-group might rub you the wrong way. Either way, building a good form is an excellent excercise in usability; limiting choice is good, but you need to know when to be flexible. Which a lot of sites fail to do.

Most common excuses: “What other genders are there?”, “If age is a textfield, users are going to write ‘ripe’ or ‘timeless’.”

Sites that use flash for Navigation

Yeah Flash, it still kinda has a place in the world. But that place is not for navigation. Are you listening, Vimeo? That related content sidebar sucks! Get with the program!

Most common excuse: “Our target audience is a different one, one that cares a lot about design and visuals. These people will appreciate that our scrollbar matches the rest of the site design. Enough to halve their battery life.”

What else is there?

I hope you enjoyed reading this incomplete list of usability nuisances. Feel free to fill in the blanks.

[Update]: It looks like Gawker has rolled out changes to their janky AJAX stuff removing the hashbang but keeping the AJAXiness. Check it out on, and I’m sure their SEO will improve, if not the overall loading consistency.