Tree Usage GuidelineBookmark this Guideline Printable Page


RCUI Document Version 5.1.1 for Oracle® Fusion Middleware 11g Release 1 Patch Set 1 (11.1.1.2.0)
Last Updated 15-Dec-2010

The Tree component displays a hierarchical list of objects, allowing users to quickly navigate to an object, view its relationship with other objects, and view or edit its details.

Guideline Contents

 

Note: Images in this guideline are provided as a general reference, and may not be exact representations of FusionFX pages.

Related Guidelines

Guideline Section For Information About
TreeTable All Alternate method of displaying hierarchical data.
Search and Query All Search implementation with hierarchies, and optional sectional grouping of search or view mechanism.

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:

ADF Element Notes
af:icon Node status icon.
af:panelCollection Container for tree menus and toolbar.
af:tree Tree component.

General Principles Bookmark this Heading Return to Top

Purpose:

The Tree component is primarily used to display hierarchies of heterogeneous objects, where different sets of attributes must be displayed depending on the type of object selected.

Definitions:

Tree components use a specific set of terms to define hierarchical relationships:

  • Node: Any object or container in a tree.
  • Parent/Child: Terms used to describe relationship between a node and its subordinate nodes.
  • Sibling: Term used to describe relationship between nodes with the same immediate parent.
  • Root: The parent node that contains all other nodes.
  • Branch: A subset of a hierarchy which is placed under a common parent node.
  • Leaf: A node without any children.
  • Container: A parent node that is used to group other nodes, but does not have specific object details.
  • Heterogeneous: A hierarchy consisting of different types of object, such as a hierarchy of networked servers and databases.
  • Homogeneous: A hierarchy consisting entirely of the same type of object, such as employees in an organization.

Usage:

All tree components all allow selection of an object within a hierarchy. However, the purpose of the selection and the resulting display may differ significantly. A common implementation model is selection to view details on another page (used when details too complex to display in the originating page).

Configurable Elements Bookmark this Heading Return to Top

The Tree component features a number of elements that are either optional or have configurable properties, as shown in the following image and subsections.

Elements of a tree are called out in the image, including menu bar, toolbar, hierarchical selector, parent and child nodes, disclosure icons, status icons, and lazy evaluation indicators.

Tree Elements

Nodes Bookmark this Heading Return to Top

Purpose:

Nodes are the building blocks of the tree, and may represent either objects or containers.

Description:

  • A heterogeneous hierarchy consists of container nodes and object nodes: Objects have associated attributes, whereas containers typically have no attributes other than container name.
  • Vertical scrollbars appear when all expanded nodes cannot be displayed at once.
  • Horizontal scrollbars appear if node labels are clipped because they are too long to be displayed.

Usage:

  • There is no limit to the number of nodes in a tree, or the number of sibling nodes beneath a single parent.
  • A tree may omit the root node, allowing multiple parent nodes to occupy the first level in the hierarchy, thus slightly reducing the amount of horizontal space needed to display the entire tree.
    • Consider using this approach when:
      • The hierarchy is unique, and not likely to be confused with other hierarchies.
      • It is difficult to find a term for the root that makes sense in relation to branch names.
    • In a tree without a root node, product teams control whether a user is permitted to create a new level one node.
  • Users can set any parent node to appear at the top of the tree as the acting root. See Menu Bar below for details. When this occurs, a Hierarchical Selector appears next to that parent node to enable navigation higher in the hierarchy.
  • Nodes have no maximum character limit.
  • Node text may be set to wrap or be clipped. It is recommended to set Wrap on when products commonly have long node labels and it is necessary for users to see the entire node label.
  • If the node text is clipped by a panelSplitter component, then the full text should appear in a tooltip on mouseover.
  • A tree may be displayed without any nodes if nodes do not yet exist.
  • By default, the tree is displayed without any nodes selected, but product teams can specify a selected node if needed.
  • Tree nodes cannot be sorted. If sorting is desirable, consider using a TreeTable with a single column rather than using a Tree.
  • By default, single-clicking a leaf node triggers an action. Teams may configure leaf nodes so that double-clicking triggers an action. In this case, single-click would select the object.
    • For example, double-clicking a leaf node could open a context menu or launch a pop-up dialog that displays document properties and other details about the leaf node for users to view.

A tree without a root node

Tree Without Root Node

Icons Bookmark this Heading Return to Top

Disclosure Icons Bookmark this Heading Return to Top

Purpose:

Expands and collapses a parent node.

Usage:

  • The default state of the Disclosure icon is collapsed, but product teams may override this on a per node basis. When nodes are expanded by default, lower branches of the Tree may scroll out of view, and may not be visible until the user scrolls down. Consequently the decision to expand a node should be based on a demonstrated need to focus on that data.
  • On page load, the display of Disclosure icons is based on a lazy evaluation strategy: Evaluation of some or all function arguments is not started until their value is needed, so the Tree component shows each node as a parent node with expand (+) signs until the user attempts to expand the node. If the node has no children, it is then displayed without either an expand or collapse (-) sign.
  • The tooltip text for Disclosure icons is "Collapse [Node Text]" and "Expand [Node Text]".

Node Icons Bookmark this Heading Return to Top

Purpose:

Help identify and distinguish nodes, and serve as additional click targets to select nodes (along with node names).

Usage:

  • Node icons may be simple folder icons or object type icons, representing object types such as employees or product lines.
  • Node icons may appear on all nodes, some nodes, or no nodes, but it is recommended to use or omit them consistently within a group of sibling nodes.
  • Teams may code such that a container node expands or collapses (depending on its current state) when a user double-clicks on either its icon or label. The icon should also visually toggle to reflect the node's state as expanded or collapsed.
  • Node icons may have tooltips. The tooltip text depends on the type of hierarchy:
    • In homogeneous hierarchies, the node icons are considered decorative elements, and their tooltip text should be set as blank (that is, no tooltip appears on hover).

A tree whose node icons are in a homogeneous hierarchy, and a tooltip showing no text (it is blank)

Node Icons in Homogeneous Hierarchy, with Empty Tooltip

  • In heterogeneous hierarchies, the tooltip text of the node icons should correspond to the object type, such as Purchase Order or Part.

A tree whose node icons are in a heterogeneous hierarchy, with a tooltip text reflecting the node's object type.

Node Icons in Heterogeneous Hierarchy, with Tooltip

Status Icons Bookmark this Heading Return to Top

Purpose:

Status icons draw the user's attention to the state of an object, such as the availability of a server, or an error condition.

Usage:

  • Status icons may appear on some, all, or none of the nodes in the Tree.
  • Status icons may be used independently of node icons.
  • A node may contain only a single status icon at any one time. If it is necessary to convey multiple statuses at the same time, use a Tree Table instead of a Tree.
  • Status icons must have tooltips that specify the status, to make sure that users do not misinterpret the icon. Tooltip text should be consistently phrased across a set of status icons.

Lazy Evaluation Icon Bookmark this Heading Return to Top

Purpose:

Indicates that a node is being evaluated to determine whether it has children.

Description:

  • When a node is being evaluated to determine whether it has children (see Disclosure Icons above), the animated Lazy Evaluation icon replaces the Disclosure icon.
  • When evaluation is complete, the Lazy Evaluation icon disappears, revealing either an expanded Disclosure icon (parent node) or no icon (leaf node).
  • The lazy evaluation icon does not have a tooltip.

Active Data Bookmark this Heading Return to Top

Purpose:

Refers to data provided through the Active Data Service (ADS), which can be refreshed without user action.

Description:

  • Active Data is indicated on the page in two ways: page-level status indicators (see the Progress/Status Indicator guideline) and the component level twinkle effect.
  • Component level twinkle provides a visual affordance for nodes within a tree that are being updated, to distinguish them from other nodes.
  • The twinkle effect lasts for one second and is not configurable.
  • The twinkle effect is also used in the and TreeTable components, when they include Active Data.
  • Active Data can be used only in read-only Tree, Table, and TreeTable components.

Active data in a tree node with component level twinkle effect

Tree Nodes with Component Level Twinkle Effect

Usage:

  • Active Data is often used when displaying information that is subject to constant change, such as stock quotes, mortgage rates, currency exchanges, account balances, and cell phone minute usage.
  • There is no limit to the quantity of Active Data in a table. However, when providing Active Data within multiple regions on a dashboard or overview page, the page can become overly busy when the Active Data elements are updated, and users may not notice individual changes. Consequently, it is recommended to limit Active Data to three or less components per page.
  • There is no limit to the quantity of Active Data in a tree. However, when providing Active Data within multiple regions on a dashboard or overview page, the page can become overly busy when the Active Data elements are updated, and users may not notice individual changes. Consequently, it is recommended to limit Active Data to three or less components per page.

