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
- Workspace
- Control Panel
- Control Center
- Object Page
(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:
-
Workspace: We don't show any page type here. The title "My
Workspace" is sufficient, since there's only one workspace page.
-
Control Panel: The page type shown is "Control Panel".
-
Control Center: We don't show any page type here. The page
title already includes the word "Center".
-
Object Page: The page type shown is the type of the object,
e.g. "Article", "User", "Product", or something similar. You don't
have to be mechanical about this and, say, always display the
pretty name of the ACS Object type. Rather, make sure that the
type you display here makes sense to the user in the context of
his or her activities.
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:
-
Workspace: There should only be one such page, and it
should be titled "My Workspace"
-
Control Panel: Say what the control panel is about ,
e.g. "User Administration" or "Site Map"
-
Control Center: These should always have a title that says
what the control center deals with, and end with "Center",
e.g. "Content Center" or "Marketing Center" or "Product Catalog
Center".
-
Object Page: These should use the name of the current
object, e.g. "How to photograph a bear" (for an article), or
"Sammy Smith" (for the User object page for a user named Sammy
Smith).
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:
-
Object list split-panel is good when you're not likely to
have more than about 20 objects to choose from.
-
Object tree split-panel is good when the objects are
naturally organized in a category, such as categories, folders, or
groups.
-
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