Portlet & Channel UI Widgets

Ensuring consistency of presentation and experience is a primary goal of portal UI design. From a portlet/channel-centric perspective, portal user interfaces can be thought of as having 2 separate pieces: "content" and "chrome." which combine from a user-perspective to produce all the pieces they can interact with onscreen.

Chrome	Portal Framework UI - controls for focusing, minimizing, changing modes, editing, customizing layouts, and portal navigation
Content	UI rendered by individual channels or portlets

Within the various content pieces of the portal layout, it is desireable to provide

consistent visual presentation
consistent tool usage
consistent behavior

To address 1 and some of 2, Rutgers recently embarked on a design exercise to envision a "common widget library" for the myRutgers portal. Deliverables targeted include:

Design Mockups
XHTML/CSS Widget Styles
Channel Layout/Design Guide
Widget Usage guide

This work is planned to occur on uPortal 2.x HEAD and is targeted for inclusion in the Spring 2.6 release.

Design Mockups

Some of the initial widgets targeted were:

Tabs

Many of our channels use or benefit from exposing "sets" of data, for which tabs is a common metaphor. Tabs are envisioned as primarily a navigational element, for use when random navigation is desired.

Toolbars - channel wide, and "captured" within particular panes/tabs

Toolbars are meant to provide a consistent interface for actions. Thus the vision is that tabs provide navigation within a channel's screens or content, while a toolbar is used to delineate actions the user may perform within the channel, or against a specific set of data. Toolbars are seen as operating in a couple of modes:

Channel-wide

These toolbars are seen as being anchored to the channel window chrome itself. Either the top or bottom are possible, though top placement would seem to offer the closest parallel with desktop application metaphors. The idea is to visually indicate the channel wide scope by having a toolbar element span the width of the entire channel content area.

"Captured"

These toolbars are intended to convey actions pertaining to a particular set of data, or view. Using similar markup and structure to the channel-side toolbar, the intention is to nest them within some other navigational or other grouping element (e.g. tab, fieldset, pane, etc.)

The top item below illustrates a channel-wide toolbar, whereas the bottom 2 channels demonstrate a captured one.

Messages - confirmation, failure, warning, etc.

These represent an attempt to standardize the placement and indication of severity of various feedback messages used by channels. The overall look and feel could probably tie in with portal framework level user feedback messages & indicators.

Data Tables

Striping rows and distinguishing headers is common. Additionally functionality which it would be nice to standardize are paging & scrolling controls, sorting, default sorting, sorting indication, cell overflow, etc.

Status Bar style details

The bottom of the channel seems to be a logical place to convey status information like disk quotas, uptime, refreshes, etc. that wish to be communicated in an un-obtrusive fashion.

>> How do these status messages jibe with disclaimers?