Hierarchical Selector Bookmark this Heading Return to Top

Purpose:

Enables navigation above an acting root node.

Description:

The hierarchical selector only appears when a parent node is set as the acting root node.

Usage:

Product teams can configure a hierarchical selector to show icons for each node. This is recommended for heterogeneous hierarchies that have icons for different types of nodes.

Menu Bar Bookmark this Heading Return to Top

Purpose:

Provides access to all commands available for the tree. Refer to the Menus usage guideline for details about menus.

A generic menu bar with the View menu open

Generic Menu Bar with View Menu Open

Usage:

  • If a tree allows direct manipulation of nodes, it must contain a menu bar or toolbar with all equivalent commands.
  • At minimum, tree menu bars must contain one menu (the View menu). Tree menu details are described in the following sections.

Object-Specific Actions Menu Bookmark this Heading Return to Top

The object-specific actions menu provides commands that act on objects in the hierarchy.

  • The name of the object-specific actions menu depends on the type of hierarchy in the Tree:
    • In a homogeneous hierarchy, the name of the object-specific actions menu is the object type, such as Employees.
    • In heterogeneous hierarchies, which contain different types of objects, the term "Actions" or "Objects" should be used rather than a specific object type.
  • Product teams define their own object-specific menu commands. Common commands include:
    • Add - an object that already exists
    • Create - a new object
    • Edit - modify an existing object
    • Delete - from the database
    • Remove - from the current view of the hierarchy
    • Increase Indent - demote
    • Decrease Indent - promote
Note: Object-specific actions are not provided as part of the ADF Tree component, and must instead be implemented by product teams.

View Menu Bookmark this Heading Return to Top

The View menu contains commands that affect the view or layout of objects in the hierarchy.

  • View menu commands typically include:
    • Expand - selected node
    • Expand All Below - all nodes below selected node
    • Collapse All Below
    • Expand All
    • Collapse All
    • Show as Top - display selected parent node as the root node
    • Go to Top - redisplay root node after it is hidden using Show as Top
    • Scroll to First - scroll up to display current root node (not necessarily the topmost node)
    • Scroll to Last - scroll down to display last node
    • Panes - see PanelSplitter guideline
  • All View menu items listed above are implemented by default. Product teams may disable any of these commands, if it is necessary to restrict users from modifying the view of the Tree.
  • The same View menu may be used for both homogeneous and heterogeneous hierarchies.
  • If multiple nodes are selected, menu items not applicable to all selected nodes appear disabled.
  • For more information, see Component Menus in the Menus guideline.
Note: Node reorder functionality is not a built-in feature of the Tree component, but can be implemented by product teams. See the Reorder action for details.

Context Menus Bookmark this Heading Return to Top

Purpose:

Display all commands available for the select node.

Usage:

  • All context menu items must appear in the tree menu bar or toolbar.
  • If multiple nodes are selected, context menu items not applicable to all selected nodes appear disabled.
  • For more information, see Context Menus in the Menus usage guideline.

Toolbars Bookmark this Heading Return to Top

Purpose:

Provide direct access to the most commonly used tree commands.

Usage:

  • Toolbars are usually displayed in conjunction with a Menu Bar, which is required if the tree supports direct manipulation of nodes.
  • Toolbars may be displayed without a menu bar if the total number of commands is low and all commands fit on the toolbar.
  • The default Tree toolbar commands are derived from the View menu:
    • Go Up
    • Go to Top
    • Show as Top
  • When the default buttons (provided by ADF) are used in a toolbar, they always appear after any custom buttons added by product teams.
  • If it is necessary to restrict users from modifying the view of the Tree, product teams may turn off any of these commands. If so, they must also turn off equivalent menu items.
  • When product teams provide a toolbar, and also provide support for object-specific actions, they should include toolbar buttons for the most common of those actions, such as:
    • Create or Add
    • Delete
    • Edit
    • Increase Indent
    • Decrease Indent
  • Buttons for common, object-specific actions, such as Create, Edit and Delete, should appear on a toolbar before View Actions, such as Go Up and Go to Top. See the Toolbars guideline for more information.

Tree Region Bookmark this Heading Return to Top

Purpose:

Contains the tree and determines its size.

Usage:

  • Developers can specify the height and width of the region or pane containing the tree. For details, see the PanelSplitter guideline.
  • If the tree hierarchy exceeds the width or height of the tree region, scroll bars appear on the tree.
  • Tree region size recommendations are as follows:
    • Height: Provide the maximum vertical space possible to display as much as possible of the hierarchy at a glance.
    • Width: Depends on the type of tree.
      • Object Selection Tree: Use the full page or window width, as related content is usually displayed on a separate page.

Common Tree Actions Bookmark this Heading Return to Top

This section describes common Tree actions that can be implemented by product teams. Access to common actions should be available from the Tree menu bar and toolbar. If the number of available commands is limited, product teams may use only a toolbar instead of a menu bar.

Duplicate Bookmark this Heading Return to Top

Purpose:

Duplicate allows a user to make a copy of an existing object, usually to create a new object like an existing one.

The Duplicate command in a context menu

Duplicate Command in a Context Menu

Description:

  • The Duplicate action should be available as follows:
    • Menu: By selecting one or more nodes and using the Duplicate command from an object-specific actions menu.
    • Context menu: By right-clicking a node and selecting Duplicate.
    • Toolbar: By selecting a node and using the Duplicate button.
  • The Duplicate command should make a copy of the selected node , and place the copy below the selection, as a peer of the original node.
  • The names of newly duplicated nodes should be distinguished from their originals by preceding the node name or identifier with "Copy of  ".

A duplicate node in a Tree

A Duplicated Node in a Tree

Usage:

  • The Duplicate command is recommended when users need to create new objects in a Tree, and those objects share common attributes. This greatly reduces the required amount of data entry.
  • By default, duplicating a parent node should duplicate both the parent and its children. Development teams may display a message dialog asking the users whether they want to duplicate only the parent node or both the parent and its children. See Duplicate Parent Node Message below.
  • Duplicate may be combined with any other common Tree action, such as Create.
  • The tooltip text for the iconic Duplicate button should be "Duplicate". Product teams may append the object type or additional context to explain the action, such as "Duplicate Order", if it may be unclear to the user what is being duplicated.

Delete Bookmark this Heading Return to Top

Purpose:

Delete allows users to permanently remove one or more selected objects from both the Tree and the database, and view the resulting Tree.

The Delete button in a toolbar

Delete Button in a Toolbar

Description:

  • The Delete action should be available as follows:
    • Menu: By selecting one or more nodes and using the Delete command from an object-specific actions menu.
    • Context menu: By right-clicking a node and selecting Delete.
    • Toolbar: By selecting one or more nodes and using the Delete button.
  • The Delete command should function as follows:
    • Leaf Node Selected: The node is deleted without any warning message.
    • Parent Node Selected: Both parent and child nodes are deleted without any warning message.
  • The Delete command is subject to the following selection-related restrictions:
    • Deleting the root node should only be allowed when creation of a root node is also allowed.
    • Users should not be allowed to delete a parent node acting as the root node.
    • Deleting a level one node in a rootless tree should be allowed as long as there are multiple level one nodes.
    • Delete should be allowed for contiguous and non-contiguous selection except when:
      • One or more parent nodes AND one or more leaf nodes belonging to unselected parent nodes.
      • Multiple parent nodes are selected at different levels of the hierarchy.
  • The Delete command may have message dialogs to warn the user that data is being deleted. See Delete Leaf Node Message and Delete Parent Node Message for details.
  • When one or more nodes are deleted, subsequent nodes should move up to fill the space. This may allow additional nodes to scroll into view at the bottom of the tree.

Usage:

  • Delete is recommended in a Tree with Duplicate or Create actions, so the user can delete objects that were accidentally created.
  • Delete may be combined with any other common Tree action, such as Edit, but should usually not be combined with the Remove action. See Modifying Existing Content in the Language in UI guideline for a comparison of the two commands.
  • If the Tree has a toolbar, it is recommended to include the Delete button on the toolbar, unless Delete is expected to be a very low-frequency action.
  • The tooltip text for the iconic Delete button should be "Delete". Product teams may append the object type or additional context to explain the action, such as "Delete Employee from Database", if it may be unclear to the user what is being deleted from the tree.

Remove Bookmark this Heading Return to Top

Purpose:

Remove allows users to remove one or more selected objects from the Tree display without saving any changes to the database.

Description:

  • The Remove action should function in the same way as the Delete action, except that changes are not saved to the database.

