JavaScript Disabled

To enjoy the full experience available to this page, please enable JavaScript for this browser.

Portfolio Show and Hide Content

Content is King and it can place unrealistic demands on our users. Pyramid writing, brevity, active voice, information mapping, and other writing strategies aim to reduce these demands, but volume of content remains a challenge in the already noisy web space.

Why Show and Hide?

Voluminous content can appear overwhelming. Written poorly, and without sufficient headings and paragraph breaks, both visual and non-visual digital consumers can be overwhelmed with the work they feel needs done to consume it all.

So, sometimes we need an "Off" switch to shut down the overwhelming volume, or we stagger our presentation of the content over time to meet the learning strategies of progressive reveal or scaffolding. Of course, the timing must be on our users' demand. (Timed text, that is text that we show or hide automatically, is not inclusive design. Some users will want more time; some less).

Working within a legacy platform architecture there were only three methods of show/hide available within the visual dialogue: links, accordions, and tabs. They were enough for the legacy context but there are many other techniques and strategies that reveal content on demand.

Introduction

Progressive reveal:

  • Is a learning strategy to sequence and scaffold contents
  • Offers information to our users rather than pushing it
  • Reduces overwhelming our user with quantities of content
  • Assists visual scanning for meaningful or attractive headings
  • Can introduce an exploratory feel, which may foster engagement with caution that clicking stuff does not equal engagement

Where this simple technique fitted best was in presenting the complex information architecture of a large support offering and in reducing the cognitive load presented by large banks of optional inputs and filters in forms.

Implementation

The principle of show/hide is employed to advantage a number of situations. Tabs like these responsive ones below are just one strategy of many available to us.

Caution: offering content does not ensure its consumption!

For example, in its presentation within a larger viewport, the first and second panels of the tabs below are long. Our user may scroll down thier content and forget or miss the unopened tabs. The addition of a "Next Tab" link or button at the bottom of each tab goes some to mitigate this risk, and may even be useful to our user.

Use in Presentations

Responsive Slide Show
Slide One: device screen with figure one displayed
Slide Two: device screen with figure two displayed
Slide Three: device screen with figure three displayed

This slideshow is based on W3 CSS although I have built one that is more accessible and usable. It is made responsive by using the <picture> element with image source options for a smaller and larger viewport. (Try adjusting your browser width, or device orientation).

There are more participative dialogues and controls we can use, but "Next" and "Previous" will do here. The Go to Next tab button below is another example of a progressive reveal control.

Go to Next tab

Use in Support Products

The HMH online support offering became quite large. Not all of it was accessible contextually from the parent product or platform. There needed to be a landing page from which our user could find and link to the support they needed. Ten products, each with three user account types of over twenty links each would produce a list of over 600 links.

Show/Hide presented a semantic search strategy and cognitive flow:

  1. Identify the parent product
  2. Identify the account type
  3. Identify the topic or support resource needed

Our user now chooses from 10 options rather than 600, and so on.

The first strategy was to use responsive tabs, but once the product numbers increased beyond nine, the presentation became bars almost by default. A new design was needed. The result has been very popular and applauded across HMH and by their millions of users.

The original responsive tab design could not cope with the numbers of products and eventually, the media query needed to be so wide that it tended to display accordion bars by default.

The original tabbed design at capacity
Using the maximum number of responsive tabs given the constraints of the user interface

The new design was more capable and gave an equal experience across browsers and devices showing accordion bars by default.

The new design using bars
Use of show and hide headings to allow rapid scanning and search for users wanting to find contextual support

Note: Because this tab is long and its visual design is low contrast, we can add a button to inform our user that they are still within a tab, and to remind them that there are other tabs available to explore. A stronger technique could be to repeat the tabs at the bottom, although this may add complexity and confusion.

Go to Next tab

Use in Forms

Even simple forms can be overwhelming to some users.

Through poor platform design, our users have learned that they may lose their inputs following error notification or after system time-outs, etc. Inputs may require research away from the workstation or error messaging may frustrate the experience.

The use of Smart Defaults aids error management. A smart default input may not be appropriate, but showing only the required inputs and offering the optional ones within a show/hide interaction helps reduce the immediate load.

