September, 2014Comments are off for this post.

UI Treadmills: An Inline Scroll Problem

As a user scrolls down the page using either a mouse wheel, trackpad or touch screen, they can become trapped by an inline scroll. Whilst trapped, they are still scrolling, but the page that they were scrolling before now becomes stationary. This situation can be likened to using a Treadmill, where you are moving, but your movement does not have any result in your position within the broader environment. In these situations, it is highly probable that the user's intention was not to scroll this subset of the page.

In order to exit the 'Treadmill', the user must either move their cursor or finger outside of the area the inline scroll occupies, or wait until they reach the bottom of that content, with scroll focus then returning to the main page. To "step off of" the Treadmill, so to speak.

How Inline Scrolls Come About

Content, such as text, occupies space on a page. If you constrain that content to a size smaller than it needs, then you are left with an overflow. Much like trying to pour a pint of water into a teacup. Eventually, it will overflow. In software, you are left with two options with this overflow when constraining; cut off the content, so the overflow is not seen (not really an option) or to allow scrollbars (potentially dangerous grounds!).

HTML elements that typically cause this are either 'iframes', or 'div' with a fixed height or width attribute value. The rational behind their use being to display content from an external site or system in the first case, or to minimise the presence of the content the div encapsulates, on the page.

What is The Problem?

Cursor or finger position on the page acts as a cue to the computer as to what the user would like to scroll. As the user travels down the page, what is below their pointer changes. This means that a user can inadvertently enter a region of the screen that has its own scrollbar, and then they would be scrolling that area instead of the containing screen. In the video below, there are three different examples of how cursor placement impacts the way the user scrolls the page:

What were the three errors when scrolling?

1. Cursor was not placed over a scrollable region
The location where the cursor is first placed in the video is not scrollable. Once the user eventually manages to scroll down the page, you will notice that the global navigation, actions bar, and heading remains in the viewport. In this case, they used a scrollable div element to make this, but instead they could have used CSS to achieve this "Sticky UI".

2. Cursor was trapped within an inline scroll
Once the cursor was placed in the middle of the screen, it began scrolling the scrollable region. Here the user got caught within the posts feed, but continued scrolling and eventually got to the end of that feed and scroll focus was given back to the parent container.

3. Cursor was trapped on the map
Finally, the cursor went down the left column, and ended up getting trapped within the map. In this situation, no matter how much the user scrolls up or down, they will never exit the map; they must first place their pointer outside of the map and then scroll, in order to continue scrolling the page.

This particular case study is a pungent one. When you begin to focus on where the user can scroll, you start to realise that there is not many locations on the page that they can safely place their cursor and travel down the page unhindered.

The areas highlighted in green allow the user to scroll unhindered.

The areas highlighted in green allow the user to scroll unhindered.

In the annotated screenshot above, the areas highlighted in green are areas the pointer can be placed without ending up on a 'Treadmill'. This means only 22% of the viewport is safe for a cursor to reside in. Should the cursor be placed in the remaining 78%, then the user will have to eventually move their cursor to one of the 'safe zones', which are not clearly marked like my annotated screenshot; they are not guaranteed to find the 'safe zone' in the first or second attempt either.

Moving a cursor to an exact location is not a quick action, as Fitts' Law will attest to. This all makes for a feeling of a loss of control, fiddly, and frustrating experience.

Remedying Treadmills

There are a number of design directions you can take to avoid or minimise the impact inline scrolling can have on an experience. Can we display on the page without the need of an additional scrollbar? Is the content list-like in nature, so that it can be paginated? Can we display it on request using progressive disclosure or a thumbnail?

In the Dynamics CRM 2013 example, the persistent header could have been solved by using a technique known as Sticky UI, which is a set of CSS rules. The posts feed could have either been paginated like the contacts section on the page, or had its own column and not introduce an additional scrollbar. Lastly, the map could have been an image, which when clicked, brings up a larger map view which is interactive; I would expect this would better fit the user's needs too, regardless of the Treadmill issue.

You cannot always avoid inline scroll. Many times, often to my displeasure, there has been a technical or business constraint which meant inline scrolling had to be used. But there are also common design patterns, like Master/Detail, which can make good use of this capability. In those cases, my advice would be to consider:

  1. Minimising the amount of screen width it or they occupies
  2. Use styling to differentiate that area, should it be a border, or background colour
  3. Do not nest inline scrolls within each other

Finally, as with everything you are doing, test it! In Axure you can make scrollable regions by placing content within a Dynamic Panel, and then:

Right click on the dynamic panel > Scrollbars > Show Vertical Scrollbar as Needed.

There is an option for horizontal scrolling too, but that should be avoided, especially if you are doing vertical scrolling as well.

August, 2014Comments are off for this post.

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!

July, 2014Comments are off for this post.

6 Tips to Make Applications Feel Faster

Speed is an important factor, and if it is not accounted for properly, can make or break an application or service. Often the focus is on measuring system performance; identifying where the most time is being spent, and then optimising the offending area.

Complementary to this, there are several strategies you can employ to make an application feel faster than it actually is. What the user sees on their screen shapes their perception on how fast they think your application/service is.

Why Faster?

It is well documented that users do not like slow websites, or software for that matter. In business terms that means:

  • Amazon: 100ms delay results in 1% sales loss
    (potential $191m lost in revenue in 2008)
  • Google: 500ms delay drops search traffic by 20%
    The cost of slower performance increases over time
  • Yahoo: 400ms delay results in 5-9% drop in full-page traffic
  • Bing: 1s delay results in 4% drop in revenue
  • AOL: Fastest 10% of users stay 50% longer than slowest 10%