touch friendly vs. regular | The Coffeehouse

Ion Todirel
buuu

Do you think an application's UX should be modeled depending on the target machine configuration and capabilities? For example should an application's UI be different (massively, but should be simple enough) and optimized if the application will be run [mainly] on a machine with [multi]touch-screen capabilities? If so, for machines with no touch capabilities should the application provide a different UI?

Maddus Mattus
Do, or do not. There is no try. - Yoda

It's always a good idea to provide the best user experience for a certain setup.

But it's kinda like with the Wii, some games just don't work with the controller. I get the same vibe with multitouch. It's really neat and all, but if it doesnt add something you can best leave it out.

And ofcourse, we need to explain to our customers the added value of a multitouch enabled interface. It's all fun and games when you are developing a product (like Windows 7), but when you are developing a solution for a customer, I have a hard time explaining why we need a user experience guy, let alone we need 25% more budget just to integrate a multi touch UI.

I think it will be a couple of years, when people take it for granted, that we are really going to see multi touch in all our applications.

And for hardware that doesnt support multitouch, you can always plug in another mouse Smiley

AndyC

Depends on the application. If it's something that will run exclusively on a multi touch machine, there is justification in a special UI completed designed for touch/multi-touch.

If it might run on a machine that is multi-touch enabled then it gives a better experience if the UI adapts slightly to facilitate easier use through touch (see Explorer in Windows 7 for some good examples), but the UI shouldn't change completely - just because my laptop has a multi-touch screen it doesn't mean I won't be using the traditional keyboard/mouse or the stylus and I certainly don't want to have to learn an entirely different UI.

In the more normal case that an app is unlikely to be used on a touch machine, but just might be, then it might be worth considering the UI design such that you don't make it unnecessarily frustrating.

Ray7

That's a really good question.

I'd rather see a UI that is geared toward the hardware it is designed to run on, but as Maddus and Andy have said, chances are you're going to be running on both. A wildly different experience will be a nightmare for people who use both. I would probably be more inclined to stick lean more closely to the regular desktop UI since I'm not sure that we've reached the 'multi-touch is everywhere' stage yet. (I still can't see why HP are building multi-touch desktops - who wants finger their monitor?)

It really depends on where you see your app being deployed. Is it for taking notes? Data acquisition?

Maddus Mattus
Do, or do not. There is no try. - Yoda

In reply to Maddus Mattus

#Sep 17th @ 1:15 AM

Multimouse support:

http://www.microsoft.com/unlimitedpotential/TransformingEducation/MultiPoint.mspx

So,.. the point that some hardware does not support multitouch is moot,.. Just buy another mouse Smiley

Harlequin
http://twitter.com/TrueHarlequin

Think of a normal app vs. Surface. On the Surface there is no "top" or "bottom", you need to design a 360 degree interface, which I find most interesting.

Ion Todirel
buuu

hmm, true, I sure hope to see the day when all the hardware will have a multi touch screen and the apps running on them optimized for that

RLO

Typing this on a keyboard on a touchscreen, I don't think you should focus on "multi-touch" per se, but address common usage scenarios.

The problems I run across using applications on this computer, is the fact that the UI controls are not spaced out far enough or large enough to use effectively. If you look at most applications used in a touch screen environment, usually Point of Sales terminals, you see individuals not needing to have multi-touch. It is usually in the order of press button a, press button b, press button c.

Allowing the proper amount of spacing and enlarging the size of your UI controls, gives the user touch capability as well as maintaining backwards compatibility to the point and click UI.

Just my two cents, hope it helps.

exoteric
I : Next<I>

In reply to Ion Todirel

#Sep 17th @ 12:09 PM

A future dream scenario: wouldn't it be nice if you could model an application in such an abstract way that a program could generate a dynamic data-bound user-interface for it, have that user-interface adapt to a dynamic set of input devices (keyboard, mouse, touch, ambient light, ambient sound, etc.) and output devices (screen, ambient light, ambient sound, tactile feedback). The question: should or should not differentiate: depends on cost/benefit. No one answer fits all scenarios. I don't think an application should necessarily be optimized for any particular kind of input or output device, rather it should ideally embrace what the environment has, and adapt to it - find a way to read from and write to available devices based on some abstractions. Allright, long-term dream. Here and now: cost/benefit. Should Word optimize for multitouch? Probably not. Should Paint? Probably. Long-term Word should too, if "multi-touch" one day truly embraces keyboards and mice. Not around the near corner though...

Ion Todirel
buuu

found also this: http://msdn.microsoft.com/en-us/library/cc872774.aspx

Maddus Mattus
Do, or do not. There is no try. - Yoda

In reply to Ion Todirel

#Sep 18th @ 1:53 AM

WPF in .Net 4.0 will have gestures you can use,..