A form with optional inputs hidden
Using a show and hide heading feature to hide optional HTML form inputs

The new design was more capable and gave an equal experience across browsers and devices showing accordion bars by default.

The new design using bars
Using a show and hide heading feature to show optional HTML form inputs

Go to Next tab

Use in Long Documents

Show/hide in longer content doesn't need to be presented as a wide bar or button. It can be indicated with ellipses or a, "Show more" link (reversed to "Show less" on reveal), etc. Scripting can automate the interaction after a specified number of characters. It's an easy technique, but one best tested with your users to be certain of the right controls.

The skill is in choosing what is visible to attract our user, and what is supporting information that can be revealed on demand. That and not overdoing the show/hide leaving your user bored and wanting only to move on to the next site!

One of many possible examples of a "Show more" link
Hiding long texts with a 'Show More' lin.

Back to First tab

Strengths and Weaknesses

Hiding everything may be as frustrating, concerning, or inappropriate as presenting a mahoosive wall of content. The strategies available to us should be fit to purpose and meet our users' needs.

Accessibility and usability are two factors we must consider. Our ability to present almost any HTML element as a show/hide button must be mitigated with accessibility adjuncts such as tabindex, element roles, ARIA controls, and scripting to ensure pointer, touch, and keyboard controls are consistent with their semantic element equivalent input buttons.

Where there is a need to show/hide, and where the strategy of choice is accessible and usable, our user can be oriented to our content and made able to scan headings quickly to find what they want, or what we need them to. We can "time" content, organise it, and reveal it progressively to encourage and ease learning. There are many and varied presentation strategies open to us and to our users.

As with any interaction, we must use it inclusively and when needed: it depends when or how that may be. For example, there follow some notes on the choice of symbols. They are supplementary to the main content. Feel free to reveal them.

Note: although we can use the tabindex and ARIA roles and controls to convert static elements into accessible buttons, it should be noted that the semantic HTML element of choice for this interaction is the input type "button". It occurs naturally in the tab index, is inherently accessible and usable, and can be styled as we wish.

Symbols

Symbols are not necessary but may help your visual user to discern the interaction's intent. Images don't need to be accessible: you can call them via the CSS. Use roles and ARIA controls for accessibility purposes.

Ellipsis

An emerging symbol for more is the ellipsis ..., which is based on the universal semiotic for dialogue; there's more to say. That's fine for an element with a close button, but may not work in isolation for show/hide more and less interaction. Most usually you will see, "More..." and "...Less" with the ellipsis indicating the direction of the expansion or collapse of the dialogue.

Plus / Minus and Lever Symbols

The "classic" icons for show/hide are the + and symbols to show more and less, or levers that our user figuratively pulls or pushes when clicking on them. The levers are most usually signified by chevrons or triangles that rotate or otherwise transform between reveal states.

When to use each symbol is really down to the visual dialogue you must follow, but care must be taken related to the Gestalt law of grouping. It is OK to place a lever within a long (and visually bounded) button away from the signifyer text, but the + and symbols benefit being proximal to the signifyer text.

I found that they can be mixed. For support materials, I used the lever for the parent expand button, and the + and for any children.

Indicate Direction

With levers, it is important to remember that chevrons and triangles are directional arrows. In a way, a humble link is a show / hide interaction, which if styled as a button may benefit an arrow to show a direction of journey. But which way should an arrow point?

  • Point right: direction of travel off or across the page. For example, linking to a new page or expanding from left to right.
  • Pointing left: direction of travel to a previous state. For example, linking to a previous page or expanding from right to left, or closing a previously side-expanded panel
  • Pointing down: direction of travel downward. For example, opening a panel of content beneath the button or link, or indicating a download (although better symbols are available with a horizontal bar beneath to indicate a destination of "down").
  • Pointing up: direction of travel up. For example, closing an expanded panel of content beneath the button or link, or indicating an upload (although better symbols are available with a horizontal bar above to indicate a destination of "up").
Example product using levers and + and symbols to show a hierarchy of information
Example product with show hide features using two types of visible icon to show an information hierarchy

Summary

As with most UI, it depends. Consider the show/hide techniques you can use effectively and employ the one best suited to the task and to your users.

Top