Tag: Usability

Make it work!

Categories
Accessibility

Accessibility 101

A11y 101: How to test manually
Categories
Design glamorous

My Glamorous Life: broken by design.

Debt brought on by large, unexpected expenses caused me to lose access to my credit card. I’d put a close friend’s storage unit in my name and on my credit card while they relocated and job-hunted. So my payments on my friend’s behalf were no longer going through, and the storage company began texting me about the missed payments.

Sounds straightforward, ordinary, and boring. Turned out not to be.

Meanwhile, my friend—after moving house twice—has landed a terrific job, and is beginning to dig themselves out of their debt. But they can’t pay the full amount of their storage fee yet. Or transfer the unit from my name to theirs.

They tried to make a partial payment by telephone, but the company’s “partial payment” line didn’t work.

It didn’t work in a highly specific way.

Specifically, it let them waste ten minutes entering data by hitting their phone’s keypad and typing “1” after each step to confirm that it had been completed correctly. Finally it asked them to confirm the entire order and type “1” to pay and finish. As soon as they did so, the bot told them that the payment had not gone through … asked them to “wait to speak to a manager” … and immediately disconnected them.

Each time they tried, they got to that stage and were immediately disconnected. With all the goodwill in the world, my friend could not pay their bill. So it was up to me.

“Nothing works” is working as expected.

I had enough cash in the bank to make a full payment on my friend’s behalf; and since the unit was in my name anyway, I followed the company’s text message instructions—sent to me personally—to pay the full bill online on their behalf and set up automated payments for future bills. My friend would pay me back when they could. Eventually we’d transfer ownership. All would be well. Such was my naive hope.

The website let me enter my data step by step, including “new card” data. I removed the defunct credit card info and replaced it with my debit card data. Unlike a credit card, my debit card never lets me spend more money than I have in the bank. That is a good thing when you’re in debt. And even when you’re not. My debit card is with one of the largest banks in the world. If I said the bank’s name, you’d know it. Cole Porter mentioned it in his lyrics. I’ve had the account for over 30 years. In short, it’s a stable account with a long history.

The website allowed me to enter my data, a process that took about five minutes.

When I hit “Send,” the website announced that the payment had failed to go through because the bill was past due.

The system is designed to block payments after first encouraging you to try sending them. There I am, working to send them my money. And the system refuses. Not to put too fine a point on it, consider the facts: their system was designed specifically to let customers make payments. It already knew who I was. It told me my name, my storage unit number, and the amount due. The notes I’d scribbled prior to using the website were unnecessary. The site knew me. It knew what I owed. It was theoretically optimized to take money sans friction. And it failed every time I tried to pay.

Two design choices are worth noting.

  1. The system only accepts timely payments, not late ones. But…
  2. The system deliberately doesn’t tell you that it won’t accept your payment. It encourages you to waste time trying. That’s key.

Is the software poorly designed? Was the company’s QA process less than perfect? Did some sadist deliberately set up the system to punish folks who are struggling?

The answer, of course, is yes. To all three questions.

I tried.

I tried three times, even switching options. Like, the first time, I asked the company NOT to use my debit card number to automatically pay my friend’s bills in the future. The next time, I said, OKAY, go ahead and charge me automatically. No matter which options I chose, the result was always: “The payment did not go through because the amount is past due.”

Who chose those defaults? Elon Musk?

Since the payment website did not accept payments, I called the special “call this number to pay” line the company’s text messages had shared with me. Again, this was a special phone number with a specially built system set up explicitly so existing cutomers could pay their bills by phone.

The number was smart. It had been waiting for my call. It recognized my phone number and told me my storage unit’s account number. It remembered my old credit card number—the one it knows doesn’t work. It asked me if I wanted to pay with the card that doesn’t work. It allowed me to say “No.” It enabled me to enter the account number and other data for my “new” debit card. It encouraged me to type “1” each time I completed a step. It asked me to confirm that everything I’d entered was correct. I did. It asked me to hit “1” one final time to finish making the payment. I did that.

The automated phone voice then informed me that the payment had not gone through, instructed me to “hold the line to speak to a manager,” and immediately disconnected me. Same as what had happened to my friend when they tried to pay.

I tried three times. Each time, the same.

Enter a ton of data by phone. Say yes over and over. Hit the phone equivalent of Send. Get the same error message, followed immediately by disconnection. (Why did I try three times? Why not two? Why not eleven? That’s a QA subject for another day.)

When one door closes, so does another.

Clearly the payment line—like the website—was not working. So I looked up the company’s website to find their main number. Not the smart automated number that knew who I was and what I owed. A dumb number, but presumably with a human being at the other end.

I figured I’d call the main number and explain that I’m trying to pay a bill, have my account number and unit number ready to recite, and all set to approve the dollar amount. If the human being on the other end told me to use the “bill payment number,” I’d explain that the bill payment number wasn’t working at the moment, and ask them to please please pretty please with sugar on top ever so kindly allow me to send them my payment.

So I called and got a busy signal.

Hung up.

Waited ten minutes, called again.

Busy signal.

I’d now wasted at least 30 minutes and it was a work day, so I turned my attention back to my job, and away from nut-grindingly pointless exercises in futility.

After roughly an hour, I tried phoning the company’s main number once again. Busy signal.

Busy, busy, busy. The call never went through. Nobody ever answered.

Here’s what I think: I think if you’re late, this company’s systems stop working. Not because they don’t want your money—they do. But because they want you to suffer for being late. Before they’ll take your money, they want you to crawl. At one time, there was probably a Japanese newsgroup dedicated to this kind of kink. And the beauty part, for the perverted, is that the pain is pointless and nonconsensual. Just like our country’s new government.

