Android, several years later

Google I/O is wednesday, which traditionally means a peek at the next version of Android. Having used Android since version 2, I thought now would be a great time to reflect on how far Android has come.

design

Droid

The Android open source project has been around since 2005, but it wasn’t until Android 2.0 (no unique dessert name, Android 1.6 was “Donut”) was released alongside the Droid phone that Android started its rise to some sort of smartphone dominance. Looking back, version 2 of Android was a pretty uninspired affair with very few good apps to brag about. Some apps were crashy and copy and paste wasn’t everywhere and not particularly good. The experience as a whole felt sluggish and laggy.

What made it worth getting instead of the iPhone, however, was the fact that everything synced as soon as you were logged in with your Google account. There was not a trace of iTunes, and did I mention the superior turn by turn navigation? Douchy hipsters would ask why anyone in their right minds would get an Android phone when they could buy an iPhone instead. Even back then, the answer was: sync and maps.

The Nexus Phones

HTC_Desire_cyanogenmod

While Android 2.0 started the rivalry between Apple and Google, Android 2.1 (“Eclair”) which coincided with the Nexus One, set the war ablaze. Pinch to zoom was omitted due to threats of themonuclear war, but the phone itself was still the best Android to date.

Only, there was a problem: way too little internal storage. 256M if I remember correctly. This little space had to hold the entire operating system, including apps, including application data. Which meant, of course, that you’d run out of space within days if you used the phone like you were presumably supposed to. Android 2.2 (“Froyo”) tried to mitigate this embarrassing hardware decision by allowing you to store apps on the SD card, but since application data was still stored on the system partition this change did little to fix the situation. Visually, Eclair received relatively minor tweaks, Froyo likewise.

home-plain

The Nexus S was released alongside Android 2.3 (“Gingerbread”) and it solved most of the problems that plagued the Nexus One. There was plenty of internal storage. Copy and paste was now unified across the operating system. There was a new, darker and flatter skin that made the experience a bit more elegant but the design felt weirdly half-baked. As a whole, the phone felt snappier, more coherent, and generally more pleasant.

Only, once again there was a problem. The stock Android browser bundled with the Nexus S was optimized for Snapdragon processors, not Hummingbird processors. The Nexus S had the latter, so browsing anything not mobile optimized was slower than it was on the Nexus One. You had to go out of your way to find an alternate (inferior) browser such as “Dolphin”. Not cool.

The Honeycomb Detour

honeycomb

We eventually found out what ailed the Nexus S. Google was busy making a tablet-friendly version of Android, and either didn’t have time to completely optimize the Nexus S, or simply chose to focus on the tablet instead. Matias Duarte, the original designer for WebOS, had been brought in to spearhead a strong visual direction for Android 3.0, “Honeycomb”. At the time, Gingerbread was just about ready to ship, and Honeycomb development was already underway. So the half-baked feeling that came with Gingerbread was due to the furious race toward the tablet.

For the very same reason, Andy Rubin had made the call that Honeycomb would be tablet only. There simply wouldn’t be time to scale the experience down to the phone form factor, that would have to happen in a later release. There was a lot to like about the end result, but arguably more to dislike. Regardless, a strong direction had been laid, and difficult structural decisions were in place.

Goodbye, Menu Button

Cue Android 4.0, “Ice Cream Sandwich”.

home-lg

Like sandwiches are combinations of things, Android 4 was for both phones and tablets. It drastically iterated on the Honeycomb UI. The spacey clock was now minimalist, and the pretty terrible Tron font had been replaced with a custom Helvetica-esque “Roboto” font. Applications, icons, even menu items were given a strong design direction, and the result for apps that used this new “Holo” theme was pretty gorgeous. Ice Cream Sandwich was released with the Samsung Galaxy Nexus, and later rolled out for the Nexus S (complete with a stock browser that was finally optimized for the Hummingbird processor).

Impressively, Ice Cream Sandwich managed to shed some of the legacy shackles that had held back earlier Androids. The Menu button, once a requirement on Android phones, was now frowned upon, and developers were asked not to rely on it. Every menu item would come with an icon and shown directly in the action-bar if there was room (and land in the Action Overflow menu if there wasn’t). The death of the menu button was welcome since the button itself was the epitome of mystery meat navigation. Ironic then, that toolbar items would be icon-only. Still, Ice Cream Sandwich was a huge release with fundamental and difficult changes to Android, necessary for the platform to stay competitive.

Waltz

For every problem Android releases would solve, however, new problems would become apparent. Like a waltz — two steps forward, one step back — Ice Cream Sandwich was no different. While the menu button had been killed, the problems with the back button had become increasingly apparent. I’m not even going to try and explain how the back button works, but here’s a chart:

navigation_between_siblings_market2

It’s not optimal. But it’s certainly fixable. Especially on the Galaxy Nexus, where buttons are software. If killing the back button is on the … menu… then it’s possible. If not, there has to be a way to make its behavior more predictable.

In a similar vein, now that Android is beautiful, it’s becoming increasingly clear how most developers don’t care about optimizing their apps for Android. Most apps aren’t using the new Holo theme (which is legitimately beautiful). There are notable exceptions — Tasks, Foursquare, Pocket — but even first-party apps like Google Listen haven’t been updated to the new 4.0 SDK level. If Google can’t eat their own dog-food, how can they expect developers to?

Jelly Bean

Wednesday is Android 4.1 day and it’ll be interesting to see how Google intends to tackle the problems facing their platform. Perhaps it’s time to mimic Apple and create the “Android Design Awards”, showcasing well-designed Android 4 apps in the market. Might as well give a reason for developers to update the SDK level.

There’s also the problem with timely updates. As it turns out, an operating system running on an ARM processor is fundamentally different from one that runs on, say, an Intel Processor. Where on the latter, you can simply make one OS distribution you can install on every Intel processor out there, ARM operating systems have to be written directly for the specific version of the processor. Which incidentally explains why you won’t be able to install Windows RT (Windows 8 for ARM) yourself. So how can Apple do it? Well they build everything themselves, so they don’t have to target more than one processor.

Still, all of that is just software. Software is written by humans. We tell software what to do. If updates for Android are hard to do because there’s no generic interface for the ARM CPU, then make one. Whatever you do, Google, the big next challenge on your table is making Android easy to update.

Hey Google? One more thing. It would be nice if the Nexus phones you make aren’t so big they don’t fit in my pockets.

Erase and Sync

eraseandsync

I don’t even want to try to explain what’s going on here. I mean, I understand it, but I don’t understand it. I don’t see how it’s in anyones interest for it to be flaming-hoops difficult to sync a device to a new Mac. Seriously, Apple, how did this pass your “it just works” razor?

Icons vs. Text

Aside from petty discussions on whether Google is evil or not, design-wise it’s an exciting time to watch the evolution of their products. Services across the board are being redesigned, some from the ground-up. There are even traces of an emerging consistency between the web-services and the Android operating system.

One trend in particular I’m following with great interest, and that is the move from text-labels to icons. Here’s Gmail:

gmailbuttons

It’s interesting because Google used to be a bastion of usability, and having only icons goes against what I’ve learned on the matter (which is that icon + text label reads best, only text label reads okay, icon only reads the least). So why did Google do this?

Google’s a big company. They’re known for being data-driven. So much, in fact, that they were once criticized for A/B testing shades of blue. Which means unless Larry Page has uprooted every previous principle the company was founded on (which I doubt), I’m pretty sure they’re watching the numbers on this one, and I’d be lying if I said I wasn’t interested in the results on their icon vs. text-label A/B tests. The fact that the icons are still there in Gmail tells me that either the negative impact of icon-only navigation was negligible, or that the decision to go with icons only was forced through despite.

Icon-only navigation can be gorgeous, sure, and well-designed icons or icons based on established metaphors can be really easy to read. The trash-can, for example, is hard to get wrong. But surely some actions can’t easily be translated to icons only? Here’s the Android 4 camera app:

android-camera

In the above screen capture, I’ve opened up the photo configuration pane. From left — the ellipsis means “more settings”, “SCN” is short for “scene”, the plus/minus is “exposure”, the “AW” is “white balance” set to “auto”, and the lightning is “flash mode” set to off. The icons are gorgeous, but some of them don’t read very well. Particulary SCN means they threw in the towel on an icon.

So where did the whole “icons first” trend start? Android, maybe. From the brand new design guide:

Action bar icons are graphic buttons that represent the most important actions people can take within your app. Each one should employ a simple metaphor representing a single concept that most people can grasp at a glance.

You should really head over to the design guide, the icons really are beautiful, and they are a core aspect of Android 4 apps. To put it briefly: Android 4 apps rely heavily on the action-bar. The action-bar is a bar across the top of the operating system. On phones it features an app icon and app name on the left, and as many icon-buttons as there’s room for on the right. If there are more buttons than there’s room for, these buttons go in to the “action overflow” button, which is the small ellipsis. Click the ellipsis and the icons are shown in a dropdown menu by their text-label counterparts. It’s discussed at length on the Android Developers blog.

As beautiful as icons can be, is the lack of text-labels sacrificing usability? Here’s Photoshop Touch for Android:

pstouch-1-600x375

Compare and contrast with desktop Photoshop and the UI is a far cry. Obviously the two apps are no-where near feature parity, but UI-wise the difference is stark. The Android app relies on the clean, uncluttered iconography whereas the desktop app fills the top of system-bar with text-labelled dropdown menus.

I really don’t know what’s best. On the one hand, icons certainly make for a prettier UI. If screen real-estate is at a premium, icons can be smaller than text-labels, and the uniform size can make them easier to fit in a clean grid. Icons need no translation either, which is nice. On the other hand, a text label can say what the button does. Right there. On the button.

Quick thoughts on the new Google-Bar

When Larry Page took over the reins from Eric Schmidt, apparently one of his first decrees was that all of Googles properties were to look prettier. A team of designers came up with the new design, featuring greys, curry reds, whites and a black top-bar which featured sharing options and notifications. Now the black bar is being rid of, in favor of a more minimal Google Bar:

This is what it looks like in my Gmail (by the way, if you haven’t received this bar yet, here’s how you can get it now):

googlebar

Collapsing the black bar certainly gives some much welcome extra room (especially welcome in Maps and Reader). Also, I personally never used the plethora of links that sat right at the top of the page starting from left, so the collapsing of those into a dropdown menu makes some sort of sense.

The new bar is now without weirdness, though. First of all, in the implementation I’ve tried (by using the cookie hack linked earlier), the Google logo dropdown menu invokes on both hover and click. I’m personally a fan of click, since hover always feels slow to me, but it gets weird if you’re used to the Google logo taking you to the homepage. Take Gmail, for example, clicking the Gmail logo (which by the way is gone now), you’d be taken to your inbox. To get to your inbox now, you have to click the left-arrow that sits on top of your email.

It’s also a bit wierd that the Google.com homepage features a different Google-bar:

newgoogle

… it’s obvious when you think about it, of course: you can’t have two colorful logos and two searchboxes competing on the same page. Oh by the way, that black dropdown shown in the screenshot above is not invoked by yours truly, it’s now shown by default when you visit the Google homepage. But at least they killed off the horrific white fade they had a while back.

It’s clear Google is in a state of flux at the moment. Some products are killed off, others are mutilated. At the same time, Google is prettier and more consistent than ever. Here’s hoping the dust settles at some point, and what made Google cool gets reintroduced.

Sync

