Before an effective user interface can be developed for a product, thorough requirements analysis is required. This analysis should include identification of business flows and typical task flows, development of user profiles, and studies of the user's environment and system.
This manual does not address methods and details of requirements analysis except to note that any software product is only as good as the ability of the user to operate it, and that the goal of creating a usable system can only be met by working with and listening to the intended users. This chapter lists several issues to consider when designing a product, and further suggests that the developer research and follow the principles of user-centered design whenever possible.
The remainder of the chapter discusses translation issues and fundamental information presentation problems and how the product designer can provide solutions to these issues.
The following topics are covered:
Design analysis
Elements of the interface, including a brief overview of interface elements such as windows, menus, fields, and LOVs
Information presentation problems
Information presentation models, including information on regions, single-record formats, multi-record formats, hybrid formats, window and block relations, dynamic layouts, and wizards
Other design considerations, including guidelines regarding general layout and querying records
Accessibility features for users who are visually or physically challenged
For every task that a product is designed to support, build a flowchart of the steps necessary to perform the task. Identifying all the aspects of a particular task will reveal the opportunities for optimization. Once the flow of a task is documented, consider the following issues to lead you to the proper user interface for the screen(s) designed to support that task:
What related information is needed to complete the task? What amount of information does the user need to ignore?
What is the frequency of use and volume of data for the screen?
What widgets are most appropriate? For example, if the screen will be used by high-speed data entry clerks, widgets requiring the mouse are inappropriate.
What level of training is expected of the user performing the task? Does the screen need to be optimized for first-time or infrequent use (activities which may be better included in a self-serve application), or for a highly trained clerk doing repetitive tasks?
What if a user makes a mistake at a particular step, or attempts to bypass a step? Must the task steps be done sequentially, or can they be done in parallel?
What decisions is the user required to make along the way? What if those decisions are only in exceptional cases?
What other tools might the user be familiar with? What are their expectations of your product based on these other tools?
Restrictions imposed to support multiple environments and languages must be evaluated early in the design phase. Any decision to deviate from these restrictions must be considered carefully.
Oracle Forms does not support all window and mouse triggers such as WHEN-MOUSE-ENTER and WHEN-MOUSE-MOVE. Products must be designed to provide alternative methods to invoke the functionality that such triggers afforded.
Extreme caution must be exercised when relying on operating system specific functionality such as OLE automation, VBX controls, or hosting commands to the operating system. Besides being non-portable, they may produce an awkward result, such as launching a window that will appear on the forms server machine rather than the user's machine.
The maximum allowed window size is 10.3" (width) by 6.25" (height). This maximum size comes from the requirement to operate with 1024x768 screen resolutions.
(OMS-71002) To support various screen resolutions on bitmap monitors, forms should be built with coordinate systems based on logical, not physical, measures. For that reason, lay out all screens in inches rather than pixels.
[Translation] Oracle products run in the native language in all countries. Therefore, all prompts, titles, messages, and data presented to the user, other than data they enter while using the product, must be translatable so that it is presented in their native language.
Fore more information on expansion requirements, see: General Properties [for Text]
Anything that is translated must have sufficient space available to expand when translated from English to other languages (assuming that English is the base language for development). Depending on the widget and its placement, this space must be available either to the left, right, or both sides.
Numeric data and dates must also be presented to the user in their proper format for the current language. For example, numbers in German use "," as the radix character, whereas in English they use ".".
The following are the basic elements to use when designing screens. Each is discussed in much greater detail in later chapters of this document.
Windows or multiple document interface (MDI) windows are frames in which information is presented. Except for the simplest of forms, most forms have several windows associated with them. There are several recommendations for what information is contained in each window, specific behaviors of how and where windows open at runtime, and usage rules for modal windows that constrain a user to act only within that window.
A menu is a list of actions from which the user can choose. A pull-down menu is associated with each form, but always displays in the MDI window. There are specific rules for dynamically enabling and disabling menu entries. Oracle E-Business Suite uses a generic menu for all products to invoke standard functions. This menu also includes three special menus for product-specific functions that can be enabled and altered at runtime. Right-mouse pop-up menus are also available in all text fields.
The toolbar is a set of iconic buttons that allow quick access to common functions that are also on the menu. It is attached to the MDI window immediately below the pull-down menu.
Canvases are surfaces or areas within windows on which objects are displayed. A window can show one or more canvases, either one at a time or simultaneously. The choice of canvas type, and placement, is based on the information presentation model chosen.
A block is the logical representation of a set of related data items referred to as a database entity. In Oracle Forms, interface items are assigned to a block. The block controls the consistency of the data which is posted to the database by requiring that all items of a record in the block be completed before the user can continue. The items of a block may be distributed among several canvases or windows, but usually this logical grouping is also reflected in the design, maintaining the relationship of the block to the window. Blocks may show more than one record of a database entity at a time, but within that structure the integrity of each record is maintained by the Oracle Forms logic.
Regions are logical groupings of fields which are generally designated by an outline and a title. The specific cosmetics used to indicate regions are discussed in Chapter 3. Tabbed regions are a specific type of region that uses the Tab control.
A master-detail relation between two blocks controls the behavior of the detail block based on the current state of the master record. Oracle Forms will automatically ask the user to save changes if any are pending in a detail block if an attempt is made to switch the master record. Additionally, Oracle Forms will prevent querying in the detail block if the master is not yet saved, and entry in the detail block if no master row exists. There are specific behaviors for the timing of querying child records, based on the visibility of the detail block, that form logic must account for.
Text items allow a user to type alphanumeric characters. They can be shown in several states, including active, inactive, and display-only. These states are color-coded automatically. Often a text item has a list of values (LOV) associated with it to assist the user in locating a valid value.
An LOV is a set of valid values for a field. It is associated with a text item both for validation and to assist the user in selecting a value by displaying the list in a pop-up window at the user's request.
Buttons are used to invoke actions and to navigate. For example, they can be used to begin the "Approve" function, or to move to the "Order Lines" entity. Usually buttons pertain to a block, but occasionally they pertain to a field or a window. There are specific guidelines for placement, size, and labeling.
Check boxes are used to indicate a two-state value. They should only be used when the label on the check box can be clearly thought of as having true (checked) and false (unchecked) states.
List items allow the user to select a value from a small set of choices (the recommended maximum is 15 entries). A list is not to be confused with an LOV; it is a simple widget which does not support the volume of data or autoreduction capabilities of an LOV. Two types of lists are available: Poplists (commonly called a "drop-down list") and T-Lists (commonly called "scroll lists" or "list boxes").
Image fields support the display of images in various formats, with the image source retrieved from either the database or from the file system.
Radio groups (sometimes called option groups) allow the selection of one value from a choice of several, represented by several radio buttons.
There are three types of scroll bars that are used:
Block scroll bars allow the user to move through the records of a block by dragging the scroll box; all multi-record blocks use a vertical block scroll bar, placed to the right of the block (OMS-73078).
Multi-line text item scroll bars allow scrolling within a multi-line text item; all multi-line text items use a scrollbar. (OMS-74007).
Canvas scrollbars are used when a canvas cannot be made to fit entirely in the window and scrolling is required.
Messages, often referred to as "alerts," are shown in pop-up windows, to which the user must respond. Different styles of pop-ups and required responses are discussed, as well as standards for verbiage they contain.
The term "flexfield" refers to a declaratively controlled mechanism which allows the administrator of the application to define custom groups of data items which are collected or shown as part of the interface.
Oracle E-Business Suite uses two types of flexfields, key flexfields and descriptive flexfields. A key flexfield is used to enter multi-segment values such as part numbers, account numbers, and so on. A descriptive flexfield allows entry of additional information where the product has not already provided a field.
The Status Bar contains the message line and other Oracle Forms status indicators, such as List of Values. It is displayed at the bottom of the MDI window.
Related Topics
The fundamental problems when designing a user interface are how to present information to the user and how to allow the user to access the information they need. This section discusses some high-level issues that must be considered while optimizing windows for a task, and presents models that attempt to resolve these issues. Each screen must be designed by carefully analyzing and applying the available presentation models, and tuning them as required to meet the needs of the specific task.
Window layouts should be based on the logical relation of data, not the physical database tables. For example, in the sales and marketing product, a user perceives an "Account" as the specific data of the account, as well as the "Contacts" and "Executives" of that account. These three entities are stored in separate physical tables, but by placing them all in a single window, the user continues to perceive them as one logical object.
Placing information in a window always involves a compromise between the presentation of many records of an entity and the display of many details about each record. A summary view has the advantage of showing more records of an entity, but at the loss of detailed information about each record. A careful analysis must be done to determine the best compromise of rows and detail for each function. Often a hybrid of the two views is the best answer.
See: Hybrid Formats
Many of the Oracle E-Business Suite products contain large and complex data structures. However, even large amounts of information can be organized in a way which allows the user easy access to what they need. If this same information is not well organized, it simply becomes clutter. At the very least, data should be grouped and organized in such a way as to help the user quickly identify the general location of the information they need, and then allow them to quickly locate that particular item without having to visually scan an entire screen - or worse, search from page to page.
An analysis of the task flows should reveal what information a user must have access to at each point in time. For example, if a user must see "Set of Books" information to enter a journal, a decision must be made as to whether the Set of Books information must be visible at all times, or the user merely needs the ability to see it upon request. This in turn impacts how much of each entity should be displayed at once, and how many windows are necessary. A good principle to follow is to present information in decreasing order of importance, so that the most commonly needed data is readily visible first. Then, design the presentation model to allow the user to easily and selectively drill down to greater levels of detail.
This section contains various methods available for laying out windows. The models presented here are guidelines which have been successful for common tasks. Alternative layouts can be used to better accomodate unique tasks.
A region is a visual grouping of logically related fields. All large entities should be broken down into two or more regions, so that information can be presented to the user in organized sets of fields. Titles make the groupings easier to identify; however, you are not required to use these identifiers if the relationship of the fields in the group is obvious. There are some situations though, where a title is always required; these are discussed in the detailed section on Regions.
After an entity is divided into groups, if all groups cannot be displayed simultaneously, it becomes necessary for two or more regions to be displayed in the exact same space, one at a time, using a Tab control. The user can jump to a specific region by selecting a tab or by progressing continuously through all fields of all Tab regions. A set of fields, minimally the primary key fields, should remain visible so the user can maintain context at all times. There, "frozen" fields must be placed inside the Tab control on the left side.
When the user must see all fields of a record in a single window, but they do not need to see them all simultaneously.
When entire regions need to be hidden from a user due to security restrictions, the current state of data, or other product installations.
Scrolling of regions is not desirable since it may leave the user laboriously switching to and scrolling through each region searching for a field. A region should only scroll when the logical grouping of fields results in a field set that simply cannot be shown simultaneously, or when the fields that are initially out of view are seldom used. Care should be taken to avoid this unless there is no other possible user interface alternative.
If it must scroll, a region should never scroll more than two times the width (in multi-record blocks) or height (in single-record blocks) of the viewport (OMS-73122).
Single-record formats allow the maximum number of fields for a single record to be displayed at once. In general, single-record formats should be used for any of the following cases:
There is only one record possible.
The user commonly works with only one record at a time.
The user must see many attributes of one record at the same time.
Multi-record formats allow the maximum number of records for a single entity to be displayed at once. In general, multi-record formats should be used for any of the following cases:
When the user must see multiple records to perform the transaction, typically because there is a relationship between the records.
When the user must see summary attributes of many rows at the same time, typically to scan for information quickly.
When the user normally perceives of the entity in a multi-record format (for example, the lines of a requisition).
When the relevant data in a record will easily fit on one line.
When the format is meant to convey that more than one record can be entered.
Often a combination of single and multi-record formats is the best, allowing both summary and detail views of the same record.
When information is presented in a multi-record format, but additional detail about the current record is displayed in a single record format in the same window, the additional detail is referred to as an "overflow region." The fields of the overflow region should be non-navigable to avoid unexpected navigation sequences. They may be enterable if they are not applicable to all records and thus cannot be displayed in the multi-record block, or have unique sizing requirements, such as multi-line text items. Fields within overflow regions may be queryable even if they are display-only.
The overflow fields are always shown in the same window as the multi-record block and below it, ideally separated by a gap. Generally, they are on the same tab region as the multi-record block they belong with (OMS-73118).
When best to use:
When the user must see data in a multi-record format, but also needs to see a small amount of additional detail about the current record.
When the fields associated with each record vary based on some context of the record itself.
When records include multi-line text items, the multi-line items may be displayed in the overflow region.
In a combination block, the user can view the data in a multi-record (summary) format, but can also view a single-record (detail) format to see complete information about the current record in a separate window. There are specific behaviors governing which format is shown after a query, and what occurs when the cursor moves to a new record, as well as how the windows are positioned relative to one another. Ideally, fields in either format should allow update, but only allowing update in the single-record format is acceptable. Fields in each format may be presented in differing sequence if appropriate.
A specific implementation of this style is the "gateway", which is the opening screens a user sees when navigating to a complex entity, such as a Purchase Order form. The gateway has a summary window and a detail window, as well as a find window, and standard textual buttons (New and Open) in the summary screen. Details regarding the behavior of gateways are discussed in the section Combination Blocks.
Although this technique is the most costly to develop, it is the most flexible for the user.
It is best to use the combination block layout for frequently used entities, where a multi-record format is most appropriate for some tasks and a single-record format is best for others, and each needs to be available.
Each window should contain a logical entity, often requiring that more than one block be shown in it. Although it is preferable to show an entity in one window, there are occasions when splitting it across two or more windows is appropriate.
If all blocks for an entity can be displayed in the desired format in a single window, and adhere to window size and other standards, then using a single window is the preferred method. Typically, master blocks are displayed above detail blocks, but this is not required if the meaning and relationship of each block is clear. A zero-height frame may be used to identify each block if the content of the blocks is not obvious.
When the blocks cannot all be displayed at once, then tabs are employed. Selecting a tab causes the appropriate block to display. Each set of blocks on a given form may have their own tab region, and each tab control may contain one or more blocks.
Combination blocks require that the different formats of the same block be shown in different windows. Additional times when this is acceptable are as follows:
As a variant to overflow regions when there are additional fields about the current record that a user may want to see, but only on request (thus the number of rows in the multi-record block is not always compromised).
When the user doesn't necessarily perceive some fields as part of the same block. For example, the credit card information region of a sales order is part of the header block, but is not necessarily perceived as additional attributes of the header.
Because of the wide variety of customers that Oracle E-Business Suite serves, many attributes are not appropriate for all customers. There are several mechanisms to handle this:
The screen layout can be dynamically modified based on the value of a particular profile, product installation, or setup parameter. Typically, this is limited to showing or hiding different sets of fields, but may be as elaborate as presenting different blocks or flows to the user. This approach may be used with any of the information presentation techniques discussed previously.
When best to use:
When an attribute appears in multiple forms, and a single point of control is necessary to establish its behavior. For example, if a customer is not using Encumbrance accounting, they should be able to declare that once, and have all related fields on all screens respond appropriately.
When, based on the setup of a product, known optimal combinations of layouts can be inferred. For example, if a customer uses serial number control, the Serial Number field should be presented more prominently.
Folders allow each user to change which attributes are on a particular screen, as well as their order, size and other behavioral characteristics. This ability to customize means that a user can tailor the screen to show just the information they are interested in.
When best to use:
All gateways use folders in the results block (OMS-73093).
If a product expects that the default layout of a particular block is not optimal for most customers, and customization would substantially improve the usability of the screen.
Note: Folders may be coded only within the Oracle E-Business Suite division: The required APIs have not been productized and are not supported by Oracle Support.
Wizards are a series of screens that guide the user through a particular task. Each screen typically has few fields for the user to interact with. Many times just one field is used. In addition to the field or fields, detailed instructions are provided for the user.
Wizards should be available for all complex tasks that can be performed in a serial order, especially if they will be performed infrequently. Wizard windows should follow the guidelines for modal windows in general, but must also include the following buttons:
| Variable | Description |
|---|---|
| Cancel | Aborts all work performed in the Wizard, reverting data to its prior state. If significant work may be lost then a confirmation dialog should open. |
| Next | Advances the Wizard to the next step. Shown on all but the last window. |
| Back | Returns the user to the previous window in the wizard. This button appears on all but the first window. |
| Finish | Used to indicate that all steps have been completed. Always appears on the last window in place of the Next button. This button may appear on other windows within the wizard, if all of the steps are not required. Pressing "Finish" should save the changes the user has entered, unless this would be considered an unexpected or undesirable behavior. |
| Help | Invokes the online help system to provide the user help on the current page. |
Related Topics
Regions in Single-Record Formats
Regions in Multi-Record Blocks
The following topics also affect your form designs:
The following rules apply to all screens. Specific exceptions are noted throughout this document.
Orient screen layouts based on a top-to-bottom task sequence. Blocks, regions, and items are arranged by order of precedence, from left-to-right, then top-to-bottom. (OMS-71005)
Do not waste screen space. Make windows only as large as is necessary. Use blank space as a way to group information.
Most widgets are 0.25" high, and multiples of 0.1" wide. Two-dimensional widgets (multi-line text items, T-Lists) are multiples of 0.25" high. Textual buttons are 0.3" high. (OMS-74044)
In single-record blocks, items should be left aligned to form margins or columns where possible. (OMS-73174)
In multi-record blocks items should be stacked horizontally and aligned along their top. (OMS-73180)
Place titles and prompts toward the top or left of the element they are describing.
Prompts in single-record blocks are always to the left of the field. (OMS-75009)
Prompts in multi-record blocks are above the field, and aligned similarly to the data within the field they describe. (OMS-75109, OMS-75011)
Exceptional cases exist for matrix-style layouts, fields that do not require prompts, connecting prompts, and multi-line prompts.
At least a one-character space should be left between the items on a canvas and the window frame. (OMS-75008)
It is also preferable to leave this space around the edge of Tab regions. Exceptional cases exist for regions used to denote blocks. (OMS-73007)
Make data stand out. Also, make the controls to access and identify that data intuitive but non-obtrusive.
Use the same widget for the same attribute in all windows. There are specific exceptions to this rule documented in the section on Widgets.
When displaying currency (such as US Dollars) and amount fields, display the currency field first.
When displaying unit of measure and quantity fields together, display the unit of measure field first.
A user must always be able to easily identify the current record(s) they are working with. This is done in a variety of ways:
The primary key, or other identifying information, of the topmost master record of a form is repeated in the title of all non-modal detail windows. For example, in a form used to enter Sales Orders, the current sales order number should be displayed in the window titles for other windows of that form that directly relate to that sales order (OMS-58505).
Context of master records, other than the topmost master record, is drawn above any detail blocks that do not occupy the same window as the master. For example, in the Shipments window of the Sales Orders form, the current sales order number is displayed in the window title, but the current order line is shown as context fields drawn within the shipments window (OMS-73072).
All multi-record blocks include a current record indicator field, to clearly point out the current record (OMS-73178).
Oracle E-Business Suite provides three methods to locate previously entered data. When using Query by Example, the same block serves as the location where a user enters search criteria and the application displays any retrieved record(s) when the query is run. When using View Find, a separate window appears to allow the user to enter search criteria. "Direct Entry" blocks are a special case to locate a master record.
All blocks that are queryable should respond to View Find with either a Find window or a Row LOV as described below. (OMS- 71105)
When the user invokes View Find, one of two types of windows will appear. Because the user must first retrieve records before continuing, the Find window automatically appears upon navigating to a gateway or to any query-only block that does not autoquery. View Find can be invoked from the toolbar or menu at any time while in a queryable block. The two types of windows are:
A Find window that allows the user to enter search criteria for more than one attribute, then initiate the search. Most fields within a Find window provide LOV validation.
When a Find window should be used (OMS-73645):
For a multi-record block or combination block that does not autoquery (automatically queries and displays data).
For allowing the user to find a subset of records in a detail block.
For any single-record or multi-record block where the user needs to search by criteria other than the primary key (for example, if the primary key is relatively obscure). For single-record blocks, though, the results of the search must be reduced to a single-record (using an LOV after the Find Window if necessary) before being displayed.
A "Row LOV" that shows all possible records the user can query within an LOV window.
When a Row LOV should be used (OMS-73557):
For a single-row block display.
For allowing the user to select a single record in a multi-record block or combination block that autoqueries. In general, the types of multi-record or combination blocks that autoquery include detail blocks, and master blocks where the number of records is small.
QBE mode is the native Oracle Forms mechanism for querying data, and allows complex queries. All blocks that allow the user to retrieve data support this. QBE is a power-user feature and can only be invoked from the menu or keyboard (it is not on the toolbar, and no product buttons should ever be coded to invoke it). The user should never be required to use this mode as the only way to locate data.
Note: LOVs are not always available in QBE mode. However, the LOV indicator in the status bar will still display as the user navigates through the fields, which can be somewhat misleading. If the user persists and activates an LOV by keystroke, and the LOV has not been specially coded to be appropriately active in the QBE, then an error message will be shown.
View Find and QBE operate exclusively of each other. In other words, criteria entered in View Find does not affect criteria entered in QBE, and vice versa.
(OMS-71018) A screen that requires a master record to be identified, but only allows entry or maintenance of the corresponding detail records, does not need to provide View Find or QBE. Instead, direct entry into the primary key fields of the master can be used to uniquely specify the master record.
The following characteristics of fields, records, and blocks are indicated:
Text and Display items that act as fields (as opposed to prompts) are displayed with an inset bevel.
Text items that cannot be edited are displayed in gray; editable text items have a white background if optional, or yellow background if required (OMS-74014, OMS-74130).
Poplist items are always gray.
Fields that respond to the LOV function show the LOV indicator in the status bar, and have the LOV icon enabled on the field when it has focus. (OMS-71019)
Text items always show the Edit indicator in the status bar, and have the Edit Field entries enabled in the menu and toolbar. (OMS-71020)
Entries on the menu and toolbar are disabled if the function is not available for the current field, record, or block. (OMS-71021)
Several elements are used to facilitate movement among the screens and blocks of a product, as well as to invoke product-specific functions:
The Navigator (or "Navigate Window") is the primary means for opening another form while in an application. The Navigate window is always available during an Oracle E-Business Suite session.
Buttons are used to invoke product-specific functions, and to facilitate navigation through the various windows of a form (often drilling down to detail blocks). In general, buttons are placed at the bottom of a window. Buttons that pertain to a specific field, or must be pressed in logical sequence among the fields, should be placed near the appropriate field.
For complex forms, frequently there will be too many buttons than would reasonably fit on the screen. Avoid creating more than one row of buttons. If necessary, a button may invoke another window in which to further qualify the action (either an LOV or a specific modal window), or the action should be invoked by a different mechanism (such as the Tools menu).
Within each window, the button a user is most likely to press is made the Default button (OMS-74039). The default button may represent a child block, a function, or a "drill-down" action.
Tabs are used to switch between regions occupying the same window space. They allow the user to select a particular region or group, and they also serve as the title of that group.
A poplist may be used to control the set of records queried in a particular block. In this case it is referred to as a Query Control Poplist.
Next Block is the mechanism for drilling down the hierarchy of a complex object. When a block has more than one detail block, Next Block moves to the most commonly used block (OMS-76016). Previous Block always moves to the previous block in the hierarchy, not necessarily the actual path taken. If sibling blocks exist in the same window, Next Block and Previous Block must move between them; this is to ensure that all blocks are accessible with the keyboard. These functions are only available by function keys.
Detail screens can be accessed in a variety of ways. As described previously, buttons and Next Block may be used to drill down through a complex object. In multi-record blocks that support drill down, the user can click on the current record indicator to perform this function (OMS-73080). In addition, fields that allow drill down are indicated by green underlined text; the link can be activated by using the right-mouse pop-up menu.
[Tab] moves the cursor to the next item in the current block. When invoked from the last item of the block it may move to one of the following:
The first item of the same record (OMS-58140).
The first item of the next record (OMS-58527).
The first item of the next block (OMS-58140).
[Shift][Tab] moves the cursor to the previous item in the block.
Product-specific functions that apply to all or most windows of a form may be placed in one of the optional pull-down menu entries on the toolbar. In addition to the standard menu entries (File, Edit, etc.), these additional menus may be added: "Tools," "Actions," and "Reports." The menus labeled "Actions" and "Reports" may be relabeled by the specific form. Specific functions found on these menus may also be replicated as textual buttons within windows to increase their visibility and accessibility. Up to 15 entries may be added to each menu.
To meet the needs of users who are physically or visually challenged, Oracle E-Business Suite products are designed as follows:
The product is completely operable without a mouse. Every item can take focus and/or be activated with a keyboard mnemonic (access key).
All screen text is available to screen readers. Fields which cannot take focus are presented within a Prompt/Value List of Values window, which can be interpreted by a screen reader.
Hidden text, which does not render on the screen but is presented to a screen reader, is available on certain fields which typically would not have a prompt.
Any use of color coding must only be used to augment. For example, a financials total may be displayed in red if negative, but should also be drawn such that it is understandable without the aid of color (such as with a negative sign preceding the value) (OMS-76046)
Related Topics