Vincent Gable’s Blog

September 5, 2009

June 22, 2009

(Hyper)Text is King of Substance

Filed under: Accessibility,Design,Quotes,Usability | , , , , ,
― Vincent Gable on June 22, 2009

…I’d rather have the text of Clay’s speech than the video. For things that matter, written words are unambiguously better than speech. To start with, anything that matters isn’t just written, it’s usually rewritten repeatedly (and more important, condensed). Plus, it has hyperlinks. Plus, it’s smaller and cheaper to ship around. Plus, it’s searchable. Plus, it works on more devices. (I acknowledge that only the first of these is fundamental; but that alone would be enough).

Tim Bray

Videos, speech, etc. will always carry more emotional content. But for consuming ideas, text offers the highest bandwidth and most precision. Unfortunately, writing well takes time, and can hinder conversation.

Conceptually, I believe illustrative pictures and infographics are valid elements of modern text, like links, or typography.

April 30, 2009

Acceptable Delays

This is a collection of sources on what constitutes an acceptable delay. It’s very much a work in progress, and will be updated when I stumble into new information. I’m very interested in any insights, experience, or sources you may have.

Based on some experiments I did back at IBM, delays of 1/10th of a second are roughly when people start to notice that an editor is slow. If you can respond is less than 1/10th of a second, people don’t perceive a troublesome delay.

Mark Chu-Carroll

One second … is the required response time for hypertext navigation. Users do not keep their attention on the page if downloading exceeds 10 seconds.

Jakob Nielsen, (in 1997?)

In A/B tests (at Amazon.com), 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. (eg 20% drop in traffic when moving from 0.4 to 0.9 second load time for search results).

Greg Linden covering results disclosed by Google VP Marissa Mayer

If a user operates a control and nothing appears on the display for more than approximately 250 msec, she is likely to become uneasy, to try again, or to begin to wonder whether the system is failing.

— Jeff Raskin, The Humane Interface (page 75)

David Eagleman’s blog post Will you perceive the event that kills you? is an engaging look at how slow human perception is, compared to mechanical response time. For example, in a car crash that takes 70ms from impact until airbags begin deflating, the occupants are not aware of the collision until 150-300 milliseconds (possibly as long as 500 milliseconds) after impact.

April 21, 2009

A Scalpel Not a Swiss Army Knife

Filed under: Design,iPhone,Programming,Quotes,Usability | ,
― Vincent Gable on April 21, 2009

Steven Frank summarizing feedback on the direction future of computer interfaces,

The other common theme was a desire to see applications become less general purpose and more specific. A good example was finding out train or bus schedules. One way to do this is to start up your all-purpose web browser, and visit a transit web site that offers a downloadable PDF of the bus schedule pamphlet. Another way is to use an iPhone application that has been built-to-task to interface with a particular city’s transit system. It’s no contest which is the better experience.

…In 2009, it’s still a chore to find out from the internet what time the grocery store down the street closes — we’ve got some work to do.

I would like to see a nice pithy term replace “very specific task-driven apps”. Perhaps “Specialty Applications” or “Focused Programs”. But I’m not enamored with ether. Whatever the term, it should emphasize excelling at something, not being limited. What are your thoughts for a name?

February 9, 2009

Color Blindness

Filed under: Accessibility,Design,MacOSX,Programming,Usability | , , , ,
― Vincent Gable on February 9, 2009

Roughly 10% of men are color blind to some degree. You need to be sure your interfaces are accessible to them. (Unless you are designing exclusively for women I suppose, since women are about 20x less likely to be color blind.)

Sim Daltonism is the best way to test an interface on Mac OS X I’ve seen.

Here is a web-based colorblindness simulator. Here is another. Personally I prefer a native program though. It’s faster and more versatile.

If you are curious, you can test yourself for colorblindness. I have no idea how accurate that test is, but since different displays and operating systems usually show colors differently I’d be a little skeptical.

ADDITION 2009-10-11: WeAreColorBlind.com is a website dedicated to design patterns for the colorblind.

January 9, 2009

Biometrics

Filed under: Design,Quotes,Research,Security | , , , ,
― Vincent Gable on January 9, 2009

Summary of an article by Bruce Schneier for The Guardian,

Biometrics can vastly improve security, especially when paired with another form of authentication such as passwords. But it’s important to understand their limitations as well as their strengths. On the strength side, biometrics are hard to forge. It’s hard to affix a fake fingerprint to your finger or make your retina look like someone else’s. Some people can mimic voices, and make-up artists can change people’s faces, but these are specialized skills.

On the other hand, biometrics are easy to steal. You leave your fingerprints everywhere you touch, your retinal scan everywhere you look. Regularly, hackers have copied the prints of officials from objects they’ve touched, and posted them on the Internet. …

Biometrics are unique identifiers, but they’re not secrets.

biometrics work best if the system can verify that the biometric came from the person at the time of verification. The biometric identification system at the gates of the CIA headquarters works because there’s a guard with a large gun making sure no one is trying to fool the system.

One more problem with biometrics: they don’t fail well. Passwords can be changed, but if someone copies your thumbprint, you’re out of luck: you can’t update your thumb. Passwords can be backed up, but if you alter your thumbprint in an accident, you’re stuck. The failures don’t have to be this spectacular: a voice print reader might not recognize someone with a sore throat…

In Why Identity and Authentication Must Remain Distinct, Steve Riley cautions,

