Designer Blindness

AFTER USING the web for twenty years, and software for an additional ten, I’ve come to believe that I suffer from an affliction which I will hereby call “designer blindness.”

Put simply, if an interface is poorly designed, I will not see the data I looked for, even if it is right there on the page.

On a poorly designed table, I don’t find the column containing the answer I sought.

On a poorly designed interface, I don’t push the right buttons.

On a poorly designed social sharing site, I delete my data when I mean to save it, because the Delete button is in the place most designers put a Save button.

This doesn’t happen to everyone, which is why I call it an affliction. Indeed, it happens to almost no one.

My non-designer friends and family seem quite capable of using appallingly designed (and even undesigned) sites and applications. Somehow they just muddle through without pushing the button that erases their work.

In fact, the less concerned with aesthetics and usability these friends and family members are, the more easily they navigate sites and applications I can’t make head nor hair of.

Like the ex-girlfriend who mastered Ebay.

Or the colleagues who practically live in Microsoft Excel, an application I still cannot use. There are tabs on the bottom, way below the fold, way past where the data stops? And I’m supposed to scroll a blank page until I find those tabs? It’s easy for most people, but it never occurs to me no matter how often I open an Excel document. I could open a thousand Excel documents and still never think to scroll past a wall of empty rows to see if, hidden beneath them, there is a tab I need to click. Just doesn’t occur to me. Because, design.

It’s not a visual or mathematical disability. If something is well designed, I can generally use it immediately. It’s the logic of design that trips me up.

I recognize that I’m an edge case—although I bet I’m not the only designer who feels this way. Give me something that is well designed, and I will master it, teach others about it, and unconsciously steal my next five original ideas from it. Give me something poorly designed, something that works for most people, and I’ll drive a tank into an orphanage.

Not that I’m a great designer. I wouldn’t even call myself a good designer. I’m just good enough to get messed up by bad design.

Yet you won’t hear me complain about my designer blindness.

See, divorce is a terrible thing, but if you have a kid, it’s all worth it. The heartache, the anger, the loss of income and self-esteem, the feeling that no matter what you say or do, you are going to be someone else’s monster forever—all the unbearable burdens of failed love and a broken family are worth it if, before that love failed, it brought a wonderful child to this world.

For my daughter I would suffer through a thousand divorces, a million uncomfortable phone calls, a trillion emotionally fraught text messages.

And how I feel about my kid is how I also feel about my design affliction. The pain of being unable to use what works for other folks is more than compensated for by the joy of recognizing great design when I see it—and the pleasure of striving to emulate that greatness, no matter how badly I fail every time.

Broken All the Way Down: Seeking Basic Information from Southwest Airlines

I was taking my daughter to Laguardia Airport to meet her mom, who would then take the girl on to Chicago for a few days’ holiday-time visit. Laguardia is a large airport, with many terminals, and as I hadn’t bought the ticket and wasn’t flying, I didn’t know which of the many terminals to go to.

So the day before my daughter’s trip, I visited Southwest’s website and punched in the flight number. It is a recurring flight from New York to Chicago that takes place every weekday at the same time. The website told me that the flight had left for the day. It couldn’t tell me the terminal of departure or anything else.

Next I punched in the confirmation code for my daughter’s flight. Her mother had already checked her in, and sent me a digital copy of the boarding pass, which I needed to get through airport Security, and which also didn’t have a terminal or gate number—not surprisingly, since, even for a recurring flight, gates aren’t typically assigned until a few hours before the flight departs. I didn’t expect a gate, but a terminal would be nice. When I punched in my daughter’s confirmation code, there was still no sign of a terminal.

So I scoured the entire Southwest website. No mention of terminals anywhere.

I then used both Google and Duck Duck Go to run every query I could think of that might tell me which terminal or terminals Southwest departs from at Laguardia. Neither search engine was able to return anything of the slightest use.

I began to think that Southwest might have a problem with its markup, and its content strategy, and with any additional findability voodoo that usually gets called “SEO.”

Even maps of Laguardia and maps of airlines at Laguardia and records of flights from New York to Chicago and other Giles-like aracana I eventually thought of were unable to produce a tiddle of information about which terminal at Laguardia plays home to all or even some of Southwest’s flights.

When all else fails, call the company.

As you might expect by now, it took work to find Southwest’s phone number on its website, and when I did find it, it was one of those 20th Century mnemonic numbers that are hard to use and rather meaningless in the age of smartphones: 1-800-I-FLY-SWA.

You will not be surprised to learn that I sat through a long, unskippable audio menu full of slow-talking sales puffery before I was offered the chance to say “agent” and speak to an agent (which I needed to do since none of the menu options led to the information I wanted). After I said “agent,” the robotic voice told me, “Okay, I will connect you to an agent,” and hung up on me.

I went through this three times to make sure I wasn’t going mad and there was in fact no chance of reaching an agent.

To summarize so far: basic information not on company website or, apparently, anywhere on the web. Hard-to-use phone number did not provide info in its menu, and hung up every time it promised to connect me to an actual human agent.

So I used the contact form on the company’s website to ask my question (requesting an answer the same day if possible), and to report the usability problem on the company’s phone system, wherein if a human asks to speak to an agent, the system agrees to provide an agent and then hangs up on the customer.

Today—the day after my daughter’s flight—I received via email a form letter from Southwest apologizing for not getting me the information in time (and still not giving me the information), and advising me to solve my own problems in the future by using Southwest’s super-useful toll-free number for concerns that require immediate assistance.

I guess the person who sent the form letter hadn’t read the second sentence of my two-sentence request for help, where I mentioned that the toll-free number was broken.

Here, in its entirety, is Southwest’s response:

Dear Jeffrey,

Thank you for your email. We certainly wish we had been able to touch base with you prior to your travel. We realize how important it is to respond to our Customers’ concerns in a timely manner, and we regret disappointing you in this regard. For future reference, you may contact our toll-free number, 1-800-I-FLY-SWA, for concerns that require immediate assistance.

We appreciate your patronage and hope to see you onboard a Southwest flight soon.

Sincerely,
Wanda, Southwest Airlines

The file reference number for your e-mail is 255648215756.

You can’t make stuff like this up. The last sentence is my personal favorite. There’s nothing like a file reference number to cheer you up after experiencing failure at every customer experience point you touched.

In the end, because my kid’s mom had shared the flight details, Tripit texted me the terminal information hours before I needed it. Terminal B, which is about two-thirds the size its needs to be for the amount of traffic it handles, was predictably mobbed with holiday travelers. There was not a free seat in the house.

Business is booming.

Shorten this

In April of 2009, in a post every web designer, publisher, or business person should read, Joshua Schachter told how URL shortening services like TinyURL and Bit.ly came to be, and why the latest ones were so addictive. (Missing from Joshua’s account of their utility is the benefit URL shorteners can provide when sharing an otherwise obscenely long link on the printed page.)

The prescient post concludes that, despite their benefits, such services ultimately harm the web, decreasing clarity while increasing the odds of linkrot and spam:

[S]hortening services add another layer of indirection to an already creaky system. A regular hyperlink implicates a browser, its DNS resolver, the publisher’s DNS server, and the publisher’s website. With a shortening service, you’re adding something that acts like a third DNS resolver, except one that is assembled out of unvetted PHP and MySQL, without the benevolent oversight of luminaries like Dan Kaminsky and St. Postel.

There are three other parties in the ecosystem of a link: the publisher (the site the link points to), the transit (places where that shortened link is used, such as Twitter or Typepad), and the clicker (the person who ultimately follows the shortened links). Each is harmed to some extent by URL shortening.

There’s more, and you should read it all.

One of Joshua’s recommendations to minimize some of the harm is that websites do their own URL shortening instead of relying on middlemen. I’ve done some of that here, via the ShortURL plug-in for WordPress. Thus I use zeldman.com/x/48 instead of a much longer URL to notify my friends on Twitter about a new comment on an oldish thread. Likewise, zeldman.com/x/49 redirects to yesterday’s big post, “Write When Inspired.”

Rolling your own mini-URLs lessens the chance that your carefully cultivated links will rot if the third-party URL shortening site goes down or goes out of business, as is happening to tr.im, a URL shortener that is pulling the plug because it could neither monetize nor sell its service.

