Table Information Design Usage Guideline

Guideline Contents

• General Principles
• Table Size
• Table Width
• Table Height
• Displaying an Empty Table
• Grid Lines and Banding
• Grid Lines
• Banding
• Grid Line and Banding Recommendations
• Column Groups
• Column Totals
• Subtotals
• Totals
• Grand Totals
• Alignment
• Horizontal Alignment
• Vertical Alignment

Related Guidelines

Related ADF Elements

Refer to the ADF Faces Rich Client demos page to find demos and tag documentation for the ADF elements related to this component:

General Principles

Table Size

Table Width

Description:

• By default, the width of the table matches the width of its container. If the width of the container changes, the table resizes to fit within or fill the container.
• Tables may have between one and an unlimited number of columns. Developers determine the number of columns by choosing which attributes to display.
• If a column contains web widgets, the column width adjusts automatically to accommodate the widest cell in that column.
• Developers may affect the width of columns by specifying the content of the cell, such as text input fields, status icons, and functional icons. See Table Cells in the Table Elements guideline for details.
• If the number of columns in the table exceeds the defined width, a horizontal scroll bar appears. See Scroll Bars in the Table Elements guideline for more details.

Usage:

• Product teams may set the width of the table using any CSS measurement unit, including pixels, percentages, inches, metric units (cm and mm), and typographic units (em, ex, pc, pt).
• If the width of the table is longer than cumulative column widths, there will be dead space at the end of the last column by default. Product teams may optionally eliminate this dead space by stretching the last column to fill the available space.
• Horizontal scrolling should usually be avoided, because users may not realize that additional columns are hidden from view.
• To avoid horizontal scrolling, a table should include no more than 6-8 columns—six for tables with wide columns and eight for tables with narrower columns, such as actions columns of functional icons. For more information on column content, see Columns in the Table Elements guideline.
• When objects have too many attributes to be displayed within the table, it may be necessary to provide a drill down link to display the full set of attributes.
• A limited amount of horizontal scrolling may be appropriate to optimize data entry and reduce task completion times. However, limit horizontal scrolling to less than three screen widths of columns. Consider allowing scrolling when production users need to:
• Quickly review or compare information across multiple objects in a table.
• See the context of other records while viewing a specific object.
• Quickly review and act upon multiple objects in succession.

Table Height

Description:

• By default, the height of the table is 300 pixels.
• Each row's height adjusts independently to accommodate the tallest cell in that row.
• If the number of rows of data in the table exceeds the defined height, a vertical scroll bar appears. See Scroll Bars in the Table Elements guideline for more details.
• If the number of rows of data in the table is less than the defined height, there will be vertical white space beneath the last visible row of data unless autoHeightRows is enabled.

Usage:

• Product teams may set the height of the table to any height using any CSS measurement unit, including pixels, percentages, inches, metric units (cm and mm), and typographic units (em, ex, pc, pt).
• Row height may be affected by wrapping in cells or the presence of long strings or tall images in cells. If the table is likely to have abnormally large row heights (as in a procurement application), product teams should set the height to accommodate an average of 20 rows or more, depending on the anticipated row height.
• Vertical scrolling within a table is not problematic. However, it is recommended to avoid having both table and browser scroll bars displayed at the same time, because users may click the other scroll bar by accident.
• When working with smaller sets of data, it is recommended to set the table height to be able to display all records without vertical scrolling.
• Variable table height is preferred when the table is the primary component on the page, allowing the table to increase its height if needed when the user resizes the browser window.
• Fixed table heights are preferred in complex layouts where dynamic resizing of components could break the layout. When using fixed table heights, all tables should be able to display a minimum of three rows in addition to column headers, toolbars, and status bars, if present. This equates to the following minimum heights in pixels:
• Tables without toolbar or status bar: 80 px
• Tables with toolbar and status bar: 125 px

Displaying an Empty Table

A table may be displayed without data. This is commonly used for tasks where the user performs an action that returns results data in a table, or where users frequently populate the table with their own data.

• An empty table is displayed to set user expectations for the type of results that will be returned once the action is performed.
• An empty table includes specific column headers and no rows. A pre-defined text string may be displayed by itself in the view region where rows normally display.
• When the action is performed, the resulting data fills the table.
• The default text in an empty table is "No data to display." Product developers may customize this text based on the table's usage context. The following matrix shows examples of such customizations:

Empty Table with "No data to display." Text

Grid Lines and Banding

Purpose:

Grid lines and banding emphasize different aspects of the information in a table.

Description:

A grid is made from thin horizontal and vertical rules between rows and/or columns in a table. Bands are formed when the background colors of rows or columns alternate between white and light gray.

Usage:

Grids are often sufficient for simple tables. Bands provide stronger emphasis for complex tables, including wide tables. Grids are also often used to provide another level of structure to a banded table.

Grid Lines

A grid is made from thin horizontal and vertical rules between rows and/or columns in a table. The following grid line combinations are supported:

• Horizontal grid lines
• Vertical grid lines
• Horizontal and vertical grid lines
• No grid lines

Grid Lines: Horizontal

Grid Lines: Vertical

Grid Lines: Horizontal and Vertical

Grid Lines: None

See Common Grid Line and Banding Combinations below for usage recommendations.

Banding

Horizontal and/or vertical banding should not be used (and should be set to "0") except when it is difficult to determine the horizontal and vertical relationships of the data, as in the following cases:

• Tables with a large number of rows and columns. For example, there may be instances where the table contains a number of columns that extend beyond the width of the table, which the user must scroll to see. In this case, banding helps the user keep track of data from row to row when scrolling across the table.
• Tables with dense numerical data. For example, when the table contains a large number of short columns of dollar amounts or numerical data, it is difficult for the user to scan the rows. In this case, banding helps to visually separate between rows of data.

Banding: Horizontal

Banding: Vertical

Banding: Horizontal and Vertical

Banding: Intervals

Any combination of horizontal and vertical banding intervals is supported, for example: 'n' non-banded rows / 'nn' banded rows. See the following section for usage recommendations.

Common Grid Line and Banding Combinations

The following matrix lists some common combinations of grids and bands, and provides recommendations for when to use them. These recommendations are based on the following characteristics:

• Emphasis: Tables may be banded based on horizontal or vertical relationships in the information, or both.
• Information Density: Tables containing single names and numbers have light information density. Tables with extensive text, complex graphics, or complex controls have medium-to-heavy density.
• Interactivity: Tables containing minimal, simple controls, such as a check box in each row, provide light interactivity. Tables with multiple complex controls in every row provide heavy interactivity.

Column Groups

Purpose:

Allow a column to be divided into multiple child columns.

Example:

A column labeled "Column Group" may be divided into secondary columns labeled "ChildBA","ChildBB", and "ChildBC". In this case, the three secondary columns span the full width of the primary column.

Column Group: Two Levels

• Column groups are only used when an attribute is a container for a set of subordinate attributes.
• Column groups consist of one parent column and at least two child columns.
• It is recommended to show no more than two levels because additional levels are not accessible. If more levels need to be displayed, consider using a Crosstab/Pivot Table.
• There is no limit to the number of child columns in a column group, but it is recommended to include no more than four to avoid having wide tables. If more child columns need to be displayed, consider drilling down to a separate table if comparison of parent columns is not required.
• A column group context menu is the same as the context menu for multiple column selection; actions that are not supported for multiple column selection appear disabled.
• The sorted column icon and sortable column indicator are not permitted in parent columns; however, advanced sort (using a context menu or menu bar) is permitted on column group selection.
• Up and down arrow keys move keyboard focus between a parent column header and child column headers.

Column Totals

Purpose:

Calculate totals for part or all of a set of objects with one or more numeric attributes.

Description:

• Totaling is not included in the component, but may be coded by product teams.
• There are three types of totals:
• Subtotals: For totaling a subset of cells in a column. Subtotals may appear anywhere in the column.
• Totals: For totaling all cells in a column, whether visible or not. When used, Totals always appear in the last row.
• Grand Totals: For totaling across multiple tables or filtered set of objects. Grand Totals are placed above or below the table.
• Subtotal and Total data need to be labeled when displayed in the table. The labels should be placed in the first data column. Additionally, the Total label should be placed in the column footer.
• Subtotals and Totals may wrap. If columns or rows containing numbers have wrap turned off, and there is not enough horizontal space to display the entire number, the pound sign '#' will repeat in the cell as many times as the width of the cell permits.

Usage:

• A single table may include subtotals, totals, and grand totals. See individual subsections below for detailed recommendations. The recommended combinations are:
• Total only: For simple totals of one or more columns.
• Subtotals and Total: For columns containing distinctive groups of objects.
• Total and Grand Total: For totals across tables or filtered set of objects.
• Subtotals, Total, and Grand Total: For totals across multiple tables or filtered set of objects that also contain distinctive subgroups of objects.

Totals and Subtotals in Multiple Columns

Subtotals

Purpose:

Calculate subtotal values for a set of rows in a single column.

Description:

• Subtotals can appear in any row in the table, and may be scrolled like other rows in the table.
• When Totaling is available on the table, Subtotal rows may not be reordered, sorted, removed, duplicated, or deleted.
• If a column has been frozen, the scrolling of the Subtotal rows behaves the same as all other rows.

Usage:

• Subtotals should only be used in conjunction with column totals.
• Teams are responsible for making certain that Subtotal rows will not be sorted, reordered, removed, duplicated or deleted.
• It is recommended to use Subtotals in longer, scrolling tables containing distinctive subgroups of objects, and to use them in conjunction with a Total for the entire column.
• Subtotals may be added to multiple columns in the same table.
• Subtotal rows do not have sequential row header text.
• Subtotal rows may only include the following content:
• The optional label Subtotal (or an equivalent label). This is recommended unless an equivalent row header label is provided.
• The subtotal value
• Optional unit description, such as a currency symbol, or weight. See the Common Formats guideline for more details.
• A Recalculate button, if refreshing the subtotal using PPR is disabled for performance reasons.

Totals

Purpose:

Calculate total values for a single column.

Description:

• The Total row is fixed and is always the footer row in the table.
• The amount in the Total row is equal to the sum of all cells in the column being totaled, whether visible or not.
• Total rows do not have row header text.
• Total rows are read-only, and cannot be reordered, sorted, removed, duplicated, or deleted.
• If a column has been frozen, the scrolling of the Total row behaves the same as all other rows.

Usage:

• Total rows should only be included if a table has 300 rows or less, and total amounts can be determined at page load time.
• Any column in the table may be totaled but it is recommended to display columns with Totals to the right of object names and other attributes. (in bi-directional layouts, the totals move to the left side.)
• Totals may be added to multiple columns in the same table.
• A Total row may only include the following read-only content:
• The optional label Total (or an equivalent label). This is recommended in most cases.
• The total value
• Optional unit description, such as a currency symbol, or weight. See the Common Formats guideline for more details.

Grand Totals

Purpose:

Calculate total values across multiple tables or filtered set of objects.

Description:

• Grand totals appear above or below the table, beneath a subheader or sub-subheader labeled "Grand Totals".
• Multiple Grand Totals may be displayed concurrently, if the table contains multiple columns with totals.
• Grand totals should be recalculated whenever totals in the table are recalculated.

Examples:

• Across Multiple Tables: A financial planning Web site shows several tables itemizing different categories of projected expenses, with a total at the bottom of each category. A grand total could be shown above the tables.
• Across a Filtered Set of Objects: A bank account Web site could display a table listing credits and debits for a specific period, along with a set of filter controls. If the user filters the data to show only the debits that are grocery related, the resulting total represents a subset of all debits for the period. In this case the overall total amount of debits could be displayed outside the table as a grand total.

Grand Totals Below a Filtered Table (less than 25 rows)

Usage:

• Grand totals are recommended when:
• Totals from a table need to be combined with totals from another table or form.
• A table containing totals can be filtered to show a subset of objects.
• Grand totals should be placed so that they do not scroll off the page:
• If tables are set to display 25 rows or less of normal height, place Grand Totals below the table, so they are close to the Total within the table. If the rows are taller, the maximum number of rows may need to be as low as 10.
• Otherwise, place Grand Totals above the table so they remain visible.
• Grand totals may be combined with other prompt/data fields.
• The Grand Totals heading should be a subheader if the table is placed beneath the page title, and should be a sub-subheader if the table is placed beneath a subheader.
• If, for performance reasons, Grand Totals cannot be determined until the complete set of records has been retrieved, it is recommended to provide Help text to inform the user. For example: "Grand Totals cannot be calculated until all {objectTypes | items} in the current set have been displayed."

Grand Totals Above Multiple Tables

Alignment

Horizontal Alignment

Column header alignment should match cell contents, except for parent column headers in column groups. The following table shows all permutations:

Vertical Alignment

Vertical alignment is set as middle-aligned by the framework, and is not customizable by product teams.