Scrollbars

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.

Next for Chrome OS

Remember Chrome OS? No? That’s okay. It’s Googles Chrome-browser with a stub of Linux underneath it, making the browser the operating system. I believe in this thing, not for myself, but for my mom; the ability to hold a couple of buttons while it’s booting to format the entire system and reinstall it from the cloud, keeping all personal files intact, is pretty much the perfect mom computer. Still, Chrome OS and “Chromebooks” never really took off. Now Google’s trying to take it to the next step, which apparently means a window manager:

While there’s some interesting UI going on, particularly with the semi-fullscreen-split-view and the ultra-minimal taskbar, I can’t help but feel like they could’ve done something really interesting with this. I don’t think the desktop has a future.

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”.