Home arrow Design Usability arrow Page 4 - Dynamic Page Elements-Cloak and Dagger Web Design

Dynamic Page Elements-Cloak and Dagger Web Design

There are not many aspects of web design that seem to ignite the same fascination in developers as making elements dynamic by hiding and showing them on user interaction. Collapsible lists, maps with hover elements and multi level drop-down navigations still seem to be hot and need to be part of a web site to make it "cool" and to "increase usability". Much like the magician conjuring the rabbit out of the top hat for the tenth time in a row, this design stunt does gets a bit stale though. Maybe it is time to take a step back and look at what we do.

Author Info:
By: Christian Heilmann
Rating: 4 stars4 stars4 stars4 stars4 stars / 14
October 18, 2004
  1. · Dynamic Page Elements-Cloak and Dagger Web Design
  2. · The Origin of Dynamic Elements
  3. · Current Problems
  4. · Troubles with Available Screen Estate
  5. · Current Uses of Dynamic Elements
  6. · Explorer Menus (collapsible list navigations)
  7. · Collapsible Page Elements
  8. · Tooltips and Hidden Extra Information
  9. · Enhanced Internal Navigation
  10. · Conclusion and Notes

print this article

Dynamic Page Elements-Cloak and Dagger Web Design - Troubles with Available Screen Estate
(Page 4 of 10 )

One of the main reasons for using hidden elements is that you do not clutter 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.

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 [note 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 [note 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 [note 8] and a lot of accessibility tutorials [note 9] swear by it - after all the accessibility recommendations [note 10] promote it and some accessibility certifications even require them.

Much like the recommendations for scripting [note 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 [note 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 do 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.

blog comments powered by Disqus

- Responsive Web Design: More Than Just a Buzz...
- Add New Website Features to Please Users
- Gzip Components in Action
- Configuring Gzip Components
- Gzip Components
- Create Great JavaScript and CSS Menus Simply
- Design Principles that Shape a Web Site
- Creating Aqua Style Images
- Easy as A,B,C dynamic A to Z indexes
- EasyChart: a Usability Teaching Tool to Demo...
- Building Friendly Pop-up Windows
- Back to School: Design Usability
- Using HTML_QuickForm To Manage Web Forms, Pa...
- Using HTML_QuickForm To Manage Web Forms, Pa...
- More Website Knick Knack

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials