August, 2014

Avoid ‘Sinkholes’ by Using Closable Panels Instead of Accordions

Accordions suffer from a phenomenon I have coined as 'Sinkhole', which in its worst cases can cause both confusion and disorientation to the user. Sinkhole is however avoidable by using  Closable Panels, a pattern that is very similar looking, but behaves differently to Accordions.

What is an Accordion?

The Accordion component is made up of two distinct elements; the panel title and panel content. This pair of elements are repeated as needed to house different sets of information.

Accordion example - Sinkhole

Only one instance of the panel content is viewable at a time, and a user switches between content views by invoking the panel title. It is this event of changing content views that brings about the Sinkhole phenomenon.


When an Accordion grows in height, the content below it is pushed downwards. Should an Accordion's height shrink, then elements below shift upwards to occupy the newly vacated space. An Accordion can grow or shrink each time the user invokes the Accordion's Panel Titles. This interaction brings about the phenomenon I have coined as a Sinkhole.

Microsoft's website uses a Mega Menu on large screen devices for its global navigation, and changes it into an Accordion for smaller screens. The small screen version of their navigation suffers from Sinkhole, exhibiting the undesirable traits I described, which is demonstrated below:

In the video the user first opened 'Products', and after scrolling down the product list, they then chose to look at 'Downloads'. When 'Downloads' was tapped it caused 'Products' to collapse, which shrank the height of the Accordion substantially. At that moment in time (8 seconds passed) the user can no longer see the navigation menu. It has disappeared from view, as it is now above their viewport, and this can cause confusion and disorientation to the user.

Remedying Sinkhole

Sinkhole, what the video above just demonstrated, is quickly remedied by switching from an Accordion to Closable Panels. Then panels are independent from each other; they only close when a user clicks/taps it again (a toggle), and opened panels remain open should the user choose to open another panel. The opposite of what an Accordion does.

In order to close a panel, the user must first scroll up to see the panel title, so that they are able to click/tap it. The page content then flows upwards towards the user's viewport, which means the user's viewport is not changed by the page reflow, keeping them where they where before invoking the panel title.

Inline Scroll

An Accordion's height can be fixed using CSS. When the Accordion's content becomes too much for it to display, a scrollbar is provided so that all of the content can be viewed. The trouble then is how big to make it? Too small when displaying lots of content and it becomes troublesome to consume that content. Too large, and it starts taking up more page space than necessary, which contradicts its very purpose of existence.

Inline scroll has its very own phenomenon too, which I have called 'Treadmilling'. This happens when you scroll down a page using a mouse-wheel or trackpad gesture and your cursor passes over the area where the inline scroll is. Then your scroll begins to scroll through that content instead of the page, with you moving but the main page remaining still. This is a topic I plan to cover shortly, so I won't go into this any further here.

Considering this, I personally cannot find an argument against using Closable Panels instead of an Accordion, with or without inline scroll. Please let me know your thoughts using the comment section below!

February, 2014

Spotify Controller Using Leap Motion and Tobii EyeX

Two representatives from Tobii visited Avanade, where I work. They gave a presentation on the background of Tobii, the way their technologies are leveraged, and how developers can make use of their technology through the EyeX SDK.

Later that day we had a brainstorming session, and consequently developed a proof of concept using Tobii EyeX and Leap Motion to control a Spotify player.

Trying out EyeX

During the day we were able to try out Tobii’s EyeX controller on Windows 8.1. We used Modern UI apps such as Bing Maps, Windows Store, and Twitter. Since these kind of apps have been designed with touch in mind, it benefitted Eye Interaction as the ‘hit target’, so to speak, was much larger compared to UI’s designed for a mouse pointer. Larger hit targets allowed for improved accuracy when invoking UI elements such as tiles. Eye Interaction was facilitated by holding down a key with a special binding. This key allowed us to switch between modes, such as zooming in or out, or panning across a map, for instance.

Designing for Eye Interaction

Tobii shared their principals on what to consider when designing eye for interaction:

  • Eyes are made for looking around
  • Eyes and hands work well together
  • Eyes are curious
  • Eye movements provide information

Read more about these principals over at Tobii's blog.

Using these principles, we began a whiteboard session to explore how we use our eyes when using computers. We agreed that our eyes are “passive”, and that the clues our eyes give should supplement another method of interaction.

NUI - Whiteboard session

Whiteboard session on how to leverage eye tracking and motion detection.

We grounded this theory based on a study by UIE, where they looked at how users found flyout menus and rollovers, and discovered:

“We found users follow a pattern: they decide what they are going to click on before they move the mouse.”
Users Decide First; Move Second by Erik Ojakaar, UIE

In keeping with our Natural User Interface (NUI) theme, we wanted to try and combine Tobii EyeX with another gestural technology. We were fortunate to have both Microsoft Kinect v2 and Leap Motion available to us, which gave us some interesting capabilities to try and combine.


The concept we developed that day was a Spotify controller using Tobii EyeX and Leap Motion.  EyeX detects when the user is looking at the Spotify icon in the task bar. Leap Motion provided an interface where a user can give hand gestures to control Spotify. Gestures recognised by Leap Motion would not be honoured unless the user was looking at the Spotify icon at the same time as performing the hand gesture. The proof of concept application supported the following gestures:

  • Poke to play or pause
  • Wave right to play next track
  • Wave left to play previous track
  • Circle clockwise to increase volume
  • Circle anticlockwise to decrease volume
Spotify controller prototype using Tobii EyeX and Leap Motion

Spotify controller prototype using Tobii EyeX and Leap Motion

Why Leap Motion Instead of Kinect v2?

We chose Leap Motion over Kinect for our Spotify controller for the following reasons:

  • The user needs to be beside the computer, as the EyeX controller has a limited range of view.
  • Leap Motion has a much smaller desktop footprint, which suits close range interaction.
  • Leap Motion specialises in hand gestures, detecting each finger and thumb.


Having the eye tracking and motion capture capabilities as separate pieces of hardware quickly clutters your workspace. The fact that they are separate also means it is not really suitable for a laptop, as it requires a desk, and makes moving from one place to another quite cumbersome.

Many computers, like the one we used for the prototype, have media keys. Those keys allow you to change the volume, skip or return to a previous track, play, and pause. In terms of interaction speed, those media keys, although not formally measured, appeared to be considerably faster than using gestures.

Nevertheless, that day was a very thought-provoking experience. The capabilities on show were very impressive, and it will be interesting to see how they develop and are leveraged in the future.