maintained by Lars Pind.
Changes on July 12:(updated July 12, 2001)
- Changed layout of form: Making the values bold was very cluttering for long values, such as a description.
- Changed the headers of the split-pane, and got rid of things that've been deprecated in the CMS UI.
- Changed the table layout: The non-breaking spaces within the cells caused the tables to look very ugly when the table got so wide the contents needed to be wrapped.
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.
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.
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.)
|
Here's the edit form:
|
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.
|
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
|
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.
|
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.
lars@arsdigita.com