Usage:

  • The Remove command is commonly used in situations such as a setup program, where users add and remove items without actually deleting those items from the source list.
  • Remove is commonly used in conjunction with Add.
  • Remove may be combined with other common Tree actions, such as Edit, but should usually not be combined with the Delete action. See Modifying Existing Content in the Language in UI guideline for a comparison of the two commands.
  • The tooltip text for the iconic Remove button should be "Remove". Product teams may append the object type or additional context to explain the action, such as "Remove Item from Shopping Cart", if it may be unclear to the user what is being removed.

Create Bookmark this Heading Return to Top

Purpose:

Create allows a user to create a new object and view the resulting changes within the Tree.

The Create Object command in object menu

Create Command in Object Menu

Description:

  • The Create action should be available as follows:
    • Menu: With the Create command from an object-specific actions menu.
    • Context menu: By right-clicking a node and selecting Create.
    • Toolbar: With the Create button.
  • On returning to the page with the Tree, the new node should be visible in the hierarchy, and the Tree should scroll if necessary to show it. The placement of the new node depends on whether a node is selected when launching the Create action:
    • No Node Selected: The new node should become the last first-level node of the Tree.
    • Leaf Node or Expanded Parent Node Selected: The new node should be created as a child of the selected node, and placed directly below it.
    • Collapsed Parent Node Selected: The parent should expand to show the newly created child node placed directly below it.
  • The newly created node should be selected.
  • The Create command should be disabled when multiple nodes are selected.
  • The Create action should not affect the expanded/collapsed state of other nodes in the tree.

Usage:

  • Create may be combined with any other common Tree action.
  • Create may be implemented in a dialog box rather than a page. For recommendations on when to use a dialog, see Dialogs in the Secondary Windows guideline.
  • If the Tree has a toolbar, it is recommended to include the Create button on the toolbar, unless Create is expected to be a very low-frequency action.
  • The tooltip text for the iconic Create button should be "Create". Product teams may append the object type or additional context to explain the action, such as "Create Line Item", if it may be unclear to the user what is being created.

Add Bookmark this Heading Return to Top

Purpose:

The Add action allows users to search for an object and add it to a Tree.

Description:

  • The Add action should be available as follows:
    • Menu: With the Add command from an object-specific actions menu.
    • Context menu: By right-clicking a node and selecting Add.
    • Toolbar: With the Add button.
  • The added node should be visible in the hierarchy, and the Tree should scroll if necessary to show it. The placement of the added node depends on whether a node is selected when launching the Add action:
    • No node Selected: The new node should become the last first-level node of the Tree.
    • Node Selected: The new node should be added as a child of the selected node, and placed directly below it.
  • The newly added node should be selected.
  • The Add command should be disabled when multiple nodes are selected.
  • The Add action should not affect the expanded/collapsed state of other nodes in the tree.

An Add dialog (from a Search and Select Dialog)

Add (from a Search and Select Dialog)

Usage:

  • The Add action may be implemented using the Search and Select dialog, or using a page or another dialog containing a list of objects.
  • The Add action may be combined with any other common Tree action.
  • The Add action is recommended whenever users may need to add existing objects to a Tree.
  • If the Tree has a toolbar, it is recommended to include the Add button on the toolbar unless Add is expected to be a low-frequency action.
  • The tooltip text for the iconic Add button should be "Add". Product teams may append the object type or additional context to explain the action, such as "Add Employee", if it may be unclear to the user what is being added.

Edit Bookmark this Heading Return to Top

Purpose:

Modify an existing object.

The edit button in a toolbar

Edit Button in Toolbar

Description:

  • The Edit action should be available as follows:
    • Menu: By selecting a node and using the Edit command from an object-specific actions menu.
    • Context menu: By right-clicking a node and selecting Edit.
    • Toolbar: By selecting a node and using the Edit button.

Usage:

  • Edit is recommended in a Tree with Duplicate or Create actions, so the user can modify objects after creating them.
  • Edit may be combined with any other common Tree action.
  • If the Tree has a toolbar, it is recommended to include the Edit button on the toolbar, unless Edit is expected to be a very low-frequency action.
  • The tooltip text for the iconic Edit button should be "Edit". Product teams may append the object type or additional context to explain the action, such as "Edit Line Item," if it may be unclear to the user what is being edited.
  • Note: Click-to-edit is supported by the Tree component. However, use of this feature is not recommended. If click-to-edit functionality is required, consider using the TreeTable component instead. For detailed information about click-to-edit, see the Table Interaction guideline.

