In The Wild: What Using Touch-Enabled Ultrabooks™ Actually Looks Like

One of the best places online to stay on top of the all the new Ultrabook news coming out (other than our very own Intel Ultrabook community, of course) is Ultrabook News, run by Steve “Chippy” Paine. Recently, Chippy received a brand new developer preview touch-enabled Ultrabook with Windows* 8 as part of his work as a judge for the Ultimate Coder Challenge. He’s been having a lot of fun with this machine, and while he can’t spill details about what’s actually inside, he can certainly show us what certain processes look like, namely, touch. In a recent post, Chippy talked about three different touch scenarios that he’s run across so far in his time with his new Ultrabook, and the pros and cons of each possible situation. Let’s take a look at each of these three scenarios, and get a feel for what we can expect from these devices.

First scenario: easy content consumption

In a short video demonstration, Chippy showed off his mad skills in Fruit Ninja, a game that invites you to use both hands, one hand, all five fingers, whatever you might feel comfortable with in order to slice and dice fruit as it comes whizzing at you. Holding the screen with both hands at times, flicking with his fingers at other times, we were shown several different ways that he interacted with the touchscreen.

This coincided with what we know about touch and touch design very well.  All devices have different “postures”, or ways we hold them, making on-screen real estate easy, moderately easy, or difficult to reach. For example, all of the action in Fruit Ninja was right in the middle of the screen or on the sides, making it easy to swipe with fingers all the way across or use thumbs with fingers behind the screen as leverage. All the controls that made decisions beyond gameplay were well out of “easy” range, i.e., the pause button was in the bottom left-hand corner where it wouldn’t get accidentally jostled during a bout with an angry watermelon. Content consumption is easy with this style of touch-enabled app.

Second: easy but with difficult elements

The second scenario demonstrated an app called MetroTweet that was relatively easy to use using touch, but offered more difficult components that took just a little bit more getting used to. It required a different posture than we saw in the first touch scenario, and important controls were placed in parts of the screen that were more difficult to reach than others, including center scrolling which is reportedly somewhat unwieldy to master.

Basically, it comes down to this: when designing for touch, developers need to keep in mind the physicality of what people will be actually doing. Scrolling in the middle of the screen is awkward. There are many apps like this that offer both comfortable and uncomfortable input, and they might struggle for full adoption by consumers without redesigning the touch experience.

Third: difficult but worth it for major productivity

The third scenario was especially intriguing to me. Chippy went right from talking about how developers need to cater to consumers and how we use touch to discussing how some apps are really hard to use with touch, but they can pay off with a little practice. It just depends on how productive the app really is the long run and if it’s worth your time to master the most effective input methods.

The app featured in this scenario was PowerDirector, an editing app for multimedia. Chippy showed us how easy it was for him (after a lot of practice, mind you) to drag stuff around, put clips on the timeline, and perform basic functions. However, he was quick to point out that this was not as smooth as it could have been. For example, crucial features such as hovering over something to reveal more information are missing in touch-enabled apps, and many websites use this to reveal more features and expand sections. It’s very difficult to accomplish this in touch design, since you can’t see what you’re pushing with your finger and you only have one chance to hit a (possibly too small) target. There are touch screens that can detect a hover command with special pens but there are none right now that can do this with fingers. This is just another good challenge for developers as we’re in the early stages of touch design to keep on pushing for better and better functionality.

Now, why push on through with an app that obviously takes more practice to master in touch when you can probably just use the keyboard? From my view, the primary benefit was simply speed.  Within the space of a few seconds, Chippy was able to accomplish much more than he would’ve with a keyboard in this scenario. It just really depends on how you want to work and what is most comfortable for you; either way, you have two options.

Different levels of touch, all useful

We’ve seen three different touch use scenarios here. First, a pure consumption-style situation where touch is absolutely easy to use and takes almost zero practice to master. Second, a more complicated touch input style for a dedicated app that requires more movement, some of which might be a little bit awkward and it’s up to the user if it’s worth the trade-off. Third, apps that require some getting used to and could even be considered difficult to use with touch; however, the trade-offs are greater productivity.

Really, it’s completely up to the user how they want to use the touch-enabled Ultrabooks. There are times when using touch is what you need, and there are times when using the keyboard along with touch fits the bill, and then there are times when just using the keyboard and mouse gets you where you need to go. The main thing to remember is that everyone is different and there’s no “one size fits all” input style. These three scenarios showed us not only what touch might look like, but they also showed us the benefits of experimenting and testing new ways of getting things done. As we move toward the release of touch-enabled Windows 8 and Ultrabook, I’m sure that there will be as many different ways to use touch as there are owners of these devices. 

Pour de plus amples informations sur les optimisations de compilation, consultez notre Avertissement concernant les optimisations.