Data processing: presentation processing of document – operator i – Presentation processing of document – Layout
Reexamination Certificate
1998-12-14
2003-12-02
Hong, Stephen S. (Department: 2178)
Data processing: presentation processing of document, operator i
Presentation processing of document
Layout
C715S252000
Reexamination Certificate
active
06658622
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to systems and methods of accepting data entry into a computer, and in particular to the use of assistance fields for diagnosing and correcting data entry errors with dependent components.
2. Description of the Related Art
Graphical user interfaces (GUIs) provide an easy to use, intuitive computer interface. A GUI typically includes a number of components such as input fields or areas that allow the user to enter data for computer program parameters or variables. GUI input fields or areas can also be used to accept user input defining parameter or variable names and characteristics.
In many cases, the parameters or variables (and hence, the data entered into the input fields) are subject to value and/or format constraints. Users must adhere to these constraints when entering data into the fields, or errors will result. For example, DOS filenames cannot exceed eight characters, optionally followed by a period and extension that cannot exceed three characters, and cannot include characters such as backslashes. Database object names, such as names for tables and stored procedure parameter names, have similar restrictions.
Multiple related input fields, each for different parameters or variables, may be grouped together and presented to the user in a dialog box or window. After data has been entered into the required input fields, the user may select an “OK” button, and the data in each field is accepted and stored accordingly.
A GUI can respond in many ways when the user violates an input field constraint. One way to respond is to wait until the user tries to commit all changes, then beep and present a dialog box informing the user of the error and information to educate the user as to the proper input form. One drawback of this technique is that it is often difficult for the user to associate the information in the dialog box with the constraint violation. For example, if the user entered data into multiple fields, the user will not know which input field is incorrect. The user must click OK on the error message dialog, associate the error message with the input field in error, select the text in the field in error, and then make the correction. This behavior maximizes the effort needed to commit a change that doesn't violate any constraint. Further, in some cases, input components are logically related so that the constraints that must be applied to one component are dependent upon the data input into another component. In such cases, the diagnostic information is best presented as soon as possible, or a single input error can propagate into a large number of errors, resulting in a diagnostic message which is unnecessarily difficult to understand.
Another way the GUI can respond to an erroneous input is to fix the errors without asking for user intervention. For example, if a comment field cannot contain a specific set of impermissible characters, those characters could be automatically stripped out before the comment is committed. This technique has disadvantages as well. First, the user may want the impermissible characters, not realize they have disappeared, and write new code that depends on their entry. This technique also does nothing to educate the user, and even worse, misleads the user into thinking no constraint has been violated.
Another way the GUI can attempt to solve the foregoing problems by avoiding the use of input fields altogether. For example, a length parameter can be specified with a slider bar or a combo box with all possible values in it. This technique is feasible for some parameters (e.g. specifying decimal precision, which generally ranges only between 0 and 31), and infeasible for others (i.e. specifying a BLOB length, which ranges from 1 to 2 gigabytes). Such controls avoid problems with lower and upper limits, and can also reflect context changes. However, such controls are not as flexible as editable text fields. For example, only an editable text field is suitable in cases where the same control (for consistency reasons) must serve as the length of (alternatively) a BLOB and a DECIMAL precision. Further, the name of a new object cannot ordinarily be specified with any other type of control other than an editable text field.
As is apparent from the foregoing, there is a need for a computer interface that validates user-entered data and provides the user with timely, diagnostic information on a field by field basis. The present invention satisfies that need.
SUMMARY OF THE INVENTION
To address the requirements described above, the present invention discloses a method, apparatus, article of manufacture for accepting data input into a computer.
The method presents an independent component and a dependent component to the user. The independent component comprises an independent component input area for accepting independent component input data. The dependent component comprises a dependent component input area for accepting dependent component input data and is associated with a dependent component constraint that is at least partially dependent on the independent component input data. User data is accepted into the dependent component input area, and an assistance policy associated with the dependent component is followed when the user input violates the dependent component constraint. The article of manufacture comprises a program storage device tangibly embodying instructions for performing the method steps defined above.
The apparatus comprises means for presenting the independent and dependent components described above, means for accepting user input into the dependent component input area, and means for following a assistance policy associated with the dependent component when the user input violates the dependent component constraint violation.
REFERENCES:
patent: 5103498 (1992-04-01), Lanier et al.
patent: 5239617 (1993-08-01), Gardner et al.
patent: 5367619 (1994-11-01), Dipaolo et al.
patent: 5390281 (1995-02-01), Luciw et al.
patent: 5432902 (1995-07-01), Matsumoto
patent: 5434965 (1995-07-01), Matheny et al.
patent: 5477447 (1995-12-01), Luciw et al.
patent: 5522026 (1996-05-01), Records et al.
patent: 5535323 (1996-07-01), Miller et al.
patent: 5644735 (1997-07-01), Luciw et al.
patent: 5778240 (1998-07-01), Buchman et al.
patent: 5859640 (1999-01-01), Judicibus
patent: 6282701 (2001-08-01), Wygodny et al.
Aiken William Holland
Sharp Frederick Thomas
Gates & Cooper LLP
Hong Stephen S.
International Business Machines - Corporation
LandOfFree
Self-diagnosing and self-correcting data entry components... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Self-diagnosing and self-correcting data entry components..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Self-diagnosing and self-correcting data entry components... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3147974