User interface for lenient exception feedback

[0001] The present invention relates to data entry on a computer system. Financial services software has automated many repetitive, but important tasks. For example, bill payment software is designed to ease the process of paying bills electronically. Generally, the bill payment software provides a user interface for entering account and payment information, and setting up periodic payment instructions. As a result, and in some cases without further user input, the payment software automatically submits the payment instructions to a payment processing system.

[0002] The configuration process for setting up the financial services software is typically a burdensome process, especially for inexperienced users. It is important that numerous data fields be populated with accurate information. Because the information is critical to performing the financial services, the configuration process will conventionally stall the process upon detecting a data entry error. For example, if a user enters an account number that does not match a given format for account numbers, the configuration process will not continue receiving data. Thus, the user has to either retrieve correct information before continuing or discontinue configuration.

[0003] Also, because conventional configuration processes either accept or reject data, there is no way of flagging data as suspicious by the application or as unreliable by the user, even though the data is technically acceptable. For example, a user can enter an account number from memory that, although is in the correct format, is not considered reliable by the user.

[0004] In various embodiments, the present invention provides methods and systems for tolerating and navigating data entry errors. In one embodiment, a computerized (or automated) financial service is configured. The steps for configuration are displayed at various levels of abstraction (e.g., displayed as an expandable tree). The data entries can be information that is critical to operation of the financial services, such as account numbers, dates, and social security numbers. An error is detected when a data entry is received that is inconsistent with a predetermined range of acceptable data. In other embodiments, an error can be detected when data is not within a range of expected data, a user marks data as unreliable, or data is missing. In response to detecting the error, an error indicium marks the error while allowing the configuration to continue.

[0005] The error indicium is displayed in association with a related configuration step. At a later point in time, a user can navigate back to the error using the error indicium as markers. The configuration step can be an abstraction of nested tasks which can be expanded to show the nested tasks. As progressively lower level tasks are revealed, an error indicium marks tasks that have underlying errors. Within the record itself, a data field can be marked with an error indicium. Then the user can remediate the error.

[0014] One skilled in the art will recognize that these Figures are merely examples of the operation of the invention according to one or more embodiments and that other configurations and modes of operation can be used without departing from the essential characteristics of the invention as set forth in the claims.

[0015] In various embodiments, the present invention provides methods and systems for tolerating and navigating data entry errors in a user interface. In one embodiment of data entry, the errors are entered in the user interface while configuring software, such as financial software. The data entries can be information that is critical to operation of the financial software program such as account numbers, dates, and social security numbers. The errors can be data entry errors such as data that is not within a predetermined range of acceptable data, data that is not within a range of expected data, data that a user determines is unreliable, and/or data that is missing. A user can navigate back to and correct errors generated during configuration.

[0016] FIG. 1 is a flow chart illustrating a method 100 for presenting errors within context according to one embodiment of the present invention. The method allows a user to navigate back to erroneous data entries without cessation of the configuration process. In one example, the method 100 is implemented in a financial software application, as described more fully below, during the configuration process. In other examples, the method 100 is implemented in a software application that relies upon data entered into records.

[0017] A record is presented which includes one or more data fields for entry of data 110. The record can be, for example, an employee record, a transaction record, or a profile. One embodiment of a record 700 is illustrated in the schematic diagram of FIG. 7. The record 700 can be used to add a new employee to a database of employees. The record 700 includes several data fields to collect information under a certain category. More particularly, each employee has data fields relating to employee information, employee home address, and contact information. Data can be entered to the data fields using, for example, a keyboard to enter ASCII text. In another embodiment, such as in a tax accounting software application, the record 700 can be used to enter monetary amounts (e.g., amount of a paycheck or account balance).

[0018] A data entry error is received for input to the data field of the record 120. In one embodiment, errors can be hard, soft, or manual. A hard error can occur when a data entry to a critical data field is not acceptable, as described below with respect to FIG. 2A. A soft error can occur when a data entry is not expected (e.g., type of data is not expected, or value of data is not expected), as described below with respect to FIG. 2B. A manual error can occur when a data entry is determined by a user to be unreliable, as described below with respect to FIG. 2C.

[0019] A record is submitted which includes the data entry error 130. Rather than prevent the user from continuing through the configuration process, in one embodiment, even a hard error will be tolerated so long as the user is apprised of the hard error. As described below, a user is allowed to navigate back to, and remediate, erroneous data at a later time. In one embodiment, a double submission can be required to continue the process. For example, after the first submission attempt, attention is drawn to the data entry error with, for example, an error indicium (e.g., an icon or highlighting of text). In another example, a submission can be delayed for an increment of time (e.g. 0.5 or 1.0 seconds) in which the error indicium is displayed. Within a data structure associated with the application, a flag can be set (e.g., a TRUE or FALSE bit), an error code can be stored (e.g., description of error), or some other digital indication of the error. Thereby, a user is alerted of errors without discontinuing the configuration process.

