Can anyone point me to research about hiding interface elements?

10 Feb 2010 - 12:01pm
4 years ago
10 replies
834 reads
Gabor Vida
2008

A project that I am involved in has raised an interesting debate about
reducing clutter in an interface.

Specifically, one side believes that it is ok to completely hide some
interface elements and only reveal them on rollover. I don't mean
disable or dim them in a normal state and then make them obviously
available on a rollover state, I mean make them magically appear out
of nowhere when the user mouses over a specific area. Of course, the
thinking is that placement should be intuitive, kind of like the user
would be moving their mouse around thinking "if I were a button that
did X, I would want to be here..." and then the element would
appear.

The argument is that while the functionality is completely hidden and
needs to be discovered, it only needs to be found once. The advantage
is that you reduce the amount of visual clutter.

I'm opposed to the idea. I don't like forcing my users to hunt and
peck around an application to learn what it does. The "they only
have to find it once" belief feels like a crutch. An elegantly
designed interface can be both immediately usable and pleasing to
look at. One shouldn't be sacrificed for the other.

For the life of me, though I can't find statistics to back up my
instinct. I'd rather have some hard facts about the subject.

Does anyone know of any studies or articles that address this?

Comments

11 Feb 2010 - 4:51am
Francis Rowland
2009

I don't know of a study as such, but something solid to back up your
argument could be #6 in Jakob Nielsen's "Ten Usability
Heuristics", namely "Recognition, no Recall".

[ http://www.useit.com/papers/heuristic/heuristic_list.html ]

I mean, if something is actually hidden, the user *might* stumble
across it, but after that, what? They would have to RECALL where that
area was in order to display that piece of the interface again.
That's surely asking too much.

I don't know how much clutter we are talking about here, but
minimising interface areas seems like a better approach.

The suggestion that users will find hidden areas intuitively seems a
bit optimistic to me, too... Intuitively, I wouldn't move my mouse
pointer around apparently empty space, thinking "Oooh, maybe this
would be a good spot for a button... "!

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

11 Feb 2010 - 4:53am
Francis Rowland
2009

Sorry... that should have read "Recognition, not Recall"... with a
"t"! :)

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

11 Feb 2010 - 8:43am
Graham Sear
2010

Hi Gabor,

It sounds like you're talking about an extras on demand approach.
http://designinginterfaces.com/Extras_On_Demand

Where you have too much to fit on one page, but they still have to be
easily accessible.

Depending on what you're hiding there are various design patterns
you could use, such as:
- Accordion mensu
- Collapsable panels
- Carousels, for more imagery
- Pagination, for a long page

Hope this helps.

Cheers

Graham

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

11 Feb 2010 - 7:56am
Kal Kalotai
2009

I'm not sure about studies on the subject but a good deal of this
depends on your users and what they expect from a ui as well as the
nature of the application. What is the app and what are your users
and business goals? Is this a walk up and use app or is it something
users will use day in and day out? if it's walk up and use you may
want to pare down functionality and expose controls. If it's walk
up an learn you can expose some functionality and progressively
disclose more advanced functionality via rollovers, right mouse
functions or other context menus. Usabilty testing will also provide
more answers to your discussion than anything else and it doesn't
need to be super formal to determine what works best in your
particular case. You guys sound like you are heading into a great
circular discussion without an outlet... Make the users decide for
you versus a stalemate :)

hope that helps

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from ixda.org (via iPhone)
http://www.ixda.org/discuss?post=49270

11 Feb 2010 - 10:26am
Gabor Vida
2008

Thanks for the link, Francis. I can finally reference Jakob Nielsen in
a positive way ;)

Graham, we are talking about an extras on demand approach - sort of.
The difference is that the button or link that would be used to open
the extras would be completely hidden and only revealed on rollover.

Thanks again guys for the feedback.

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

11 Feb 2010 - 1:51pm
Gilbert Guerrero9
2008

It's not quite research, but John Maeda has a great book "The Laws
of Simplicity" where he discusses this in the first "law", Reduce.

He has an acronym for accomplishing this, SHE: Shrink, Hide, Embody.
So hiding functionality has a certain value in his opinion, but only
if it's done thoughtfully and if it doesn't prevent basics tasks
from being done.

http://lawsofsimplicity.com/?cat=5&order=ASC

I thought it was a very enlightening book. I recommend reading it.

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

15 Feb 2010 - 12:12pm
Anindita
2010

http://en.wikipedia.org/wiki/Mystery_meat_navigation
Here's more on wikipedia that i think is the official term for
hidden navigation.

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

17 Feb 2010 - 9:11pm
Petteri Hiisilä
2004

On 10.2.2010, at 9.01, Gabor Vida wrote:

> I'm opposed to the idea. I don't like forcing my users to hunt and
> peck around an application to learn what it does. The "they only
> have to find it once" belief feels like a crutch. An elegantly
> designed interface can be both immediately usable and pleasing to
> look at. One shouldn't be sacrificed for the other.

Forcing people to search for a Send or Get Mail button in their email client is obviously bad design. It would also be bad design, if PowerPoint's "Start Presentation" button was hidden between some random icons in some random corner. Oh, wait...

Anyway, there are special cases where completely hiding the action button works. Safari's tabs are a fine example: making the "close tab" icons visible at all times would just add unnecessary visual clutter. Many web apps hide delete buttons when editing lists, until you hover over the line. At first they may show only a pen icon for Edit, but a mouseover reveals more functionality. iPhone's Mail.app has a shortcut to reveal a hidden Delete button with a gesture, without clicking Edit and tapping a selection first. Note that the app also has an explicit Edit button.

My rule of thumb: If it's safe to expect that users will look for functionality in the location of the "hidden" button, and they will use it early and often, and having the button visible would cause a lot of visual clutter through repetition, then I might dim or hide it.

One way to reduce clutter is to use the most invisible color contrast that still reveals the button's location. An eye doesn't need much hint to find a button, assuming that it's already looking for one.

If you're unsure, make an A/B usability test with an interactive prototype and try it out. It's not a lot of code to hide the button after the test, if people find it without showing it.

Cheers,
Petteri

--
Petteri Hiisilä
Senior Interaction Designer, owner / iXDesign

Mobile: 408-256-0430 (USA), +358505050123 (FIN)
Twitter: http://twitter.com/petterihiisila
LinkedIn: http://www.linkedin.com/in/petterihiisila

18 Feb 2010 - 9:17am
Paul Eisen
2007

I am also a supporter of the guideline of graying out any fields or
controls that are not available in the current context, but can be
made available to the user by shifting the context. Among other
reasons stated above, another advantage is that tooltips can be
displayed on the inactive fields or controls about how to make them
active.

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

18 Feb 2010 - 10:56am
Bella Martin
2010

A couple of references to "progressive disclosure" have already been
made in this thread, and I wanted to point you to some of the applied
examples I've come across specifically regarding progressive
disclosure and progressive reveal:

The Xerox "Star": A retrospective
http://members.dcn.org/dwnelson/XeroxStarRetrospective.html

"Training Wheels in a User Interface"
http://portal.acm.org/citation.cfm?id=358218
also
http://www.useit.com/alertbox/training-wheels.html

Hope these help!

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

Syndicate content Get the feed