The company wants you to try paying them via the payment website till your eyes cross. They want you to dial the “payment” phone number and jump through your own anus until you tire of being disconnected after approving the payment. They want you to weep endless, useless tears. To curse. To try dialing the main number a thousand skrillion times before you get through to a human being. They want you to break down altogether when you finally hear a human voice. Like you’ve been rescued from a desert island and had forgotten the glorious sound of ordinary human speech.

There’s probably a German word for the relief you feel after banging your head against the obtuseness of American business systems until you are finally, after great sorrow, permitted to pay your bill and get back to your life. It’s like the relief you feel when the cable internet finally comes back on after an unexplained blackout. Or when the New York landlord finally fixes the water heater so you can stop washing your private parts in ice water. Or when your trainer finally says, “Good job, let’s go stretch.”

The underlying belief is clear: making a payment should not be routine. It should be a privilege, forged in fire and earned in blood.

Mind you: I don’t know that there actually will be a human being at the end of the phone line if I spend all day Saturday trying to reach one, but, at the moment, that’s my plan. Try and try and try and try and try again and keep trying world without end ad infinitum until at some blessed hour, some stranger finally agrees to take my money.

And here’s the point of all this:

I encounter broken systems like this almost every week.

As a UX person, it makes me nuts. Also as a human being. It’s not right. It’s not fair. And we all put up with it.

Even if you’re lucky enough to have a good job, and even if you live in a progressive city like New York, our increasingly automated business systems are not our friend. In short:

They want to take your job and replace you with a machine that doesn’t work.

Categories
Accessibility Advocacy architecture Authoring Best practices development ethics industry Performance Platforms Responsibility Standards State of the Web Usability User Experience UX W3C Web Standards

CAPTCHA excludes disabled web users

What’s widely used, no longer particularly effective, and makes web content inaccessible to many people with disabilities? It’s our old friend CAPTCHA! In a group note dated 16 December 2021, the W3C explains how CAPTCHA excludes disabled users, and suggests alternatives which may be kinder and more reliable:

Various approaches have been employed over many years to distinguish human users of web sites from robots. The traditional CAPTCHA approach asking users to identify obscured text in an image remains common, but other approaches have emerged. All interactive approaches require users to perform a task believed to be relatively easy for humans but difficult for robots. Unfortunately the very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users. Research findings also indicate that many popular CAPTCHA techniques are no longer particularly effective or secure, further complicating the challenge of providing services secured from robotic intrusion yet accessible to people with disabilities. This document examines a number of approaches that allow systems to test for human users and the extent to which these approaches adequately accommodate people with disabilities, including recent non-interactive and tokenized approaches. We have grouped these approaches by two category classifications: Stand-Alone Approaches that can be deployed on a web host without engaging the services of unrelated third parties and Multi-Party Approaches that engage the services of an unrelated third party.

W3C: Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web

We can do better!

Tell your friends. Tell your boss. Tell your clients.

Tip o’ the blue beanie to Adrian Roselli.

Categories
Accessibility Design IXD Usability User Experience UX

A faster horse

“The user is never wrong” means, when a user snags on a part of your UX that doesn’t work for her, she’s not making a mistake, she’s doing you a favor.

To benefit from this favor, you must pay vigilant attention, prioritize the discovery, dig deeply enough to understand the problem, and then actually solve it.

In so doing, you will not only be secretly thanking the user who discovered your error, you’ll be aiding all of your users, and ultimately, attracting new ones.


Think about this tomorrow. For today, Happy Labor Day to all who toil.

Categories
Design Usability User Experience UX

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.

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.

P.S. If your design works for 80% of the people, and you begin to think it’s bulletproof, give me a shout. I’ll depress you posthaste.

Categories
Usability User Experience UX

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.

Categories
apps Blogs and Blogging Design industry plugins Publishing software Standards State of the Web Usability wordpress

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]

Categories
A List Apart Accessibility architecture Code Design development User Experience UX Web Design

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]

Categories
Design Usability User Experience UX

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]

Categories
A List Apart Design Happy Cog™ Layout Publications Publishing Usability

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]

Categories
Accessibility Design Happy Cog™ Ma.gnolia Usability Zeldman zeldman.com

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]

Categories
A List Apart client services Design development engagement findability Standards Tools

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.
Categories
.Mac Applications Design iphone

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]

Categories
Accessibility An Event Apart cities Community Design development eric meyer events industry New Orleans Standards Zeldman

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]

Categories
Accessibility client services creativity Design development Publishing Standards

Appreciating web design; setting type

We have what we think is a special issue of A List Apart for people who make websites.

  • Every responsible web designer has theories about how best to serve type on the web. In How to Size Text in CSS, Richard Rutter puts the theories to the test, conducting experiments to determine the best of all best practices for setting type on the web. Richard’s recommendation lets designers reliably control text size and the vertical grid, while leaving readers free to resize text.
  • And in Understanding Web Design, I explain why cultural and business leaders mistake web design for something it’s not; show how these misunderstandings retard critical discourse and prevent projects from reaching their greatest potential; and provide a framework for better design through clearer understanding.

Plus, from October 2001, we resurrect Typography Matters by Erin Kissane, the magazine’s editor, who is currently on sabbatical.

[tags]webdesign, css, textsize, type, typography, sizingtype, sizingtext, understanding, typedesign, architecture, newspaperdesign, posterdesign, bobdylanposter, erinkissane, richardrutter, zeldman, jeffreyzeldman, alistapart[/tags]