tr.im is now in the process of discontinuing service, effective immediately….

No business we approached wanted to purchase tr.im for even a minor amount.

There is no way for us to monetize URL shortening — users won’t pay for it — and we just can’t justify further development since Twitter has all but annointed bit.ly the market winner.

The Short URL Plugin for WordPress installs automatically. It provides simple statistics, telling you how many times a link has been clicked, sets up redirects automatically, allows you to choose a custom link style, and more. You’re not limited to shortening your own URLs, although that’s mainly how I use it; you can also shorten third-party URLs, turning your site into a miny TinyURL. I’ve used this plugin for months, with nothing but joy in its cleverness and usability.

[tags]ShortURL, plugin, WordPress, plugins, joshua schachter, tr.im, bit.ly, URL, Twitter, TinyURL, web, usability, internet, links, security[/tags]

ALA 272: Accessible web video, better 404

In Issue No. 272 of A List Apart, for people who make websites:

This is How the Web Gets Regulated

by JOE CLARK

As in finance, so on the web: self-regulation has failed. Nearly ten years after specifications first required it, video captioning can barely be said to exist on the web. The big players, while swollen with self-congratulation, are technically incompetent, and nobody else is even trying. So what will it take to support the human and legal rights of hearing impaired web users? It just might take the law, says Joe Clark.

A More Useful 404

by DEAN FRICKEY

When broken links frustrate your site’s visitors, a typical 404 page explains what went wrong and provides links that may relate to the visitor’s quest. That’s good, but now you can do better. With Dean Frickey’s custom 404, when something’s amiss, pertinent information is sent not only to the visitor, but to the developer—so that, in many cases, the problem can be fixed! A better 404 means never having to say you’re sorry.

[tags]alistapart, closedcaptioning, captioning, captions, webvideo, video, accessible, accessibility, 404, error, reporting, usability, programming, design, webdesign, webdevelopment[/tags]

Zing

John Gruber is right: his four-year-old Daring Fireball essay, Ronco Spray-on Usability, still holds up nicely indeed.

Alas, the notion that usability is the easy part—something you just add on after doing the hard part of writing the code—is hardly limited to the open source community.

There are still many companies that think information architecture holds a mirror up to the org chart.

There are still many web clients who believe it is more important to support an “investment” in a moribund technical platform than to create great user experiences.

There are even (although there are far fewer than there used to be) some designers who think their primary job is to wow the user with their skills.

[tags]design, usability[/tags]

ALA 258: art of community, science of design

What does it take to build an online community like Flickr’s? And how can we tell if interface design conventions we take for granted actually help or hurt users? In Issue No. 258 of A List Apart, for people who make websites, George Oates, a key member of the core team that shaped the Flickr community, tells what it will take to build the next Flickr (hint: the answer isn’t Ajax). And Jessica Enders drops some science on the widespread belief that zebra stripes aid the reader by guiding the eye along a table row.

[tags]alistapart, publishing, publications, happycog, zebrastripes, zebrastriping, usability, design, community, flickr, georgeoates, jessicaenders[/tags]

The feed is gone

Over the weekend, I added my Ma.gnolia bookmarks feed to my blog post template, such that every post would be followed by links to and descriptions of the last five external web pages to have caught my fancy. Inserting the feed into the template was easy and took all of three minutes.

This morning, I removed the feed.

Why I inserted the feed

From 1995 until around the time Happy Cog worked on the Ma.gnolia design project, one of the things I wrote about here was other people’s websites. I did it because I was passionate about web design, and so were the people who read this site. And of course, writing about other people’s sites also provided a ready form and steady stream of content. From 1995 until about 2001, I wrote here several times a day, and had millions of readers.

Then married life, and a business that grew in spite of my lifelong effort to avoid commercial success, ate into my blogging time. Today I write less frequently and have fewer readers. In an effort to provide linkage even when I don’t have time to write posts, I added my Ma.gnolia feed to my site’s sidebar in 2006. (It’s still there, on my front page. You may need to scroll down to see it.)

A flaw in the design

