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 Gawker.com, Lifehacker.com and io9.com. I’m sure their SEO will improve, if not the overall loading consistency.

A couple of quick notes on Googles new profiles

Google just revamped their profiles:

We think this new design helps highlight the information that’s most important to you, making it easier for people who visit your profile to get to know you. As the new layout gradually rolls out, current users of Google Profiles will notice that their existing profile will automatically update to the new style. To update and add to your profile, simply click on the new “Edit Profile” button.

Here’s my revamped profile, and here are my thoughts about it:

  • It’s good. It’s easy to scan, it’s very easy to create and edit, and it’s a nice overall upgrade to the old style profiles.
  • It’s not very pretty. The cleanliness of Googles white color hasn’t bled through and while I’m all for making it easier on the eyes by muting down a bright white, the odd result of gradients, drop shadows and baby blues muddies it all quite a bit.
  • Just the other day, I used “truth to materials” as a subtle criticism of a drop shadow that didn’t blend realistically considering the z-index of layers if one considered a website to be physical. It’s worse here; the the white sheet’s left shadow breaks the physics for me. Go on, point at me and laugh for pointing out something so nitpicky. But it gets to me, subconsciously, and my eyes can’t rest knowing the visuals are off like this.
  • I wonder what a filled-out profile means for search results.
  • Hey, it looks like Google finally got the message, and separated Google Buzz out from Gmail! Maybe it’s useful now!
  • Click the “Buzz” tab. Now click the “About” tab again. Fast isn’t it? Must be AJAX. Nerds: notice that the URL doensn’t contain the infamous #! slug. This is HTML5 boys and girls.
  • It comforts me that profile items you don’t fill out, don’t show up at all on your profile. There’s nothing worse than an item that says “Gender: Won’t say”.

I’d like a redesign, but everything else about this, I kinda like. That said, it’s no-where near replacing my about.me/joen profile in my email signature yet.

Use Microsofts official Internet Explorer Virtual PC testing images in VirtualBox on OSX

If you need to test Internet Explorer 6 on your Mac, but don’t want to resort to multibooting, you can download the free VirtualBox software, and grab one of Microsofts free VirtualPC testing images and get up and running.

  1. Download a VPC image of your choice.
  2. Rename the .exe file to .rar, then unpack using a RAR unpacker on the Mac
  3. Create a new Virtual Machine in Virtualbox. When you get the chance to select an existing disk, do that and point to the VPC image.
  4. Boot. The VPC image may require activation and/or a password (which resides inside the .txt file that came with the VPC image)

Yep. There’s the activation hassle. It’s Microsoft. What did you expect? It’s still easier than manually installing Windows XP.

CSS box-sizing; File under “really helpful”

When it comes to layouts, proper widths define whether or not you’ll get a headache. Especially when sizing input fields or textareas, setting the proper width is a challenge. This is due to the CSS box model, which calculates margins, paddings and borders outside of the box width.

A behavior which you can fortunately change:

box-sizing: border-box;
-moz-box-sizing:border-box;
-webkit-box-sizing:border-box;
-ms-box-sizing:border-box;

This changes your divs and block elements to calculate paddings and borders inside the specified width.

The peculiarly bad situation with web-fonts on Apples iPad

I’ve thrown a lot of love in the general direction of Apples open source WebKit lately. It looks like WebKit, moreso than Firefox, has ousted every other browser as the rendering engine of choice for a richer web. Unfortunately, I’m about to throw something other than love at WebKits little-sister, Mobile Safari. Why? Because it’s useless at web-fonts.

Typekit’s talked about it:

Rendering multiple weights from a font family can cause Mobile Safari to crash, even when the individual font file sizes are small (<5k). In our testing, using two weights from a family caused Mobile Safari to crash on up to 50% of attempted page loads, and the crash rate seemed to increase as we increased the number of weights we added.

So that means you can use ONE weight of a web font. “Regular”, for instance. But you can’t use that fonts “Bold”, “Italic” or “Bold Italic” versions.

Just recently I wanted to use the glorious DejaWeb font for a project, and now that all the major browsers support web-fonts, I quickly fed the fonts to FontSquirrels excellent multi-platform font-converter and was output something that was supposed to work in all the browsers. EOT for Internet Explorer, WOFF for Firefox, TrueType for WebKit and SVG for Mobile Safari. Everything seemed to work just perfectly. Except of course for the intermittent crashes on the iPad.

A Temporary Solution

Now since the bug has been filed and Apple will probably fix this in some unannounced not-soon-enough future (maybe the iPad will get multitasking and font-face support at the same time?), I’m not going to waste any more tears. Instead I’m going to let you know what I did to deal with this issue.

At first, I worried that I wouldn’t be able to use DejaWeb at all, since this project had to be at least compatible with the iPad. I didn’t want to look into CSS hacks or JavaScript to detect user agents to then serve web-fonts to only capable browsers, carefully omitting the fonts for the iPad. Then it dawned upon me, a realization that in retrospect is embarrassingly simple (pointing and laughing for a little while is okay). Since MobileSafari can only render fonts converted to SVG, the solution to the crashes was to simply not serve an SVG font. Or in my solution, serve it only one SVG file: DejaWeb Regular.

@font-face {
	font-family: 'DejaWeb';
	src: url('fonts/DejaWeb.eot');
	src: local('DejaWeb'), local('DejaWeb'), url('fonts/DejaWeb.woff') format('woff'), url('fonts/DejaWeb.ttf') format('truetype'), url('fonts/DejaWeb.svg#DejaWeb') format('svg');
}

@font-face {
	font-family: 'DejaWeb';
	font-weight: bold;
	src: url('fonts/DejaWeb-Bold.eot');
	src: local('DejaWeb Bold'), local('DejaWeb-Bold'), url('fonts/DejaWeb-Bold.woff') format('woff'), url('fonts/DejaWeb-Bold.ttf') format('truetype'), url('fonts/DejaWeb-Bold.svg#DejaWeb-Bold') format('svgFIXME');
}

@font-face {
	font-family: 'DejaWeb';
	font-style: italic;
	src: url('fonts/DejaWeb-Italic.eot');
	src: local('DejaWeb Italic'), local('DejaWeb-Italic'), url('fonts/DejaWeb-Italic.woff') format('woff'), url('fonts/DejaWeb-Italic.ttf') format('truetype'), url('fonts/DejaWeb-Italic.svg#DejaWeb-Italic') format('svgFIXME');
}

@font-face {
	font-family: 'DejaWeb';
	font-weight: bold;
	font-style: italic;
	src: url('fonts/DejaWeb-BoldItalic.eot');
	src: local('DejaWeb Bold Italic'), local('DejaWeb-BoldItalic'), url('fonts/DejaWeb-BoldItalic.woff') format('woff'), url('fonts/DejaWeb-BoldItalic.ttf') format('truetype'), url('fonts/DejaWeb-BoldItalic.svg#DejaWeb-BoldItalic') format('svgFIXME');
}

Notice how I’ve invented a new font format called “svgFIXME”? Yep, that stays until the iPad can render SVG fonts in more than one weight. Until then, plain old regular it is. Even for bold-face text. It’s better than a crash, right?