When building any application it is critical to create a space that supports the primary activity of the user, while doing your best to keep your interface focused and the appropriate data on screen at all times.
When dealing with multi-dimensional data this can be incredibly tricky. For example, imagine displaying a filesystem.
Each directory represents another location within the system, and could contain dozens of files at each location. Those files could be related such as files within a project folder, or they could be unrelated, such as files within a downloads folder. Managing the location of those files is completely determined by the user, and usually only a minimum structure is provided by most operating systems.
The difficulty with managing such multi-dimensional data is understanding user intent, and the purpose of your application. Faced with an invariably unlimited amount of data your interface can quickly become overwhelmed and thus your user. This can result in decreased user focus.
Whatever the task or focus of your application, it’s important to understand user habits, and overall human habits and ability to manage large structures of information simultaneously. The size and interconnectivity of the information effects the user’s ability to manage that information.
If we refer to this paper on Cognitive Load Theory we can see that the mind has a limited set of things it can grasp at any one time before that cognitive load is overcome and the understanding of the whole problem breaks down.
Without properly framing and constraining the information into logical units, the cognitive load on the end user increases and complexity decreases.
A way to accomplish this is to separate and focus the information into smaller portals, while maintaining the ability to shift each portal along the informational axes. Normally in desktop applications this is accomplished by using windows. Returning to our filesystem example, Finder windows provide a columnar view into the hierarchy of information. These windows allow the user to quickly return up the directory tree to an earlier location and then continue to dive further into the hierarchy, until it reaches the end of a branch at a single file where the final column is used to display the file’s information. This column view offers a broad view into the filesystem data, while keeping the viewport focused on the task of navigation and file location. This is a basic example but the concepts should apply to any display of large data sets.
When working with a single portal (ie. window) it’s important to establish at least three principles to manage the data, and control the flow and focus of the view.
Determine the logical units of the data set. These represent the base of the data. Even if these units themselves contain nested data, that data should be explicitly different than that of the data from the primary set.
Establish a grouping paradigm that contains your units. The sets themselves should be light and facilitate only to organize the units and create focus on that subset.
The overview is a navigation mechanism to traverse the data sets. Whether this be a mini-map, or a source selector, or another type of interface. This mechanism should allow quick and fluid movement through the data sets.
While these are the minimum principles to establish, some nice additions might be:
- Favorites / Bookmarking
- Labels / Tags
- Coloration to separate sets by type if necessary
and if possible…
- Multiple portal views (ie. more windows with the same capabilities)
Where data can become even more dimensional is when references or links occur between sets. In these cases it is important to be explicit in those connections and to indicate those sets apart from disconnected sets. The key is to create a starting point from which to view those connections. In the example of our filesystem that start point can be the user’s home directory or the top directory of the hard drive. If sets are aliases or symlinks to other locations that connection is indicated by those directories showing an arrow above the icon.
Before trying to define your Units, Sets, and Overview it’s important to define your user’s intent and the focus of the application, or relevant view. This could be one of the hardest parts of your design exercise but once that intent is clearly defined then the units should quickly fall into play. Keep in mind that your user has a limit to their cognitive load, can only hold a limited data set in mind at any one time, and work within that limit.