[msandford]

This is hands down far, far better than what's out there already. A lot of thought went into this and it shows.

Could there be a few options to enter other modes, though? What I mean is that right now there are only 8 adjustments possible. That's better than the 4 I thought it was limited to, but still nowhere near enough for modern cars.

I would estimate that on a modern car you need to be able to adjust something like 100 parameters. Only a few of them frequently, but definitely more than 8 in total.

One of the thoughts I had was that using a (say 90 degree?) twist motion along with a number of fingers could bring up sub-menus. That way if you want to adjust other radio parameters like fade, balance, equalizer, etc you would put two fingers on (for volume) and twist.

Maybe you'd arrange the different controls in a loop so that every twist indexes to the next and there's a ~10 second timeout before you head back to the default. So if you want to adjust all the "volume" parameters you put two fingers and twist right once for balance and adjust, twist right again to get fade, twist right again to get highs, etc. Make a mistake? Twist left to go back and re-adjust.

If you want to get out of one of the sub-menus you're in prior to the ~10 second time-out for default, another gesture? Maybe a double tap? I don't know on that one, really.

[masklinn]

> I would estimate that on a modern car you need to be able to adjust something like 100 parameters.

Not the author, but the way I see it this is specifically an interface for adjusting things eyes-free when driving. In an actual implementation, there would be some sort of physical switch between the in-drive control (demoed here) and a high-density "at rest" operation for passengers or more specific tasks (e.g. configuring the GPS).

> One of the thoughts I had was that using a (say 90 degree?) twist motion along with a number of fingers could bring up sub-menus.

The problem with this is there'd likely be a rotational component to movement, and a movement component to rotations, discriminating becomes harder and the chances of false positive (and thus frustration) increase. Only using a single axis is actually a smart move as far as I'm concerned.

[SimHacker]

I've found that pie menus with four different directions are quite reliable (see the description I posted here of the ConnectedTV palm app, which supported buttons with four different stroke directions plus tap). Eight different directions work well with a mouse or big touch screen, in situations where you can afford to give the screen some visual attention and the consequences of making a mistake aren't deadly, but I believe four directions are reliable enough for automotive applications, as long as you require enough motion to get enough "leverage" and give decent feedback.

[msandford]

> The problem with this is there'd likely be a rotational component to movement, and a movement component to rotations, discriminating becomes harder and the chances of false positive (and thus frustration) increase.

I agree that you might end up rotating your fingers SOME while moving them up or down. But I'm not sure that I agree that you would move them 90 degrees completely unaware. In order to move your thumb and index finger from vertical aligned to horizontally aligned you're going to require some (maybe a lot) of wrist motion. It's hard to make that wrist motion happen accidentally.

You might end up setting it to accept a range between 70 and 120 degrees to qualify for a "go to the next setting" motion and you can provide some kind of feedback (vibratory or audible or both) that you have indeed twisted far enough to trigger the change.

[SimHacker]

When designing pie menus, there are both physical (articulatory) and mental (cognitive) factors that you should consider when choosing the number of items and their directions.

Gordon Kurtenbach and Bill Buxton did an experiment that varied the number of menu items and measured the selection time and error rate. They expected the selection time to be monotonically increasing as they added more items. To their surprise, that was almost true, except for the transition from seven to eight items. It was quicker to select from an eight item menu, then from a seven item menu!

That, I believe, was because of the effect of the cognitive bottleneck of associating the items with which direction to move, not the physical difficulty of moving in those directions. While the slices of the seven item menus were wider and had more area than the slices of the eight item menus, and Fitts' Law would predict that seven item menus were faster than eight item menus, Fitts' Law does not take into account the time it takes for users to map their intended command to the direction of that command, and how the mental framework in which users remember and relate the directions to each other affects selection time.

Eight item menus have all of their items in well known directions, each of which is associated with a very familiar concept, which come in nice pairs, and the pairs come in convenient orthogonal groups, like up/down, left/right, vertical/horizontal/diagonal, like compass directions.

