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 LOV's
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 ".".