Checklist Page - Oracle
Hierarchy Search Guideline
Version 1.0.0.1
Last Modified: Nov 10 2008 4:26:53 PM
Author: Sherry Mead
Contributors: Harris Kravatz, Amy Chen
This guideline describes a set of hierarchy conditions that can be added to the condition choice list of a search field when the data to be searched is hierarchical. It also provides guidance on how to display hierarchy search results.
Guideline Contents
Hierarchy Search Guideline 1
Hierarchy Conditions 2
Hierarchy Condition Terminology 2
Family Terminology 2
Tree Terminology 5
Selection-Independent Conditions 5
Default Search Conditions 6
Conventional Search Defaults 6
Hierarchy Search Defaults 7
Conventional and Hierarchy Search Combined Defaults 7
Hierarchy Search Results 8
Results Marked in a Tree Table 9
Results and Their Ancestors in a Tree Table 9
Flat Table and Path 10
Flat Table 10
View in Hierarchy 10
Appendix: Examples 12
Conditions that Use Family Terminology 12
Is a Descendent of Node 13
Is a Last Descendent of Node 14
Is a Child of Node 15
Is an Ancestor of Node 16
Is a First Ancestor of Node 17
Is a Parent of Node 18
Is a Sibling of Node 19
Conditions that Use Tree Terminology 20
Is a Member of Branch 20
Is a Leaf Node 21
Is a Leaf Node Under Node 22
Is the Root Node 23
Conditions that Require Metadata 24
Is a Member of the Level 24
Has the Label 25
Change History 25
Hierarchy Conditions
When hierarchy search conditions are available, the condition choice list (drop-down) should be visible by default. Use ADF Query Basic View, not ADF Quick Query. See the Focused Search Guideline. Any of the Transactional Search Design Patterns may be used for the search.
The searchable fields must include:
• Tree Node
The prompt for the Search field must be the name of the object each tree node represents. For example, if tree nodes are employees, the prompt for the search field is "Employee Name". See the example below.
Note: ApplCore will provide a "Tree Node Picker" in Drop 7. Use it for all tree node search fields. All select tree node illustrations in this guideline represent the ApplCore tree node picker.
• Tree Node Label
If you are using Fusion Tree Management and have Labels enabled, then the Labels field must be a searchable field. The prompt for the field must be the name of the attribute the label represents. For example, if tree node labels represent Positions, the search field is labeled "Position". See the example below.
Figure 1: Tree Node and Label in search region
[pic]f
Figure 2: Tree Node and Label in search results
[pic]
Hierarchy Condition Terminology
There are a few different options in displaying hierarchy Search Condition Terminology to the user. The three options are: Family Terminology, Domain-Specific Terminology, and Tree Terminology.
Family Terminology
Family terminology provides a set of seven (7) different conditions. These conditions include: Is a descendent of node, Is a child of node, Is a parent of node. Some family condition names may be confusing if used standalone. For example, Is a last descendent of node of Node may not make sense when used on its own. Use family terminology when users will be accessing several levels of a hierarchy and will need to use a majority of these terms.
Not all of these are required in the condition choice list. Use the ones that are applicable to your use cases.
• Is a child of node
• Is a descendent of node
• Is a last descendent of node
• Is a parent of node
• Is an ancestor of node
• Is a first ancestor of node
• Is a sibling of node
Figure 3: Sample hierarchy: Chart of accounts
[pic]
Table 1 shows the search results of each of the Family Terminology conditions. For a more detailed diagram, click on the link for each of the Family Terminology conditions.
Table 1: Search results for family conditions
|Family Condition |Selected Node |Search Results* |
|Is a child of node |Current |Cash, Market, Receivables, 127000 |
|Is a descendent of node |Current |Cash, 100000-100099, 100100; Market, 110000, 110001, 110002, …, 110099, 110100;|
| | |Receivables, 120000, 120001, 120002, …, 120199, 121000; 127000 |
|Is a last descendent of node |Current |100000, 100001, 100002, …, 100099, 100100; 110000, 110001, 110001, …, 110099, |
| | |110100; 120000, 120001, 120002, …, 120199, 121000; 127000 |
|Is a parent of node |Current |Assets |
|Is an ancestor of node |Current |Assets, Balance Sheet, All Accounts |
|Is a first ancestor of node |Current |All Accounts |
|Is a sibling of node |Current |Prepaids |
*Note: Matching range nodes appear expanded in the search results. Range nodes are expressions that represent a set of tree nodes. The actual tree nodes appear in the search results.
Figure 4: Detailed example of an “Is a child of node” hierarchy search.
[pic]
1. User selects a hierarchy condition in a search field.
2. User launches the tree picker then selects the desired node.
3. Step 3 in the illustration is not visible to the user. It is included here and in the Appendix to illustrate the definition of the selected condition by displaying the tree nodes that match it.
4. Results are displayed to the user.
Note: In Fusion v1, this dialog contains a Tree Table and will only support browsing for tree nodes. Also note that the tree picker behaves like a date picker and is based on LOV Text Field, rather than LOV Choice list (see the BLAF+ LOV UI Spec.)
Domain-Specific Terminology
Use domain-specific terminology when you are certain it will be familiar to the majority of your users. For example, when searching for an employee of a specific manager, use a condition such as “Is an employee of person” instead of “Is a child of node”, which is the less familiar family term.
Table 2: Examples of Domain-Specific hierarchy conditions for employee search.
|Family Terminology |Domain-Specific Terminology* |
|Is a child of node |Is a direct report of person |
|Is a descendent of node |Is a report of person |
|Is a last descendent of node |Is an individual contributor |
|Is a parent of node |Is the manager of person |
|Is an ancestor of node |Is in the reporting chain of person |
|Is a first ancestor of node |Is the CEO/President |
|Is a sibling of node |Is a peer of person |
*Note: These are examples, not recommended terms.
Tree Terminology
Tree terminology provides a set of 7 conditions. These conditions include: Is a leaf node, is the root node. Use tree terminology when domain specific terminology is not appropriate, and where tree terminology will be the most familiar terminology for the users.
Table 3: Relationship between family terms and tree terms
|Family Terminology |Tree Terminology Equivalent |
|Is a child of node |Is a child of node |
|Is a descendent of node (excludes selected node) | |
| |Is a member of branch (includes selected node) |
|Is a last descendent of node |Is a leaf node |
|Is a last descendent of node |Is a leaf node under node |
|Is a parent of node |Is a parent of node |
|Is an ancestor of node |Is an ancestor of node |
|Is a first ancestor of node |Is the root node |
|Is a sibling of node |Is a sibling of node |
Selection-Independent Conditions
The following conditions are selection-independent. Selecting one of these conditions should trigger a PPR event that hides the value field. Selection-independent searches do not need a value in the hierarchy to compare to execute the search.
Table 4: Selection-independent hierarchy conditions
|Family Terminology |Tree Terminology Equivalent |
|Is a last descendent of node |Is a leaf node |
|Is a first ancestor of node |Is the root node |
Figure 5: Selection-independent condition: Is a leaf node
[pic]
The Value field is hidden when a selection-independent hierarchy condition is selected.
Figure 6: Selection-dependent condition: Is a leaf node under node
[pic]
The Value field remains visible when a selection-dependent hierarchy condition is selected.
Default Search Conditions
This section explains the Default Search Conditions shown in Conventional Search, Hierarchy Search, and Conventional and Hierarchy Search.
Conventional Search Defaults
Typical Focused Search default conditions include: Starts With, Contains, or Equals; depending on the field type.
Figure 7: Default condition list for character fields
[pic]
See the Focused Search Guideline for the list of default conditions by data type.
Hierarchy Search Defaults
The Hierarchy Search default recommendation is to use the most common search condition for the particular task as the default. This default may differ from task to task.
For example, if the most common task in this Hierarchy search example task is to find the child of an Account in the hierarchy, then the default should be “Is a child of node.”
Figure 8: Select the default hierarchy condition based on common use cases.
[pic]
Using Conventional and Hierarchy Search Conditions
When Conventional and Hierarchy Search are combined, the recommendation is to group conditions by type of search. For example, group Conventional search conditions together, such as Starts With, Ends With, Equals, Contains; then group the Hierarchy Search conditions together, such as Is a child of node, Is a descendent of node.
Figure 9: Hierarchy condition list
[pic]
Hierarchy Search Results
There are four format options for presenting the results of a hierarchy search:
• Results Marked in a Tree Table
• Results and Their Ancestor in a Tree Table
• Flat Table and Path
• Flat Table
To illustrate these four hierarchy search results options, we will use the example of the following organizational chart as the tree to be searched.
Figure 10: Sample hierarchy used in examples
[pic]
Results display examples show the results of the search: “Employee Name starts with K”. The following are examples of the search results shown in the four hierarchy search result formats.
Results Marked in a Tree Table
Figure 11: Matching nodes highlighted in full hierarchy
[pic]
The full hierarchy is displayed with nodes expanded to show matching records. Matching records are indicated using an icon (see icon request SHERRY.MEAD.2381).
This results display is often preferred by users but produces the slowest performance. Use this display when the hierarchy is small and it is important for users to see matching nodes in the context of their peers and descendants as well as their ancestors. This display is also preferred when most use cases involve searching for multiple target records per query.
Results and Their Ancestors in a Tree Table
Figure 12: Matching nodes and their ancestors
[pic]
Search results are displayed in a tree table. Matching records appear as leaf nodes under their ancestors.
This results display typically produces acceptable usability and adequate performance. Use this display when users require some context when viewing search results, which can be adequately provided by displaying the ancestor nodes. This display works well when most use cases involve searching for a single target record.
Flat Table and Path
Figure 13: Matching records with their ancestors in a flat table
[pic]
Search results are shown in a flat table along with a list of their ancestors in path or breadcrumb form.
This results display provides the same amount of hierarchy context as the Results and Ancestors in Tree Table display, but in a less usable form. Use this design only if the path will be short in the large majority of cases.
Flat Table
Figure 14: Results in flat table with no hierarchy context
[pic]
Matching nodes are shown in a flat table without information regarding where they appear in the hierarchy. Other relevant attributes can be added to the results table, such as Label.
This results display provides no hierarchy context for result items, but it supports the display of additional node attributes better than the other alternatives. Use this display only if users do not need to see hierarchy context for matching nodes.
View in Hierarchy
When search results are displayed in a flat table, with or without hierarchy context, place a View in Hierarchy button on the toolbar of the results table. When users select a result item, then click View in Hierarchy, the results table is replaced with a tree table. The selected item's parent (if exists) appears as the root note and the tree is expanded to display the children of the selected result item (if exist).
The View in Hierarchy button is disabled if a row is not selected. Note that the results table should not support multiple selection.
Figure 15: View in Hierarchy interaction
[pic]
Appendix: Examples
Each of the following examples use one of three sample hierarchies, an organization chart, a geography hierarchy and a chart of accounts. Each example shows:
• A hierarchy condition in a sample search panel
• Selecting a node from a hierarchical Search and Select dialog with search results displayed in a Tree Table
• Nodes that match the search criteria highlighted in yellow
Note that, when hierarchy conditions are used as section headers in this document, they appear headline capitalized. When used in a search panel, hierarchy conditions should appear sentence capitalized. See BLAF+ Language in UI: Capitalization.
Conditions that Use Family Terminology
Not all of these are required in the condition choice list. Use the ones that are applicable to your use cases.
▪ Is a descendent of node
▪ Is a last descendent of node
▪ Is a child of node
▪ Is an ancestor of node
▪ Is a first ancestor of node
▪ Is a parent of node
▪ Is a sibling of node
Is a Descendent of Node
All tree nodes under the selected node, children, grandchildren, and so on to the leaf nodes.
[pic]
Is a Last Descendent of Node
All leaf nodes under the selected node.
[pic]
Is a Child of Node
All nodes directly under the selected node.
[pic]
Is an Ancestor of Node
All nodes above the selected node, parents, grandparents, and so on up to the root node.
[pic]
Is a First Ancestor of Node
Is the Root Node or nodes above the selected node in a multi-root hierarchy. Is the Root Node in a single root hierarchy. In this case, the value field should be hidden. See the Is the Root Node condition.
[pic]
Is a Parent of Node
Is the node directly above the selected node.
[pic]
Is a Sibling of Node
All nodes that are peers of / have the same parent as the selected node.
[pic]
Conditions that Use Tree Terminology
Not all of these are required in the condition choice list. Use the ones that are applicable to your use cases.
▪ Is a member of branch
▪ Is a leaf node
▪ Is a leaf node under node
▪ Is the Root Node
Is a Member of Branch
The selected node and all nodes under it, children, grandchildren, and so on to the leaf nodes.
[pic]
Is a Leaf Node
All leaf nodes (last nodes in each branch) in the tree. All last descendents of the root node.
[pic]
Is a Leaf Node Under Node
All lead nodes under / last descendants of the selected node.
[pic]
Is the Root Node
The top most node in a single root tree. This condition would be "Is a root node" for trees with multiple root nodes and requires a value field if multi-parent nodes are allowed. See the Is a first ancestor condition.
[pic]
Conditions that Require Metadata
▪ Is a member of the level
▪ Has the label
Is a Member of the Level
All nodes the same distance from the root node in a level-based hierarchy. A level-based hierarchy is a hierarchy in which all nodes the same distance from the root node are logical peers and have the same label.
[pic]
Has the Label
All nodes having the specified developer-defined label.
[pic]
Change History
|Date |Description |Author |Bug |Previous Version |
|10-Nov-2008 |Note added referring to ApplCore Tree Node|Sherry Mead |7262268 |1.0.0.0 |
| |picker to be available in Drop 7 | | | |
| |Fixed examples | | | |
| |Recommendation is to include the immediate| | | |
| |parent when the user selects View in | | | |
| |Hierarchy. | | | |
|16-Jan-2008 |Initial Version |Harris Kravatz, Amy Chen, |7199778 |n/a |
| | |Sherry Mead | | |
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- step by step template oracle
- solutions chapter 1 sql and data test your thinking
- advanced pl sql and oracle etl
- first steps towards oracle 10g
- checklist page oracle
- oracle queries gowthamivuppala
- leveraging oracle business intelligence tools with the
- dba daily checklist
- table names and properties gonzaga university
Related searches
- us steel oracle self service
- my oracle advantage solutions
- advantage oracle sign in
- oracle cloud revenue 2018
- financial analyst resume with oracle experience
- us steel oracle log in
- oracle employee self service portal
- city of memphis oracle payroll
- oracle payslip self service
- memphis oracle employee self service
- memphis oracle sign in
- oracle employee log in memphis