Inactive UI elements: disable or disappear?

5 Dec 2008 - 3:07am
5 years ago
7 replies
2706 reads
Bart Schouten
2008

I'm struggling with an UI issue, so I'm hoping to receive some advice from
you. Imagine a textprocessor (i.e. Word) application in which you can edit
both text and image objects. The interface is clean and simple, only the
most needed functions are available in this app. An advantage of the
limited amount of functions is that they all fit in one toolbar without
cluttering or being miniscule. This toolbar contains a group of buttons
that can change image objects (crop button, rotate, transparency ...) and
a group of buttons that can change textareas (textcolor, bold, italic ...)

So far the introduction. My trouble is that I can't decide what to do with
the image buttons(group) when a textarea is selected and the other way
around, what to do with the text buttons(group) when an image object is
selected.

I've got two options:

1) Disable the buttons(group) which cannot be used because of the type of
object selected. This means, grey out the text buttons(group) when an
image is selected.

2) Completely remove the buttons(group) which cannot be used because of
the type of object selected.

I know that letting the system remove/show UI elements is generally not
good practice as it will lead to an inconsistent UI and a 'jumpy' UX of
the UI. But, greying out buttons may just as well be confusing for the
end-user. "Why is this grey?", "How can I enable this button? I need this
button!" are just some questions I recon the user may have when the system
greys buttons by itself.

Now, I know I've said that I've got two options, but if you have a better
idea that's very welcome too ofcourse ;)

Just a last one to think about: maybe I can grey them out and then have a
tooltip (nicely designed and usable) that says "Text editing buttons are
not available when an image is selected." I don't like UI's that can't
explain themselves and need tips like that. However, in this situation it
just might be a solution.

What do you think?

Comments

6 Dec 2008 - 3:49pm
Jack L. Moffett
2005

Bart,

Your instincts are correct. Here's a post I made on my blog awhile back:

> Developers often ask me whether a function should be hidden when not
> available, or merely disabled. I gave them the following two rules
> in my UI Design First Aid lecture.
>
> When a function is unavailable due to current system state, but may
> be enabled for the current user when the state changes, the control
> should be disabled.
> This provides a visual indication that the function exists, and the
> user knows that there is an action they can take to enable it. When
> possible, I specify a tooltip that explains why the function is
> disabled.
>
> 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.
>

http://designaday.tumblr.com/post/47558495/back-to-basics-disable-or-hide

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

The public is more familiar with
bad design than good design.
It is, in effect, conditioned
to prefer bad design, because
that is what it lives with.
The new becomes threatening,
the old reassuring.

- Paul Rand

6 Dec 2008 - 3:38pm
vzambrano
2008

I for one would say never make interface items disappear, as it might
startle the user and might create modes, and modes are usually
difficult to deal with.

Disabling might be a solution. Including rollover tooltips that
explain why buttons are disabled might help the user understand the
situation.

Contextualising the palette (making it appear right around the edited
object while in editing mode) might also work, as then it will show
the text one when editing text and the image one when editing images,
like some WYSIWYG editors do.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36261

6 Dec 2008 - 6:05pm
DampeS8N
2008

The only exception to the above rules I can think of is when a user
can never use a particular tool. Or when they can only use it should
someone give them new permissions.

An example of this might be admin tools that only a site
administrator needs, such as deleting posts on a forum, or a menu
item that lets them handle user types.

However, I also think a change like this should come with a
new-first-run message saying why their interface suddenly changed.

Another example of this might be very-large scale applications for
big business, Custom suites where there may be hundreds of interfaces
that a user -might- need, but it is easy as pie to know that someone
in accounting isn't going to need the marketing screen, and neither
of them is going to need the HR screen.

However this leans more into the idea that different users need
different software, and these different screens, even if part of the
same overall system, are like different pieces of software.

Kind of like how an office suite comes with several applications and
most users never bother with most of them. The mosts they pick just
so happen to be different.

Will

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36261

8 Dec 2008 - 10:56am
Michael Micheletti
2006

I like the clear way you've stated these rules Jack, thanks.

I recently did a design review with support and field engineers looking at
concept sketches. They all spoke out (rather strongly) to request that
controls always be visible on the screen and not disappear. It seems that
vanishing controls make their support tasks more complex. I'm attempting to
honor their request. Mostly I can, but there are still some cases where
different configurations create or expose different controls. For example,
in my application some people will have telephony configured and see phone
controls, others not. 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.

Michael Micheletti

On Sat, Dec 6, 2008 at 12:49 PM, Jack Moffett <jackmoffett at mac.com> wrote:

> Bart,
>
> Your instincts are correct. Here's a post I made on my blog awhile back:
>
> Developers often ask me whether a function should be hidden when not
>> available, or merely disabled. I gave them the following two rules in my UI
>> Design First Aid lecture.
>>
>> When a function is unavailable due to current system state, but may be
>> enabled for the current user when the state changes, the control should be
>> disabled.
>> This provides a visual indication that the function exists, and the user
>> knows that there is an action they can take to enable it. When possible, I
>> specify a tooltip that explains why the function is disabled.
>>
>> 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.
>>
>>
> http://designaday.tumblr.com/post/47558495/back-to-basics-disable-or-hide
>
>
>
> Jack L. Moffett
> Interaction Designer
> inmedius
> 412.459.0310 x219
> http://www.inmedius.com
>
>
> The public is more familiar with
> bad design than good design.
> It is, in effect, conditioned
> to prefer bad design, because
> that is what it lives with.
> The new becomes threatening,
> the old reassuring.
>
> - Paul Rand
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

8 Dec 2008 - 11:48am
Jack L. Moffett
2005

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 <jackmoffett at mac.com>
> 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

8 Dec 2008 - 6:02am
Bart Schouten
2008

Thanks for the replies! I'll go with the disabled tooltip solution.
I think that's best :) Sometimes you just need a little confirmation
on your thoughts to make up your mind ;)
Thanks again.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36261

6 Dec 2008 - 10:45pm
Karl Proctor
2008

I tend to agree with Will here; a couple of years ago I was working
for a company in the UK. The software gave users access to different
functions or features depending on their permissions, but the
developers opted to make all functions show while those that were
unavailable were greyed out.

While this made sense to the developers (not sure why though), the
users couldn't understand why they were not able use a particular
function, even though it was shown. The helpdesk received numerous
calls regarding these greyed out functions from users who thought
that there were problems with the software as functions were greyed
out.

I think that it is also perhaps worth considering the kinds of users
who will be using the software; Will white-collar users understand
differently than blue-collar workers? Will you need different design
considerations based on the socio-economic group of your [potential]
users?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36261

Syndicate content Get the feed