UI Considerations: Layouts

This is the second entry in what I might make into a “UI Considerations” series. The first entry was UI Considerations for the Small Independent Developer that covered a few basic concepts like use-cases, Information Value and Interaction Impulse.  As a reminder, these entries are oriented toward to the hobby developers that do not have the resources of an expert UI design or test team, but are still seeking some easily digestible UI guidance that they can act on at design time.  To be clear, this is not canonical UI guidance nor is it intended as a substitute for expert advice. These are just a collection of my observations over the years as a hobbyist and a borderline-obsessed fan of design in general and UI design in particular.

A quick recap from the first entry:

• Ideally, use-cases should be implementation-agnostic.
• The best UI allows the user to accomplish their goal(s) with minimum cognitive impact.
• Reducing or eliminating elements with low Information Values should a goal of the UI designer.
• Minimizing or eliminating high Interaction Impulse elements that do not support the use case should be a goal of the UI designer.

In this entry, I’ll take a look at layouts from a pretty high level.  The focus will mostly be on the high-level layouts you see when you first encounter an application, a desktop environment, or website, not necessarily the low-level layout used for individual UI elements. These high-level layouts may also be how you recognize or remember the application.  For example, when you think of a Windows 7 desktop what is the first image that comes to mind? For me that image has two general sections: the desktop area on top and the taskbar area below.  How about a web browser like Chrome or Rekonq?  Address bar + tabs on top, page content below. How about a file manager like Dolphin or Nautilus?  Places on the left, list of file icons on the right. I’m talking about that high-level layout you encounter when you first ask yourself  “Ok, how does this thing work?” and proceed to visually scan the application for clues.  Go check out your favorite app, desktop environment or website and see if you can identify the top level layout pattern.

Consider the layout patterns in Figure 1.

Figure 1 - Two Section Layout Patterns

Each layout pattern has two areas or sections arranged in different ways. In order to answer “How does this thing work?”, the user looks at each section, tries to understand its purpose then move to another section if necessary. Depending on the UI elements in each section and, in some cases, depending on the t layout pattern itself, a visual hierarchy will emerge that encourages the user where to look first, then where to look next. As the user moves from section to section, they may also try to understand how the sections relate to each other.  This visual scanning allows the user to accumulate the necessary information to answer the question.

Note that while I’ve framed the user’s question as “How does this thing work?”, answering that question is not really what the user is, in the end, hoping to accomplish. The user hopes to accomplish a specific goal (use-case) by using your application as a tool.  Answering “How does this thing work?” is a means to that end, not an end in itself.  During the visual scan the user accumulates information that is relevant to the use-case they are trying to satisfy. This implies that the user is generally not terribly interested in scrutinizing every icon, reading endless text and twiddling all the knobs and dials of your application to see what happens just for the sake of it.  Again, the user is interested in accomplishing a specific goal. Once the user has enough information to satisfy the use-case, every remaining UI element that was not scanned by the user is entirely extraneous to that use-case.  The quicker the user can answer the question the better, which means that the Information Value of each UI element in a section, and of the section itself, must be high enough that the user can quickly determine the section’s purpose and its relationship to other sections.

The arrows shown in the layout patterns are intended to show the relationship between sections. If the user is just gathering information visually then consider the arrow to mean “provides context for”.  If the user  is interacting with the application , consider the arrow mean “can affect”.  So in all the four layouts, it could be said section 1 provides context for, or can affect, section 2. In layout pattern D, section 2 provides context for, or can affect, section 1.  In each section high Information Value elements (again, relevant to the use-case) help the user figure out the “provides context for” relationships and high Interaction Impulse elements (relevant to the use-case) help the user figure out the “can affect” relationships.

So consider Dolphin, for example, which has the Places panel on the left and the file listing on the right as in Figure 2.

 

Figure 2 - Dolphin

When the user is just gathering information, the files displayed in the file list section generally corresponds to the selection in Places section – the Places section provides context for the file list section. The highlighted Home element in the Places section also appears in file list section as the “header” (breadcrumb control) in that section (even with a similar icon), providing a relatively high Information Value for understanding how the two sections might be related. The familiar selection highlight in the Places section also provides a high enough Interaction Impulse to suggest to the user that they can make a different selection in this section. If the user makes a different selection in Places, the file list section is updated to reflect that selection – the Places section can affect the file list section.  However, if the user selects a different icon in the file list section, the Places panel doesn’t (generally) change – the file list section doesn’t (generally) affect the contents of the Places section.  These sectional relationships suggest that the layout pattern is similar to Pattern A in Figure 1.

The default KDE Plasma or Windows 7 desktop environment is similar to Pattern D with the panel/taskbar area in section 2 and the desktop area in section 1. Can you recognize these patterns in your favorite application, desktop environment or website?

Of course, there can be more than just two sections in a layout pattern.  Generally, the more sections in a layout, the greater the opportunity for increased effort on the part of the user.  For every added section, the user may have to visually scan more sections and spend more time figuring out the purpose of each section and the relationships between sections.  That doesn’t mean a successful design is impossible with more sections. It just means greater design effort is needed to minimize user effort. Figure 3 shows some three section layouts.

 

Figure 3 - Three Section Layout Patterns

Section relationships, if they exist, should always be between adjacent sections. Pattern I and III shows what I think are good relationships between sections.  Pattern II and IV shows section relationships that might be a bit more challenging for the user to deal with.

It can also be helpful to keep the relationships going in the same general direction (Pattern I and III).  When the user is visually scanning the interface, this can help create a consistent mental model of how to gather information from the application. E.g. “Start at the left to get general information, move to the right to get additional information.”  The choice of direction can, in some cases, be influenced by right-to-left (RTL) writing systems.  Also, there may be times where keeping the same relationship direction may be unavoidable or even desirable, like for toolbar sections surrounding a central content section.  One example might be a photo editor or painting application with toolbars on both sides of the picture or painting.

Let’s look again at Dolphin, this time with a three section layout as in Figure 4.   On the left is the Places panel, the middle the file list and on the right is the Information panel.

 

Figure 4 - Dolphin, three sections

The layout is similar to Pattern I from Figure 3.  As before the Places panel provides context for and can affect the file list view. With the added Information panel, the file list view now provides context for and can affect the Information panel.

Other three section patterns can get a little more challenging.

Figure 5 - Other Three Section Patterns

In the patterns in Figure 5, each section is adjacent to two other sections, which means there are potentially two relationships to figure out per section.  If adjacent sections potentially  have bidirectional relationships then there are up to six potential relationships between sections for any of these layout patterns.  Again, this does not mean it is impossible to create a successful design with these patterns.  (I confess that the Dolphin layout in Figure 2 may actually be more similar Pattern I here but I’ll get back to this in a little). Convention can assist the user in making a decent guess about these sectional relationships.  But sometimes the convention the designer is appealing to may not be one the user is familiar with.  That can be one of the weaknesses of relying solely on convention, especially conventions based of poor precedents.

Of course, it gets even more challenging as we add more sections.

Figure 6 - Four Section Patterns

So how do we handle more complex patterns that can sometimes be necessary as applications become more complex and full featured?  One way is by embedding layout patterns or subsections into each section, as in Figure 7.

Figure 7 - Embedded Two Section Patterns

Using grouping elements (whitespace, color, framing, etc.) to provide strong, unambiguous visual hints for each section, the user can easily identify and deal with a collection of sections as one section. This can be helpful since, it reduces the number of sectional relationships the user has to figure out.  For a successful design that uses Pattern I of Figure 7, the user would only need to identify the relationship between section 1 and 2 and, where necessary, between section A and B within section 2. Compare to Pattern III from Figure 5, where the user may need to figure out the relationships between all three sections.

Now let’s look at Dolphin again. So I cheated a bit earlier since I basically ignored the menu and toolbar. If you consider them, then the layout pattern is actually similar to both Pattern I in Figure 5 and Pattern II in Figure 7.  However, due both to very strong convention (how menus and toolbars are used in most apps) as well as whitespace and framing, I think most users consider the menu and toolbar as one section – a kind of header – and the lower portion as another section containing the Places panel and file list view (and Information panel if present). In that sense the Dolphin layout pattern is more like Pattern II here. If you look even closer at Dolphin, you’ll see that the file list view area actually contains another three section pattern with the breadcrumb section on top, the list view in the middle section and the status and zoom controls in the lower section. There, even more so, most of the information and interaction relationships are strictly between those subsections with little-to-no outward relationships to top level sections.

Since I’m most familiar with Bangarang, I’ll talk a little about how what has been mentioned so far influenced the current UI design. The top-level application layout pattern is basically a two section pattern (Pattern D from Figure 1). Embedded section patterns/subsections are used in many places to minimize the number of sections at each level. The intent was to keep the application looking relatively simple and easy to scan and interact with.

 

Figure 8 - Bangarang Now Playing

The Now Playing view has an upper and lower section. The lower section contains mostly playback controls as well as a control to get to the Media Lists View. When the playlist is visible, as shown in Figure 8, the upper section contains two subsections – the now playing art/info and the playlist view.   Color is used to create a relatively strong visual hint for the upper section and its contents and to distinguish it from the lower section.

Quick note: It took some trial and error to settle on the final contents of the lower section.  One decision was to put the Shuffle and Repeat controls in the header subsection of the playlist view instead of in the lower section beside the full screen control.  A survey of several media player UI designs uncovered a split between designs that consider Shuffle and Repeat to be player properties (like fullscreen) and designs that consider them to be playlist properties.  For several reasons, including the desire to minimize the number elements in this lower section, I chose the latter. We end up with less elements in the lower section for the user to scan, and the new placement of Shuffle and Repeat took advantage of the existing relationship between the playlist view header (which at that point in the design process already contained the Clear Playlist control) and the playlist contents.

Figure 9 - Bangarang Media Lists

The Media Lists view has an upper section and a lower section as shown in Figure 9.  A little white space as well as vertical alignment of the framing elements of the upper section help to define both the upper and the lower sections.  Additionally the lower section has the same height as the lower section of the Now Playing view which helps reinforce it as a separate section with some persistence and visual weight. Another result of this lower section height is that the upper section in the Media List view “replaces” the upper section from the Now Playing view when switching between the two views. These help maintain the application layout pattern and keeps a conceptual connection between Media Lists view and the Now Playing view even though they look quite different.

The upper section itself contains two subsections: the Media Lists selection on the left and media list contents on the right. The “Media Lists” title – same text and font-weight as the control in the Now Playing view that the user clicked to get here – along with the surrounding white space serves as an anchor that establishes the left section as the starting point in the visual hierarchy. Early on in the design, one attempt at this title included placing it at a top-center location.  Another attempt included just setting the window text title to say “Media Lists”.  But, in neither case did the text actually provide much additional meaning or value (there’s that Information Value term again..). When it was moved its current location it started to make much more sense for reasons mentioned above.

Strong grouping elements (framing and color) are used to define the media list contents section on the right, which itself also has two subsections containing the list view on the left and the Info View on the right (you could also consider the header another section which helps reinforce the section as a whole).  The autoFillBackground property is purposefully turned on for the header of the media list contents so that the window background gradient doesn’t continue into the section. The background color in the Info View section was purposefully altered to use the view background color from the palette (to match the list view) instead of the window background color.

The relationship between the upper and lower sections of the Media Lists view is bidirectional. Because of the relatively high information density in the upper section, the lower section was kept relatively sparse, which minimizes the amount of information needed to understand the purpose of this section and its relationship to the upper section. In the upper section, the direction of the sectional relationships are maintained even within subsections. So the Media Lists selection section on the left provides context for and can affect the media list contents section on the right. The search field was placed in this left section instead of somewhere else in the interface since performing a search is just another way to affect the media list contents – one less sectional relationship the user has to figure out. Additionally, within the media list contents section, the list provides context for and can affect the Info View to its right.

The above discussion is not meant to imply there’s no room for improvement or that we got it all “right”. We are always looking for ways to improve Bangarang’s design. 🙂

Below are some other applications screenshots I found around the web.  What do you think are the application layout patterns, embedded patterns/subsections and sectional relationships? (Of course, it’ll be tougher to figure out interaction relationships if you’re not familiar with the application.) If you think there are deficiencies, how would you improve them?

Pages

KWord

iTunes

Outlook 2003

Take a look at your favorite application, desktop environment or website and see if you can identify the layout patterns, embedded patterns/subsections and sectional relationships. Mobile applications have fairly tight restrictions on space so careful attention is paid to layouts in the design process.  The transition from mobile to tablet applications gives designers a little more room to work with, but generally not quite as much as desktop applications.  Desktop applications have even more room, but there are limits since they do have to share the desktop space with other applications. There are likely are many, many lessons that us desktop application designers can learn from mobile and tablet application designs, especially in the area of layouts.  The desktop environment of course can use the entire screen.Websites tend to have less constraints vertically than they do horizontally, but even here some restraint can be a merciful relief for users.

Conclusion

So after all that yammering (geez ,I’m long-winded), here are some of my suggestions for my fellow hobby hackers. When laying out your UI, consider the following:

• Basic concepts from the first entry in the series. Remember to identify the use-cases and keep in mind the concepts of Information Value and Interaction Impulse.
• The number of top level sections. The fewer the better.
• Section contents. Try to ensure elements in each top level section have high enough Information Values to serve the primary use-cases of your application and to help direct the user to the starting point in the visual hierarchy.  Avoid dumping elements into top level sections that only serve obscure use-cases, or that are better functionally located elsewhere  – use other discovery mechanisms (menus, stacks, toggles, tabs, etc.) to reveal additional functionality. Also, avoid dumping functionally unrelated elements into the same section.
• The relationship between sections.  Unidirectional relationships are generally easier on the user than bidirectional relationships. Try not to force the user to re-examine a section they’ve already scanned. Use embedded layout patterns or subsections to minimize the number of relationships. Try to provide elements with a relatively high Information Value across sections to help the user quickly understand the “provides context for” relationships. If a primary use-case for your design requires user interaction in one section that “can affect” another section, provide the minimum elements with relatively high Interaction Impulse necessary to help the user quickly understand these relationships.

As with most design, you are just as likely to stumble into a solution before you understand why it works, as you are to understand what will work before you craft a solution.  For Bangarang, so far, it has been about 50-50, and many decisions are rarely absolutely “right” or “wrong”. What matters, for me at least, is coming to some kind of understanding of why a solution works.  And for this geek, that’s been a lot of fun!

Hope you find this helpful!