On Dec 8, 2008, at 10:56 AM, Michael Micheletti wrote:
So I seem to be following your rules at the feature level - if the users have phone functionality, show them all the phone controls, even if some are disabled. Within a feature/panel though, I'll always show the controls. So, for example, even if someone's configured phone provider will never support conferences, the application will still display a conference button in a disabled state.
I would argue that in this case, the conference button is adding unnecessary clutter to the UI. It doesn't seem that this type of state should be a hard thing for support people to understand. After all, the functionality doesn't vanish for the user. But, that's easy for me to say. We have to make compromises.
On Sat, Dec 6, 2008 at 12:49 PM, Jack Moffett <[EMAIL PROTECTED]> wrote: If a function will never be made available to the current user (barring a change of the user's access privileges), it should never be seen by the user. There is no reason for the user to be exposed to functionality they cannot use. This only leaves them wondering why they can't access it.
There is, actually, one reason that unavailable functionality should be exposed. I didn't include it in the rule because it is a marketing reason, rather than for usability. Showing disabled features within a UI is one method of advertising to customers. "Why can't I use the conferencing feature? Oh, we haven't paid for that. That might be useful..."
Best, Jack Jack L. Moffett Interaction Designer inmedius 412.459.0310 x219 http://www.inmedius.com Design is like California. No one is born there. -Dick Buchanan ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