Twelve item menus like a clock face also work well, especially for circular sets of items like hours, months, zodiac signs, etc. But the effect going from 11 to 12 is not as dramatic as from 7 to 8. But still the 12 item menu has a nice familiar aesthetically pleasing cognitive framework (including opposite and orthogonal pairs, first tier vertical/horizontal axes and second tier in-betweens) that you can often exploit, depending on the content.

Three item menus are still slightly faster than four item menus, because the effect of the proportional difference in target area overwhelms the difference in the number of items, and two of three triangular directions are well known concepts that are pretty easy to remember, compared to six of seven directions.

An eight item menu optimally exploits that effect, while a seven item is unfortunately sub-optimal with mostly difficult to remember directions. There's no word or concept in the English language for six out of seven of those directions -- they're all just kind of slanted differently, similar to but not quite like the well known compass directions, and there are no nice symmetries, opposite or orthogonal groupings to exploit, by arranging complementary items in opposite directions, independent pairs along orthogonal axes, etc.

So if you're designing a pie menu with seven items (or even eleven), it's better to just throw another item in to bring it up to eight (or twelve)! I gave an example in the DDJ article of a "seven days a week" menu with an additional "today" item thrown in at the bottom to bring it up to eight, with the weekend and today in the lower part of the menu, and Wednesday at the top. See, I don't even have to link to a picture or enumerate every item for you to easily visualize and remember it!

[Schwolop]

I would build this switch with two IR sensors on each side of the console. If the arm and hand touching the screen is approaching from the passenger side, many things are possible. If the car is in motion and the arm is approaching from the driver's side, many things are locked out.

[matthaeus]

> Not the author, but the way I see it this is specifically an interface for adjusting things eyes-free when driving. In an actual implementation, there would be some sort of physical switch between the in-drive control (demoed here) and a high-density "at rest" operation for passengers or more specific tasks (e.g. configuring the GPS).

Yes!

[banachtarski]

It's really not. It's a huge step back from even the interfaces he presented.

You exhibit the symptoms of somebody just introduced to multitouch and gesture recognition and trying to "explore the possibilities." The reality of gesture control is that they make for horrible user experiences. You are encouraged to try it on your own if you aren't convinced. Adobe, Apple, and a number of other companies did a lot of user study into this.

Double tap, twists, etc. All those gestures suck and fail for different reasons sadly.

[msandford]

Actual buttons are better than fake buttons on a touch screen. What he dreamed up is in my opinion better than fake buttons on a touch screen. Real buttons might be better than his interface.

I got interested in multi-touch something like 6 years ago when I saw this: http://vimeo.com/6712657 So I don't think that I'm someone "just introduced to multitouch" at all. But thanks for trying to subtly call me a naive idiot!

So far the best people are able to do is two finger scrolling and pinch zoom. It's kinda sad.

[banachtarski]

> What he dreamed up is in my opinion better than fake buttons on a touch screen.

No you are "new to multitouch" in the sense that you haven't tried to implement multitouch yourself, conducted a user study on multitouch learning curves and intuitiveness, or used a real life application exhibiting the multitouch you claim to understand for a prolonged length of time.

Seeing one video qualifies you perfectly for being "just introduced to multitouch."

[gutnor]

At some point you would probably be better off having physical button. A huge touch screen on which you need to draw weird gestures you had to memorize does not strike me as very user friendly.

That said that is neat implementation and it very elegant but I would like to have that in the living room rather than the car.

A possible evolution I guess would be to have different screen you would flick through that would group 2 or 3 command together with a big visual cue on the background.

[qq66]

It's hands down better than other touchscreen-based controls. It's still quite a ways behind the old technology -- i.e., physical buttons.

I drive a 1998 car and can operate every single control without looking at the console, except audio tone controls and choosing a specific FM station not in my presets. Granted, navigation is missing since it's an older car -- better voice controls on the phone could make up the gap.

[matthaeus]

Interesting ideas. Maybe this is just me, but my wrists suck at twisting.