Search and Query Templates

General Description

• Overview of Searching in BLAF
• General Search Notes
  • Basic Search Criteria Field Behavior
    • Single Search Field in a Criteria Section
    • Choice Lists with Search Fields
    • Multiple Search Fields (or Widgets) in a Criteria Section
  • Case Sensitivity
  • Length of Search Time
  • Wildcard Searching
  • Multiple Strings in Search Field
  • Quote Usage
  • Boolean Operator Usage
  • Search with Conditions
  • Symbols
  • Misspellings
• Search with an Object List
• Search Criteria Section with an Object List
  • Simple Search
  • Search with More Options Appended
  • Advanced Search
  • Views Section
• Object List with Quick Search
• Search in the Side Navigation
  • Search in Side Navigation within a Home Page
  • Search in Side Navigation of an Object List Page
• Multiple Sectioned Advanced Search as Own Page
• Matrix of Search Instruction Text
• Removal of Results Section Header

Guideline Attributes

Interaction and Usage Specifications

Overview of Searching in BLAF

Across BLAF applications, there are many different types of search pages used depending on the requirements of the application, and needs of the user to find the objects needed to perform tasks. Search functionality in BLAF is surfaced on object list pages in different formats (such as a criteria section, a quick search, or in the side navigation). Search is not a generic function (i.e., a tab or a global button) since it is always used in context of a specific object type or centralized aggregate page location, such as a home page or portal page.

Different Search Templates for Different Search Needs

The most common search template used is Search with an Object List where the template is comprised of 2 sections, a search and a results section. (See also Object List Templates: Search and Results Guideline for more details.) This template allows a user to enter in criteria (from a single criteria to advanced criteria) to narrow down the results of a given object type. Other templates that have search capabilities are Object List with Quick Search and Search in the Side Navigation (of an object list or home page). See below for more details regarding usage of each different template.

Multiple Types of Backend Search Technologies Available

Across Oracle there are different types of search backend technologies used to actually perform the search query and return the appropriate results once the user has entered information in a search section of a page. These different search technologies may have slightly different front-end UI's, but overall the end-user should not be aware of the differences. For example, two types of search technologies used in Applications (ERP and CRM) are SQL-based searching and Intermedia-based searching. Each has it's unique benefits, but again, the end-user should not be exposed to the different pro's and con's of each search type, but be able to perform a search and retrieve results regardless of the technology used. See below for some more details regarding these two types of search technologies.

General Search Notes

Below are interaction notes outlining the expected behavior when a user enters various types of information into a search criteria field on one of the various search templates. (For detailed flows, see Search Flows guideline.)

Each type of search template has specific instruction text. For details, see Matrix of Search Instruction Text below.

Basic Search Criteria Field Behavior

Since a variety of search options are allowed (i.e., simple search with one criteria, advanced search with multiple criteria), it is important to understand the basic behavior of a search criteria field when data is entered into the field, and the "Go" button is selected.

Note: Blind queries (searches without filling in any fields) are never permitted in any type of search, because of excessive response time. A blind query results in an inline error message with the following text: "You must specify search text before starting your search."

Single Search Field in a Criteria Section

• A single "Search" label and open text field may be placed in the criteria section of an Object List. This field is intended to search a specific key attribute of an object type, such as Object Name. (Note: The object type is the name of the page.) For instance, on an object list page called "Purchase Orders", there may be a single field labeled "Search" in the criteria section. The user enters in the purchase order name (or partial string) then "Go" to query the results. If there is not a key attribute, or most common attribute that a user may search for, then it is best to either:
  • Be specific with the search field label and rename the label to the exact object attribute that is being searched (such as "Asset Number") or
  • Add a choice list in front of the search field to allow the user to pick the specific attribute to search for (see below under "Choice Lists with Search Fields".)
  • Display the 3-4 most common attributes instead.
• It is not recommended to have the single search criteria field be an LOV value. An LOV forces a user to pick a specific value. This defeats the purpose of the object list where a user may want to search for multiple values containing a similar string, and/or requires the user to have to search twice, first in the LOV, then when the "Go" button is selected.
  

