Minimising visual overload

18 May 2006 - 6:19am
8 years ago
1 reply
470 reads
Paul Hunter
2006

Hi,

I would be interested to know if anyone has explored reduction in potential
visual overload of graphical based interfaces? Particularly around action
buttons which take action on some visible object in the UI.
There are two aspects which I'm considering, one is the visual appearance of
the button (should it look like a button - affordances - or can it appear
much simpler). The second is whether it can be hidden altogether until the
user has moved focus onto the object which the command applies. This would
mean the UI would show all the objects, represented by their important
content whether that be a graph or a row of numbers or a persons
photograph. Then when the user focuses on an object, the UI presents the
actions you can take on that object. For example when you hover over a
contact in gmail it presents the option to chat or phone that contact. Or
in http://www.tiddlywiki.com/ where when you hover over a posting, relevant
actions are presented along side the posting such as view the posting. This
makes it easier I think to read the content without presenting the same
actions for each posting.

I guess my concern was with discoverability of what you can do with the UI
and issues with consistency. For example (maybe a bit extreme) if you were
in an office with doors to meeting rooms and until you approach a door its
handle is hidden, when you get close enough it appears.

I'm currently looking at a table which offeres the ability to edit, delete
and copy elements of the table and was considering only showing these
actions when the mouse hovers over an element.

thanks
--
-paul

Comments

20 May 2006 - 12:15am
Juan Lanus
2005

Hi Paul,
You are posing to different issues, one is the generalized pair of
questions about hiding unneeded controls, and the other is the
particular table edition UI.

As of the first one, I think that users need to know that there is a
"submit" button before starting to enter data in the fields of a form,
otherwise it would be annoying. It's sort of a convention.
I started thinking about a disabled button that comes to life once
certain conditions are met. Usually I don't hide but disable. The
advantage of disabling over hiding is that when the control "revives"
all other artifacts stay in their places, nothing moves, the user is
not scared "Hey, what happened? What did I do!?"

As of the editable table, by sure it has many elements, as tables do.
Setting a set of controls for each element would lead to visual
overload.
Instead, there is "selection". You can set one set of controls and
make them operate on the (single) selected table element. As when in
Excel one selects a cell and then applies a transformation using the
single instance of a toolbar button.
I'd display the control initially disabled, and only enable them when
the user makes a selection.
Then tere is the hover thingy. If instead of making the user click for
to select you prefer to let them act on the hovered element, then it
can be done like a contenxtual menu, one that appears near the hovered
element. I'd keep the click to select operation mode described above,
and make the menu appear on the hovered element after a slight delay.
He first method will make the people start mousing, than they'll
discover the other. Not all users start mousing at first.
Amazon has an example. Go to their very home page and mouse ver "see
all 33 product categories." It looks like a tab, and it works lita a
tab, but it's also a hoverable menu.
--
Juan Lanus
TECNOSOL
Argentina

Syndicate content Get the feed