Design – Quoderat

Web unusability

David Megginson — Wed, 02 Sep 2015 11:23:42 +0000

When might a company decide that web usability is a bad thing?

If I were a conspiracy theorist, I’d suggest that companies deliberately sabotage forms for tasks like refund requests, to discourage user conversion. Practically speaking, however, I think it’s more a matter of just not bothering to invest in them past the alpha stage. Consider FedEx Canada’s refund form:

https://www.fedex.com/ca_english/services/moneyback-claimform.html

Every field on this form is required, even though many of them won’t apply (e.g. you might not have your own invoice number associated with the shipment, and you almost certainly won’t have a fax number), and some are actually contradictory (you will have either a FedEx Express Air waybill number or a FedEx Ground Tracking ID, but not both).

On a higher level, nothing in the form makes it clear whether you’re filling in your address or the address to which you were sending the package. Flip a coin!

Fortunately, the form also doesn’t bother with data-type validation, so I was able to put “n/a” in all the fields that didn’t apply (1995 called and took away my fax machine), and I was able to guess that they wanted my address, based on the presence of a picklist for Canadian provinces.

If you’re an enterprising soul, you might consider setting up shop as a Web Unusability consultant, to help companies find ways to keep customers from filling out unwelcome forms.

Breadcrumbs: yes or no?

David Megginson — Sat, 23 Aug 2014 17:00:15 +0000

In web design, Breadcrumbs are those little navigational links you see across the top of some web pages, like

Home → Canada → Ontario → Ottawa

Media»Music»Classical»Beethoven

Good idea?

Breadcrumbs let you can see where you are in a web site’s information hierarchy, and let click to climb up to a more-abstract level. As of 2014-06-13, I use geographical breadcrumbs on OurAirports to let users climb up from looking at a specific airport to looking at the list of all airports in an administrative subdivision (e.g. province/state/governorate), country, or continent. I have haven’t changed the site design by the time you’re reading this article, you can try it out for Cairo International Airport.

I like breadcrumbs, because they reflect the way I think. I tend to organise information hierarchically, like a librarian, and breadcrumbs let me find my way around an e-commerce site (for example) without wasting time on frustrating searches. The article “Breadcrumb Navigation Examined: Best Practices & Examples” goes into great detail on different types of breadcrumbs and their benefits.

Bad idea?

While I love breadcrumbs, I notice that not many people use them on OurAirports. People almost never click up to see all airports in the same province or country; they really just want to look at a specific airport. Are my breadcrumbs just wasting screen space?

Back in 2008, Jared M. Spool posted an article “Design Cop-out #2: Breadcrumbs” suggesting that breadcrumbs represent a design failure:

The biggest problem is the lack of scent for the other areas of the site. If a user is in need of breadcrumbs because they are in the wrong part of the information tree, what they need most is good scent to the right part of the tree. However, the breadcrumbs only communicate the branch they’re on — not the branch they need to be on.

In 2011, Shanshan Ma wrote in “10 Ways Mobile Sites Are Different from Desktop Web Sites” that even if breadcrumbs belong on desktop web sites, they don’t belong on mobile ones:

However, breadcrumbs rarely appear on mobiles sites, and there is usually no necessity for them. Limited space is one reason breadcrumbs are uncommon on mobile sites. But the main factor is that the design of mobile sites prevents users from having to go too deep into a hierarchy to find what they are looking for.

What do you think?

Do breadcrumbs perform an important function in modern web design, or are they just a crutch for bad design?

It’s never the end of history

David Megginson — Sat, 23 Aug 2014 16:46:48 +0000

Link: http://alistapart.com/article/fluidgrids/

Ten years ago, circa 2004, it felt like the web had found its rut and would never get out: XML and XHTML had failed to fix the browser-incompatibility mess, the horrid Internet Explorer had achieved almost total browser-market dominance, and web designers were focussing on animated pre-rolls and big screens. Even in 2009, when the rise of mobile was impossible to ignore, Ethan Marcotte still sounded like an Isaiah shouting from the wilderness when he pleaded with us to think differently:

Instead of exploring the benefits of flexible web design, we rely on a little white lie: “minimum screen resolution.” These three words contain a powerful magic, under the cover of which we churn out fixed-width layout after fixed-width layout, perhaps revisiting a design every few years to “bump up” the width once it’s judged safe enough to do so. “Minimum screen resolution” lets us design for a contrived subset of users who see our design as god and Photoshop intended.

