ACS Visual Style Guide for Administrative User Interfaces

ACS Developer Central : ACS Home : User-Centered Design : ACS Visual Style Guide for Administrative User Interfaces

maintained by Lars Pind.


Changes on July 12: (updated July 12, 2001)

1.0 Introduction

This document will define the standards for ACS administrative user interfaces. It'll outline the structure, the layout, common elements, and solutions to common problems.

It will not deal with the site visitor user experience. This has sufficiently different requirements that it needs separate treatment. And since most sites will want to customize their visitor experience anyway, that has lower priority at the time being.

2.0 Posture

An administrator of an ACS site will most likely be spending a large chunk of his or her day working with the ACS administrative user interface.

This has several consequences for the design. Most importantly, it means that our users will be experienced with the interface. Yes, each user will start out being inexperienced, but that will only be for a short time. After that, they'll be experienced. (Alan Cooper has more on soverign applications.)

It also means that we can use conventions from other applications of this sort, that our users are likely to already know. This won't generally be other websites, since most other websites are not of soverign posture, but rather applications such as Word, Excel, PowerPoint, or even Onyx. It's up to us to ensure that this experience carries over as best as possible to a web-based user interface.

3.0 Structure

The administrative user experience has these main types of pages:
  1. My Workspace is where users go right after they're logged in. This is the place to learn what is going on at this site, and to launch into control centers and control panels, where focused interaction can take place. It's a portal. The information is customized to the individual's responsibilities and interests. The workspace can be fully customized by the user, but we will provide useful starting points.
  2. Control Centers are home for focused interaction around larger concepts, such as content management, collaboration, personalization, product catalog, or promotion. A control center ties together all the tools and information needed to achieve a higher-level goal, such as making sure the site is fresh with content, learning about the site's visitors or customers and promoting the most relevant content to them, or facilitating collaboration between users. Control Centers are tabbed pages, with the first tab being a "Summary" tab that bubbles up the most important information in that control center, such as items currently under production, recently published items and their popularity metrics, most active collaboration forums or discussion threads, etc. We should be creative in offering the information that the users are really interested in.
  3. Control Panels are for interactions that are much more narrow in scope, such as viewing and managing a to-do list, the site map, server logs, categories, package installation, etc. Control panels may be used stand-alone, or they may be integrated into control centers. For example, we could have a Site Map control panel, a Package Installation control panel, and a Server Log control panel, which could be accessed stand-alone, and/or integrated into one Site Management control center.
  4. Object Pages are for managing an individual object, e.g., a content item, a user class, or a task in a to do list. Object pages should look out to other applications to pull in relevant information, such as the status of a workflow around the object, permissions on the object, where the object is used, and offer links to relevant actions that can be done with the object, such as starting an internal discussion thread about the object. The object page will be a tabbed page, with the first tab being a Summary tab that summarizes the most important information about that object.

4.0 Interface Patterns

There are a number of recurring patterns in ACS user interfaces. Here's a list of the most prevalent ones:

4.1 Standard Page Layout

Header, possibly tab bar, possibly another header, body, footer. The standard layout of a page contains these pieces (example):
  1. A bread-crumbs bar
  2. Out-of-flow links: My workspace, sign out, help
  3. A header
  4. A tab bar, or just a horizontal line
  5. Body of page
  6. A horizontal line
  7. Footer
