The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

overloading f()ality onto keyUp.time-keyDown.time - good?

Overloading functionality into the amount of time a key is pressed. Is this a good idea? I am seeing this on more and more consumer devices. It makes it cheaper to build - less buttons, but also makes the user interface a LOT less discoverable.

Example 1: 10 years ago I rented a car. Could not set the radio station presets no matter what I tried. Finally read the manual and discovered to SET the station, you hold the preset down for 4 seconds. Holding it for less than that switches to the preset channel instead.

I would never in a million years have figured this out without reading the manual. But now that I know how it works, it's a good design, I think. Less buttons, so the buttons are bigger. Setting a station doesn't involve searching for a 'store' button or anything like that - just hold the thing down for a long time.

Example 2: Cell phone speed dial 0-9. Press the button to call your friend. Hold the button down for 3 seconds, and it instead goes to a menu of options for this speed dial preset, well mainly to set it to view it, edit the name, or set to some other number.

What do you think? I am pretty sure there is no way anyone ever discovers these functions without reading the manual. And most users do not read the manual. So that is bad, yes?

Maybe for the cell phone it would be better to also have some alternative way to get to that menu, and then have a 'tip' line or something that explains how the 'shortcut' works. This way, it would be discoverable via the online help. Haven't seen that design yet, but it could overcome the problems with this.

For the car presets, I would bet that most people with those sorts of radios never manage to set the presets for as long as they own the car.
Scott
Saturday, May 17, 2008
 
 
Oh, anyway I was also wondering if I should add this to my palette shortcuts.

Press K to select the bucket tool. Press K and hold for three seconds, and I bring up the bucket options. Since you can already select options with the mouse a couple different ways, this would just be one more way and maybe would be OK.
Scott
Saturday, May 17, 2008
 
 
The radio example is related to the limitations of the UI, and is a good compromise.  Similarly for the cell phone.

There are lots of examples of UI elements that aren't easily discoverable.  For example when you shut down XP you have to press the SHIFT key to see a Hibernate button.

And a particularly irritating example is VSS 2005, where the Add Files menu now show all files, rather than only the files that are not already in VSS.  To get the old Add Files dialog, press SHIFT while clicking the menu option.

In your case, only trying it out will tell if users are comfortable with it.
Joe
Saturday, May 17, 2008
 
 
You bring up some interesting points.

I am not sure that the UI on the phone or radio is related to intrinsic limitations, both phones and radios existed for years with these functions without the depression-time element.

The big problem with them is that setting presets this is a basic fundamental feature that 70-95% of the users want to use, and it is utterly undiscoverable to them.

I totally agree that for the advanced user who has learned the trick, it's a useful shortcut.

I think the solution has to be that it can't be the only way to do things. Car radios should ALSO have a small "store" button on the panel, and if you press store, then a preset button, it stores it. Verb-Object paradigm rather than the obscure Object-Gesture paradigm of the depression-time.

Object-Gesture shouldn't be the only modality available for fundamental features unless the gesture is really well known, like mouse-click.
Scott
Saturday, May 17, 2008
 
 
> both phones and radios existed for years with these functions without the depression-time element

Well as far as car radios are concerned I've seen this feature long before the controls were electronic.  One of my older radios had an on-off/volume knob, a tuner knob, and six preset buttons that worked as you describe.

So personally I've never had trouble with this feature.  And it could be argued that modern radios already have too many buttons without adding a store button.

And phones existed for years without all the smart features available today, so didn't need to provide more functionality with the 12 or so keys available.

Having said that I agree completely with your point about discoverability.
Joe
Saturday, May 17, 2008
 
 
Possibly good, but you need to try it out with real users to find out whether it really is or not.  If your users become annoyed at the bucket options constantly popping up when they were just thinking whether they really wanted to select the bucket tool or not, then you might like to reconsider.  :)
Iago
Saturday, May 17, 2008
 
 
If you think that  f()ality is a funny pun to use instead of typing the whole word, you're a terminal nerd and must never design anything that will be used by actual human beings.

Sunday, May 18, 2008
 
 
I think you are on the wrong board, this is a board for software designers to talk.
Scott
Monday, May 19, 2008
 
 
One potential problem is that you might be overriding the system's accessibility functions (does that pop up whenever I fall asleep while pressing some key).
Daniel_DL Send private email
Monday, May 19, 2008
 
 
Yes, that's something to consider too.

I started in prototyping it and then decided against it.

I was only thinking about it after I decided to post here about the car radio issue. It was going to be a rant where I said it was always a bad idea and obviously no one would ever implement such a crazy thing on a PC program. But thinking about it I started wondering if maybe it could work.

For the toolbar modes, the problem is some of them hitting the key repeatedly cycles through the tool's modes (like in photoshop). To keep this (which is a must) and also add the time element, I'd have to wait to do the advance mode until the key up event, or a time out, instead of key down as it is now. This proves to ruin the workflow enough and would be a nuisance to customers who are used to the way it is now, so I'm not going to do it.
Scott
Monday, May 19, 2008
 
 
On a car radio (sound system?) or heating/AC system, I do not like overloading.  It means that when I am driving, I can not simply adjust something, because the control might not be in the right mode or I can not press the control for long enough.

Overloading also makes it harder to determine how to use the system without the manual.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Monday, May 19, 2008
 
 
Let's throw away our keyboards. All you need is one button.

Monday, May 19, 2008
 
 
"All you need is one button."

Just be sure to make it a big red button and give all of your users a mallet. Sort of on the order of "whack a mole".
dood mcdoogle
Wednesday, May 28, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz