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.
Dynamic Page Elements-Cloak and Dagger Web Design - The Origin of Dynamic Elements (Page 2 of 10 )
Hiding and showing elements on user interaction originates from application design. Applications become more usable by not showing us all their options at once but allowing us to turn them off and on. Furthermore, we can arrange the elements freely on the screen and the application "remembers" their state and location when we end it.
Application design offers a much richer interface than web design to allow for these usability enhancements. An HTML page is a document, and resides inside several applications - the operating system, the browser and, if needed, an assistive technology like a screen reader. What makes it worse is that we don't know which applications are used, and trying to guess which ones they are [See Note 2] is flaky at best if not impossible.
The Perfect Solution
A perfect dynamic elements solution should be unobtrusive and accessible:
It should only apply itself when it can be applied to avoid hiding elements that cannot be shown again.
It should be independent of input device
These are the basic legal requirements [note 3], but our solution should also offer a bit more usability.
Maintaining the Current State
If possible, our solution should store the users' current status. Typically a hiding and showing solution initializes the page every time the browser loads the page. All elements that are to be hidden get hidden, which can be pretty annoying when you reloaded the page without wanting to. These unwanted reloads happen a lot when we use collapsible elements to simulate a whole web site in one document "to avoid long loading times".
As web users who had to suffer badly designed pages for years, we got used to going back to the previous page when we ended up on a wrong one either via the "back" button or the equivalent keyboard shortcut - not via the navigation - thus initializing all hidden elements. This can only be prevented by storing the current state in a session, database or cookie.
Telling the Users Where They Are
Our solution should make sure that users get the information where they are in the page hierarchy at any point, the "you are here" effect of the boring old text links.