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!

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.

Gawker failed to kill the scrollbar

Gawkers 2.0.1 redesign:

We had mistakenly thought mouse scrolling (via scrollwheels or trackpads) and keyboard shortcuts were enough for story navigation—an overly optimistic expectation to say the least. News web sites may indeed become more application-like and readers may grow accustomed to swiping instead of scrolling. But they’re not there yet, as the extensive criticism of the sidebar made clear.

Back when the now almost universally panned redesign was first unveiled, the usual posse and myself had a discussion on Gawkers rather non-traditional new layout. The scrollbar is a good first step, but the real challenge for Gawker will be to get their fancy AJAX layout to load in a reasonable, fast, predictable way and ensuring the back button works properly.

The impending demise of the URL

TechCrunch writes that Google is in the process of killing the URL bar from its Chrome browser. To be fair, this is not recent news. Google has been exploring various UI configurations to its Chrome browser for for most of the last year, and the information looks to have come from the Window UI page from the Chromium documentation project.

It’s also worth noting that the proposed UI change appears to have found its way to the Android Honeycomb browser:

chrome_browser_full

Either way, the direction for Chrome is interesting, and for a number of reasons, it makes sense.

Apple has demonstrated that there’s a great economy in apps, but “app” is an increasingly diffuse term, considering you can create quite complex create apps in HTML and a number of new non-platform-native technologies.

If Google can change the public understanding from an app being something you download and install to rather being a place you visit, the change can help inventorize the web. The result could be easier to make discoverable to users but most importantly, it could be monetized. On the old web, you’d visit The New York Times and throw up in your mouth at the paywall. On the new web, you’d visit The New York Times and get all the free content, but have an option to buy a premium web-app which stores your access credentials while it serves as a bookmark.

The URL bar is the commandline, and like iOS doesn’t need a commandline for you to launch Angry Birds, Chrome doesn’t need a URL bar for you to launch Facebook.

fingerfriendly_apps

A few weeks ago, I created a Chrome web-app to see how the Chrome web-store works. That app has now been installed a couple of hundred times a week, even though the app is merely a glorified bookmark for a Google service. If we can learn anything from this, it is that pointing at a large fingerfriendly icon on your new tab page is quicker than typing in a URL or clicking a small navigation bar bookmark.

But what about search? Search is the core of Googles business, and Google won’t revamp a proven UI without good reasons. While putting apps front and center makes a lot of sense, there’s a UI challenge in having both search and apps front and center.

A few weeks ago, I wrote about Internet Explorer 9s new UI which disconnects the URL bar from the tab:

But with the emergence of Chrome Web-Apps, which are just around the corner, there’s a new, albeit not super strong, argument for disconnecting the addressbar from the tab, and that is that it’s still, despite web-apps, a place people use to launch new webpages. In the case of the omnibar, it’s also where people start searching. In Chrome Web-Apps […], the omnibar is hidden when you’re inside, say, the Google Maps web-app. How do you launch a new page or search? You have to click “new tab” in order to get the omnibar back.

The solution could be putting the omnibar on the new tab page. Clicking “new tab” would then set text focus on the search field:

google_new_new_new_tab_page

It’ll be interesting to see where Google goes with this.