ACS Human Interface Elements

ACS Developer Central : ACS Home : User-Centered Design : ACS Human Interface Elements

maintained by Lars Pind.


In Progress. I'm planning on evolving this into a ACS Human Interface Guidelines document that can become part of the standard ACS documentation. (updated August 28, 2001)

Types of Pages

(This is basically the same stuff that's described in Visual Style Guide for Admin Interfaces)

Page Layout

Here's an example of what a standard ACS page looks like:

The page layout has several standard elements that will be there on all pages. This gives our users a sense of stability and gives them a way to always know where they are, and how they get from here to other parts of the software. We'll go over each element in turn.

Bread crumbs and page type

The bread crumbs and page type bar tells you where you are in the software. All of the pages in the software belong in a site map, a global hierarchy of pages. A page may be accessed through different routes, but it always has one and only one location in the site map, so the page will have the same bread crumbs trail, regardless of the way the user navigated to go there.

Note that this is true only when talking about pages in the user model, that is, things that the user thinks of as separate pages. If two pages happen to share implementation, but they should be perceived to be different pages by the user, then they should have different bread crumb trails.

The bread crumb trail starts at the level just below My Workspace. It doesn't contain My Workspace, because there's a permanent Global navigation link to the workspace in the upper right corner. It contains a link for each level up the site map hierarchy, the links separated with a greater-than (>) character.

Page Type (as shown on the page)

The page type, as shown on the page, depends on which of the four general types of pages you're writing:

If appropriate, each link label in the breadcrumbs bar should have the form "page type: page title", for example "Content Section: Articles", "User: Sammy Smith", or "Control Panel: User Administration". Note that we don't say "Control Center: Content Center", because that just adds unnecessary clutter, as explained above. Instead, just say "Content Center".

The last element of the breadcrumbs bar should be the page type of the current page, i.e. "Article", "User" or "Control Panel". The page type at the end of the bread crumbs bar, and the page title on the line just beneath it, form a logical unit.

Page Title

The appropriate page title depends on the type of page: The page title is shown inside the page, right below the bread crumbs bar.

Note that only pages that are control centers should end with the word "Center".

Browser Window Title

The browser window title should be the page title, followed by a dash, followed by the page type. For example, for the user administration control panel, the browser windows title should be "User Administration - Control Panel". For the page for user Sammy Smith, the browser window title should be "Sammy Smith - User".

Tabs

Most pages will be tabbed, though some will not. Tabs are displayed just under the page title.

Use short labels that as clearly as possibly communicate what's on that tab. If a tab contains access to objects of a certain type, use the object type in plural, for instance "Users" or "Content types". If the label must have two words, capitalize the first word, but not the second, so that it's easier to see where a tab ends and where a new one begins.

Here's an example of a page without tabs.

Note that the tabs, when present, are conceptually a part of the standard page layout, not part of the body of the page. Like ways, while there could be a tabbed pane in other parts of the pane, these would be a separate user interface element, and should have a distinct design.

Global Navigation Links

In the upper right corner are permanent links to take the user to well-known, friendly places, so there's always a safe way out if they get lost. There'll be a link to "My Workspace", and, if possible, a link to get help. We may in the future add further links to go here.

Local Action and Navigation Links

Links and options that are local to a page, but permanent across all the tabs on a page should go to the far right of the tab bar, and look like the global navigation links. This could be a "Preview" link that opens up a preview of the current object or an "Options" link to set the display options for this page. This may be either a navigational link (taking the user to a different page) or an action link (performing some modification on the user's data), as long as you're careful with the wording so the user will know what to expect.

If there are no tabs on the page, these links will still go in the same place, only there'll be only white space to the left of them.

Maintainer Email

Put the working email address of some responsible person who can help out in case of errors in the lower left corner. This should be configured on the site, so it points to someone within the business operating the web server.

Global Action Links

Links that perform some action that should always be available to users, such as signing the user out, are put in the lower-right corner.

Body

Between the vertical line below the tabs (or below the page title, if there are no tabs) and the vertical line at the bottom of the page, is the page body. What goes here is up to you. Most commonly, the first thing inside the page body will be either a section, or one of the split-panels, the object list split-panel, the object tree split-panel, or the tabbed split-panel. More on each of these below.

Sections

Sections are used to visually and logically separate and structure the content on a page.

A section has a header which holds the section title. The header background contrasts with the white background in the rest of the page, and thus the visual effect of the header as a separator, and as a container of the body, is strong.

Subheaders

This also means that you can easily get to too much visual clutter if you have more than three or four sections on a page. If you find yourself in such a situation, either redesign your page or page flow so you don't need as many sections, or try using subheaders within the body of a section instead.

Split-panels

Spit-panels consist of a relatively narrow, vertical section down the left side of the page (or down the right side of the page in case of a right-to-left language), called the navigator panel. The rest of the page is the body of the split-panel.

The navigator lets the user make a selection between a number of choices, and the body will change to reflect that choice, i.e. display the details of the object the user chose, or display the contents of the tab that the user picked.

When you use a split-panel on a page, you shouldn't have anything else on that page, outside the body of the split-panel. For instance, it would be confusing and cluttered if you had other elements or text either above or below the split-panel.

The split-panel comes in different variants, suitable for different purposes:

  1. Object list split-panel is good when you're not likely to have more than about 20 objects to choose from.
  2. Object tree split-panel is good when the objects are naturally organized in a category, such as categories, folders, or groups.
  3. Tabbed split-panel is used when you're picking from a set of functions, instead of a set of objects.
The object list and the object tree split-panels are similar to each other, in that they both display objects of the same type. The tabbed split-panel is significantly different, and thus also designed to be visually different from the others, because it contains functions, not objects.

Object List Split-panel

The object list split panel has a header, saying what kind of objects are in the list, a list of objects, and an action link to create a new object of this type.

All the objects in this split-panel must be of the same type (or at least of the same ancestor type). The structure of the body should be the same, regardless of what object is chosen; only the content should change. For instance, in this example page, when the user selects the "Big Boss" role, the Name of role, description, members, and other information in the body changes, but the body should still have the same three sections, the first containing a display-form, the second a table, and the third an action link. This should not change.

The object list split panel will list all the objects in one flat list. Thus, it only works when there are so few elements that humans can take in all of them at the same time. This can often be ensured through a natural mapping. For instance, in this example, the objects are roles that the maintainers of a content site can take on. It is a reasonable assumption that the organization will never become so complex that there will be more than about ten different roles, because no employee would likely be able to really grasp the subtle differences between all those roles, and it's more than likely that they find a way to reorganize their organization. There are many similar natural mappings that lend themselves well to the object list split-panel.

Object Tree Split-panel

The object tree split-panel has (obviously) a tree instead of a list of objects. This also means that this element can handle more objects than the list can, because they'll have a natural organization into more comprehensible chunks.

Because an object tree split-panel can handle more objects, it also features a search box.

As with the object list split-panel, each object must be of the same type. The structure of what's in the body of the split-panel should remain consistent, regardless of the user choice, only the contents should change. There's an action link to create a new object of this type.

Tabbed Split-panel

The tabbed split-panel is significantly different from the other split-panels. Here, the contents of the navigator is not objects, but functions. Since each function will be different, the body of the split-panel is likely to be different for the different tabs.

The example here is from the User Administration control panel. It would be unwise to use the object list split-panel to show a list of users in the navigation panel, because there are likely to be hundreds or thousands of users of a site. Likewise, there's no one natural hierarchy of users, so the object tree split-panel wouldn't work either. Instead, what we've done is offer a number of different functions for browsing and searching and taking in the user population, and offer those as functions in a tabbed split-panel.

Buttons and Links

Yet to come...

Forms

Yet to come...

Tables

Yet to come...

lars@arsdigita.com