A recent video from UX thought leader Luke Wroblewski briefly touched on the topic of designing applications for 2 in 1’s accounting for the virtual keyboard. With 2in1s offering several different orientations and keyboard options in one form factor, it’s important to understand how to equip the user to get the most from all of them. Watch below:
2 in 1 devices – just like tablets and smartphones – don’t just offer physical keyboards, but they also offer the convenient option of virtual keyboards as well. Visual keyboards can impact how developers design apps for them on mobile devices; whether you’re dealing with a large or small form factor, half the screen real estate can be taken up by the virtual keyboard.
Keyboards on 2 in 1 devices are standard, and are there for whenever the user needs it, particularly for programs utilized in desktop mode that are not necessarily designed for touch, i.e., Excel. A 2 in 1 device is especially useful in this regard, since the user can utilize the standard desktop mode for working, then take a break from desktop/keyboard and flip it to tablet mode for more casual content consumption utilizing touch. The keyboard can also be used in conjunction with touch while in desktop mode on device.
One of the most appealing features of touch-enabled design, aka virtual keyboards, is how it makes the content much more intimate, playful, and overall just more fun to interact with. Touch design "cuts out the middleman", so to speak, of traditional desktop GUI controls (pointers, icons, forms, etc.), making it easier to get to what you want, fast. Getting users “closer to content” is great, but what do you do with them once you get them there? Sometimes textual input is needed, and while virtual keyboards are convenient, your WPM speed tends to dip down pretty low when using them. This is something that needs to improve as better touch design paradigms evolve.
This is true on larger touch-based devices as well. In the video, Luke points out a document app on 2 in 1 in which half the screen is given over to the virtual keyboard. Why is this important? The example is given of a user attempting to book a flight with a virtual keyboard. The controls that allow the user to select a date are virtually inaccessible when the keyboard is showing.
Is there a way developers can get around this irritating problem? Yes. There are a couple of different design techniques that can be applied. First, virtual keyboard positions and inputs should be right on top; for instance, a comment field and the “Send” button could be in the top position for a virtual keyboard position, front and center, allowing for streamlined input. Access to primary controls and input functions should be the goal of virtual keyboards, not obscuring them.
Some form factors do offer a virtual keyboard that is more responsive to user inputs than others; sensing when users are done filling in fields and moving around the interface in a forward fashion. Vertical orientations might not be the best choice for these touch-based interfaces; instead, developers can possibly consider horizontal controls. There really is a limited amount of vertical screen space available, thus, developers need to design accordingly, considering that when the virtual keyboard is up, half the screen real estate has disappeared.
Touch has a ways to go, especially when you consider the latency problem. The average touchscreen and virtual keyboards have a bit of a lag between the user touching the screen the screen displaying the reaction; that’s why when you’re dragging an app across the screen it does a bit of a dance around your fingers. A quote from a recent touch latency study speaks to this:
“The difference is staggering, especially when Dietz trots out the slow-motion footage. With the delay between touch input and screen response slashed by orders of magnitude, a device that sports the sort of super-low-latency Dietz envisions has the potential to feel far more (for lack of a better term) natural than its brethren. There’s zero delay when you slide a checker across a board, for example, and bringing that sort of instantaneous feedback to the many screens in our lives could help to bridge the gap between operating a bit of software and the feeling of interacting with objects.”
Developers should keep in mind multiple touch postures and touch usages when using this device to make it sync as easy as possible with whatever apps they come up with. App input controls, like swiping, should be intuitive with the operating system controls; otherwise data could be lost (for more on making touch-based apps, read Touch Design Principles). Touch is expected in today’s marketplace. Applications that are designed to use touch intuitively will be especially enjoyed in tablet mode on a device like this.
The 2 in 1 device offers up different usage modes for PC apps. Smart developers will take advantage of those modes, building apps that leverage the desktop mode when it’s needed, as well as the tablet mode when it’s required. The keyboard is still the best experience for productivity-focused activities, including apps, but virtual keyboards are becoming more ubiquitous. Developers should keep that in mind when developing apps for the 2 in 1 form factor.
For more in this 2 in 1 series from Luke Wroblewski, check out the following links: