Can 1 dial or menu do it all?

So I bought a new iPod. There have been many articles have their been lauding and fewer criticizing (mostly the battery) the iPod. I think this one is going to do a little critiquing, but hopefully for the purpose of moving IxD forward and less to give pointers for the next version of the iPod or anyone else wanting to use (with or without permission) a Click Wheel.

Now in all honesty, not everything is in the wheel/menu combo: play, skip forward/reverse(|<, >|), pause, and power off; Oh! and of course the "hold" key which is vital b/c it turns off everything else. For the most part, though, the system is used through the touch-sensitive wheel, clicking the "menu" button, which is really the top of the wheel and is really a "back" button from a navigation sense. and the center-button which is a select button. The wheel navigates flat lists, actually really fast (sometimes faster than you think or can keep up with) and then you move to the item you want to select and select it. Oh! the play button is also used as a form of selection depending on the "mode" or what part of the menu taxonomy you are in. I think it only works as selection if you are in the "music" node of the menu taxonomy/heirarchy.

Another "modal" behavior of the wheel is that what you are viewing what is playing the volume is the command of the wheel and not navigating. You can also change this default by clicking the center-button and then the wheel allows you to fast-forward (>>) or rapid-reverse (<<). It is interesting to note what is not in the menu. There was a conscious decision made by the designers (and I invite them to comment on their process for their problem structuring and design decisions in the comments here) to give some functions an immediacy that the others don't require. This idea of immediacy is something that is not often addressed as a pattern in and of itself from what I have experienced thus far. The idea through the use of my iPod has become very important to me and I am now trying to think about how I apply this question to other projects I work on. Here are some samples:

• Web sites ... "I want to get from anywhere to everywhere with one click."

• Applications ... "Put it in the toolbar so it is always available"

But samples of where we decide on purpose to hide things are even more bountiful:

• cellphone ... hiding the power button so it isn't hit on accident

• palms ... requiring that you turn on the screen before other buttons work (I realize this is an options)

• Applications ... menus, menus, menus

• Applications ... wizards

• Web sites ... intro pages

Obviously, some of these are meaningful and useful and others are not. The same is true for the iPod and every other interactive device software or hard out there.

The question I have is how do you make a decision in this regards? What is immediate vs. what can be hidden or modal?

Going back to the iPod for some examples:

1. Volume: volume control needs to be available no matter what I'm doing. Instead of giving a reason, it is better to give a scenario. I'm playing Solitaire, and one of my songs comes on too loud ... I need to instantly lower it before my ears blow. With the iPod today this is not so easy to do. You have to go up 3 and down 1 in order to get to the point where your volume control will work. Now admittedly this changes dramatically if you have the remote. But when I pay $300 for a device, should I really be expected to pay a 15% ($40) premium to have this feature? I won't make it a separate subject, but where is mute? This to me is really missing from many portable devices. The reason this is so important as a feature for the iPod is b/c it is not only used in a "portable" setting. Many people attach their iPod to their stereos and more and more are being used in cars (take the BMW example).

2. Shuffle: This is my personal pet peeve of the iPod. Turning this on and off is something I do in tandem with my music selection, and is not a static choice as might be the EQ or something like that.

3. EQ: The issue here is slightly different than the others. THIS one is about how do you decide what should be modal vs. what shouldn't. This to me deserves the same behavior as that of volume. It is dependent on the song so when a song is being displayed then you need to be able to change the EQ to fit the requirements of that song. Now I know you can pre-set EQ settings in iTunes, but most of us wouldn't be able to do that, or wouldn't choose to do that. So it is connected to the song. So there should be a way to choose EQ from the song like you can use <<>>.

4. Backlight: This one makes no sense to me. Why? because when I need it I can't use the menu in the first place to find the switch to turn it on, no? And there is no specific mode when I would need it more than any other. This one is also something easy to add to the system through 1 of 2 methods that wouldn't require a single change to the system's form (see below). Currently "holding down" the click wheel at the "play" position turns the power off. Well what if I held down the "menu" or the center-button until the light comes on and then it stays on for a timed period or until usage stops or until I go back to that item and hold it long enough again but this time till the backlight turns off? This is just as un-intuitive as holding "play", but just as easy to remember in that it is directly related to an appropriate context--menu or selection.

What makes these items so interesting is that they are items that change the parameters of play and their use exist outside of mode for all practical purpose or more accurately the first 2 are pan-modal and the last one is defined not by mode but by context of use.

This idea of pan-modality and contextualized immediacy are both variables that need to be addressed when thinking about the use of menus, modal behaviors, and other similar structures.

The thing that balances this is clarity of complexity. How much can you prioritize in any given mode or pan-modally and still keep the interface clear and simple. There have been pushes lately within IxD towards a model where complexity is hidden and only displayed on a "need" basis. There is a phrase for this, I'm not inventing it, but I'm going blank. Email me if you know the two word phrase I'm trying to think of here. The other thing that Apple is definitely balancing here is the form vs. the function. The iPod is beautiful. It has the lines of a car--minimalistic, smooth, precise, technical, clean. Adding more interface items to it would hinder that. Making a touch screen (and all that goes into that) would make it too expensive.

"Immediacy" is defined in the context of use. For tools that have such a broad-base of use like an iPod it is impossible to achieve total and complete satisfaction. One way out of this is the way palmOS does by providing the 4 application buttons as a means of configuring YOUR primary needs. The iPod could have configurable behaviors across some of the items that I suggested above in the backlight case. Double-clicking is also another item that is not utilized in the iPod, which is interesting since the Mac relies so heavily on it.

It might be good that when designing your products that you make part of the process the question of "What does the user need NOW?".