Photoset

decodering:

How people really hold and touch their phones

Slides from a talk by Steven Hoober:

Despite decades of research and years of us all carrying a touchscreen mobile handset around, there’s a lot of myth, disinformation and half truth about how they work, and how best to design for touch.

Steven has evaluated dozens of studies and performed some of his own to find out how your users really grasp their phones, and how to make touch targets that work reliably.

Link

Affordances are the baby to skeuomorphism’s bathwater. When they engage our instincts just right, they create an emotional bond, and the unfamiliar becomes inviting. Without them, it’s just pictures under glass. It makes no difference how flat, how deep, how minimal, or how ornate the look-and-feel is if it can’t show us, when we look, how to feel.

(Source: twitter.com)

Tags: ux design
Link

Never use ‘Yes’ or ‘OK’ when you could use a verb instead.

And you can almost always use a verb instead of ‘Yes’ or ‘OK’.

I agree with Lukas Mathis’ postulation that nobody reads your dialog boxes. Use a verb whenever possible instead of ‘Yes’ or ‘OK’ because your buttons will make sense out of context with the explanatory text or title.

While we’re at wording, another interesting StackExchange UX “User Experience @ StackExchange” question: Should error messages apologize?

(Source: twitter.com)

Tags: ux wording
Link

Unfortunately a UI walkthrough is quite an inelegant way to explain the core functionality of an app. It can be a frustrating obstacle before you can dive into an app, and you have to remember all of those new ways of using it once you get in. […]

Arguably a less intrusive way compared to a walkthrough is to guide the user in the situation with UI hints. This can be done through slight visual cues and animations. A hint should not be a popup (it’s probably even more disruptive than a tutorial).

(Source: news.ycombinator.com)

Tags: ux
Video

You might wanna watch the video above, but in short: When scrolling content on a touch-screen, instead of letting momentum stop the scrolling, you can decide exactly where it should stop. It stops at the point where you flicked it.

(Source: twitter.com)

Tags: ux idea touch
Link

This method has several good points:

  • It can reasonably handle more than two options at once.. Eg, A, B, C, D, E, F, G, …
  • New options can be added or removed at any time.

But the most enticing part is that you can set it and forget it.

The strategy that has been shown to win out time after time in practical problems is the epsilon-greedy method. We always keep track of the number of pulls of the lever and the amount of rewards we have received from that lever. 10% of the time, we choose a lever at random. The other 90% of the time, we choose the lever that has the highest expectation of rewards.

Update: a reaction by Visual WebSite Optimizer: Why multi-armed bandit algorithm is not “better” than A/B testing.

There’s a clear tradeoff between average conversion rate and the time it takes to detect statistical significance. Moreover, it is also clear that any advantages of multi-armed bandit algorithms vanish if conversion rate of different versions is similar. […]
So, comparing A/B testing and multi-armed bandit algorithms head to head is wrong because they are clearly meant for different purposes. A/B testing is meant for strict experiments where focus is on statistical significance, whereas multi-armed bandit algorithms are meant for continuous optimization where focus is on maintaining higher average conversion rate.

(Source: twitter.com)

Tags: ux code idea
Link

(Source: twitter.com)

Tags: ux ethics iOS Apple
Text

WebKit placeholder better than the W3C specs?

Update 2/15/2012: previous version of this article was s/WebKit/Safari/g, but Chrome also implemented this behavior in v17.

Placeholder is a cool feature for HTML5 inputs and textareas that let you specify a sample/advice text in the form field when the user has not typed anything in. Unlike a default value - the actual value (sent on submit) is empty - the text is rendered with a distinctive look, usually a faded gray for black-on-white inputs - when the field is focused or not empty, it disappears

Indeed, the W3C specifications explicitly state:

User agents should present this hint to the user, after having stripped line breaks from it, when the element’s value is the empty string and the control is not focused

Firefox, Opera, and the polyfill for older browsers implement this to the letter:
W3C implementation: placeholder text is displayed when empty + unfocusedW3C implementation: placeholder text is hidden when focused

WebKit thinks different. It waits for the user to actually type in something before removing the placeholder text:
WebKit implementation: placeholder text is still displayed when empty + focusedWebKit implementation: placeholder text is hidden only when text is entered

This behavior can be useful, because the focused field doesn’t always means the user remembers the placeholder text. He may hit tab before reading the content of the next field. He may give focus to the field, switch to another tab or application (because of an unrelated event like IM as well as to copy/paste some information) and come back to the form. And if one would like to auto-focus the field in the first place, then the W3C-compliant implementation beacomes useless.

The only drawback I see to WebKit’s approach is that some user might be confused of some text being still present in the field while it’s focused, thinking it is content and unable to delete it. But the rendering is different and WebKit also uses this technique in its search bar, so I guess this confusion rarely occurs.
WebKit search bar

Also, placeholder is not to be confused with in-field labels, which is not the same purpose and shouldn’t use the same code, preferring labels + styling. Yet it can (and should even more than for placeholder) make use of the same mechanism of waiting for user input before removing the label.

We can use the same polyfill to force this behavior, but we’re faced with a dilemma here: feature detection won’t work, since placeholder is supported by, say, Firefox. So we must either use the polyfill on all browsers (even those supporting placeholders) but waste CPU in WebKit, or do vendor detection which we don’t like to rely upon.

Quote
"Quick #usability tip: Make disabled controls more obviously disabled with :disabled { cursor: not-allowed; }"

@LeaVerou

Tags: ux tip css
Quote
"I like this definition: A tool addresses human needs by amplifying human capabilities.
[…]
Hands do two things. They are two utterly amazing things, and you rely on them every moment of the day, and most Future Interaction Concepts completely ignore both of them.
Hands feel things, and hands manipulate things."

A Brief Rant on the Future of Interaction Design, by Bret Victor

(Source: twitter.com)