• If Intermedia-based searching is used, a "Search" label with a text field that accepts multiple object attributes to search on is possible. For instance, the field may be labeled "Search" and the user may be able to enter in a project name, project number, project owner or project description into the field to query results. If this option is used, it is recommended to place a hint below the field denoting which object attributes may be searched.

• Unless the application contains only one object type (very rare case) it is recommended to use a choice list with the search field so the user can specify the object type that is being searched. (An application with a catalog that exposes a search field on the home page may not need to follow this recommendation, since the search typically is associated only with the catalog. The search label should be explicit in this case, such as "Search Catalog".)

Choice Lists with Search Fields

• A choice list containing attributes of the object that is being searched may be used with the field to help the user refine his/her search.
• The choice list should be defaulted to a specific attribute. For instance, if searching for an Order, the attributes in the choice list may be Order Name, Order Number, Order Date, etc. One of these attributes should be defaulted in the choice list associated with the text field.
• The choice list should not contain an "All" value, since searching across attributes may cause a long performance time. (Note: If Intermedia-based searching is used, it may be applicable to have "All" as a valued in the choice list to search across attributes.)
• When a choice list is used with a search field, all search field rules apply, but also the search is confined to query for results within the selected item parameters.
• It is recommended that the items be indexed within the choice list to improve search performance. For more information on indexed fields and slow response time, see Length of Search Time below.

Multiple Search Fields (or Widgets) in a Criteria Section

• If a user needs the ability to search by many different object attributes (i.e., Order Name, Order Number, or Order Date) then multiple search fields (or widgets - choice lists, radio group items, LOV's) should be placed in the search criteria section.
• The user may fill out some or all of the attributes within the criteria section. If a user leaves one of the attributes blank, the attribute is not searched on. However, at no time may a user perform a blind query.
• It is recommended that the items be indexed within choice lists to improve search performance. For more information on indexed fields and slow response time, see Length of Search Time below.

Case Sensitivity

The search critieria text fields should NOT be case sensitive but allow the user to enter in upper or lower case letters and retrieve similar results.

i.e., "KMart" "Kmart," "kMaRt" or "kmart" are all treated the same way, and will return any value with Kmart regardless of capitalization.

Length of Search Time/Performance Issues

It is recommended to have an optimized search, so that the user does not have to wait a long time for results to be retrieved. Depending on the size of the data set being search, and/or the complexity of the search, the search time may vary. Users should be aware of these issues prior to conducting a search, so that they will know what is expected, and/or may avoid certain conditions. Also, during a long search retrieval, it is also important to give the user information that the search is being conducted. Below are some UI techniques that may be used for searches that may take a long time:

• Use a hint under the search criteria field stating, "The search may take several minutes." Or, something more specific, like: "The search may take several minutes if field is left blank."
• A processing template should be used if the search is conducted and it will take over 30-45 seconds to return results.
• A choice list may be used to restrict the user to search by a specific object type and/or attribute.
• It is recommended to have at least one attribute within the search criteria indexed to reduce performance overhead.
• If, for performance reasons, one or more indexed fields must be filled out, it is strongly recommended to append the following text to the instruction text used for each type of search: "You must fill out [one of] the following field[s] before starting your search: {FieldNameX}[, FieldNameY][, and FieldNameZ]." (There should not be any specific "indexed field" indicator by the field, since this concept is not well understood by users and should NOT be exposed.)
• If the user fails to fill out one of the indexed fields, the text is repeated in an inline error message. Note that an indexed field is only flagged with an error icon if it is the only indexed field in the search section; if there are multiple indexed fields, then error icons would indicate that all fields must be filled out, which is neither correct, nor practical in certain search contexts.
• For details on instruction text for each type of search, see Matrix of Search Instruction Text below.

Note: Blind queries (searches without filling in any fields) are never permitted in any type of search, because of excessive response time. A blind query results in an inline error message with the following text: "You must specify search text before starting your search."

Wildcard Searching

Implicit Wildcard at the End of a Value

If a user enters a string, the search is treated as a wildcard search ([partialstring][wildcard]) with the wildcard implicitly appended to the end of the string. A user does not need to enter a percent symbol to perform a wildcard search. If the user explicitly enters a wildcard at the end of a string (i.e. "liz%"), the extra wildcard is ignored since there is already an implicit wildcard at the end of the string. (Note: "%" and "*" should be allowed as wildcard symbols.)

For example
• If a user enters "liz", the search will return:
  • liz
  • lizard
  • lizzie

Wildcard at the Beginning of a Value

The user may enter an explicit wildcard as the beginning of the string if so desired. The implicit wild card will also be added to the end. For instance, if the user enters %liz, the search will return:

• liz
• lizzie
• lizard
• elizabeth
• belize
• etc.

NOTE: In the OA Framework (ERP and CRM Applications) leading wildcards are prohibited due to performance overhead. If a wildcard is entered at the beginning of a string, OA will trap as an error.

Multiple Strings in Search Field

Depending on the search backend technology used, there are slightly different behaviors when a user enters in multiple strings into a search field.

For SQL-based searching, if multiple strings are entered into a field (say a "Customer Name" field) it is treated as a single entity or single string.

I.e., if the user enters Oracle Corp, the search will return:
• Oracle Corporation
• Oracle Corporate Offices
• etc.

For Intermedia-based searching, if a user types multiple words into a search text field, the system searches by implicit "or", and does relevance ranking using "and". This may vary if a condition is associated with the search criteria field. See Intermedia-based Conditional Searching below for more details.

I.e., If a user enters in the search field calvin klein black skirt, the search will return:
example shown a hypothetical order
• Calvin Klein black skirt
• calvin klein skirts
• calvin and hobbes
• Kevin Klein
• black
• skirt steak
• etc.

Quote Usage

Quotes are allowed in Intermedia-based searching. When used, the words within the quote will be searched in that exact order.

I.e., If a user enters in the search field using quotes, "240 Perry" - the search will return:
• 240 Perry Street
• but not 240 Perrywinkle

If the user enters without quotes 240 Perry - the search will return:
• 240 Perry Street
• 240 Perrywinkle Street
• 240 Perry Lane
• etc.

Boolean Operator Usage

In general, users find forming complex query statements with many levels of "and" and "or" statements a difficult task. For most all BLAF applications, there are 2 simple options provided for the user to perform these more complex queries: using "and" and "or" surrounding a set of criteria or using "and" or "or" within a specific criteria.

An expert user who may be familiar with more complex boolean searches, though, may need the ability for more complex searching. Some BI applications may have this capability. This UI is handled through a query building process (or a step by step/wizard approach to building a query), and is not in a typical search/results page layout.

And/Or Surrounding a Set of Criteria

In condition-style advanced searching, using SQL-based backend technology, a radio group is exposed surrounding the entire criteria set to denote whether or not the search criteria should be "and" together, or "or". See below under Advanced Search with Conditions: SQL-based Conditional Searching for more details.

And/Or within a Specific Criteria

Intermedia-based search technology allows a user to have "and" and "or" functionality per certain criteria type. For instance, when condition-style advanced searching with Intermedia is used, a condition may be "Match Any Words". The user may enter in multiple words within the associated text field. These words would form an "or" statement. Another conditions allows the user to "Match All Words". Again, the user may enter in multiple words into the associated fields. These words would form an "and" statement. See Advanced Search with Conditions: SQL-based Conditional Searching below for more details.

Search with Conditions

Conditions such as: less than, greater than, is, is not, begins with, etc. should be in a choice list associated with a search criteria field. These terms should not be entered into the search field if a user is trying to form a query statement. Equivalent symbols for these terms should not be in the choice list, words should be used. For more details on condition-style advanced searching see below under:

• Advanced Search with Conditions: SQL-based Conditional Searching
• Advanced Search with Conditions: Intermedia-based Conditional Searching

Symbols

(Note: This section may be edited with more current details - Oct-2003)
If a user enters other symbols into a search field such as a currency symbol (dollar sign, yen symbol, french franc symbol), or sentence punctuation (comma, question mark), the search should ignore these. An inline information message box may appear after a user performs a search with these symbols stating that these symbols are ignored.

Misspellings

If possible, closely associated words, or correctly spelled words should be provided if a user enters an incorrect spelling of a word (e.g. search that can pull back results based on correct spelling). This feature may be handled with Intermedia-style searching.

Search with an Object List

There may be 100's-1,000's of records regarding one specific object type. Searching allows a user to narrow down the list to a manageable size. The different search criteria section options (simple, advanced, etc.) provides the user with more functionality to narrow his/her results set. These different search criteria sections can toggle between each other to allow the user flexibility in the type of search he/she may want to perform.

Note: For more information about the "Views" section, see the Personalization of Views (Tables and HGrids) guideline for details.

Search Criteria Section with an Object List

The search criteria section on the object list toggles between simple search, advanced search (as conditional statements, or large set of attributes), and views (table queries and customized display.) Depending on the complexity of the object (if the object does not have too many attributes associated with it), simple and advanced search can be combined to form a search with more options (hide/show more options). This option may toggle between Views. Below outlines each search criteria section option.

Simple Search Section

A simple search criteria section allows a user to quickly search for an object or objects based on a key attribute(s). This option is typically displayed as the default search section when a user first comes to an object list page.

• The simple search section may contain just a label, an open text field and a "Go" button to initiate the search.
• The simple search section may optionally also contain a choice list containing object attributes that the user can search by.
• The simple search section may contain up to 3-4 attributes maximum. Beyond this, other search options should be explored (See more options below like: search with more options, advanced search.) These attributes should be the most commonly used attributes.
• Simple searches are typically used to search objects at a broad level. For example:
  • Catalogs
  • Top level object list pages of applications
• See above for detailed notes regarding General Search Notes and Basic Search Criteria Field Behavior

Search with More Options Appended Section (Hide/Show Used)

Search with More Options should be used when a user typically only searches on a key attribute, or a few attributes, but occassionally may need more attributes to search by in certain circumstances. This option is a combination of a simple search and advanced search and not used that often. This option may be used when the object that is being searched does not have too many associated attributes. (For larger objects, it is better to use the simple search/advanced search toggle option.) To reduce confusion to the user of too many tiers of search options, the "Search with More Options" section should not toggle with Advanced Search, but just toggle with a "Views" section. (Only in rare exception cases should this be allowed.). If in the "more options" region, there are many attributes, it is best just to use an advanced search toggle button for this, rather than the hide/show region.

• As a default, the search section should appear with the more options hidden. The top portion of the section may contain either a single key attribute of an object to search by; a couple (2-3) key attributes of an object to search by; or a choice list of many attributes and an associated text field. To initiate the query, the user selects the "Go" button adjacent to the field or choice list and field (if 2-3 attributes, the button is below the set.)
• When the user selects "Show More Search Options" hide/show link or icon, the search region redraws with additional search criteria or object attributes to search by. The "Go" button is moved below the newly shown attribute fields since the entire new attributes are appended to the existing attributes already shown.
• If attribute fields are specified in "more search options" region, and then the user selects "Hide More Search Options", the "Go" button will move up to be associated only with the shown fields. The specified attributes within the hidden options region will be ignored if a search is performed.
• When the search field is filled out and then more options are shown, the search field should remain filled.
• Attributes specified in "more search options" region are not persistent when user toggles from "Show" to "Hide", and then vice versa.
• For more details regarding hide/show, see Hide/Show guideline.

Advanced Search Section

Advanced Search allows the user to search based on many attributes of an object. There are 2 variants of an advanced search criteria section, advanced search with many attributes and condition-style advanced search. Below outlines the differences between the advanced search section options.

Advanced Search with Many Attributes

This option is used when a user needs to search for an object or objects with many associated object attributes. He/she may not have found the object or objects in the simple search, and want more attributes/criteria to fill out to find exactly what he/she is looking for. For instance, the user may be searching for all projects that were started by a certain date, with a certain status, are managed by a certain person and fall under a specific organization. Advanced Search with Many Attributes section allows the user to fill out these specific criteria/object attributes to retreive this type of query.

• A minimum of 4 and a recommended maximum of 10 attributes are allowed for the Advanced Search within a single section. If more there are more than 10 attributes, it is recommended to consider breaking the search criteria up into multiple sections. If this option is chosen, then a different advanced search page should be used. See below under Multiple Sectioned Advanced Search as Own Page for details.
• It is recommended to not overload the user with having to specify many attributes in such a way that no results are returned when search is performed.
• See above for detailed notes regarding Basic Search Criteria Field Behavior.
• The "Go" button should be placed directly below and left-aligned to the set of attribute fields. If the criteria is in 2 columns, then the "Go" button should be left-aligned below the fields under the first column.

Advanced Search with Conditions

For more complex querying capabilities, the advanced search may be shown with conditions associated per object attribute. There are two types of condition building queries. Each type has somewhat similar front-end UI features, but varies based on the backend search technology that is used, either SQL-based or Intermedia-based. The end-user, though should not be aware of this backend difference. Also, it is not recommended to mix the two technologies on the same page. The basic common features of these two condition building search options are:

• Each attribute has an associated choice list of conditions. The conditions in the choice list are based on the attribute type. For instance, in a SQL-based search, if the attribute is "Start Date", the conditions in the choice list are different than if the attribute is "Project Name". See each picture below for details.
• The default number of attributes with conditions that are shown is 4. These should be defaulted based on the most frequently searched attributes. The user may add more attributes to search by using the "Add Another" choice list and "Add" button below the search criteria. The user has the ability to add the same attribute several times, and specify different conditions for each, if needed.
• To instantiate the search, there is a button labeled "Search" aligned below the condition choice lists. The button label is "Search" not "Go" since this condition-style advanced search is more complex than the other search options listed in this guideline.

The differences between the two types of conditional searches are outlined below:

• The user can select from a radio choice either:
  • Filter table data when all conditions are met or
  • Filter table data when any conditions are met.
• Condition Statements:
  • Below the and/or radio group are condition statements containing a label (column or object attribute), a conditions choice list, and an standard web widget based on the column/object attribute (i.e., field, LOV field, date field, choice list, etc).
  • Conditions within the choicelist are specific to the data type. A data type can be a date, text, numeric or alphanumeric. See image above regarding which condition applies to the specific data type.
  • If the user leaves the values blank in the text field, the query will not search on that attribute.

• All condition statements are "and-ed" for Intermedia-based searches. The user does not select between "and" or "or" for all condition statements like in the SQL-based search method since each conditional statement may be an "and" or "or" within itself.
• Condition Statements:
  • Below the subsection title are condition statements containing a label (column or object attribute), a conditions choice list, and an standard web widget based (date field, field, etc) on the column/object attribute.
  • Conditions within the choicelist are specific to the data type. A data type can be a date, text, numeric or alphanumeric. See image above regarding which condition applies to the specific data type.
  • Some of the Intermedia-based search conditions allow the user to enter in multiple text items per condition. For instance, the attribute may be "Employee Name" and the associated condition may be "Match All Words". In the field, the user can type in several words to be searched such as "Bob, Jane, Julie". These values will be "and-ed" together when searched. Another condition example is "Match Any Words". If the attribute is "Product Color" and the user types in the field "blue, green, yellow" with the "Match Any Words" condition, the text items will be "or-ed" when searched.
  • If the user leaves the values blank in the text field, the query will not search on that attribute.

Multiple Sections of Advanced Search Criteria

In rare cases, when extreme amounts of search criteria need to be available to the user, it may be applicable to have a search criteria grouped in multiple sections. The single section of search criteria does not fit with this requirement, and the user must navigate to a full advanced search page. See below under Multiple Sectioned Advanced Search as Own Page for details.

Views Section

Views are personalized and/or seeded searches (criteria and display).

• The views are listed in a choice list with a "Go" button. Once selected, the results section redraws with the results based on the critieria and display settings of that view.
• The views may also be personalized.
• For full details regarding Views, see the Personalization of Views guideline.

Object List with Quick Search

The "Quick Search" allows a user to search across an applications tabs (across multiple objects). For instance, an application may have 4 tabs, "Home", "Customer", "Orders", "Products". The quick search may contain a choice list with the object types, allowing the user to quickly search for a specific order, a specific customer, or a specific product from any page with the quick search available. (The choice list should use key attributes to search by, such as Customer Name and Order Number, unless Intermedia-style search is used and multiple object attributes can be searched based on the object type.) It may also be used for a user to search a catalog of information. (Typically pages within a catalog are within one tab.)

• The quick search area may contain:
  • a "Search" label (or more specific label if necessary)
  • an optional choice list for object types or object attributes
  • an optional choice list containing scope options of the search (i.e., within the results or new results)
  • a text field for entering search strings
  • a "Go" button to instantiate the search
  • an optional "Advanced Search" button if needed.
• A quick search is typically used on top level pages of an application like Object Lists
• The quick search resides directly under the tab component, and technically is part of the tab component.
• The quick search should be used consistently throughout the sections of content which the search covers (i.e., if the quick search encompasses 3 different object types [in different tabs], each tabbed section (containing the object list) should have the quick search. (Note: The quick search does not need to be persistent throughout an entire application.)
• Quick search should not be at low levels of an application, like a task/transactional page. For instance, when a user has drilled down to update a specific object, it is best not to give the capability to allow the user to search for another type of object, since modified data may not have been applied before the user tries to search.
• Quick Search should not be used on the same page that also has a search section as the two search mechanisms on the page may become competitive and confusing.
• The quick search may not be used with the side navigation element.
• Selecting the advanced search button in the Quick Search area will take the user to the respective object list page (based on the object type chosen in the choice list), with an advanced search section. (See Search on Object List above for details.)

Search in the Side Navigation

Search in Side Navigation of a Home Page

Searching on the home page can allow the user to quickly navigate to the object(s) or section of the application that is most important to him/her.

• The possible search options in the side navigation for a Home Page are:
  • a "Search" label (or more specific label if necessary)
  • an optional choice list for object types or object attributes
  • a text field for entering search strings
  • a "Go" button to instantiate the search
  • an optional "Advanced Search" link if needed (localized applications may not be able to fit a long button label in the side navigation).
• The search on the home page resides at the top of the left hand column, above the shortcuts and/or browsing links.
• The search field must either have a label (prompt) or a header (side navigation header) to define the section.
  • Search Label/Prompt: If a search label is used, it should be explicit regarding what the user is search. For instance, if the search on the home page only searches a catalog, the label should read, "Search Catalog." If the search is only for a single object type (no object type choice list), the search label should read "Search [objecttype]".
  • Search Header in Side Navigation: A search header is good to use when there are multiple sections within the side navigation area of the home page. For instance, the top section is search, and the section below is a catalog of catagories to browse. If a search header is used, it should be explicit regarding what the user is searching similar to the guidelines for a label. (Note: The field must have hidden identification attributes assigned to it in the HTML to label the field label for accessibility. This is not seen in the UI.)
• Searching on the home page is optional depending on the requirements of the application.
• Selecting the advanced search link in the side navigation area of the home page will take the user to the respective object list page (based on the object type chosen in the choice list), with an advanced search section. (See Search on Object List above for details.)
• Once a search is conducted, typically it would take the user to the Object List Page with the search results shown in the results section. The user then has the ability to search again as necessary (one of the valid search criteria sections should also be on the page).

Search in Side Navigation of an Object List Page

This search allows the user to perform a simple search within the side navigation region, and have the results appear in the content area. This search is not as extensible as the search section used on an object list, and should only be used when necessary. This configuration is good for searching only one object type, and not across objects. It is best when the application does not have a deep hierarchy.

• The possible search options in the side navigation of an Object List Page are:
  • a "Search" label (or more specific label if necessary)
  • an optional choice list for object types or object attributes
  • a text field for entering search strings
  • a "Go" button to instantiate the search
  • an optional "Advanced Search" link if needed (localized applications may not be able to fit a long button label in the side navigation).
• The search within the side navigation resides at the top of the navigation area. Another section of navigation links may be below.
• The search field must either have a label (prompt) or a header (side navigation header) to define the section.
  • Search Label/Prompt: If a search label is used, it should be explicit regarding what the user is search. If the search is only for a single object type (no object type choice list), the search label should read "Search [objecttype]".
  • Search Header in Side Navigation: A search header is good to use when there are multiple sections within the side navigation area. For instance, the top section is search, and the section below is a links of other sections within the tab. (Note: The field must have hidden identification attributes assigned to it in the HTML to label the field label for accessibility. This is not seen in the UI.)
• Searching within the side navigation area is an alternative to searching as a section of an object list page. These should not be combined.
• Selecting the advanced search link in the side navigation area of the home page will take the user to the respective object list page (based on the object type chosen in the choice list), with an advanced search section. (See Search on Object List above for details.)

Multiple Sectioned Advanced Search as Own Page

In rare cases, when many attributes need to be searched on (more than 10-15), it may be necessary to have a full advanced search page where the search criteria is grouped into multiple sections. For this type of page, the results do not show on the same page as the criteria. There are other flow issues that need to be taken into consideration when this option is used. See Search Flows guideline for full details.

• A minimum of 2 sections and a recommended maximum of 4 sections are allowed on this page.
• The user navigates can navigate to this page from:
  • An Object List Page (with Simple Search or Views section on page and "Advanced Search" section button):
    • Once the user has filled out the search criteria fields, he/she selects the page level "Search" button and navigates back to the Object List with the Simple Search section, and the Results section displaying the appropriate results.
    • If the user would like to change the advanced search criteria, he/she must select the "Advanced Search" section button. The criteria should be persistent from the last advanced search, unless a simple search on the previous page was conducted in the meantime.
  • An Object List with a Quick Search section and an "Advanced Search" button:
    • Once the user has filled out the search criteria fields on the Advanced Search page, he/she selects the page level "Search" button and navigates back to the Object List with the Quick Search section. The Results appear under the page title.
• There is also a page level "Cancel" button. This will return the user to the initiating page.

Matrix of Search Instruction Text

The following matrix provides standard instruction text for each type of search and its optional variations. Current plans for user preferences include the option to turn off instruction text throughout the application or suite of applications. Consequently it is recommended to provide instruction text by default so new users have a more successful introduction to the application. Once familar with the application, users can then turn off the instruction text.

When search functionality is provided without a separate Search subheader, search-related instruction text is appended to the instruction text for the page as a whole. Depending on the length and complexity of the other instructions, developers may need to omit the search-related instructions.

Note: All types of search, other than simple search with a single field, may have the requirement to fill out one or more indexed fields for performance reasons. If so, append the following text to the instruction text for that search type: "You must fill out [one of] the following field[s] before starting your search: {FieldNameX} [, FieldNameY] [, and FieldNameZ]."

In drafting instruction text, it is preferable to reuse the same text wherever possible. In the following table, common instruction text is indicated by a number/letter in parentheses in the Options column, such as (2a), where the number indicates the search type, and the letter indicates the option(s). Except for the Views section, no instruction text is provided for Advanced Search/Simple Search toggles (the button makes this obvious).

Notes: Key Flexfield Search is not included in this matrix as it is a special case. Nevertheless, the general manner of phrasing is consistent.

Visual Specifications

Below are details and links to other guidelines that relate to the layout of these search templates.

• Display of an Empty Search Results Table: "No Search Conducted" or "No Results Found"
• Search Criteria Layout: 1 Column, 2 Column, etc. - See Content Layout Templates Guideline
• Button Placements:
  • "Go" button per field - See Buttons: Action/Navigation - Placement per Field/Widget guideline.
  • "Go" button per group of fields - See Buttons: Action/Navigation - Placement per Group of Fields/Widgets guideline.
  • Section "Toggle" buttons - See Buttons: Action/Navigation - Placement per Section guideline.
• Page and Section Titling for Search and Results Object List - See Language: Page Titles and Breadcrumbs: Object List Guideline for heading syntax.

Removal of Results Section Header

The Results section header is optional on object list pages with search sections. Oracle Applications removes the header in all cases, but other divisions may choose to include or remove it. When the Results section header is omitted, it is replaced with a separator line, as shown in the following image:

Open/Closed Issues

Open Issues

13-Nov-2003:
• Need new design for sysdate feature.
10.25.02 - v3.0(+)
• Persistence of search criteria and results is being investigated and documentation may be modified in future versions of this guideline and the Search Flows guideline.




Closed Issues

13-Nov-2003: Following revisions to address bugs:
• Developers now have option to omit Results section heading.
• Provided specific instruction text for all types of search
• Applications to append instruction text when user must fill out an indexed field to avoid an error message.
01.02.02 - Quick Search is NOT ALLOWED when Side Navigation is present.
02.09.01 - Usability testing for all search section options A-G. Designs may alter based on test results.
03.13.01 - Need to watch usability with quick search and searching within a tab vs. across all tabs.