TouchWeb
From MobileDesign
Contents |
[edit] A Summary of Touch
No pointer, no highlight, the hand gets in the way. Inadvertent touches are easy. Stylus pointing is somewhat inaccurate due to parallax and digitizer issues, finger-pointing is much worse.
[edit] How Touch is Different (from other mobile)
All touch screens have some common issues: the touch digitizer is not fully accurate, there is a distance between the surface being touched and the graphics being displayed causing parallax, and edges of screens cause problems for a handful of reasons. The addition of finger interaction makes touch even less accurate, so targets need to be bigger. The user’s finger and hand will obscure the screen during interaction, requiring both more movement from the user and larger targets from the device.
Most touch + script browsers will be highly standards compliant, with CSS3 support. Expect Pocket IE to lag. Coding “gestures” may be more difficult. The screen interaction causes more user errors: scrolling might be more difficult due to the array of controls on the screen, the finger is less accurate for selecting, and parallax. Thus error control is especially important.
[edit] How Touch is the Same
The current batch of touch browsers, no matter how capable, are still on mobile phones. Battery life is difficult. The Skyfire and Opera Mini browsers likely uses the same battery regardless of the web page, and are thus in a special case of most work done on the server.
[edit] Scripting Adds Complexity
Any time capabilities are added to a platform, the number of ways to make things bad for the user also increases. For example, standard Ajax techniques allow for updating part of a web page. If that part of the page is outside the current viewport, the user may never notice. Further, moving the user’s focus to another area can be especially annoying unless the user requested it.
[edit] App Considerations
This article is about touch practices for web, in which we have limited rendering. Once we move into apps, consider the following:
- Responsive UI. Ensure that your UI frame rate is at least 30 frames per second (fps), preferably 60. Check out this TAT video on solid UIs and framerate
- Keep gestures simple. While people can technically remember hundreds of gestures, they probably won't be motivated to do so.
- Provide affordances and feedback that make touch gestures obvious.
- If a gesture is neither obvious (tap, drag) nor readily recalled (swipe to page-scroll on iPhone idle screen), then ensure that the gesture is not the only way to accomplish the goal.
- Use standard human factors design principles. Design for real hand sizes, obscured views, and so forth.
Check out Punchcut's design considerations for touch UI for more.
[edit] Best Practices (Web)
[edit] General Design
It’s still a mobile browser, so speed is important. With a more natural interaction, lack of responsiveness is even more important. Use best practices for mobile design, but with scripting. Additionally, browsers have varying capabilities. Use graceful degradation and progressive enhancement, as noted by the W3C document on mobile web app best practices.
- Use light backgrounds to reduce glare and fingerprints.
- Use lightweight script elements. These need to be responsive to user interaction immediately, not at a delay.
- Consider using scripting such as JQuery to enhance the experience for effects like transitions ... but only if it is low processor load and rapid response.
- Provide ready cancellation of actions.
[edit] Clickable Elements
Anchors, buttons, and more.
- Provide spacing, at least 1/8” (20 or more pixels for an iPhone) between clickable elements ... unless the clickable elements are larger than 1/3” (50+ pixels)
- Provide large target sizes, at least 25 pixels for rare elements, 1/4” (40 or more pixels for an iPhone) for frequent. Note that the visual element need not be this large, just the clickable area. This is both for fat fingers and reducing eye-touch parallax.
- Make button targets near the edge large enough that users will be able to reliably press them, regardless of touch screen calibration variance. Screens with bezels at the edges or with lower accuracy at the edges will result in fewer errors.
- Avoid full-width clickable elements without any space between them. This oddity is due to how the user must scroll the page. Mostly, a page is scrolled by “grabbing” the page and moving it up or down. If all parts of the page, or most parts of the page, are clickable, the first part of the grab can be interpreted as a click, thereby preventing the user from accessing the whole list. In a list of European cities, Zurich may never be found.
- Avoid mouse events other than click.
- Ensure the on-mouse-down highlight area, typical indicated by the element plus padding, is approximately the same size as the visual element, if not larger.
[edit] Page Layout
[edit] Dealing with A New Browser Scrolling Method
Many touch browsers, such as iPhone’s Safari, scroll not by operating a scroll bar, but by “grabbing” the page and “moving” it. Mostly, this is a good thing; certainly it is easier to do than to find a 3-pixel-wide scrollbar. It does have some inherent disadvantages as well, as you have to perform one grab per screen height: rapid access to 5 screen heights away is inconvenient. These browsers also rescale full web sites. The result is that unless the user is quite focused on moving up and down, a scroll gesture will follow the arc traced by the thumb as it moves. And the page will move sideways, even if no content is readily available.
Define a viewport. This tells Safari and Opera Mobile (and likely Opera Mini) that the page is mobile optimized.
<pre><meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/></pre>
- Don’t allow scaling. (user-scalable=false or 0) Opera will ignore this, but likely won’t have the diagonal scroll problems that Safari users do. Exception: if providing content that responds well to scaling, such as detailed images, then scaling may make sense.
- Set width to device width. On Safari, use the viewport
- Only pages of content that most likely will be read screen by screen should be longer than about 4 screens long. Don’t make the user flick down 5 pages to find something known to be there. A workaround: within-page links.
[edit] Elements
Unlike with scroll-and-select interfaces, a tab-like display will be quite effective design. In general, use a single-column layout.
[edit] Styling
Most high end browsers will support enhanced CSS3 styling capabilities.
- Use CSS3 rounded corners to enhance aesthetic without increasing file size
- Use opacity settings to enhance aesthetic.
- Consider using a single image for all non-content images in a page or site to reduce http requests, for fully scripted high end browsers only (Safari, Opera Mobile not Mini, Firefox). The CSS below accesses the larger star in the image to the right.
- Use large padding or enclosing linked divs to increase the target size
- Be sure the target size is at least as large as the visual presentation
- Stay away from the edge of the screen, at least 5 pixels
[edit] Gestures
Apple has provided a gestures API to enable multi-touch. These would be ideal for a task such as map zooming: the user already knows the gesture both generally and specifically. However, experience with Google Maps mashups on the iPhone has rendered unsatisfactory results. A typical developer comment:
“Panning is very jumpy and slow. Ignoring about 4/5 touch moves improves performance a little, so I hypothesise that the iPhone Safari javascript engine can't keep up with whatever script stuff happens on a setCenter(). The people at iphone-google-maps-component have found the same thing (although that component uses native iPhone events captured in a superview).” - one of many developers
Another issue with gestures is that even when the performance issues get resolved, they will only work on iPhones.
- Use gestures only on mobile Safari targeted pages
- Use pinch and pan only
- Optimize code for a rapid experience
- Continue to provide non-gesture interaction - the gesture might not be known to the user, and is not visible.
For touch interfaces, drag operations are imprecise, relatively slow, and smear the screen surface.
