Tags: touch

22

sparkline

Wednesday, July 20th, 2016

Adapting to Input · An A List Apart Article

Jason breaks down the myths of inputs being tied to device form factors. Instead, given the inherent uncertainty around input, the only sensible approach is progressive enhancement.

Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.

Sunday, June 12th, 2016

Research with blind users on mobile devices | Accessibility

Some interesting outcomes from testing gov.uk with blind users of touchscreen devices:

Rather than reading out the hierarchy of the page, some of the users navigated by moving their finger around to ‘discover’ content.

This was really interesting - traditionally good structure for screen readers is about order and hierarchy. But for these users, the physical placement on the screen was also really important (just as it is for sighted users).

Monday, January 11th, 2016

Without delay

When I wrote about mobile Safari adding support for touch-action: manipulation, I finished with this snarky observation:

Anyway, I’m off to update my CSS even though this latest fix probably won’t land in mobile Safari until, oh ….probably next October.

Historically, Apple have tied mobile Safari updates to iOS version number increments, and they happen about once a year. But this time, it looks like my snark was unfounded:

On Safari for iOS, the 350 ms wait time to detect a second tap has been removed to create a “fast-tap” response. This is enabled for pages that declare a viewport with either width=device-width or user-scalable=no. Authors can also opt in to fast-tap behavior on specific elements by using the CSS touch-action property, using the manipulation value.

That’s from the release notes for Safari 9.1—a point release.

I’m very pleased to have been absolutely wrong with my prediction of Apple’s timing.

Wednesday, December 16th, 2015

More Responsive Tapping on iOS | WebKit

This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:

Putting touch-action: manipulation; on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.

It would be nice to know whether this has been discussed with other browser makers or if it’s another proprietary addition.

Saturday, August 9th, 2014

UX How-To with Luke Wroblewski - YouTube

A fantastic collection of short videos from Luke on interaction design for devices of all shapes and sizes.

Make yourself a nice cup of tea, hit “Play all”, sit back, relax and learn from the master.

UX How-To with Luke Wroblewski

Friday, December 13th, 2013

300ms tap delay, gone away - HTML5Rocks Updates

I think Chrome is doing the right thing by removing the 300 millisecond tap delay on sites that set width=device-width — it’s certainly better than only doing it on sites that set user-scalable=no, which felt like rewarding bad behaviour.

Tuesday, July 9th, 2013

Issue 18850005: Disable double tap zoom on mobile sites, to remove 300ms click delay - Code Review

Well, this is interesting: it looks like Chrome might stop waiting 300ms for potential double-tap-to-zoom events if the site is using a meta viewport declaration that sets the width to device-width.

Monday, February 18th, 2013

Designing for Touch by Josh Clark

Josh the Touchmaster is here at An Event Apart Atlanta to tell us about Designing for Touch.

Science! Science and web design. As Scott said, a lot of what we’re doing now is checking the nuances of things we’ve been doing all along. We’re testing our assumptions.

We had web standards. Then we had responsive design. Now there’s a new revelation: there is no one true input for the web.

There are lots of new input mechanisms coming down the pipe, but right now the biggest new one is touch. This talk is about designing for touch.

As of last month, 31% of US adults have tablets. A few years ago, it was zero. The iPad is the fastest-growing consumer product in the history of consumer products. But touch isn’t just for mobile phones and tablets. Touch is on the desktop now too. All desktop web designs have to be touch-friendly now.

The ugly truth is that we’ve thought of web design as primarily a visual design medium. But when you add touch into the mix, it gets physical. It’s no longer just about how your pixels look; it’s about how they feel too. You are not “just” a visual designer now. There are portions of industrial design in what you do: honest-to-goodness ergonomics. In a sense, you’re designing a physical device, because it will be explored by hands. Phones and tablets are blank slates. We provide the interface. How will it feel in the user’s hands? More specifically, how will it feel in one hand?

Phones

Thumbs are fantastic. The thumb, along with celebrity gossip, is what separates us from the beasts. There’s a natural thumb-resting area on the iPhone (coming from the bottom left to the centre). That’s why positioning conventions have evolved they way have on iOS—very differently to the desktop: navigation at the bottom instead of the top.

There’s an age-old principle in industrial design: content at the top; controls at the bottom. Now we see that in iOS. But in Android there are assistive buttons at the bottom (just as the industrial design maxim suggests). But now if you put your controls at the bottom too, you’ve got too much going on. So on Android you should be putting your controls at the top. But the drawback is that this is no longer in the thumb-sweeping area.

That’s iOS and Android. What about the web?

There are problems with pinning navigation to either the top or bottom. First of all, position: fixed is really screwy on mobile browsers. Secondly, in landscape (or other limited-height environments), the controls take up far too much room compared to the content. The third problem is also related to space: browser chrome.

Instead, a better pattern is to have a menu control that reveals navigation. The simplest version is when this is simply an internal link to navigation at the bottom of the page. As Luke says, forget HTML5: this is HTML1. Best of all, this pattern leads with the content and follows it with the navigation.

So that’s where things stand with touch navigation on phones:

  • iOS: Controls at screen bottom.
  • Android: Controls at screen top.
  • Web: Controls at page bottom.

Tablets

What about tablets? This is more likely to be a two-handed grip. Now having controls at the bottom would be really hostile to touch. The phone thumb-zone no longer applies, but thumbs still matter because they could be obscuring controls. Your thumbs are more likely to be on the sides, with easy reach to the top. So put controls in those regions where thumbs can come to rest: the side.

There are some cases where bottom navigation is okay: in an ebook where you’re showing a complicated control …or a map with a draggable interface below it. When you need a control to do browsing or preview for the content above it, the bottom is okay.

Hybrid

The unholy alliance: a laptop with a keyboard combined with a touch-enabled screen. There are lots of them coming down the line.

Mouse and trackpad usage drops off a lot on hybrid devices. There was always the fear of “gorilla arms” with hybrid devices but it turns out that people are gripping the sides of the screen (like a tablet) but when people are jabbing the screen, it’s more like a phone. If you overlay the thumb comfort zone of a hybrid laptop with the thumb comfort zone of a tablet, there’s one area that’s left out: the top …exactly where we put our navigation on laptop/desktop screens.

This is a headache for responsive design. We’ve been correlating small screens with touch. It turns out that screen size is a lousy way to detect a touchscreen. And it’s hard to detect support for touch. So, for now, we’re really just guessing.

But we have top men working on the problem. Top. Men. There’s a proposal in CSS4 for a pointer property. But even then, what will a hybrid device report if it supports trackpad, keyboard, mouse and touch?

Desktop

All desktop designs have to be touch-friendly. This is going to require a big change in our thinking. For a start, it’s time to bid farewell to hover events, certainly for crucial content …maybe it can be used for enhancements.

Given the thumb zones on tablets and hybrids, we can start putting frequent controls down the side—controls that stay in view even when the content is scrolled. Just to be clear: don’t put your main navigation there—put the controls that people actually use. Sorry, but people don’t actually use your main navigation. People use main navigation only as a last resort.

Quartz uses a very thumb-friendly layout. But how big should the touch targets be? It turns out …seven millimeters; the tip of a finger. Use nine millimeters if you really need to be safe.

I don’t know about you, but I’m not using millimeter as a unit in my CSS. But standards can help here. A pixel is defined in CSS2.1 to have a set millimeter size. But that doesn’t factor in the reality of dynamic viewports: zooming, pinching, scaling. Devices still report they’re actual physical size; the hardware pixels, that have nothing to do with the calculated web pixels.

On the iPhone we arrive at this magical 44 pixel number, which is repeated over and over throughout the UI. As long as one dimension is 44 pixels, you can squeeze the other dimension down to 29 pixels: 44x29 or 29x44. On iOS, that unit is repeated for a rhythm that just feels right: 44, 88, etc. The interface is designed not just for the hand, but of the hand. Use that rhythm, even on desktop screens.

That’s lovely and elegant. Digital watches are not. Touch targets need to be a certain size.

Now these optimisations mean there’s inevitably some constraint. But that can be a good thing: you might have to reduce what’s on your screen, and that means that your interface will be more focused. Clarity trumps density.

But simplicity isn’t always a good thing. Complexity has become a dirty word, but sometimes it’s needed. People don’t want a dumbed-down interface that won’t let them do everything.

And when you don’t have space constraints, that doesn’t mean you should fill up the space with crap. Aim for clarity, no matter what the size of the screen. On a smaller screen, that can be a more conversational, back-and-forth interaction, requesting and revealing information; question, answer; ask, receive. This progressive disclosure requires more taps, but that’s okay. Extra taps and clicks aren’t evil. When done right, they can actually be better because they provide clarity and invite conversation. As long as every tap is a quality tap that provides information, and helps complete a task, they are not evil.

But the long scroll …that is evil. That’s how kittens get killed.

Luke has documented the off-canvas pattern as a way of pushing some information off-screen. It’s kind of like a carousel. So instead of everything being stacked vertically, there can be sections that are navigated horizontally. That’s what Josh and Ethan did on the site for People magazine on small screens.

So for desktop interfaces, these are the points to remember:

  • Hover is an enhancement
  • Bottom left for controls.
  • Big touch targets.
  • 44px rhythm.
  • Progressive disclosure.

But even though Josh has been talking all about the touch interface, it’s worth remembering that sometimes the best interface is no interface at all. And we need to stop thinking about input mechanisms as singular things: they can be combined. Think about speech + gesture: it’s literally like magic (think: Harry Potter casting a spell). Aral’s hackday project—where he throws content from the phone to the Kinect—gets a round of applause. Now we’ve got Leap Motion on its way. These things are getting more affordable and available. So we could be bypassing touch completely. We can move the interface off the screen entirely. How can we start replacing clumsy touch with the combination of all these sensors?

Digital is growing more physical. Physical is growing more digital. Our job is becoming less about pixels on screens and more about interacting with the world. We have to be willing to challenge established patterns. We have to think. We have to use our brains.

Friday, January 4th, 2013

» Responsive Design for Apps — Part 1 Cloud Four Blog

A great piece by Jason analysing the ever-blurring lines between device classes.

Mind you, there is one question he doesn’t answer which would help clear up his framing of the situation. That question is:

What’s a web app?

Tuesday, November 6th, 2012

New Rule: Every Desktop Design Has To Go Finger-Friendly (Global Moxie)

Josh takes an-depth look at the navigation design implications of touch/keyboard hybrid devices, coming to a similar conclusion as Luke and Jason:

Unfortunately, the top-of-screen navigation and menus of traditional desktop layouts are outright hostile to hybrid ergonomics. Tried-and-true desktop conventions have to change to make room for fingers and thumbs.

Want to test for a hybrid device? Tough luck. Instead, argues Josh, the best you can do is assume that any device visiting your site could be touch-enabled.

Saturday, November 3rd, 2012

LukeW | Responsive Navigation: Optimizing for Touch Across Devices

Luke and Jason have done some excellent research (and put together some demos) into how the placement of navigation could be optimised for touch screens of all sizes. Turns out that the “standard” convention of having navigation along the top is far from ideal on a touch-enabled device.

Wednesday, November 9th, 2011

A Brief Rant on the Future of Interaction Design

The next time you make a sandwich, pay attention to your hands. Seriously! Notice the myriad little tricks your fingers have for manipulating the ingredients and the utensils and all the other objects involved in this enterprise. Then compare your experience to sliding around Pictures Under Glass.

Saturday, March 26th, 2011

Touching Strangers

The premise of this work is simple: I meet two or more people on the street who are strangers to each other, and to me. I ask them if they will pose for a photograph together with the stipulation that they must touch each other in some manner. Frequently, I instruct or coach the subjects how to touch. Just as often, I let their tentative physical exploration play out before my camera with no interference.

Monday, February 21st, 2011

YouTube - A Day Made of Glass… Made possible by Corning.

There are two things I’d like to see after watching this video:

  1. A slew of parodies to highlight the unintended consequences of this marketeer’s panopticon,
  2. The Paleofuture blog post in 100 years looking back at this.
A Day Made of Glass... Made possible by Corning. (2011)

Thursday, July 15th, 2010

Building iPhone Apps with HTML, CSS, and JavaScript

Jonathan Stark's book is available online, in HTML, for free.

Thursday, July 8th, 2010

Non Hover | Trent Walton

A timely reminder: don't hide information behind mouseover events.

Tuesday, September 15th, 2009

My first experience using an accessible touch screen device « Marco’s accessibility blog

A hands-on account of the new accessibility features in the iPhone. Sounds like a great experience.

Tuesday, March 3rd, 2009

BBC NEWS | Programmes | Click | Stevie Wonder interview

Stevie Wonder talks about assistive technology. I think this finally proves that yes, accessibility *is* sexy!

Sunday, July 13th, 2008

Last.fm – the Blog · Last.fm for iPhone and iPod Touch

If, like me, you were going cold turkey on Mobile Scrobbler after updating your jailbroken iPhone/iPod Touch, you can stop sweating now. The official Last.fm app is really, really nice ...and it's free.

Thursday, December 27th, 2007

Let’s Jailbreak the iPod touch 1.1.2 with OS X « RupertGee’s iBlog

A step-by-step guide to hacking your iPod Touch even if you've already upgraded to the new firmware.