The bread crumbs bar is only present in pages that are beyond the levels of workspace and control center. The workspace link is always present elsewhere. When present, it holds a link to the control center from which you navigated, or under which this page logically belongs (there might be problems here with certain objects belonging in differnet control centers, we'll see). When at an object page, the last element in the bread crumbs bar should be the type of the object, e.g., "Content Section", whereas the header contains the name of the object currently on screen, e.g., "Articles". The bread crumbs bar is placed above the header, to make the hierarchy of pages and how the current page relates to it, visually clear.

The out-of-flow links are placed in the upper right corner, and holds links to go to My Workspace (unless we're already in the workspace), to sign out, and to access help (yet nonexistent). Other links may turn out to be appropriate here, and it's an obvious place for customization. Also, similar types of links could also be placed in the footer.

The header has different colors, depending on the layer in the hierarchy we're at.

The labels on tabs in the tab bar should only capitalize the first letter. This makes it easier to distinguish between tabs, when a tab label contains multiple words. If the second word was capitalized as well, it might be mistaken for being a separate tab.

The footer is currently unused. We used to have the admin email down there, but I'm not sure anyone ever used that as intended. We might use it as a place to put more out-of-flow links, or we could do a number of other things with it, since it'll generally not disturb the user.

4.2 Portal Page

The user's My Workspace is an example of a portal page. The body of the page contains a number of frames of information and links to launch interaction pages. These frames are called "portlets".

Portlets come in two widths, narrow and wide. Each individual portlet may be avaiable in both narrow and wide, or it may only be available in either of these forms. Needless to say, the choice depends on the amount of information there is to share, and the narrow version of a portlet available in both forms should contain less and more focused information than the wide version. Narrow portlets have a gray background, wide portlets have white background. Each share the same background color and style for headers.

No interaction takes place on the portal page itself, although it's perfectly appropriate for a portal to contain a form, that then redirects to a page where focused interaction can take place.

A portlet should generally only give a summary of, say, the 5 most important tasks, based on a weighted index of priority, deadlines, or amount of recent discussion about the task, and then offer a link to visit the complete list of tasks.

4.3 Forms

Forms are pretty straight-forward. They come in two different versions: One for display and one for editing. (Note: The blue frame is just for this page, forms shouldn't be framed on the final pages.)

Title:    How to photograph a bear
Content Type:    How-to article
Location:    /articles/how-to/photographing-bears
Description:    Explains in detail how to take pictures of bears, including things such as what clothes to wear, and what food to bring (and what food *not* to bring).

    Edit

Here's the edit form:

Title:   
Content Type:   
Location:   
Description:   

   

The buttons are labeled "Save" and "Cancel", and are found in the lower right corner. If there's a frame around the form, the buttons should be inside that frame, to make it clear what the buttons are operating on.

4.4 Tables

The task list is an example of a sortable table with dimensional sliders.

Deadline
any | overdue | one week | one month ]
Task
any | author | edit | categorize ]
   RankReverse order   
   Item   
   Task   
   Deadline   
   Action   
   1.   
   Bear Photography   
   Author   
   Aug 4, 2001   
   Lock item   
   2.   
   Using a Flash for Nature Photography   
   Edit   
   Aug 8, 2001   
   Lock item   
   3.   
   Choosing a Camera Bag   
   Categorize   
   Aug 12, 2001   
   Lock item   
   4.   
   New Digital Elph   
   Author   
   Aug 9, 2001   
   Lock item   
   5.   
   Digital Camera Accessories   
   Categorize   
   Aug 11, 2001   
   Lock item   

In addition to following this layout, tables should also follow some other conventions. The header, while being a link, should in this case be black, not blue. This is an exception to the links-should-be-blue-and-underlined rule, but it is necessary because we don't want the headers, which are the static, to attract the user's attention over the content of the table, which is what changes.

When clicking on a header, the table should be sorted by the values in that columns. The default for whether we're sorting ascending or descending should depend on the content of that column. For example, a title should by default sort alphabetically, with A before B, etc., while a column containing dates in the past should normally sort descending, with the most recent date first. Make judgements based on what the user is most likely to want.

Note also that the links make use of the TITLE attribute to explain what happens when the user clicks on a link. Browsers that support it (MS IE) will display this as a tool tip.

If there are no dimensional sliders, then the frame around the table isn't necessary. They're only necessary to make it visually clear that the dimensional sliders are operating on the table, and not on some other object on the page. See the content sections tab for an example of this.

4.5 Non-table list of things

Choosing a camera bag
How to Photograph a Bear
Flash photography

Use the little orange triangle when you want to display lists of items, but don't have any additional information to present about them, in which case you'd be using a table.

Make sure there's no space between the triangle and the item link.

4.6 Split-pane with list of objects on the left

The Staff tab in the Content Section is an example of a vertically split page. The left column holds a list of objects, while the right column holds the details for the selected object. Again, the frame below shouldn't be there in the real interface.

Select a Role
 Manager
 Author
 Editor
 Publisher
 Lawyer
 
Create new role
Name and Description

Role label:    Publisher
Description:    Has overall responsibility for the content of the site. Is allowed to make decisions about creating or requesting new content, oversees the production workflow, and has authority to override any decision made by other staff members.
Permissions:   
  • Administer categories
  • Administer staff
  • Create new items
  • Publish items
  • Manage workflow
  • Edit name and description

    Users who are publishers     (4)

       User   
       Action   
       Carrie McGee   
       Remove   
       Sean Levy   
       Remove   
       Alistair Jensen   
       Remove   
       Sarah Oswald   
       Remove   

    Add user to this role

    ... more stuf ...

    There are a number of things to be aware of when using this layout. First of all, for consistency, the items on the left should always be a list of objects, such as roles, content types, etc., and the user can create new objects of this type. In contrast, we might want a similar layout where the items on the left are different functional areas, similar to what the tab bar does. In this case, it's important that we come up with a visually clearly different design for this, so that we don't appear to be inconsistent.

    There are a couple other issues. This interface might lead the user to believe that she can start editing the details for one object, switch to another object, and then switch back to the first object, without loosing her edits. This is obviously not the case. In order to minimize the problems that this would cause, the amount of interaction to be performed on the right half of the screen should be limited. Rather, the right pane should contain links that will take the user to a separate page where interaction can take place. This interaction-focused page would then either not contain the links on the left at all, or they wouldn't be clickable. In particular, in the case, as here, where the right pane contains lots of different information, the interaction page should still only hold the stuff that's currently being interacted on.

    Another problem is what information do you display in the right pane when the page is first hit, and no object on the left is yet selected. I advocate pre-selecting the first object, and showing those details on the right.

    5.0 Outtro

    This is a first draft, intended to be a living document, as our standards continue to evolve. Feel free to give us your feedback on these issues.

    lars@arsdigita.com