In his Fast User Interfaces for the Cross-Device Web presentation at Google I/O in San Francisco, CA Boris Smus discussed the challenges of building Web interfaces that work across an increasing number of devices with different screen sizes and input methods. Here are my notes from his talk:
- What are the issues for cross-device Web design & development? Variety of form factors, CPUs and networks are slow, new kinds of input (touch, voice), development on actual devices.
- How are Web developers dealing with this? Two extreme options exist.
- Extreme 1: create one version for all screens without any adaptation. This will lead to sub-optimal experiences on many devices.
- Extreme 2: create a different version for each device. This is not theasible as the number of devices continues to increase.
- You need to seek a middle ground between level of effort and creating an optimized experience for each device.
Cross Device Options
- Align with Platforms: You might consider building to the specifics of each platform. After all, there are less platforms than devices
- Native platforms make it easy to build consistent user interfaces through SDKs and interface guidelines. So there are design references.
- But beware of emulating specific platform guidelines on the Web. They are hard to implement exactly and what you make will always be slightly off. Some differences between platforms are easy to deal with (visuals) others are more substantial (form factor of devices).
- Device Classes: create phone, tablet, desktop versions of your Web site. You can start from one version and tweak it to adapt to other versions.
- 650pixels is a good dividing line between smartphones and tablets that considers landscape mode and different device size sizes.
- Client Redirects: Device.js can be used to have the same URL load a different version of the site to a different device. This requires a redirect, which could slow things down a bit.
- Server Detection: On the server all we have is a user agent string, which is pretty messy to deal with. Yet many Web properties redirect users based on UA string and a device database. Device Atlas and WURFL can be used to identify devices but they are not easy to get up and running and not free.
- If you are using separate templates, start with device.js, see if the overhead is too much, if so then move on to server-side UA solutions if you need them to boost performance.
- To manage the issue of multiple templates, make sure you use a MVC structure for your app that separates the presentation layers.
- Jank-free UIs: the limit of human perception is 60 frames per second. Use hardware acceleration as much as possible to get your animations close to this frame rate.
- You can use transform and translate (esp 3D) to force hardware acceleration in CSS animations
- -webkit-overflow-scrolling: touch custom Webkit property that works on iOS and Chrome which forces hardware accelerated scrolling. This results in really fast scrolling on mobile devices. iOS also adds intertia scroll and bounce-back effects.
- Touch is not the same as mouse: no hover states, multiple points, less precise inputs, and will eventually will also measure pressure, size, and more.
- Touch events are usually delayed in the browser (300ms) to figure out what kind of gesture it is. Use touchend to react faster to touch inputs.
- Create separate handlers for input and drawing to manage the speed at which touch gestures come in. Request Animation Frame will give you as smooth an animation as possible.
- Microsoft’s MSPointer consolidates pen, touch, and mouse inputs into a single input model. However it works as another event type and isn’t well supported yet.
- Pointer.js consolidates the input model across browsers. It will also have gesture models on top of the pointer events.
- The easiest path to mobile development is to emulate it on the desktop through screen size, UA agent changing, and emulating touch events.
- Ultimately, you need to test on your device. Chrome has remote debugging tools available.