> 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.
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.
> 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.
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!
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.
> 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).
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.