Proper biometrics are identity only and will be accompanied, like all good identifiers, by a secret of some kind — a PIN, a private key on a smart card, or, yes, even a password.

May 18, 2008

Intuitive Considered Harmful

Filed under: Accessibility,Design,Programming,Quotes,Research,Usability | ,
― Vincent Gable on May 18, 2008

intuition
noun
the ability to understand something immediately, without the need for conscious reasoning.

“Intuitive” sounds like a great property for an interface to have, but in The Humane Interface (pages 150-152), Jeff Raskin calls it a harmful distraction:

Many interface requirements specify that the resulting product be intuitive, or natural. However, there is no human faculty of intuition…When an expert uses what we commonly call his intuition to make a judgment … we find that he has based his judgment on his experience and knowledge. Often, experts have learned to use methods and techniques that non-experts do not know… Expertise, unlike intuition, is real.

When users say that in interface is intuitive, they mean that it operates just like some other software or method with which they are familiar.

Another word that I try to avoid in discussing interfaces is ‘natural’. Like ‘intuitive’, it is usually not defined. An interface feature is natural, in common parlance, if it operates in such a way that a human needs no instruction. This typically means that there is some common human activity that is similar to the way the feature works. However, it is difficult to pin down what is meant by ‘similar’. … the term ‘natural’ (can also equate) to ‘very easily learned’. Although it may be impossible to quantify naturalness, it is not to difficult to quantify learning time.

The belief that interfaces can be intuitive and natural is often detrimental to improved interface design. As a consultant, I am frequently asked to design a “better” interface to a product. Usually, an interface can be designed such that, in terms of learning time, eventual speed of operation (productivity), decreased error rates, and ease of implementation, it is superior to both the client’s existing products and competing products. Nonetheless, even when my proposals are seen as significant improvements, they are often rejected on the grounds that they are not intuitive. It is a classic Catch-22: The client wants something that is sigificantly superior to the competition. But if it is to be superior, it must be different. (Typically, the greater the improvement, the greater the difference.) Therefore, it cannot be intuitive, that is, familiar. What the client wants is an interface with at most marginal differences from current practice — which almost inevitably is Microsoft Windows — that, somehow, makes a major improvement.

There are situations where familiarity is the most important concern, but they are rare. One example is a kiosk at a tourist attraction. Millions of people will use it only once, and they must be able to use it as soon as they touch it (because they will walk away rather then spend their vacation reading a manual). And in such cases, mimicking the most promiscuously used interface you can find, warts and all, makes sense — if that means more people will already know how to use it.

Outside of rare exceptions, software that people use enough to justify buying is used repeatedly. The value of the product is what people make with it, not what they can do with it the moment they open the box. Designing for the illusion of “intuitiveness” is clearly the wrong choice when it harms the long-term usefulness of the product.

This is not an excuse for a crappy first-run experience! The first impression is still the most important impression. By definition, the less familiar something is, the more exceptional it is. And an exceptionally good first impression is what you are after — so unfamiliarity can work to your advantage here. It is more work to design an exceptional first-run experience, but good design is always more work.

This is not a rational for being different just to be different. It is a rational for being different, when different is measurably better. For something to be measurably better, it first needs to be measurable. That means using precise terms, like “familiar” instead of “intuitive”, and “quick to learn” not “natural”.

April 11, 2008

NSWindow setResizable:

Filed under: Cocoa,MacOSX,Objective-C,Programming,Sample Code | ,
― Vincent Gable on April 11, 2008

-[NSWindow setResizable:(BOOL)] does not exist. But, here is a way to get that effect as long as the window was resizable when created. (I don’t know of a way to make a window resizeable if it was first created unresizeable).

The basic idea is to show/hide the resizing controls, and implement delegate functions that prevent the window from being resized when the resizing controls are hidden.

//show or hide hide the window's resizing controls:
[[window standardWindowButton:NSWindowZoomButton] setHidden:!resizable];
[window setShowsResizeIndicator:resizable];

Note that setShowsResizeIndicator: only shows/hides the resize-indicator in the lower-right of the window. It will not make the window non-resizeable.

To keep the window from being resized when showsResizeIndicator is false, implement the delegate methods:

- (NSSize)windowWillResize:(NSWindow *) window toSize:(NSSize)newSize
{
	if([window showsResizeIndicator])
		return newSize; //resize happens
	else
		return [window frame].size; //no change
}

- (BOOL)windowShouldZoom:(NSWindow *)window toFrame:(NSRect)newFrame
{
	//let the zoom happen iff showsResizeIndicator is YES
	return [window showsResizeIndicator];
}

No Delegate Hack

Finally, there is a hack that avoids using delegate methods, although I don’t recommend it.

[[window standardWindowButton:NSWindowZoomButton] setHidden:!resizable];
[window setShowsResizeIndicator:resizable];
CGFloat resizeIncrements = resizable ? 1 : MAXFLOAT;
[window setResizeIncrements:NSMakeSize(resizeIncrements, resizeIncrements)];

setResizeIncrements “Restricts the user’s ability to resize the receiver so the width and height change by multiples of width and height increments.” So setting it to MAXFLOAT x MAXFLOAT means that the user can’t resize the window, because they won’t have a big enough screen. Note that this won’t disable the “zoom” function, although the user probably couldn’t use it with the zoom button hidden.

This approach uses slightly fewer lines of code, but it is more brittle and indirect, since it depends on the screen-size, not if the window is (visibly) resizeable. I wouldn’t use it over delegates. But here it is.

Powered by WordPress