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.

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!

Android 3.0 SDK preview reveals flat UI goodness

Google has released a preview for the Android 3 SDK, and it’s choc-full of UI goodness, including:

android3_mail

What’s so special about Android mail? Well it’s one of the plain apps, an app that is likely to be used the most on Android devices, and it’s got to be designed to just work, and from that perspective, this is one gorgeous piece of UI design. It’s deliciously almost flat, a design trend I expect to see explode like Apples noisy backgrounds. It’s got very few lines, and it’s got a delicious color palette. Dark blacks contrasting gray and white with a splash of accent color — Matias Duarte clearly gets contrast. It’ll look gorgeous on an OLED screen.

Which brings me to the System Bar — that line at the bottom which holds soft buttons for back, home and multitask, the notification bar, a clock, and battery info.

Wait, always present?

According to the SDK preview, yes.

But isn’t that a waste of precious pixels?

Depends on your point of view. The thing doesn’t use more than 48 pixels, and so it’s probably not a coincidence that these screenshots betray a device that’s 1280×800 px in resolution. That’s HD (1280×720) + 80 pixels. So this particular Android device will be able to play an HD video that’s almost perfectly vertically centered, while still permanently having a system bar present. Combine that with an OLED screen which uses the least power displaying the color black, and I approve.

Notes on Androids new Honeycomb UI

It’s CES time, which means a plethora of new slightly improved gadgets to hold us over until the next time we get slightly improved gadgets. For fans of Android and fans of UI design, Google dropped a bundle of joy in this video introduction to Android 3.0 “Honeycomb”. Here are screencaps and anecdotal commantary.

android3_visuals

This must be Matias Duarte’s art style. Or perhaps the movie Tron Legacy designed the new Android?

tron_legacy_poster

No matter, I loved Tron Legacy (please go watch it so I can get a sequel!), I’ll learn to love this as well.

android3_lockscreen

Nice lock screen. It’s still “something you drag from A to B”, but it’s probably not something Apple’s patented this time. Also, there’s a good chance this won’t unlock in your pocket (if you could fit a 10 inch tablet in your pocket, that is). That font though… It’s very 1993. The wallpaper is very 2001 though, which is actually not bad, just very techno.

android3_homescreen

New homescreen still shows select app shortcuts and widgets. So that’s classic Android with a new coat of paint and a nice new ubiquitous app launcher button (so you can launch a new app without going to the homescreen first).

The three buttons in the bottom left reveal potential awesomeness. We’ve been told (at one point) that Android tablets won’t have any facing physical buttons — no permanent context buttons — which in itself is a step forward. But these buttons, to me, look like “back”, “home” and “switch between apps”. Which, if true, spells the not-soon-enough death of the infamous “menu” button. Why is this good? It means that lazy Android app authors can no longer hide settings and help links in a mystery-meat hidden context menu. If they want their apps to be tablet compatible, that is.

android3_chromebrowser

Hey, that almost looks like Google Chrome, doesn’t it? Does that mean improved speed, standards support, bookmark sync, tabs and extensions? Oh my. I can see myself wanting one of these tablets now.

Overall, this looks really nice. Some of it is a bit off, but the sharp diagonals and mostly flat colors aesthetic seems to land in a good place between the delicous but spartan Windows Phone 7 UI and the overly textured and glossy iOS UI. It’s got some growing to do, but this a good place to grow from. The best thing: this UI feels like a serious jab at skin vendors like HTC and Motorola. People are going to want this UI, not “Sense” or “Blur”.

Firefox 4 gets custom alertboxes

Look, Firefox 4 is getting custom UI for JavaScript alert boxes:

ff4_alerts

My first impression is that while that’s pretty, it seems to be pretty for the sake of pretty. My gut feeling is, however, that with the XUL-based interface Firefox has, they need to make custom UI if they want to make JavaScript alerts tab-modal — and why wouldn’t they? So they might as well run with it. Tab-modal, if that is in fact what they’re doing: thumbs up. Pretty for the sake of pretty: mullet.

On Apples new OSX interface ideas

Fullscreen.

osx_fullscreen

It’s about as near a maximize feature — something I’ve been clamoring for for years — as you’re going to get.

Some thoughts on that, and Apples other OSX news.

Stoplight Consistency

stoplight

Apples stoplight window management controls, the red, yellow and green buttons at the top left of OSX windows, have long been a cause of headache for me. The problem I’ve always found, is consistency and predictability.

At first glance, red yellow and green means “stop, wait, go”. When you hover over the buttons, however, you’re shown x, - and + symbols. Classicy mystery meat navigation. Fine.

When you click the red button, you close the window. Fair enough, even though you don’t actually close the app. It takes some getting used to. Also fine.

When you close the yellow button, you minimize. Very good.

When you close the green button. Well, it’s anyones guess. Firefox will scale the window to fit the available space on your screen; Chrome will toggle the height of your window. This is the bad one, this is the one that needs changing. Which is why the next OSX should own the green button and let it invoke fullscreen for every app there is.

Launchpadosx_launchpad

 

Apple introduced a launchpad which shows all your apps in an icon grid view similar to your iPhone device. That’s nice, especially in concert with the new App Store. It’s a bold new step in Apples vison of ridding the world of the file-system. In fact, apps may be the final frontier, as installing, managing and uninstalling apps cleanly and easily has been the bane of operating systems for decades. As such, it’s not the launcher interface itself that interests me — that could really have been anything and a grid of icons is not supremely original per se — but the fact that adding, managing, removing and launching apps is now done in a completely new and easier way is going to be something new Mac users are going to love. That’s nice.

Mission Control

This’ll be interesting.

osx_mission_control

The love-child of Exposé — the thing that explodes all your open apps on to the screen to help you select — has hooked up with fullscreen and Spaces, the arguably orphaned multi-desktop environment. The resulting ménage à trois is one where each fullscreen app gets its own “screen”. When you invoke “Mission Control”, you’re able to switch between screens — one screen for your oldschool stoplight windows, one for each fullscren app you have.

It really doesn’t look so intuitive. Frankly it looks confusing.

But that’s okay, because for most users, when you maximize an app — iPhone style — you get to another app by minimizing. And that’ll still work (I assume). Mission Control is for those willing to learn how to use it. It’s a window management feature for not-casual users, and those users are going to love it.

Next Project: Kill The Menu

One of the reasons I’ve clamored for fullscreen all these years, is so that screen edges can be used. You know, when you drag the mouse to the top, bottom or sides of your screen? Yup, that’s real easy because when you hit the edge, you can’t go any further — when you’re at the edge, you need only worry about moving in one direction, horisontally or vertically.

Which makes me excited for a fullscreen Chrome browser. Tabs can now work in Chrome as they’re supposed to — sit right at the top for extremely fast access. I betting Safari is going to try tabs on top again.

Long time OSX apologists have been pointing to the fact that OSX does in fact utilize screen edges. The top of the screen is reserved for the ubiquitous “file menu”. The only problem is, file menus are oldschool. They’re boring. They’re there because no-one had a good idea how to tuck in lots of features in very little space.

Be honest. When was the last time you used the Edit menu? Just now, for copy pasting? Oh, alright. How did you do that on your phone? You long-pressed? Right. Because that’s the new way of doing things.

That’s your assignment for your next OS, Apple. Rid us of the file menu. It’s okay to do it in a Snow Leopard-esque maintenance release to Lion. You could call it Liger.