For years my lunatic Apple friends have asked me: “when are you going to get a Mac?”. When I finally did, they started asking me: “when are you going to get an iPhone?”. As iOS is growing increasingly more useful with good notifications and over-the-air updates, my answer has been trimmed down to when it has a Gmail app that’s as good as the Android one. “Gmail with IMAP works great” is the usual knee-jerk reaction and “what’s so special about the Gmail app?” the followup question. I’m thinking perhaps it’s time I change my stock answer. I think my new response will be: sync.

This morning on my way to work I was listening to Macbreak Weekly. A bunch of my heroes, including John Gruber, were talking about iCloud sync and the problems some of them were experiencing. Tonya had factory reset her iPhone several times trying to get contacts to sync properly. Andy jokingly suggested the merging of contacts was painful and would sometimes merge 17 different versions of the same contact into a lean 12. Chris suggested it was a good idea to make sure you had a backup of the contacts, calendar and email setup you considered “canonical”, before embarking on your iCloud adventure. When the team started talking about the supposed iOS 5 battery drain, iCloud was almost universally assumed responsible for this.

Grubers level-headed approach was that, while he apparently had no problems himself, he did believe Apples iCloud transition was going to be monumentally difficult and compared it to stepping from solid ground on to a boat while carrying valuable trinkets. Transitioning MobileMe customers to a new free setup, making sure not only calendars, email and contacts sync, but also documents, was bound to generate some headaches, but they’ll pass in time, he suggested. I agree, I’m sure things’ll improve once Apple is on the boat.

Perhaps there is something to be said about Apples approach to sync. As much as they tout that “the truth is in the cloud” — as Yogi Berra would say: that’s only true when it’s true. It’s no secret Apple loves native apps. Native apps run faster, smoother, nicer than web-apps. You’ll hear many chant this, they might even use allegories such as “being closer to the metal” when describing why a web-app can never be as good as a native app. Let me tell you this: Yogi Berra doesn’t care. If it works, it works. If the app is good, it’s good. If things sync, things sync. And if they don’t sync properly, they don’t sync properly.

Googles overarching approach to sync is to not sync. Push the changes immediately. When you add a bookmark to your Chrome browser, a teensy signal is immediately sent to Googles bookmark sync server pushing the change. When you finish typing a word in Google Docs, changes are saved. There is no sync, because there are not copies of files anywhere. There is only one file. There is only one email. There is only one contact. You’ll never have to worry about whether your Android phone, tablet, or Macbook has the most recently edited version of your document, or which one has the most complete contact, or which calendar you added an event to. Because everything is always in sync. It just works.

You’d think it would get muddy if you scratched the surface and peeked underneath. If you do, you’ll find that Android sync is actually asynchronous, and that if you use Google Docs’ offline editing capabilities, you’ll actually end up with some of the same sync challenges that Apple is facing: which version is the right version? Somehow I’ve never once had a problem with this, though. I don’t know if it’s because Google started with the web-apps and built native apps and offline sync at a later time, but I have no trust issues with Google getting my sync right. I know that if I visit google.com/contacts and edit a contact, my changes will propogate to all my devices seamlessly. I never have to worry about losing contacts, losing appointments, losing emails, getting corrupt data, or even backing up. While these words may smell like famous last words, I wouldn’t even think of backing things up. I expect it to work, I trust that it will work, and has done so far.

Compared to the flaming hoops I had to jump through to get just calendars, contacts and Gmail to sync on my wifes iPhone, using an Android device is just a relief.

The Assassination of Google Reader by the Coward Google+

reader

I’m pretty excited about the visual shakeup that’s going on at Google these days. Gmail and Calendar are prettier than ever, and it looks like there’s even some cues that align with Android now. Google Reader was one of the last properties to get the overhaul, and I was rather nervous about the announced Google+ integration.

I was totally unprepared for the scorched earth tactic Google employed, though. It appears that Google, after applying the new look, systematically uprooted every pretty little flower that made Reader what it was. Google then ground up all the flowers into mulch, burned the mulch, and salted the ground.

