1. - Physical design of output reports and input forms
Input/Output Design
- Physical design of output reports and input forms
In this module, we discuss the physical design of output, input, and user interface. Although in the textbook authors include input forms as part of interface design, I separated them. In my view, the user interface is not just input screens but is a communication between users and the system. It is a two-way communication. Input data and instruction (what users want to do) go into the system in many forms. System replies with outputs, error messages, feedback, warning, help functions, etc. Also the interface includes how users navigate through the system. It could be commands, menus, or links that lead users to the next screen. It is a structure of the system from users’ view point (while DFDs and Flowcharts are the structure of the system from programmers’ view points).

2. Figure 7.1 Typical Physical DFD with Input and Output Functions
Outputs are data going out from the system to the users. The users may be an external entity, or maybe internal (boundary between computer-system and manual system). You have to be careful when determining the output data flow. Notice that dataflow – inquiry form – is a form that induces the input from the user (Customer), that means although the dataflow goes out of the system boundary, that form is an input form and not an output.
System Boundary

3. Output-design Objectives
Serve the intended purpose
Deliver the right quantity of output
Deliver it to the right place
Provide output on time
Outputs present information to system users. Outputs, the most visible component of a working information system, are the justification for the system. During systems analysis, you defined output needs and requirements, but you didn't design those outputs. In this section, you will learn how to design effective outputs for system users.

4. Types of Outputs
Internal outputs stay inside the system to support the system's users and managers
Detailed, Summary, Exception reports
External outputs leave the system to trigger actions on the part of their recipients or confirm actions to their recipients
Turnaround outputs are those which are typically implemented as a report eventually re-enters the system as an input

5. Internal Outputs Detailed Reports: Summary Reports: Exception Reports:
Present information with little or no filtering or restrictions.
Some detailed reports are historical in nature.
Detailed reports confirm and document the successful processing of transactions and serve as an audit trail for subsequent management inquiry.
Summary Reports:
Categorizes information for managers
Exception Reports:
Filter data before it is presented to the manager as information.
Exception reports only report exceptions to some condition or standard.

6. Detailed Reports

7. Summary Reports

8. Exceptional Reports

9. External Outputs
External outputs leave the system to trigger actions on the part of their recipients or confirm actions to their recipients
Turnaround outputs are those which are typically implemented as a report eventually re-enters the system as an input

10. External Output
Figure 7.2 Typical External Output

11. Turnaround Output Figure 7.3 Typical External Turnaround Output
Notice that the invoice has a top and lower portion. The top portion is to be detached and returned with the customer payment.

12. Output Media Paper – tabular, zone output Screen – graphic output
Point-of-Sale (POS) terminal
Video/Audio
Hyperlink
Although the paperless office (and business) has been predicted for several years, it has not yet become a reality. Perhaps there is an irreversible psychological dependence on paper as a medium. In any case, paper output will be with us for a long time.
The use of film does present its own problems - microfiche and microfilm can only be produced and read by special equipment. Therefore, other than paper, the most common output medium is screen (monitor).
Although the screen medium provides the system user with convenient access to information, the information is only temporary. When the image leaves the screen, that information is lost unless it is redisplayed. If a permanent copy of the information is required, paper and film are superior media. Often times when system designers build systems that include screen outputs, they also may provide the user with the ability to obtain that output on paper.

13. Sample Report Prototype
Figure 7.6 Sample Report Prototype Screen
The figure above is a prototype of a typical report that may result from the previous customization screen. Examine the content and appearance of the tabular report. We draw your attention to the following:
Icons are included for activating commands for allowing the user to “zoom” the report to 100%, fit the report to window size, and to adjust the page width. These features take into consideration the user and often times difficult task of viewing a report on a display screen.
Buttons are included for activating commands were included to permit the user to easily move from one report page to another (Notice that the window’s scroll bar is active allowing the user to scroll through the report.)
A Printer Icon is provided as a visual clue to suggest that the user can request a hardcopy of the report.
The user is given the opportunity to save the report as a file or to load a different report.

14. Example of Graphic Output

15. Web based Output

17. System User Issues for Output Design
Be simple to read and interpret.
Be dated and time-stamped.
Include sections and headings
Only required information should be displayed
Computer jargon and error messages should be omitted
User issues are so important here (and also in the Input design and User interface design):
Users will use the system mostly; and therefore, they determine the success or failure of the system.
Users don’t see the databases or how the program is working; yet output, input, interfaces (navigation) affects their use of the system and those are the ones the users see.
Bottom line – design these parts of the system for users
User-type and the degree of user-friendliness have correlation. For example, casual users require the most user friendly interfaces. You cannot expect them to handle command interfaces. On the other hand, dedicated users want the performance of interfaces, meaning that minimizing key-strokes, movement of mouse should be minimized. In such a case, user-friendliness is not so important
A dedicated system user is one who will spend considerable time using specific programs. This user is likely to become more comfortable and familiar with the terminal or PC's operation.
The casual system user may only use a specific program on an occasional basis. This user may never become truly comfortable with the terminal or the program.
Most of the time you design a part of the system (one report, or one input screen), you can see who are the users. Most probably you can tell the type of the users. With a few exceptions, those users are either dedicated or casual, not both. So you design that part of the system according to the users’ preference of user friendliness.