Not everyone notices the Ma.gnolia feed in my sidebar, due to a flaw—one of many—in the way I redesigned zeldman.com in 2004. (I used to redesign this site several times a year, but haven’t touched it since Spring of 2004.)

When I redesigned zeldman.com in 2004, I thought it would be “neat” to make my sidebar’s linked text almost the same color as the background until you hovered over it. The idea being that the focus was on the site’s content, not all the little crap in the sidebar. The sidebar was like sand, and you, the reader, were like a beachcomber with a metal detector. Hover the metal detector over the sand, and you might find a quarter. Hover over my sidebar, and you might find additional content.

Like most “neat” ideas that aren’t entirely practical, this one required compromise in the execution. The result is a conventional sidebar with low-contrast text. Because of the low contrast, lots of people (including people with certain kinds of dyslexia) pay little attention to the sidebar’s content. So I need to redesign.

But meantime, slipping the Ma.gnolia feed out of the sidebar (on blog posts) and into the body of posts itself seemed like another neat idea. People who’d ignored the Ma.gnolia feed in the sidebar would now, finally, bask in its glory. Every post would end with the last five third-party links I’d reviewed. Neat, neat, neat.

Why I removed the feed

This morning I removed the feed from the body of the blog posts for a technical reason and a design/usability reason.

Technically, as we all know, it’s not a great idea to pull content from a third-party site. The third-party site can be slow. It can get hacked. It can even go down, causing one’s own pages not to finish rendering. (As I write this, Ma.gnolia’s server appears to be taking a little nap—an infrequent occurrence, although the server is often slow. As for my embedded Twitter feed, like yours, it suffers from near-constant narcolepsy.)

And from a design usability perspective, the idea just didn’t gel. For one thing, people would dig up old posts and write comments on them about sites newly added to the Ma.gnolia feed. Owing to the age of the posts, those comments were unlikely to be found by other readers. And as soon as the feed updated, the comments would become nonsensical, because they discussed content no longer found in the post.

So the feed is gone.

[tags]design, usability, ma.gnolia, zeldman.com, happycog, links[/tags]

Books of Luke and Aarron

In Issue No. 255 of A List Apart, for people who make websites:

  • Findability, Orphan of the Web Design Industry – Aarron Walter, author of Building Findable Websites: Web Standards, SEO, and Beyond (New Riders, 2008), provides an overview of this essential web discipline, explains how it is like SEO but different, and tells how every member of your team can contribute to your site’s content’s findability. (See Aarron speak about findability and web standards live and in person at An Event Apart New Orleans, April 24–25, at the Hilton New Orleans Riverside.)
  • Sign Up Forms Must Die – Luke Wroblewski, Senior Principal of Product Ideation and Design at Yahoo! and author of Web Form Design: Filling in the Blanks (Rosenfeld Media, 2008), calls for the abolition of sign-up forms where web services are concerned. Via “gradual engagement,” says Luke, we can get people using and caring about our web services instead of frustrating them with forms. (Get more Luke live and in person at An Event Apart Boston, June 23–24, 2008 at the Boston Marriott Copley Plaza.)

As a glance at the masthead suggests, thought-provoking content about web form design and findability isn’t all that’s happening in this issue of A List Apart:

  • Deeply gifted and seriously experienced web design magazine editor Carolyn Wood finally joins the ALA staff as acquisitions editor, taking that post from …
  • … the witty and excellent Krista Stevens, who now becomes editor of the magazine.
  • For his profound contributions to branding and usability, art director Jason Santa Maria becomes creative director.
  • And after eight years at the magazine, Erin Kissane steps down as editor (but will stay with us as contributing editor). The improvements Erin has made to the magazine in her years with us cannot be counted, not even by the angels.

Usability problems with .Mac sync

I’m afraid this is another of those entries outlining bizarre design decisions and perplexing usability quirks in the otherwise brilliant world of Apple computers and phones. The problem is sync. It can be done, but it often goes wrong, even for smart people who understand computers, haven’t hacked their equipment or broken the law, and are kind to dogs, cats, and children.

Here’s a particular setup: .Mac account. Tiger laptop at home, Leopard iMac at office.

On both Macs, you need to refresh your subscriptions (Calendar: Refresh All) before you sync for the first time at that location. Otherwise, sync deletes the subscribed calendars’ information. Just wipes it clean away.

And even if you Refresh All first, sync may wipe away your data, just because.

Fortunately, after sync erases your data, hitting Calendar: Refresh All again reinstates it, downloading saved data from .Mac.

Why does syncing on either Mac remove all the calendar events from subscribed calendars? It’s the opposite of what any user could possibly want. There’s not even a conceivable edge case where a user would expect “sync” to mean “I’m bored with my life. Surprise me. Make my calendar data disappear.”

One doesn’t sync to lose data. Losing data by syncing is the exact opposite of what a user expects—which also makes it the opposite of what the Macintosh experience promises and usually delivers.

.Mac sync is either partly broken; or correctly designed, but to absurdly limited scenarios; or designed so counter to a user’s expectations that it should only be run with instructions, which Apple does not provide.

Apple does not provide instructions because instructions imply a learning curve, and Apple’s pitch is that its stuff just works. One nevertheless expects at least a slight learning curve when using, say, GarageBand or Keynote. But not with sync. “Sync now” seems pretty self-explanatory, and no user doubts what’s supposed to happen.

Sync does give you a warning before dumping your data, and that warning provides a clue to what’s going wrong. It tells you that syncing will remove x number of items from your calendars, and even lists which items they are. In Leopard, it goes further, and shows you before/after views of items that will change.

Significantly, there is generally no change at all between the before and after views. Probably the “change” is to a part of the database that the user doesn’t see, and has to do with differing file formats or differing time-stamp conventions between Tiger and Leopard. A less buggy or better conceived interface would hide this non-information from the user instead of asking her to think about it.

Do I really need to see that “Lunch with Jim at 1:00” is going to “change” to “Lunch with Jim at 1:00?” Probably not, since, from my perspective as a human, the two items are identical. It’s lunch. With Jim. At 1:00.

If “Lunch with Jim at 1:00” is “different” from “Lunch with Jim at 1:00” to my Macintosh because Leopard and Tiger encode or store calendar items differently, or because Leopard and Tiger time-stamp event creation dates differently, that’s not information I need to know and it’s not a before/after view I need to see.

Before/after seems cool, and probably is if your data is actually changing. For instance, if you’ve changed one of your friend’s photos, it would be nice to compare the before and after views and decide which photo you prefer. But I’ve never seen before/after work that way. Changed photos just get changed. Before/after only seems to come into play on my networks when “Lunch with Jim at 1:00” is changing to “Lunch with Jim at 1:00.”

The irrelevancies I’ve just described must be endured, and the sequence (Refresh: All, then Sync, then Refresh: All again if data was lost during sync) must be performed in the order described, before syncing the iPhone. If, in a moment of derangement, you plop your iPhone onto its dock before doing the herky-jerky data dance I’ve just described, you will lose data not only from your iPhone, but also from .Mac, and then you will never get your data back.

Your mileage may vary.

There are always 100 people for whom everything works correctly, and some of them are always moved to tell me it works for them, and to imply that I’m somehow to blame for the obvious usability problems I’m clearly describing.

They are followed by a dozen Apple haters who want to believe that the lengthy and detailed description of a specific usability problem proves Apple makes bad products, and anyone who claims to enjoy using Apple’s hardware and software is a “fanboy.” Juvenile homophobic and misogynist name-calling often accompanies these messages of hope.

Here’s what I am actually saying.

On my two-Mac setup where one is on Tiger and the other on Leopard, I can make sync work, but I must carry out actions in exact sequences, and know the tricks to undo the damage that syncing inflicts on my data due to bizarre design decisions on Apple’s part.

A few times I have irretrievably lost data, although I was able to manually recreate it by emailing colleagues and asking, “When are we meeting?”

It reminds me of running an old analog mixing board in a dirty, smoky recording studio. Everything’s cool if you know which faders you must never touch, which inputs are dead, and how far to the left you can pan a sound source before shorting out the system.

There’s genius in the concept of sync, and it works magnificently when you’re, for instance, syncing just one iPod to just one Macintosh, always the same iPod and Macintosh.

It gets weird when syncing from home to office via .Mac across operating systems, and weirder when you throw hot iPhone action in.

How should sync work? Just like you think it should work. Just like the two arrows circling in on each other (sync’s icon) imply that it does work. Hitting sync at any time on any networked device should cause all the latest changes to be stored on .Mac and downloaded back to whichever connected device you’re using.

There’s a whole other discussion to be had on why the iPhone is supposed to sync to only one machine, (Sure, iPods do that because of DRM restrictions; but competitive PDAs can sync to any computer: home, office, you name it. Likewise with digital cameras. The iPhone is a phone, an iPod, a digital camera, and a PDA, but its syncs like an iPod, not like a digital camera or PDA, and that’s just dumb.) but we’ll save that one for a rainy day.

Sync long and prosper.


Addendum: Another crazy thing is that subscribed iCals from Basecamp don’t update upon refresh in Leopard. In iCal in Tiger, subscribed Basecamp iCals correctly refresh automatically when one selects Calendars: Refresh All. But in iCal in Leopard, subscribed Basecamp iCals do not refresh, period, no matter what one does. In order to “sync” Basecamp iCals in Leopard, one must delete the calendars every day, and subscribe to fresh copies. When one does this, one gets fresh calendar data, but sync fails due to “conflicts” that do not load in the frozen Conflict Resolver and thus cannot be resolved. This of course is not what Apple intended. It is, by any reasonable measure, an idiotic and self-defeating system. The basest ape would not design such a system. Obviously the system is not operating the way Apple intended. How does one fix it? Apple isn’t telling.

Comments are now off, but you can read what others had to say when comments were open.

[tags]dotmac, .mac, sync, iphone, imac, laptop, macbook, macbookpro, apple[/tags]

An Event Apart New Orleans

An Event Apart, the design conference for people who make websites, kicks off its 2008 season with An Event Apart New Orleans, a monster, 19-hour, two-day creative session. Join us April 24–25 at the Hilton New Orleans Riverside for two intense, 9.5-hour-long days of learning and inspiration, featuring twelve of your favorite web design authors.

  • See Dave Shea, co-author, Zen of CSS Design, explore what makes sites flexible visually, experientially, and code-wise.
  • See Jeff Veen, design manager, Google, explore how new thinking, born of creating the latest generation of web apps, is being infused into design practices.
  • See Robert Hoekman Jr., author, Designing the Obvious, perform slam-bang, on-the-spot usability reviews of sites submitted by our live audience on the fly.
  • See Cameron Moll, author, Mobile Web Design, uncover the differences between good and great design.
  • See Aaron Gustafson, co-author, AdvancED DOM Scripting, go beyond “unobtrusive” JavaScript to truly meet users’ needs, no matter what their device or platform, by applying the principles of “progressive enhancement” to client-side scripting.
  • See Andy Clarke, author, Transcending CSS, explain how comic books inspire his award-winning web layouts.
  • See Stephanie Sullivan, co-author, Mastering CSS with Dreamweaver CS3, explore practical, standards-based approaches and techniques to some of today’s toughtest design challenges.
  • See Aarron Walter, author, Building Findable Web Sites, explain “findability bliss through web standards SEO”
  • See Brian Oberkirch, Publisher, Like It Matters, review, catalog, dissect, and champion small design victories that daisy chain to create a delightful overall user experience.
  • See Jason Santa Maria, designer, Happy Cog, share techniques for maintaining individuality and brand distinction in a world of generic templates and design sameness.
  • See An Event Apart co-founder Eric Meyer, author, CSS: The Definitive Guide, present two new talks that shed brilliant light on the darkest corners of CSS.
  • As for me, I’ll be doing two new sessions on the whatness of web design (what it is, what it ain’t, and why it matters) and the whereness of web standards (as in, where we are with them).

It’s the longest, biggest, densest, hardest, coolest show we’ve ever done, and we’re doing it where Louis learned to blow his horn. Join us if you can.

Can’t make New Orleans? Join us in these cities!

  • Boston, June 23–24
  • San Francisco, August 18–19
  • Chicago, October 13–14

Tickets for all four shows are on sale now.

[tags]aneventapart, webdesign, conference, neworleans, aeaNOLA08[/tags]