Vincent Gable’s Blog

January 17, 2009

Lessons From Fast Food: Efficiency Matters

Filed under: Design,Programming,Quotes,Research,Usability | , ,
― Vincent Gable on January 17, 2009

Every six seconds of improvement in speed of service amounts to typically a 1% increase in sales. And it has a dramatic impact on the bottom line.

–John Ludutsky, President of Phase Research, quoted on the “Fast Food Tech” episode of Modern Marvels, aired 2007-12-29 on the History Channel.

I wouldn’t expect things to be much different in the software world. The faster you get your burger bits the better.

UPDATED: 2009-02-05:
Apparently people want service much faster from software. Greg Linden reports,

Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.

This conclusion may be surprising — people notice a half second delay? — but we had a similar experience at Amazon.com. In A/B tests, we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.

If the Mr Ludutsky’s figure is accurate, a 20% drop in fast-food revenue would require a two minute delay. Does this mean every second spent waiting on a computer is as bad as waiting 4 minutes in meatspace? I don’t know — I’m doing a lot of extrapolation from hearsay. But it’s something to consider.

January 15, 2009

Even a Small Child Can Do it

Filed under: Accessibility,Design,Programming,Usability | , , , , ,
― Vincent Gable on January 15, 2009

This segment of an Alan Kay presentation (pt 2) really jumped out at me.

She’s never lived in a world that wasn’t densely populated with Macintoshes. …She literally learned to use it by sitting on her mother’s lap while her mother was working. So for this child, the Macintosh is not a piece of technology, but simply more material in the environment to manipulate.

Another interesting point to note is that even though she can’t read, she’s able to recognize standard textual menu items.

And in fact we discovered that she was about 70% literate — that about 70% of the generic window commands that are found in any Macintosh application, she’s able to use. Not just in a visual program like Mac Paint.

One message Alan Kay really drove home is not just that that computers can be simple enough for children, but that designing for children can lead to better designs for adults. But remember that that just because a child can use a computer does not make it a silver bullet for education.

January 14, 2009

People Do NOT Want to Register

Filed under: Design,Security,Usability | , , ,
― Vincent Gable on January 14, 2009

Jared M. Spool writes about how removing compulsory registration from a website translated into a $300,000,000 increase in sales. (Via UI and us). The intentions behind the registration were good: make things easier for repeat customers by remembering their information. This would reward the most loyal customers, and for first-time customers registration would only be a small one-time step. But in practice, the registration was universally hated.

We were wrong about the first-time shoppers. They did mind registering. They resented having to register when they encountered the page. As one shopper told us, “I’m not here to enter into a relationship. I just want to buy something.”

…Without even knowing what was involved in registration, all the users that clicked on the button did so with a sense of despair. Many vocalized how the retailer only wanted their information to pester them with marketing messages they didn’t want. Some imagined other nefarious purposes of the obvious attempt to invade privacy. (In reality, the site asked nothing during registration that it didn’t need to complete the purchase: name, shipping address, billing address, and payment information.)

Repeat customers weren’t any happier. Except for a very few who remembered their login information, most stumbled on the form. They couldn’t remember the email address or password they used. Remembering which email address they registered with was problematic – many had multiple email addresses or had changed them over the years.

When a shopper couldn’t remember the email address and password, they’d attempt at guessing what it could be multiple times. These guesses rarely succeeded. Some would eventually ask the site to send the password to their email address, which is a problem if you can’t remember which email address you initially registered with.

(Later, we did an analysis of the retailer’s database, only to discover 45% of all customers had multiple registrations in the system, some as many as 10. We also analyzed how many people requested passwords, to find out it reached about 160,000 per day. 75% of these people never tried to complete the purchase once requested.)

The form, intended to make shopping easier … just prevented sales – a lot of sales.

The $300,000,000 Fix

The designers fixed the problem simply. They took away the Register button. In its place, they put a Continue button with a simple message: “You do not need to create an account to make purchases on our site. Simply click Continue to proceed to checkout. To make your future purchases even faster, you can create an account during checkout.”

The results: The number of customers purchasing went up by 45%. The extra purchases resulted in an extra $15 million the first month. For the first year, the site saw an additional $300,000,000.

Personally, I am in complete sympathy with the test’s participants. I don’t want to have to register to do something. In fact, I’ve re-registered for ADC a few times, because I lost my login information. (I really wish I could reclaim my first ADC membership from highschool, now tied to a defunct AOL address, because the member # is one digit shorter!)

Security Implications

Unfortunately, people have good reason to be wary of registration — it puts their credit card information at risk. And we’ve all been burned by spam and junk-mail from someone who abused registration information.

The Future is Here

Modern web browsers all have some kind of auto-fill that can remember and enter shipping/billing information. This technology obsoletes the benefits of registration in the story.

There’s more that could be done to be smarter about registration. For example, not exposing it in any way unless a person has made several orders.

Of course, the smartest thing is to avoid registration, because your users hate it. Services like BugMeNot prove this.

January 7, 2009

Objective-C 1.0 Style: Don’t Name Your Enumerators “enumerator”!

Filed under: Bug Bite,C++,Cocoa,Design,Objective-C,Programming,Tips,Usability | , , ,
― Vincent Gable on January 7, 2009

Disclaimer

There is a better way to iterate over collections in Objective-C 1.0. You really should use it. It’s easier to write, easier to read, less prone to bugs, faster, and makes what I’m going to rant about here a non-issue, because you won’t have any NSEnumerator variables in your code.

Badly Named Problem

The standard iteration idiom in Objective-C 1.0 is:

NSEnumerator *enumerator = [collection objectEnumerator];
id element = nil;
while( nil != (element = [enumerator nextObject]) ) {
   ;//do stuff...
}

Unfortunately, I see otherwise steller programmers name their NSEnumerator variables “enumerator”. That’s always wrong, because it does not tell you what the enumerator enumerates. We already know that enumerator enumerates things, because it’s type is NSEnumerator, unless it’s name tells us more then that it’s hardly better then no name at all.

This is an especially amateurish practice because …

Naming an Enumerator Well is Easy!

Call it, the plural of the element variable. And if that won’t work you can always fall back on calling it collectionEnumerator.

For example, to fix:

NSEnumerator *enumerator = [input objectEnumerator];
NSString *path = nil;
while (path = [enumerator nextObject])

We should name enumerator paths or inputEnumerator. You might find “paths” to be too close to “path” in which case let the “plural form” of element be everyElement, giving everyPath.

These rules can be applied without much thought, but will improve the clarity of code.

Why enumerator is Worse Than i

Firstly, the practice of naming an the index in a for-loop i is not good. You can avoid it by renaming i to thingThatIsIndexedIndex.

But at least, for(int i = 0; i < collection.size(); i++), is concise; therefore better than a equally-poorly-named NSEnumerator.

Also, there is something to be said for the idiom you can just use collection[i] over declaring an extra element variable.

The Right Choice

Everyone agrees informative names are good, yet poorly named enumerators are everywhere (just browse Apple’s sample code!) Poorly named enumerators persist because nobody really uses an enumerator per se, they are just part of an iteration idiom. (So stop declaring them and iterate smarter). When was the last time you saw code that did anything with an enumerator besides [enumerator nextObject] in a while loop?

But bad habits matter. Don’t pick up the habit of naming something poorly when it’s easy to do the right thing.

January 4, 2009

How To Beat Web Apps

Filed under: Cocoa,Design,Quotes,Usability | , , ,
― Vincent Gable on January 4, 2009

The way Apple stays ahead of the web app trend is by creating native Cocoa experiences that can’t be duplicated in web apps — both on the Mac and iPhone.

—John Gruber

December 31, 2008

Ellison’s Law

Filed under: Quotes,Security,Usability | , ,
― Vincent Gable on December 31, 2008

Carl Ellison (a cryptographer at Intel, a great guy) formulated what I call Ellison’s Law, which states that the userbase for strong cryptography declines by half with every additional keystroke or mouseclick required to make it work. Think about that when you’re designing tools.

–Cult of the Dead Cow

Mac OS X Redesign: Feedback for “Hold Keys”

Filed under: Design,MacOSX,Usability | , , , ,
― Vincent Gable on December 31, 2008

To prevent particularly bad slips (physical, not cognitive, mistakes), Apple makes certain keys hold keys. That means you have to hold them down for a while before they do their thing, unlike any other button that you just tap to use. This prevents accidentally engaging the hold keys, because a quick tap isn’t enough to trigger them. Unfortunately, it causes major problems for users. Apple could fix things by simply adding 3 words to the key-pressed-indicators they already use, and displaying it immediately.

The eject key is a hold key on MacOSX 10.4.9+. It’s a pretty bad thing to accidentally activate, because it takes several seconds to put a physical disk back into a tiny slot . By comparison the most common slips (typos), can be corrected in a split-second with 2 keystrokes(delete + the right letter). The eject key is located just above the delete key (which behaves like backspace on other computers), and right next to F12, which by default is mapped to Dashboard. Both of these keys are relatively high traffic, so it’s a sure bet that many a slipped finger will tap the eject-key. Making the eject-key a hold key prevents accidental taps, because a tap isn’t enough to trigger it.

caps lock on new keyboards is a hold key to turn on (but not off). Anything that makes caps lock harder to engage is great, since there’s no good reason to have a caps lock key anyway.

But there is a big problem with what Apple has done here. There isn’t any indication that hold keys are special. Worse, if you try to use one the way you use every other button on the keyboard, mouse, or computer — by tapping them – nothing happens. It’s like the hold keys are broken. here’s a video showing how confusing the eject key is.

One of the first things I noticed after updating Mac OS X Tiger to 10.4.9 was that my CD eject key didn’t seem to work anymore

Unfortunatly, that is a common reaction.

All hold keys should give immediate feedback when tapped, and also indicate that they need to be held down to trigger their action. Macs already flash an translucent eject indicator when the eject key’s action is performed:

Media Eject Symbol

Immediately displaying the following indicator, and pulsing the symbol when the action is triggered does everything we need:

Media Eject Symbol + 'hold key down' message

This is just a quick mock-up to get the idea across, it has a lot of flaws.

Unlike the eject symbol, the text has no drop shadow — this makes it less busy, and easier to read; but arguably unaesthetic.

The text is in all lowercase, because all words on Apple keyboards are in all lowercase. The idea is that it more closely associates the instructions with the keyboard. It’s probably a mistake, since it does not follow the capitalization rules for Mac OS X, but it made sense to me at the time.

The text also should have a stronger border, so it will show up clearly no matter what it is displayed over. And it should be bigger. And in a better font.

But hopefully this is enough to get my idea across.

December 30, 2008

Different Symptoms of Different Eyestrain

Filed under: Accessibility,Design,Usability | ,
― Vincent Gable on December 30, 2008

(Sheedy, Hayes, & Engle) found that reading with difficult environmental conditions such as upward gaze, glare, flickering light, or small text caused the participants to report symptoms of burning, irritation, and dryness.

While reading with internal problems like having to turn your eyes inward, astigmatism, and stress on the focusing lens caused the participants to report ache, strain, and headache.

Sheedy, J.E., Hayes, J., & Engle, J. (2003). Is all Asthenopia the Same? Optometry and Vision Science, 80 (11), 732-739.

Via fontblog.

December 26, 2008

Which Side To Use

Filed under: Accessibility,Tips,Usability |
― Vincent Gable on December 26, 2008

If you are ambidextrous, feel smug and ignore this.

Keep your keys, wallet, or whatever opens doors, in your weak-side pocket.

This is a bit counterintuitive. I used to keep them in my strong-side pocket for years. It’s natural to use your strong hand to unlock a door or buy a sandwich. But it causes problems when you need to open a door while carrying something awkward/heavy (say groceries, a cat, etc).

You should be carrying awkward things with your strong hand. It’s safer and easier. But when your strong-hand is full, it’s hard to get keys from your strong-side pocket. Meanwhile, keys in your weak-side pocket are still easy to employ.

I’m not especially dexterous, but in my experience, using my weak hand to unlock something hasn’t been a problem. I expected it to be harder, but honestly it hasn’t been perceptibly more difficult. Keeping keys in my weak-side pocket has been nothing but good.

Mobile-phones, pocketknives, cameras, PDAs, etc. should be in your strong-side pocket.

You should be using your strong-hand when you use them, but more importantly you (generally) don’t need to use them while carrying something. Cutting stuff while carrying a bag of groceries is a bad idea, for example.

But, anything you need to use while your strong hand is full should still live on your weak side with your keys. Phones make handy flashlights, for example.

Hold drinks with your weak hand.

I’ve been trying to train myself to do this for years, and I haven’t been able to.

The theory is that your weak hand is plenty up to the task of bringing a glass to your mouth (if it isn’t, you shouldn’t be drinking!), and it’s useful to have your strong hand free. Plus holding a cold drink makes your hand cold and wet, which surprisingly isn’t cool when you need to shake with that hand. So holding drinks in your left hand = a better first impression.

December 18, 2008

Fast Enough or Not Enough Fast?

Filed under: Quotes,Usability | , ,
― Vincent Gable on December 18, 2008

…people are now willing to make trade-offs against performance. For the entire history of the PC industry, computers have been too slow, so trade-offs were made in favor of faster CPUs: higher prices and heavier laptops. But today, for many common tasks, the type of CPU you get when you build a $400 lightweight laptop is fast enough. That’s (a) breakthrough.

—John Gruber

Cynically I also wonder if this is because “more cores” isn’t as compelling as faster. As Hank Williams says,

The problem of multi-core computing is really very simple. As most of us have experienced, every problem *can’t* be solved better or faster with more people. Some problems can be solved faster by adding a few people, but most problems cannot. In truth, most problems can best, or only be solved by one person at a time. And so it is with computing. The vast majority of problems can only be solved by one logic thread at a time. The reason is obvious. For most process-oriented work, step B is based on the results of step A. And step C is based on the results of step B, and so on.

« Newer Posts — Older Posts »

Powered by WordPress