It turns out that we weren’t at the end of web history, but just finishing the first act. After a decade-long intermission of stagnation, things started changing even faster than they had in the optimistic early days of the mid 1990s. IE has become so irrelevant that it’s barely necessary to test against it any more (unless your audience is big industry or government office workers using obsolescent desktop computers), HTML5 and CSS3 have exploded, the Javascript ecosystem has matured, the majority of page views happen on small-screen mobile devices, and those devices ensure that most users always have the latest version of their browsers (a vain hope in 2004 or 2009).

Five years after Marcotte’s article, any so-called web designer proposing to work with a fixed “minimum screen resolution” would … and should … be fired.

Except maybe in government and big industry.

Mobile web app or web site?

David Megginson — Mon, 17 Mar 2014 14:15:46 +0000

If you’re creating an HTML5 mobile web application, this is the minimum you need to give your users what Google calls a “homescreen launch experience” on an iOS or Android mobile device:



 
  Awesome app

The “shortcut icon” link element is pretty straight-forward: it simply provides a pretty, app-style icon to save to the iOS homescreen or Android launcher. The “mobile-web-app-capable” meta element, on the other hand, strikes right to the core of what you’re doing: are you creating a web app, or a web site?

I’m a web app

Here’s what Chrome for Android gives me if I save a web app to the homescreen (launcher), then tap on that icon:

The app gets its own entry in the task switcher.
All the browser chrome is hidden, and there’s no way to add a new tab, create a bookmark, change options, etc.
If the user chooses a link outside my domain, Chrome will animate a normal browser launching, to warn me that I’m outside the app.

I’m a web site

If I don’t include “mobile-web-app-capable,” then Chrome for Android will still let me create an icon on the homescreen, but when I tap on it, I’ll see my regular browser launch, with all its chrome, tabs, bookmarking, etc.

So which am I?

A web app is a loner. It has several advantages over a native mobile app (cross-OS/-device compatibility, avoiding app-store bottlenecks and censorship, more-flexible security model, linkable, etc.) and several disadvantages (can’t handle an Android Intent, weaker notification support), but its plan is clearly to stand on its own, like a native mobile app. A web app is designed around actions: with a clever combination of HTML5, CSS, JavaScript, and newer stuff like AppCache and LocalStore, you could create (e.g.) a Twitter web app that was very similar to the Twitter native app (important caveats). The web app designer doesn’t want her app open in one browser tab with a different site open in another, while the user switches back and forth. Online video games, interactive edit/design tools, and anything that is supposed to feel a bit like a MacOS or Windows program installed from a CD-ROM 15 years ago is likely an app.

A web site is a social creature. It’s orthogonal to a native mobile app, because it inhabits a different universe. A web site is RESTful, designed around pages (more generally, “resources”), most of which contain either information a user wants to see with links for navigating to related information, or a means to create/change/delete that information (there’s also typically a search feature). Unlike web apps, web sites embrace the browser chrome, which provides an important part of the user experience: because the browser allows a user to search for text within a page or bookmark any page, the web site itself doesn’t have to provide that support; similarly, the browser lets a user open multiple views into the same site using different tabs by default (so that a user can view two pages at the same time), while an app treated as an app has to have that support built in. Wikipedia, blogs, tutorials, newspapers and magazines, most online discussion forums, and my own OurAirports are all examples of things that are most naturally web sites.

Last thoughts

I’m starting the process of making OurAirports responsive and otherwise mobile-friendly, and one of the first things I tried was adding “mobile-web-app-capable” and then saving the icon to my Android desktop. It worked exactly as advertised — it was cool having the site open up as if it were a phone app, appear in the task switcher, etc., but it took me only minutes to realise that I’d crippled it: a user launching OurAirports that way could no longer bookmark a specific airport page to come back to it later; could no longer open two airports in different tabs; and could no longer search for text in a long comment stream. I removed it and let the browser chrome come back, because really, that browser chrome is a lot of what makes a web site useful.

So when you’re designing your next web thingy, ask yourself a few questions:

Is it valuable for users to be able to search for text within a page, bookmark pages, and open multiple tabs (site)?
Is it mainly about manipulating an external resource, such as a picture or diagram (app)?
Does it have lots of pages with relatively stable URLs (site)?
Can it potentially provide a reasonably-complete offline experience using only a small number of files containing markup, code, and data (app)?
Is it designed as part of a bigger web, linking out and receiving inbound links (site)?
Would browser chrome distract rather than help the user (app)?
Is it something that Google should index and make searchable (site)?

Over the past few years, I think, too many people have been taking things that are more-naturally sites (e.g. newspapers) and trying to force them to behave like apps by forcing in AJAX, hashbang URL syntax, etc.: the result is typically impressive and flashy, but a crappy user experience. On the other hand, the greatest advance in the Web over the past ~10 years has been its growing ability to support activities like creating spreadsheets or editing photos that really don’t fit the REST/web-site model. So by all means, if you have an app, let it be an app, but don’t try to force everything into app world; REST is still the web’s heartbeat.

Link: Transitioning To a Mobile Centric World (Bill Gurley)

David Megginson — Fri, 19 Jul 2013 07:18:00 +0000

http://abovethecrowd.com/2013/07/17/transitioning-to-a-mobile-centric-world/

This article argues that the verdict is in, and users want apps, not mobile web sites. My friend and colleague Michael Roberts (who, I suspect, is neutral in the debate) shared this link on Google+, and – as if to prove Mr Gurley’s thesis – I read his posting in the Android G+ app, not the mobile site.

Here is the comment I left:

Interesting piece – thanks, Michael . He’s absolutely right that people prefer apps to the browser for common tasks, but I don’t think he’s got the whole story. For example, like most people, I currently read G+, Facebook, and Twitter in the dedicated mobile apps rather than in the browser. However, a large plurality (if not majority) of interesting posts to those services are actually links back out into the web, so the result of of reading a tweet is generally opening not a dedicated app, but a web site.

Case in point – we’re both reacting to a pro-app/anti-browser article, but the only reason we know about it is that you were able to share a web link in your G+ post. If Mr. Gurley had created a “GurleyPosts” app for his thoughts, then (a) most people probably wouldn’t have it installed, and (b) you wouldn’t have been able to pass a link from iOS that I could use to read it on Android.

In other words, for something I do a lot (read Facebook, check the weather, play a game, get driving directions) I will tend to use an app. But I won’t install a dedicated app just to read an article from a magazine or newspaper, and even when I am using an app, I need a link if I’m going to share it with anyone else.

So in 2013 for mobile, apps are for the tall head of any user’s activities, and the browser is for the long tail. Of course, every startup thinks it’s going to be the next Facebook (at least in terms of its importance to the people who use it), but few of them end up there, so the way people are going to find them is by following links from FB, Twitter, Google+, emails, chats, etc. I wouldn’t give up on that mobile web site quite yet.

Is fluid layout old-fashioned?

David Megginson — Wed, 09 Feb 2011 17:04:56 +0000

No one would mistake me for a graphic designer — I believe that no merely visual design can match the breathtaking beauty of a properly-normalized database schema — but still, I recently found myself helping someone design a simple theme for a Drupal web site.

The site owner was visually-focussed (poor woman, stuck with me as designer!), and had very specific ideas about where layout items and whitespace should go, so I decided that while I have issues with fixed-width layouts like the [in]famous 960 grid, I shouldn’t make her suffer for my beliefs: I designed a fixed-width, em-based layout for her.

Two weeks later, she got in touch and said “I’m really sorry, but …”. She had been looking at the web site on a laptop up to that point, but the first time she opened it on her big monitor at work, it looked like garbage, a tiny strip surrounded by huge bands of whitespace.

Window size: an obsolete problem?

I mention this story because I just read a web page that suggests that fluid layouts — web-page layouts that adjust themselves to fit the width of the browser window — are passé:

With the advancement in displays and the cheap prices of large 22″ and 24″ displays fluid layouts have quickly become more a hinderance than a help because you don’t run your browser full screen anymore. You generally run your browser alongside your mail client, your IM client, iTunes, etc. You find a common size for your browser that accommodates most sites, and you leave it at that width.

Well, apparently not. At least, not in this case. The argument seems to be that users will conform to the needs of designers, by carefully resizing their browser windows to make the designs look good, but the web site owner I’m working with wasn’t one of those people, and I suspect that not all her visitors will be, either.

Rogues’ gallery

The designer of the web site proclaiming the demise of fluid layout probably hoped his or her site would look like this:

This is what you’d see on a typical laptop screen, or on a window sized smaller on a big screen. It’s beautiful — I freely admit that I could never design such a nice-looking web site.

Now, here’s how the same site would look in a large browser window on a large monitor:

OK, even I (and probably my guinea pig) can design something nicer-looking than that. Damn those uncooperative users! Why do they forget to size their browser windows properly?

Now, let’s go down-market, and see how the same site might look in a browser window on a tiny netbook (where the user doesn’t have the option of choosing a bigger window size):

Not nearly as bad as the big screen, but awkward — I can sort-of see what the designer was trying to do, but I have to scroll around to get the whole effect: it’s like looking at the Mona Lisa in 5 cm² segments.

Fluid vs fixed-width is a trade-off

I’m not going to conclude by saying “fixed-width bad, fluid layout good”, or any such oversimplification, but instead, to suggest that the tradeoff that existed between the two ten years ago still exists today:

If you want a web site that’s a respectable B- in a wide range of screen sizes, use a fluid layout (it’s not an accident that that’s what popular sites like Google use).
If you want a web site that’s a spectacular A+ in one screen size, and a dismal D- in all others, use a fixed-width layout.

If you need to demonstrate that you are capable of stunning visual beauty, if you know that most of your users will be viewing the site on a certain type of device, or if you just want to stoke your ego by winning design awards (and you know the resolution the selection jury will be using to view sites), then fixed-width can be a great choice. For me, however, usability trumps style, so I’ll stick with fluid-width when I can.

And yes, for the record, you’re reading this blog (as of 2011-02-09) in a fixed-width layout. I just use the default theme on wordpress.com with a custom picture in the banner, because I’m not really all that visually-focussed. Maybe some day I’ll get around to seeing if I choose a WordPress theme with a fluid layout here, too.

The past, future, and present of mobile apps

David Megginson — Sun, 16 May 2010 22:35:33 +0000

Now that I’ve had a few weeks to play with my Nexus One, I’m starting to grok the gut-level experience of living with a smart phone. I understand why people download apps, how it feels to have the Internet with me everywhere, and what it’s like to experience the web by touch on a screen that’s only a few centimetres square.

Past

Device-specific apps are sweet and shiny at first, but after a couple of weeks, it becomes obvious that many of them are the encore of the floppy-based PC shareware world of the 1980s and early 1990s (SEND $5 TO GET RID OF THE ANNOYING ADS! ONLY $10 FOR THE FULL VERSION!).

Discovering an interesting app through Apple’s or Android’s market (or taking a picture of a barcode on your computer screen) is surprisingly awkward compared to just following a link from one web site to another, and as we’ve learned from the postal service, the telegraph, the telephone, email, and the web, connectivity always wins in the end.

Future

Web apps run everywhere and connect to each-other seamlessly, and HTML5 allows a well-written web app to do almost everything a closed, device-specific app can do on a smart phone — many of the mobile web sites I’ve used (hello, Google!) are as good as or better than the corresponding device-specific apps. There are some things, though, that make mobile web apps stand apart:

The built-in buttons on your smartphone are tied to the browser, not to the app, so the Android menu or search button (for example) brings up a browser menu or search box, not an app one.
For good security reasons, a web app will probably never have as much access to the filesystem and device hardware as a closed device-specific app (do you want a malicious web app to be able to turn on your video camera when you’re browsing in bed? do you ever consider that when you give a downloaded app access to your camera?).
While HTML5 supports notifications, you have to actually be on the web page to receive them. That can be fixed by allowing the browser to launch web pages automatically on start/restart, but it’s still more awkward than an autostart app.
Web app processes need to be managed from inside the browser, not from a device-wide process manager.
As far as I know, there’s no way for a web app to install its own icon on the device home screen — the user has to install it manually (though it’s pretty easy).

I don’t consider most of these to be a big deal, but they do point to the fact that no matter how much extra functionality HTML5 provides, web apps have a different world view: they’re nodes in a huge network, not standalone silos.

Present

I’ll probably have to continue to use a device-specific app for anything related to playing music or capturing photos/video for a while longer, and I’ll hang onto the Android WiFi analyzer I’m running on my phone. Android has a lot of the same apps that show up in iPhone commercials (like Urban Spoon), but while they’re pretty, they’re limited in the end — there’s way more out there on the web than there will ever be an an app store.

