Dynamic Elements Cloak And Dagger Web Design

"Three clicks" vs. "content overload"

When talking to clients and designers about collapsible navigations

we will sooner or later stumble over the "

three

clicks rule"[4].

This rule states that users should find any content on your page with

three clicks (otherwise they get bored and fed up and leave your site

to spend millions on your competitors' sites).

This rule does not state that the three clicks should happen in the

same document and without a page load in between. Therefore we can

satisfy it by adding a sitemap to our site, and voilà, two clicks

and users can go anywhere on the page.

Of course this does not apply to a product catalogue, the three click

rule needs to apply to the sub section you are in there.

Multi level foldout menus replicating a sitemap do allow the user to

go anywhere on the site from any page. For a sighted user with scripting

and CSS turned on

this can be very convenient (granted the navigation is easy to use and

does not require neurosurgeon hand-eye coordination skills), but what

is shown on our screen is not everybody's experience.

By adding the link data of the whole site to each page, we create a

"content overload". Depending on the depth of our site, the

user might see a nested list of 50 links, and will have to cope with this

amount of data. Sighted users who can use a mouse might not have a

problem with that, but keyboard and screen reader users will have to

navigate through these links one at a time.

This can be a quite infuriating experience when you want to read

link 28 and link 29 afterwards - it means hitting tab 28 times, reading,

waiting for the page to load and hitting tab 29 times, repeated ad nauseam.

Some browsers have

"type ahead"[5]

functionality that jumps to a link when you type a word contained in it,

and speech recognition systems can number the links for you. Regardless of

these handy extensions, we still create a whole load of content

that is not really relevant to this section of the site. A real world

equivalent would be to print the register of a catalogue on each of its

pages.

Back to menu

Troubles with available screen estate

One of the main reasons for using hidden elements is that you do

not clatter your pages with text and navigation elements and that the

user does not get confused by too many options at once. Unless we hide

and show these elements via a reload, this does not apply to everybody.

If we use Javascript or CSS

to show and hide elements, we should make sure that the amount

of content is not too overwhelming when all elements are visible.

This is especially important when we use multi level foldout menus, as these

can become unusable when they exceed the available space.

Back to menu

Mouse dependence

Hiding and showing page elements is a visual stunt (unless we do it

on the backend and only write out the elements when they are visible),

and thus we are tempted not to require a click to activate it but use

a smoother way: The hover. This event takes place when the pointing device

of the user is on the element but does not activate it. According to the

CSS specifications

[6] interactive user agents should support

that, but may not be able to.

With the browsers currently available there is no reliable way to

trigger a hover state with a keyboard. This means that a lot of

well thought CSS-only solutions are dependent on a mouse or other

pointing device. Even more annoying is the fact that the focus and

active states, which by definition allow keyboard events and are the

CSS equivalent of an

onclick event are not

supported properly by some browsers[7].

"Users without a mouse most probably have

CSS turned off, too"

is a nice idea to reassure ourself that we did well, but does not quite

cut it.

One possible life saver is the

accesskey attribute

[8] and a lot of accessibility tutorials

[9] swear by it - after all the accessibility recommendations

[10] promote it and some accessibility certifications even require them.

Much like the

recommendations

for scripting [11],

they appear great on paper (or on screen), but when we try to

implement accesskey we run into some issues. First of all there is no

indicator as to what the accesskey associated with the element is, as

not all browsers or agents display them. This is a folly of the browsers

and should not really be our problem, but if we use accesskey as the

mean for keyboard users to use our solution, they should be made aware

of that. Another issue is that there are not many keyboard shortcuts left

at our disposal. The browser is already running inside several

applications, all of them with their own set of keyboard shortcuts. By

following the recommendations, we might

overwrite

some of their important functionality [12].

Any way we look at it, the only reliable solution to allow elements to be

shown and hidden and remain independent of input device is by relying on

the onclick event - as boring as that may seem. What scripting and the

onclick event does allow us is to only apply the effect when it can

be used: Rather than adding the script calls in the markup and guessing

the script is available, we add the functionality via scripting.

Back to menu

Foldout or Dropdown navigations

This type of navigation is the most common use of hidden elements, a navigation

on the top or the left of the page which acts like the menus of applications

or the windows start menu. The sub menus are positioned over the content and

do not cause the rest of the content to shift when being expanded.

If we use this kind of navigation, we need to be aware of several problems:

1. Content overload

If we use the whole sitemap as a navigation on each page, we do exactly what

was explained earlier. Too many irrelevant links for this section will confuse

users and the extra markup will slow down the page.

2. No "you are here" state

As the whole navigation collapses once users have chosen a page, there is

no indicator as to where they are in the site, how many other elements there

are in the same section and how many levels deep they are. We need to make them

aware in another way (breadcrumbs, repeating the section navigation in a visible

way).

3. Screen estate restrictions

The worst thing that can happen with a multi level drop-down menu is that it

doesn't fit the screen and either cuts off options or causes a scrollbar.

State 1 does not pose a problem, State 2 makes it impossible for a

sighted user to know what the options are and State 3 might make it impossible to

use the menu. When the menu causes a scrollbar, and the menu hides and shows itself

on hover rather than click, it gets hidden when the user tries to reach the

scrollbar. This can become pretty frustrating.

To avoid these issues, we need to fix the page dimensions and check

if all menus fit the screen when expanded to the last level. As we cannot

know the size of the users browser - which can be different to the

screen resolution - this poses other usability and accessibility problems.

One annoying browser bug we have to be aware of is that some browsers

show flash movies and form elements on top of the menus instead of being

covered by them. There is a

work-around

using an IFRAME [13],

but that is hardly accessible. The safest bet is to ensure that the

space all the expanded elements cover is free of multimedia elements,

forms and - of course - frames.

4. Mouse dependence

A foldout menu has to be navigable via keyboard to remain accessible.

Therefore it should expand and collapse when the user clicks it, for reasons

explained earlier. This is less sexy and does not give the same experience

as an application menu, but web development is just not application development.

Many foldout menus using hover to trigger the sub menus can even get

mouse users into real trouble. Examples are menus that don't allow for

a big enough space to hover over or show gaps in between menu and sub

menu. It is pretty frustrating to navigate down into the third level

just to see the menu vanish again when you slipped a bit.

5. Unknown functionality

When we use foldout navigations then we should make users aware that there

are more options to come when they activate this link.

Studies have shown

[14],

that if users don't get that information, they won't use the navigation

and get easily lost - rendering our whole effort to increase

usability pointless.

Back to menu

Explorer Menus (collapsible list navigations)

Explorer tree menus are vertical list menus that expand and collapse the

sub-menus when you click their parent element - much like the explorer tree on

windows showing sub-folders and programs when you click on a folder name. While

posing less problems than a foldout menu, there are still some pitfalls to avoid.

1. Content overload

The rules of "content overload" apply here, the user may be

confused or even annoyed by the amount of links not related to this section.

2. Not maintaining the current state

A good explorer navigation should keep the current section expanded when

the page loads - something that can be easily achieved. As the current

sub section stays visible after choosing an element, highlighting this

element and keeping a visited state should also be no big issue.

3. Mouse dependence

Expanding and collapsing the elements on hover is not possible without

trading off keyboard users. Therefore we should stick to clicking the

menu sections to expand sub-elements. As the menu items are arranged

vertically, expanding the sub sections when hovering over each of the

parent elements could appear rather annoying. Users want to reach link

number 5, not expand and collapse all sub-menus in between 1 and 5

before reaching it.

4. Unknown functionality

Elements that have sub elements should tell the user so, to avoid

frustration loading a page when in reality there was a shortcut. We should make

sure that this highlighting is only applied when the solution is working.

Back to menu

Collapsible page elements

One not that common enhancement is to only show and hide certain parts

of the page, for example a right hand extra navigation or extra

information in a list of products.

Unless we add extra information this way, we don't have a case of content

overload. The only remaining things to keep in mind are:

1. Not maintaining the current state

Once users chose to hide or show a certain page element, they should not

have to repeat their decision on each page. We should ensure the state is

kept in a cookie or some other mean of data storage.

2. Jumpy display

Unless we show and hide the element via including it or not on the backend,

there will be a brief moment when the element is visible before it gets hidden.

This is nothing serious, but users can be confused and annoyed.

3. Unknown functionality

We need to tell users that they can hide and show this part of

the page, or that there is extra information.

Back to menu

Tooltips and hidden extra information

One example of hidden and shown elements are "tooltips" that

appear when you hover over a navigation or an imagemap.

Eric Meyer [15]

lead the way for this functionality with his

"CSS

only popups" [16]

which turned out

not

to work on some browsers unless you create your CSS the right way [17].

They also have some other problems:

1. Content overload

As these tooltips re-use already existing markup, there shouldn't be any

content overload. We simply need to turn off

CSS or scripting to see if the

extra information is really helping or just represents a "nice to have".

For example, a navigation with spans inside each link which get positioned

and shown outside the link via CSS

can be a nice effect, but the same amount of text in each link might

render the navigation hard to follow. HTML already has the title

attribute for extra information that could be

displayed as a tooltip [18].

2. Mouse independence

Per definition, these effects are mouse over effects. However, as they are

an enhancement and not a necessity, not much is lost if they don't work with

alternative access.

3.Giving false hope

One common mistake is to style the tool tips as if they

were clickable and yet hiding and showing them with a hover effect. Users will

try to reach the tips with their mouse and get frustrated when they vanish.

Back to menu

Enhanced internal navigation

Scripting is often used to enhance "internal

navigation" - a list of links pointing to anchors inside the

same document. We can use scripting to hide content parts and show

them when the user clicks the link, thus avoiding a long scrolling page.

Effectively, we are simulating a site navigation in one document, which

creates other problems:

1. Changing user behaviour patterns

As mentioned earlier, a wrong jump in a simulated paged navigation

like this might make the user try to go back via the back button or the

appropriate keyboard shortcut. This will initialise - hide all elements,

and show the first one - not the last one the user has chosen. There is

not much we can do about that except for making the user aware that

this is not a "site inside one document".

2. Disallowing bookmarking and direct linking

User won't be able to bookmark a certain section of the document, and

some browsers do not change the state of the links to visited once you

jumped to this section. A good scripting solution should allow the

user to directly jump in the page by supplying the anchor in the URL:

http://www.foo.org/index.html#bar

Furthermore, we could trace the clicks and set a cookie to show

the last section when the user visits the page again.

3. Jumpy display

Unless we show and hide the element via including it or not on the backend,

there will be a brief moment when the element is visible before it gets hidden.

This is nothing serious, but can be annoying.

4. Cutting off content

By hiding different content sections and showing them onclick we make

it easier to read the document on the screen. Some users, however, may

want to print out or see the whole document. We should give them an option

to do so.

Back to menu