Increase Indent Bookmark this Heading Return to Top

Purpose:

Demote a node one level within the hierarchy.

A sibling group on the same level within a tree hierarchy.

Sibling Group

Description:

  • In the Increase Indent action, a node becomes the child of the sibling node listed above it.
  • The Increase Indent action should be available as follows:
    • Menu: By selecting a node and using the Increase Indent command from an object-specific actions menu.
    • Context menu: By right-clicking a node and selecting Increase Indent.
    • Toolbar: By selecting a node and clicking the iconic Increase Indent button.
  • In order to increase the indent of a node, it should be part of a sibling (peer) group of at least two nodes and it should have at least one sibling node listed above it.
  • Users should be allowed to increase the indent of parent nodes; all descendent nodes should be indented one level at the same time, maintaining the hierarchy among descendants.
  • Users should be allowed to increase indent the root node or a parent node acting as the root.
  • Users should be allowed to increase indent the topmost node in a sibling group.

Two images of a tree, in which the first one shows the unsorted nodes, with Node 3 on the parent level; the second one shows Node 3 aligned with other child nodes after the increase indent action

Increasing Indent of a Node

Usage:

  • The Increase Indent action is recommended in the following cases:
    • In all editable homogeneous hierarchies.
    • In heterogeneous hierarchies that are editable and either:
      • Contain more than one level of a single object type, OR
      • Allow users to change an object from one type to another (uncommon).
  • Increase Indent should always be provided in conjunction with Decrease Indent, so users can reverse changes.
  • Increase Indenting a leaf node directly below a collapsed parent node should cause the parent node above to be expanded automatically. The leaf node should maintain its selected state throughout the Increase Indent action.

Decrease Indent Bookmark this Heading Return to Top

Purpose:

Promote a node one level within the hierarchy.

Two images of a tree, in the first, the Decreasing Indent menu is used to decrease the indent of a node, with the results shown in the second tree image, where Node 4 has gone from the child level to the parent levels.

Decreasing Indent of a Node

Description:

  • In the Decrease Indent action, a node becomes the sibling (peer) of its parent node.
  • The Decrease Indent action should be available as follows:
    • Menu: By selecting a node and using the Decrease Indent command from an object-specific actions menu.
    • Context menu: By right-clicking a node and selecting Decrease Indent.
    • Toolbar: By selecting a node and using the iconic Decrease Indent button.
  • Users should be allowed to decrease indent parent nodes; all descendent nodes are decrease-indented one level at the same time, maintaining the hierarchy among descendants.
  • Users should not be allowed to decrease indent the root node or a parent node acting as the root.
  • Users should not be allowed to decrease indent a node at level one in the viewable hierarchy.
  • Users should be allowed to decrease indent leaf and child nodes.

A sample tree in which callouts point to Nodes 1 and 2 as level 1 nodes, Nodes 4 and 5 are Level 2 nodes, and Nodes 6 and 7 are level 3 nodes.

Node Levels

Two images of a tree with no root node, in which the second one demonstrates the Decrease Indent action to move Node 4 from a child level to the parent level.

Decrease Indent in a Tree with No Root Node

Usage:

  • The Decrease Indent action is recommended in the following cases:
    • In all editable homogeneous hierarchies.
    • In heterogeneous hierarchies that are editable and either:
      • Contain more than one level of a single object type, OR
      • Allow users to change an object from one type to another (uncommon).
  • Decrease Indent should always be provided in conjunction with Increase Indent, so users can reverse changes.

Reorder Bookmark this Heading Return to Top

Purpose:

Relocates nodes from one parent to another, or repositions a node in relation to its sibling nodes.

Description:

  • The Reorder Nodes action can be available as follows:
    • Keyboard: By pressing Ctrl+Shift+Up/Down arrow keys.
    • Drag and Drop: Selecting a node and dragging it to a new location.
    • Menu: By selecting a node and using the Move Down, Move Up, Increase Indent or Decrease Indent commands from an object-specific actions menu.
    • Toolbar: By selecting a node and clicking the Move Down, Move Up, Increase Indent or Decrease Indent buttons in the toolbar.
    • Context menu: By right-clicking a node and selecting Move Down, Move Up, Increase Indent or Decrease Indent.
  • In the Relocation action, a node may move to another parent or, if there is no root, it may move to the topmost level of the hierarchy.
  • In the Reposition action, a node always stays beneath the same parent node, and at the same level in the hierarchy.
  • Users should be allowed to reorder parent nodes; all descendent nodes move with the parent.
  • Users should not be allowed to reorder the root node or a parent node acting as the root.
  • Users should be allowed to reorder leaf and child nodes.
  • Relocating a node into a collapsed parent node does not automatically expand the parent node.
  • If scrollbars exist and the desired drop target is out of view, holding the mouse over the edge of the pane should scroll the contents of the pane in the desired direction.
  • Reordering nodes in an instance of a tree should persist across sessions (as a user profile) until explicitly changed by the user. No explicit 'save' action by the user should be required.

Usage:

  • The Reorder Nodes action is recommended for all editable hierarchies that have the default set of View menu commands.
  • When implementing Relocation in a heterogeneous hierarchy, product teams have to develop rules to specify what type of nodes may be dropped on each type of parent node, and provide error messages when users attempt to drop a node on an invalid target.

Optional Messaging Bookmark this Heading Return to Top

This section describes optional messages for the Tree. For more information on messaging, see the Message Framework guideline.

Expand All/Expand All Below Message Bookmark this Heading Return to Top

Purpose: Page-level message warns users that Expand All or Expand All Below action may take some time to complete.

Expand All/Expand All Below Alert featuring the Warning icon, a message about the action being contemplated, and a question 'Are you sure you want to continue?' associated with a yes/no buttons.

An Expand All/Expand All Below message dialog

Usage:

  • Consider using this message if the delay is likely to be greater than ten seconds.
  • Message Text: "It could take several moments to complete this action. Are you sure you want to continue?"

Duplicate Parent Node Message Bookmark this Heading Return to Top

Purpose: Page-level message that gives users Duplicate options.

A Duplicate Parent Node message dialog showing the Warning icon and radio buttons giving the user the option to choose to duplicate a tree's node and its children, or to duplicate only the selected node.

Duplicate Parent Node Message

Usage:

  • Consider using this message when:
    • Users may need to duplicate parent nodes without duplicating child nodes.
    • Users may not be aware that duplicating a parent node also duplicates child nodes.
    • Duplication of child nodes in a large hierarchy may cause performance problems.
  • Message Text: Radio buttons with the following choices:
    • "Duplicate node and its children"
    • "Duplicate node only"
  • In heterogeneous hierarchies, development teams should substitute the terms "node" and "child" with distinctive object types, such as "department" and "employee". In homogeneous hierarchies, the development team should use terms commonly used to describe relationships in the hierarchy, such as "manager" and "subordinates".

Delete Leaf Node Message Bookmark this Heading Return to Top

Purpose: Page-level message that warns users before deleting leaf nodes.

A Delete Leaf Node message, showing a Warning icon and the message: 'delete selected node?' associated with yes/no buttons.

Delete Leaf Node Message

Usage:

  • Message dialogs increase the number of steps required to perform an operation, so consider using this message only in the following contexts:
    • When the data would be time consuming to recreate.
    • When it may not be obvious that one or more objects will be deleted, such as a selection across multiple record sets, or a very slow Tree refresh time.
  • Message Text: "Delete selected node?"
  • Development teams should substitute the term "node" with distinctive object types, such as "department" and "employee".

Delete Parent Node Message Bookmark this Heading Return to Top

Purpose: Page-level message that gives users delete options.

Delete Parent Node message showing the Warning icon and radio buttons giving the user the option to choose to delete a tree's node and its children, or to delete only the selected node.

Delete Parent Node Message

Usage:

  • By default, deleting a parent node deletes the parent and its children.
  • Message dialogs increase the number of steps required to perform an operation, so consider using this message only in the following contexts:
    • When the data would be time consuming to recreate.
    • When users may need to delete parent objects and reassign their children to another parent.
    • When it may not be obvious that one or more objects will be deleted, such as a selection across multiple record sets, or a very slow Tree refresh time.
  • Message Text: Radio buttons with the following choices:
    • "Delete node and its children"
    • "Delete node only"
  • In heterogeneous hierarchies, development teams should substitute the terms "node" and "child" with distinctive object types, such as "department" and "employee". In homogeneous hierarchies, the development team should use terms commonly used to describe relationships in the hierarchy, such as "manager" and "subordinates".