18. Input Design

19. Input Methods Keyboard, Mouse, Touch Screen Point-of-Sale (ATM)
Sound, Speech
Optical Mark (OMR, Barcode)
Smart card
Biometric

20. Taxonomy Data capture Data entry Data processing
the identification and acquisition of new data
Data entry
the process of translating data into a computer-readable format
Data processing

21. Data Entry / Processing
Batch input
Key-to-disk (KTD) and key-to-tape (KTT)
On-line input
graphical user interface (GUI)
Remote batch
Batch input is the oldest and most traditional input method. Source documents or forms are collected and then periodically forwarded to data entry operators, who key the data using a data entry device that translates the data into a machine-readable format.
The most common medium for batch input data are Key-to-disk (KTD) and key-to-tape (KTT) workstations that transcribe data to magnetic disks and magnetic tape, respectively.
On-line input is the capture of data at its point of origin in the business and the direct inputting of that data to the computer, preferably as soon as possible after the data originates.
The system user directly enters the data when or soon after that data originates. No data entry clerks are needed! There is no need to record data onto a medium (paper and such) that is later input to the computer; this input is direct! If data is entered incorrectly, the computer's edit program detects the error and immediately requests that the operator make a correction.

22. Trends in Automatic Data Collection Technology
Biometric ADC (automatic data capture)
Electromagnetic (radio)
Optical (Bar coding )
optical-mark reader (OMR) or optical-character reader (OCR)
Smart Cards
Touch
Biometric ADC technology is based on unique human characteristics or traits. For example, it is known that every individual can be identified by their own unique fingerprint, voice pattern, or pattern of certain veins (retina or wrist).
This technology is particularly popular for systems that require security access.
Electromagnetic identification technology is becoming very popular in applications that involve tracking physical objects are out of sight and on the move. For example, electromagnetic ADC is being used for public transportation tracking and control, tracking manufactured products, and tracking animals to name a few.
There are over one billion magnetic stripe cards in use today! They have found their way into a number of business applications such as, credit card transactions, building security access control, and employee attendance tracking.
Point-of-sale terminals in retail and grocery stores frequently include bar-code and optical-character readers. Bar codes eliminate the need for keying data, either by data entry clerks or end-users.
Smart card applications are particularly promising in the area of health records where a persons blood type, vaccinations, and other past medical history can be made readily available. Other uses may include such applications as passport, financial information for point-of-sale transactions, pay-television, etc.

23. System User Issues for Input Design
Capture only variable data.
Do not capture data that can be calculated or stored in computer programs.
Use codes for appropriate attributes.
Because inputs originate with system users, human factors play a significant role in input design. Inputs should be as simple as possible and designed to reduce the possibility of incorrect data being entered.
The volume of data to be input should be minimized. The more data that is input, the greater the potential number of input errors and the longer it takes to input that data. Thus, numerous considerations should be given to the data that is captured for input.
Do not enter constant data. For instance, when deciding what elements to include in a SALES ORDER input, we need PART NUMBERs for all parts ordered. However, do we need to input PART DESCRIPTIONs for those parts? PART DESCRIPTION is probably stored in a database table. If we input PART NUMBER, we can look up PART DESCRIPTION. Permanent (or semipermanent) data should be stored in the database. Of course, inputs for maintaining those database tables must be designed.
If you input QUANTITY ORDERED and UNIT PRICE, you don't need to input EXTENDED PRICE, which is equal to QUANTITY ORDERED times PRICE. Another example is incorporating FEDERAL TAX WITHHOLDING data in tables (arrays) instead of keying in that data every time.

24. Suggestions for capture data
Include instructions for completing the form
Minimize the amount of handwriting
Data to be entered should be sequenced so that it can be read like book, top to bottom and left to right
When possible, use design based on known metaphors

27. Use Known Metaphors

