« Back to blog

Background and Design of Rackspace's Unbounded List Widget

Skip to The Problem, Interaction Research, UI Research, Usability Testing or the Final Design.

The Problem

Like many of the major web applications and social networks, Rackspace must meet the needs of any customer, from those with only 10 employees to a large enterprise. Enterprises present several interesting design challenges to our Email & Apps Control Panel because they have a large amount of email addresses, aliases, group lists, etc., and are essentially boundless. Loading these large datasets can impact the performance of our services for that specific user, and in come rare cases, the performance of the entire Control Panel. We've started to roll out our solution to the issues, which we call the Unbounded List, and I wanted to provide some insight on how we arrived at our solution. It is also important to note that our background research and user study methodologies also include interviews, survey results, statistical analysis of usage and other quantitative practices which are not covered in this blog post.

Interaction Research

We first looked to existing solutions in the industry, particularly those by Google and Twitter because both companies display extremely large sets of data. The original Twitter interface used a traditional list and provided a button to show more tweets. This is a very simple method but can get cumbersome when you are required to hit the button five times to view 100+ tweets or if you are looking for a tweet in the middle of a long list.

Screen_shot_2010-11-10_at_9

The new Twitter redesign uses a scroll-based loading mechanism that will load new tweets when you start to scroll within a certain percentage of the bottom of the list. This practice works well when you are reading each tweet, but not when you are trying to find a specific item, as in our use-case.

Screen_shot_2010-11-10_at_9

Google Images uses a hybrid of both of these practices by loading several "pages" (basically sections) of images, then loading the content of each "page" as you scroll towards it. As you reach the last "page" you are presented with a button that will load more pages. I suspect that Google designers have found that any images past this point are mostly useless and are trying to guide the user to make a new search instead of looking through useless images.

Screen_shot_2010-11-10_at_8

UI Research

Facebook has made a huge improvement in the format and display of their lists in the past few versions of their application. Our design team especially liked the concept of showing "All" and "Selected" friends when creating an event. Facebook also has a very prominent search box that helps the user to find someone among hundreds of friends. Search is very important to us because enterprise customers frequently need to find a single email address out of 30,000 or more.

Screen_shot_2010-11-10_at_9

The iPhone also does a good job of displaying a list of recipients for sending an email or a text message. However, Apple's interaction practice is different from our control panel because iPhone data is already on the device, but we will need to load ours on the fly from a remote server. The luxury of having the complete list to scroll through is immediately apparent, particularly when combined with Apple's acceleration-based scrolling algorithm. UI-wise, our team liked the section dividers and the alphabetical listing on the right.

Photo

Design Iterations

Our first wireframe concept was focused on allowing users to accomplish the two main use-cases: adding someone to the list and confirming their change/viewing who is on the list. Most of what you see in the next two screenshots was eventually discarded, but you can see how we experimented with expanding/collapsing/side-by-side sections, an alphabetical listing on the side, and an inline search field.

Screen_shot_2010-11-10_at_9
Screen_shot_2010-11-10_at_9

After a few interactions and informal testing, we arrived at the design below, which was then used for formal usability testing. The floating "All" and "Selected" links became tabs to solidify their relationship to the list and align with our current UI practices. Custom checkbox icons were chosen to give us maximum flexibility to reflect states other than just on and off in any future designs. Product icons were also included to allow for mental filtering and add a little bit of color. At this point we were heading towards the Google Images interaction model, which prefetches a set of results then loads the rest as the user scrolls up or down.

Screen_shot_2010-11-10_at_9

Usability Testing

Our formal test plan included two groups of users: those already familiar with our Control Panel and who had never seen it before. We found that most users initially understood what the widget was showing them, but had a hard time comprehending the selected and de-selected states. This was caused by our over-stylized check boxes and our choice to select the "All Users" tab by default. Most of our testers wanted to see a list of the current members, not all possible members on the domain. This comes down to which use-case is more important: Which users are on this list? or I need to add Joe to this list.

In light of these results, we clarified the names of the tabs, modified the sprites of the checked/unchecked states, and changed the default tab state. Because the list used custom icons instead of native browser checkboxes, we were able to improve usability by adding a hover state to both the row background and the icon itself, which is impossible with native checkboxes.

The Final Design

Screen_shot_2010-11-10_at_9

You can find this new Unbounded List widget in several places in our Beta Control Panel and will soon be launching into our production Control Panel.

Comments (0)

Leave a comment...