What made Reader so great? The social stuff. For every feed item you could click “Share”, and other Reader users who followed you would then get a customized RSS feed with your shares. You could even add a small comment to the top of the shared feed item. This spurned quite a lot of discussion, some of which I’ve archived here. From a “simplify your product line, focus on fewer products”, I completely understand why Google did this. Google+ already supports sharing and commenting, so why not share directly to Google+ instead of to a dedicated RSS feed? Unfortunately, that’s whiteboard philosophy at its best, and it betrays a fundamental lack of understanding of why Readers social ecosystem worked so well. Ironic, because Google+ is Googles social initiative. It’s really quite embarrasing.

I started writing a long blog post about how Google could fix reader and keep the Google+ integration. I thought long and hard about solutions to every problem introduced by the massacre. In the end, the frankenbuild that would have resulted from my advice would have been terrible. I even  went in to detail as to what exactly was massacred, but most of what I had to say has already been said elsewhere.

There’s a saying: if it ain’t broke, don’t fix it. Let me be clear, I loathe that saying. It’s shortsigthed, backwards and reactionary. It stands in the way of progress, and indicates the previous iteration of whatever is being referred to, “ain’t broke”. Let me tell you a secret it took me half a lifetime to learn: nothing is ever perfect, and everything can be improved upon. The notion of “perfect” is silly and highly philosophical. Reader wasn’t  perfect by any stretch of the imagination. Finding people to follow was a ridiculous hassle, and advertising the fact that you were sharing on Reader was nigh impossible. But once you did follow someone in Reader, once you did start sharing and commenting on shared feed items, the experience was easy to follow, highly intimate and very enjoyable.

What remains is a good feed-reader, but everything social about it has been scrubbed. Good feed-readers are a dime a dozen, and the sharing features while really well-implemented, are not that hard to copy. It is not unlikely that someone will eat the lunch Google left on the table here. Perhaps Google is fine with that. Or perhaps they’ll listen to sense:

Dear Google,

Reader is about reading RSS feeds, so please make shared items show up in an RSS feed again. +1 buttons are fine, but “Share” and “Note” should append to your shared feed and nothing else. Google+ is also a fine way to advertise that you’re curating an RSS feed. A theoretical integration with the circles might even make sense. But keep discussions, feed items and shares in Reader — where it belongs.

Google Chrome, Metro-Style

Windows 8 is a pretty bold new move for Microsoft. It’s bright, vivid, touch friendly and puts apps and contents way up top. It appears to have ditched the traditional desktop metaphor and filesystem. Apps look very different. Here’s what Internet Explorer 10 looks like:

IE10

That new look and feel for apps is being referred to as “Metro-style”. Metro-style apps run fullscreen and navigation happens through edge-activated interfaces. While I’m concerned about discoverability for edge-activated interface controls (essentially this is classic mystery meat navigation), I do like that apps are full-screen and that Metro-style apps ditch all archaic notions of UI chrome.

Which brings me to Google Chrome, capital C. Really great browser, my such of choice. From a high-level perspective, Google built this browser to accelerate the pace of web technology development, so that Googles own web-apps — Gmail, Calendar, Docs — could adopt newer features sooner. To that end, Google has gone to great lengths to make sure Chrome is not only cross-platform (Windows, Mac, Linux, soon Android), but that Chrome looks native to each platform. This tenet has been taken to the extreme, actually, with Chrome on Windows XP featuring the horrible “Luna” skin, and Chrome on Linux more or less establishing GTK as the de-facto UI toolkit on the platform, just to be able to use said toolkit. It’s really quite impressive, the amount of work put into making Chrome not only look native, but be native.