[0020] In response to submission or the data entry record, an error indicium can optionally be displayed within context of the plurality of records 140. The context of an error can be established by, for example, an outline of the configuration process. In one embodiment, the outline comprises an expandable tree that displays details within one part of an outline upon selection. The expandable tree allows different views of the configuration process.

[0021] One example of the expandable tree includes three levels: a task list, types of records within a task, lists of records within a record type, and actual records. The task list can form an interview process necessary to configure automated financial activities such as automatic deposits to or from a payroll. A task can include several types of records for payroll such as compensation payments, insurance payments, and retirement payments. A record type can include, for example, an employee list. In turn, the employee list can include a list of employee records. Each employee record comprises a number of data entry fields. The indicium is displayed proximate to, and in context with, a level that includes the error. If the current view is of tasks, the indicium will be displayed next to the appropriate task. On the other hand, if the current view is of the list of records, the indicium is displayed next to the appropriate record. Of course additional layouts are possible.

[0022] A user can navigate to the record for display of the data entry error 150. Perhaps at a later time, after the user has been able to retrieve correct data, the user is able to find errors within the configuration process and correct them. Using the indicium, the user traverses the tree in order to identify the record of interest. When the record itself is displayed, the data field containing the error can be identified with indicium.

[0023] FIGS. 2A-C are flow charts illustrating methods 210,220,230 for determining error types according to one embodiment of the present invention. An error can be detected, responsive to submitting a record during configuration, or alternatively, immediately when entered in the data field.

[0024] In FIG. 2A, a record submission is tested for hard errors. A data entry is received for input into the data field of the record 212. The data entry is compared with a predetermined range of acceptable data 214. The predetermined data can be a database populated with, for example, exact data values or particular data types that are acceptable. For example, a data field for entry of a social security number may have several restrictive parameters. First, a social security number should only contain numerical values, so non-numerical data entries signify errors. Additionally, the social security number should contain nine numbers, and there may be further characteristics such as numerical values that are not valid for the first digit of the social security number. Other data field entries can have additional characteristics such as only text values. In another example, there is a closed set of values that can be selected for data fields such as when selecting a state in the United States. In response to detecting a hard error, an error indicium is displayed within context of the plurality of records 216.

[0025] In FIG. 2B, a record submission is tested for soft errors. A data entry is received for input into the data field 222. The data entry is compared to a range of expected data 224. The expected data can be set by limits that are normally or reasonably acceptable, but not definite. Whereas it is impossible to have a negative value for number of children, a hard error, it is highly unlikely to have 13 children, although not impossible. In response to detecting the soft error, a a warning indicium is displayed within context of the plurality of records 226.

[0026] In FIG. 2C, a record submission can be marked with a manual error by a user. A data entry is received for input into the data field 232. The data entry, although it may be within acceptable and/or expected ranges so as not to trigger an error or warning indicium, can be deemed unreliable by a user 234. In other words, the user generates the error. In response, a confirm indicium is displayed within context of the plurality of records 236.

[0027] In some embodiments, data entries can be tested for each of hard, soft, and manual errors. In other embodiments, variations are possible such as testing for one or two types or errors, or testing for other types of errors outside of the examples listed herein.

[0028] FIG. 3 is a block diagram illustrating a method 300 for navigating errors in context according to one embodiment of the present invention. Configuration tasks organized in an outline format can be presented in an expandable tree format. That is, when a member of the tree is selected, additional tasks within the task can be presented, and so on. The expandable tree provides navigation to errors nested within a task. Depending on a current view of the expandable tree, the error can be presented in various contexts with respect to the actual error. In one embodiment, errors are presented in this manner after a user has already attempted to complete the configuration process, but has entered data errors in doing so.

[0029] In one view, a list of top-level configuration tasks is displayed 310. The top-level tasks include error indicium to show which top-level tasks having at least one data entry error. One example of top-level payroll set-up tasks 410 is illustrated in FIG. 4. A user interface 400 includes a list of top-level tasks 420 that are to be completed to set up automated payroll deposits for an employer. Specifically, the list of tasks 420 include steps for: Signing-Up for a Payroll Service, Setting-Up Company Options, Adding Employee Information, Setting-Up Tax Deductions, Tracking a Payroll History, and Checking Payroll Data. An error indicium 430 indicates that the task for Adding Employee Information contains an error. The error can be contained in one of the many sub-tasks and individual records nested within the task. By selecting the task for adding employee information, a user can navigate to the error.

[0030] Referring again to FIG. 3, in response to selecting a member of the list of top-level tasks, the member is expanded into a list of additional tasks nested therein 320. A list of sub-tasks within the selected configuration tasks is displayed 330. As with the top-level tasks, an error indicium shows which subtasks have at least one data entry error. FIG. 5 illustrates one example of the user interface 400 that includes the sub-task Creating Employee List 522 as an expansion to the top-level task Adding Employee Information 422. An error indicium 530 indicates errors within the sub-task, thereby allowing the user to continue navigating to the error.

[0031] As shown in FIG. 3, in response to selecting a member of the list of sub-tasks, the member is expanded 340. A list of records is displayed within a selected sub-task which includes at least one record with a data entry error 350. FIG. 6 illustrates one example of the user interface 400 that includes a list of records 620 within the sub-task Creating Employee List 522. An error indicium 630 indicates errors within a record. As a result, the user can navigate to the record to view and correct errors.

[0032] Referring to FIG. 3, in response to selecting a member of the list of records 360, the record itself is displayed which includes error indicium associated with data fields having a data error 370. FIG. 7 illustrates one example of a record 700 that includes a data field 722 with an error. As with other levels of the expandable tree, an error indicium 730 draws attention to a location of the error within the record 700. In particular, during the initial configuration, the user submitted the record 700 without designating a state. The state may be needed to determine which banks and/or legal processes are used for depositing a payroll check. Without this critical information, payments may not be able to be made.

[0033] FIG. 8 is a block diagram illustrating a system 800 for presenting errors within context according to one embodiment of the present invention. The system comprises 200 a financial service module 212, a configuration module 214, an error module 216, and a records repository 218, together in communication with a financial institution 250. Communication can occur over a data or telephonic network, a bus, through wireless transmission, etc. The system 800 can be implemented in a device such as a personal computer or handheld device executing software instructions. The system 800 can be located on a single device or distributed across a network (e.g., local application software or web-based software). In one embodiment, the system 800 can implement the methods described herein, and is a means for doing so, as recited in the claims.

[0034] The financial service module 212 can be an automated money management application such as payroll management, escrow services, bill payments, and other services. The financial service module 212 uses data entered by the user (e.g., data in the records repository 218) to automatically perform a financial transaction, and is a means for doing so. The financial service module 212 can be a client of the financial institution 250. The financial institution 250, in such an embodiment, can receive and process financial transactions (and other types of transactions such as general client/server transactions, database transactions, and storage network transactions.) from the financial services module 212. For example, a bank can receive certain funds into a particular account at a scheduled time.

[0035] The configuration module 214 can be a script, set of user interfaces, wizard, or tutorial that facilitates data collection. The configuration module 214 can be a separate module as shown (e.g., a plug-in), or be integrated with the financial service module 212. The configuration module 214 can initiate upon a new install, registration of a new user or profile, or from a menu. The configuration module 214 can present a user interface with data entry fields, and store data entries in the records repository 218, and is a means for doing so.

[0036] The error module 216 tracks data entry errors occurring during configuration, and is a means for doing so. The error module 216 can use a flag, bitmap, or other entry related to the error. The entry can indicate that there is an error, and in some embodiments, indicate the type of error (e.g., hard, soft, or manual error), indicate a location of the error (e.g., top-level task, sub-task, or record), indicate remedial measures, or indicate how to display the error in context. In some embodiments, the error module also displays the error and controls navigation (e.g., see FIGS. 4-7).

[0037] The present invention has been described in particular detail with respect to one possible embodiment. Those of skill in the art will appreciate that the invention may be practiced in other embodiments. First, the particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, as described, or entirely in hardware elements. Also, the particular division of functionality between the various system components described herein is merely exemplary, and not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead performed by a single component.

[0038] Some portions of above description present the features of the present invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules or by functional names, without loss of generality.

[0039] Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “determining” or “displaying,” refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0040] Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by real time network operating systems.

[0041] The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored on a computer readable medium that can be accessed by the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magneticoptical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

[0042] The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent to those of skill in the, along with equivalent variations. In addition, the present invention is not described with reference to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any references to specific languages are provided for invention of enablement and best mode of the present invention.

[0043] The present invention is well suited to a wide variety of computer network systems over numerous topologies. Within this field, the configuration and management of large networks comprise storage devices and computers that are communicatively coupled to dissimilar computers and storage devices over a network, such as the Internet.

[0044] Finally, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.