28. Internal Controls for Inputs
To ensure that the data input to the computer is accurate and that the system is protected against accidental and intentional errors and abuse, including fraud
Completeness checks
Limit and range checks
Combination checks
The number of inputs should be monitored. This is especially true with the batch method, because source documents may be misplaced, lost, or skipped.
In batch systems, data about each batch should be recorded on a batch control slip. Data includes BATCH NUMBER, NUMBER OF DOCUMENTS, and CONTROL TOTALS (e.g., total number of line items on the documents). These totals can be compared with the output totals on a report after processing has been completed. If the totals are not equal, the cause of the discrepancy must be determined.
In batch systems, an alternative control would be one-for-one checks. Each source document would be matched against the corresponding historical report detail line that confirms that the document has been processed. This control check may only be necessary when the batch control totals don't match.
In on-line systems, each input transaction should be logged to a separate audit file so it can be recovered and reprocessed in the event of a processing error or if data is lost.
Combination checks determine whether a known relationship between two fields is valid. For instance, if the VEHICLE MAKE is Jeep, then the VEHICLE MODEL must be one of a limited set of values that comprises cars manufactured by Jeep (Wrangler, Cherokee, Grand Cherokee to name a few).

29. How to Prototype & Design Computer Inputs
Step 1: Review Input Requirements
Step 2: Select the GUI Controls
Step 3: Prototype the Input Screen
Step 4: If Necessary, Design or Prototype the Source Document
Developing graphical user interfaces for new applications involves two stages for input design. In the first stage, the designer focuses their efforts on correctly identifying the confirming content of the input. And, consistent with the repository-based programming emphasis discussed earlier, to identify properties or characteristics for that input data.
The second stage deals with the overall appearance or look and feel of the input. This stage is typically deferred until the designer has given consideration to the overall appearance and working of the entire application’s interface.
Given an input to be designed, we should review the required attributes. The basic content of these inputs should have been recorded in the project repository during systems analysis. If the content has not been recorded, we can define input requirements by studying the output and database requirements or designs. An output attribute that can't be retrieved from database tables or calculated from attributes that are retrieved from tables must be input! Additionally, inputs must be designed to maintain the database tables in the system.
Now that we have an idea of the content for our input, we can address the proper screen-based control to use for each attribute to appear on our screen. Using the repository-driven programming approach, we would first check to see if such decisions and other attribute characteristics have already been made and recorded as repository entries. If so, we would simply reuse those repository entries that correspond to the attributes we will using on our input screen(s). In those cases where there is no repository entry, we will have to simply create them.

30. Review Input Requirement

31. Prototype the Input Screen
Figure 7-9: SoundStage Prototype for NEW VIDEO TITLE, DISCONTINUED VIDEO TITLE, and VIDEO TITLE UPDATE inputs
The logo appearing in the upper right portion of the screen was included to adhere to a company standard - that all screens must display the company logo. The buttons also appearing in the upper center and right portion of the screen were added because of the decision to combine the three inputs into a single screen. They were needed to allow the user the option of select the desired type of input and record action. Draw your attention to the following:
The PRODUCT NUMBER, MONTHLY UNIT SALES, YEAR UNIT SALES, and TOTAL UNIT SALES are screened in a special color as a visual clue to the user that these fields are locked and they cannot enter data into them. These fields are automatically generated by the system. Other fields appearing on the screen have white background as a visual clue that they are editable.
Notice that edit masks were specified for these input fields. The UNIVERSAL PRODUCT CODE field contains dashes in specified locations. The user does not actually enter these dashes. Rather, the user simply types in the numbers and afterwards the entire content is redisplayed according to the specified edit mask. The same is true for the MANUFACTURERS SUGGESTED RETAIL PRICE, CLUB DEFAULT UNIT PRICE, AND CURRENT SPECIAL UNIT PRICE fields. For example, in either of these three fields the user could type the number “9”, press enter, and the content would be redisplayed (according to the edit mask) with a dollar sign and decimal point.
Each field on a screen has been given a label that is meaningful to the users. Feedback from the indicated that “CC” was a commonly recognized abbreviation for “closed caption”. Also, the users indicated that a label was not necessary for CATALOG DESCRIPTION.
Notice that related radio buttons have been arranged in a group box that contains a descriptive label. Group boxes are frequently used to visually associate a variety of controls that are related. For example, notice the group box labeled “Common Information”. The fields located inside this group box were grouped together because the user associates these attributes any type of SoundStage product. Also, realize that each label that correspond to a radio button option is not what is actually input and stored in the database. Rather, what you see is the meaning of the value. The actual value that is stored is a code. For example, the code value “E” would actually be stored instead of “English” if the user selects the radio button labeled “English” for the attribute LANGUAGE.
Notice that the multiple-line text box has a vertical scroll bar feature. This is a visual clue that there is additional text not appearing inside the CATALOG DESCRIPTION field.

32. Well-designed Source Document

33. Web-based Input Prototype for Web Shopping Cart