Of course we’re only on the cusp of the future. The next round of operating systems are likely to be much more mobile inspired. Windows is blazing a trail with adopting the Windows Phone Metro UI, OSX is likely to become even more iOS-like, and Ubuntu is already exploring more touch-friendly UIs. If Google is going to keep following the path of full-on nativity, Chrome engineers are going to be having some nasty headaches in the not too distant future. Is it even technically possible to replace Internet Explorer 10 as your browser of choice? With Windows 8 treating HTML5 web-apps as first-class citizens among native apps, it’s likely that IE is baked in to the operating system more deeply than it ever was before.

It’s also an interesting mind-game, imagining what Google Chrome would look like, if it were to theoretically be re-written as a Metro-style Windows 8 app. The Metro-style UI is already so minimalist in layout, icon style and even interaction patterns that it’s difficult to think of Metro-style Chrome looking very much different from IE10. The racing-car diagonal tabs for instance, which are important to Chrome’s branding, are hard to translate to Metro-style. Though I suppose if Google were to go this way, they could make their tabs look similar to those of the Android Honeycomb browser (which is likely to spell the direction of how Chrome will look like on Android, once that happens).

Will it happen? I think so, but I think Google will want to play the wait-and-see game for a while. Just like Android Ice Cream Sandwich may be a make-or-break proposition for Google, so do I think that Windows 8 is for Microsoft. Could be that Windows 8 adoption is too slow to worry about. Could be Google’s already working on Metro-style Chrome.

Whither Web-Apps

icloud_hero

The web changed things. It’s dictated the path of Android, iOS and Chrome OS. All three are operating systems that approach menial computer tasks in an entirely different way:

  • they store things in the cloud
  • they hide the filesystem from you
  • they’ve shed the shackles of the traditional desktop and windowing metaphor

We no longer have to discuss whether it was actually Xerox PARC that invented the “Recycle Bin” concept, we can instead discuss whether we even need one1. It’s exciting. A computer no longer has to have a floppy or a disc drive. In fact, often times you don’t even need a keyboard. In the future, we might not need a physical interface at all, controlling everything with voice and gestures. It’s as if the new way has uprooted us from the rut of putting application links in a dock and discussing whether the window close button should be in the top left or the top right corner. Everything is different, and we can thank Apple first and Google second, for finally bringing us this much needed paradigm shift. In one key area of this exciting new future, however, Google and Apple differ in their approaches.

Continue reading

  1. The answer is yes, but not for files. Could be for closed tabs, or it could hold an “Undo” history perhaps. []

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.

On native UI

Google rolled out password sync today! Wohoo! They also rolled out a new options page with styled select boxes and push buttons:

chrome_ui_widgets

Looks nice, doesn’t it?

Still, the styling of UI widgets seem to represents a shift in how Google does things. For the longest time, Google has been accused of doing “non-design” — their approach to design being extremely minimalist with little or no styling and whitespace as long as the eye can see. I believe this trend traced way back to the time when Google swayed us from using AltaVista and MetaCrawler; it was the really fast, no-frills search engine that got us the result faster than any of the other search engines.

chrome_passwords

I have been a fierce proponent of keeping UI widgets unstyled. I’ve always tried to adhere to the usability studies done by Jakob Nielsen which suggest that the less UI you have to learn, the better; that if you let your buttons, select-boxes and radio groups stay the way their operating system made them, users will know natively what to expect. But something has changed. I feel it in the water.

The nativity argument was a good one, so what ruined it? Could it be the plethora of nasty advertisements that look like alertboxes? Could it be a new digital age where computers are appliances and moms no longer fear them blowing up when they turn them on? Maybe, simply there are so many apps that only the good ones — the well-designed ones — float to the top? Perhaps Jakob Nielsen was wrong all the time — is it enough that a button looks like a button, for people to confident in what happens when pressing it?

Nah, it’s still good advice. I’ll still take a native app over a non-native one any day of the week, and I still think that unless you know what you’re doing, you shouldn’t style your widgets. As clear as it is that things are no longer like they used to be — lickable buttons be darned — you can’t go wrong with common UI. This is Unix! I know this!