If you’re an person or organization that wants to interact with people on mobile devices, you have two choices:

You can develop and maintain separate apps for iPhone, Android, Blackberry, Palm, and any other smart-phone OS’s that may come along, and let the phone vendors be gatekeepers between you and your users.
You can run a single mobile web app on your own server, one that’s only a click away from any other web site that links to it.

The first option lets you force an icon onto the users desktop, but the direct development costs and opportunity costs of losing inbound links and search-engine love just seem too high.

A farewell to tabs

David Megginson — Wed, 05 Aug 2009 12:32:12 +0000

I’ve used tabbed layouts in web sites for a while without thinking much about it. I find them less obtrusive than menus, and have always believed that the idiom was familiar to nearly all users because of desktop applications. Here’s an example of the tabbed interface at OurAirports as of 5 August, 2009:

The “Airport” tab has bold text, and a white background that runs smoothly into the rest of the page, while the other tabs have a light-blue background, blue text, and a line at the bottom separating them from the page — that should make it obvious to everyone that “Airport” represents the current page, while the others represent alternative pages that you can view by clicking on them.

Right?

Err, maybe not. Even though it doesn’t look linky, the active tab is still, by a lucky coincidence, a link, so I was able to track it using the Google Analytics Site Overlay out-link tracker (note that it’s not actually a click tracker, even if it looks like one). I have over 40,000 airport pages like this, so I can’t check every one, but the few dozen I looked at all told the same, sad story…

People don’t get tabbed interfaces

On most airport pages, the majority of user clicks were on the active “Airport” tab. In other words, people go to the page, see the word “Airport” in bold in a prominent position, and click on it. They don’t notice that it’s the active tab — maybe they don’t know that it’s a tab at all. They just figure that it must have more information about the airport they’re looking at.

For example, on the Heathrow Airport page over the past month, Google Analytics tracked 17 outlinks to the same page (via the active “Airport” tab), 5 to airport arrivals, 4 to airport departures, and 0-2 for every other link.

Once they click on what I thought they’d recognize as the active airport tab, the same page just reloads. Blech. I assume that’s when they get sick of the site, and go back to their Google search results to find a better page about the airport.

Tabs encourage information clutter

So the tabbed interface just leads to confusion and frustration from many of the visitors to my web site. But there’s another problem evident from the the outlink stats: tabs encourage a designer to present too many options in too many contexts. The tabs are all visible on every page they cover, but most of the time, they represent information that the users don’t actually need, and there’s no clear visual cue that some of the tabs (e.g. arrivals and departures) are a lot more interesting than others (e.g. the airport page’s change history).

Here, for example, are the last month’s outlink counts for each of the tabs on the Myrtle Beach International Airport page:

Tab	# followed
Airport	33
Arrivals	36
Departures	12
Pilot info	0
Visitors	4
Nearby airports	7
Nearby members	1
Changes	0
Edit	0

For reasons I don’t understand, this was the most-visited airport page on OurAirports last month, with 371 pageviews (300 uniques). It’s a little atypical, in that the active tab is not the most clicked (though it’s still unacceptably high), but otherwise, it shows the picture well. The “Pilot info” tab has existed for only a few days, so we can leave it out, but in general, it’s clear that the main thing accomplished by the tabs is showing a lot of links at the top of every page that no one actually wants to use. I suspect that even the four clicks on the “Visitors” tab were accidental — instead of trying to see what OurAirports members have visited the airport, people were probably just looking for visitor information.

How to redesign?

So if (a) tabs aren’t actually intuitive for most of my visitors, and (b) they fail to distinguish useful/popular information from more esoteric information, then they have to go. It’s going to take me a while to redesign the site, but what I think I’ll do is highlight the 3-5 most useful actions for each type of page in a side bar beside the map, like this:

Show me…

arrivals or departures

visitor comments

pilot information

nearby airports

points of interest

more…

A list like this, as opposed to tabs, provides a clear call to action for a page visitor, providing more detailed options in language that will make sense to them. It highlights useful information they might have missed in a tab (e.g. pilot info) or a section lower on the page (e.g. Visitor comments), and hides stuff they rarely need in a menu that appears only on demand, when they click “More…”.

Farewell, tabs. Even if you weren’t helpful, you were fun to design with CSS and rounded-corner images.