Input/Output Design User Interface 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).

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

Output-design Objectives Serve the intended purpose Deliver the right quantity of output Deliver it to the right place Provide output on time Choose the right method 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.

Types of Outputs Internal outputs stay inside the system to support the system's users and managers 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

Figure 7.2 Typical External 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.

Types of Outputs Detailed 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. Exception Reports: Filter data before it is presented to the manager as information. Exception reports only report exceptions to some condition or standard.

Figure 7.4 Sample Detailed Report An example detailed report is depicted in the figure above. This example is a listing of all purchase orders that were generated on a particular date. Other example detail reports would be a detailed listing of all customer accounts, orders, or products in inventory.

Figure 7.5 Sample Exception Report An example is depicted in the figure above where delinquent member accounts are identified for following-up. Another classic examples of an exception report is a report that identifies items that are low in stock (soon to run out).

Output Media Paper Screen Microfilm/Microfiche Video/Audio CDROM, DVD Other electronic media 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.

Output Formats Tabular output Zoned output Graphic output Narrative output Most of the computer programs written probably generated tabular reports. Zoned output is often used in conjunction with tabular output. For example, an order output contains zones for customer and order data in addition to tables (or rows of columns) for ordered items.

System User Issues for Output Design Be aware of output bias. Computer outputs should be simple to read and interpret. The timing of computer outputs is important. The distribution of computer outputs must be sufficient to assist all relevant system users. The computer outputs must be acceptable to the system users who will receive them -> Need for training. 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 mouth 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.

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.

Designing Effective Input Figure 7-7: Sample input form 1

Input Methods Batch input On-line 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.

Trends in Automatic Data Collection Technology Biometric ADC Electromagnetic (radio) Magnetic (MICR) 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.

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.

Figure 7-8 Keying from Source Documents Data to be entered (keyed) should be sequenced so it can be read like this book, top to bottom and left to right (see Figure (a) above). The data entry clerk should not have to move from right to left on a line or jump around on the form (see Figure (b) above) to find data items to be entered.

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).

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.

3 1 2 5 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. 4

Example Suppose you are going to design input forms for a system that deals with customer orders. The above figure were designed in logical design phases. The first arrow coming into the process (Order with CC-Auth) must be input into the system. Order Detail information includes such data item as: Order ID Customer ID Ordered Date Ordered Product ID Quantity

Now, here are two alternatives of input form design Now, here are two alternatives of input form design. Which one do you like? And Why?

User Interface Design User interface design is the specification of a conversation between the system user and the computer. The user interface should provide a friendly means by which the user can interact with the application to process inputs and obtain outputs. Recall that in previous lectures, you learned how to design and prototype inputs and outputs. User interface design and prototyping addresses the overall presentation of the application and may require revisions to those preliminary input and output prototypes. Today, there are two commonly encountered interfaces: terminals (or microcomputers behaving as terminals) used in conjunction with mainframes and the more common display monitors connected to microcomputers. There are also several strategy styles for designing the user interface for systems. This conversation generally results in either input or output -- possibly both.

Interaction Methods and Devices Command Language Interaction Natural Language Interaction Form Interaction (Fill-in-the-blank) Key-word search Menu Interaction Object-Based Interaction (GUI) User interface design is the specification of a conversation between the system user and the computer. There are two issues to be determined: Methods of Interacting (or navigating through the system) and Contents of dialog. Interacting methods are how the system users convey instructions and data to the system. Dialogs are how the system responds (feeds back) to the users.

Controlling Data Input One objective of interface design is to reduce data entry errors Role of systems analyst is to anticipate user errors and design features into the system’s interfaces to avoid, detect and correct data entry mistakes

Providing Feedback Status Information Prompting Cues Keeps users informed of what is going on in system Displaying status information is especially important if the operation takes longer than a second or two Prompting Cues Best to keep as specific as possible Error and Warning Messages Messages should be specific and free of error codes and jargon User should be guided toward a result rather than scolded Use terms familiar to user Be consistent in format and placement of messages Providing feedback to the users has several patterns. Status Information: e.g., downloaded 1,000 kb or 1% of 100MB Prompting Cues: e.g., Installation complete, reboot your computer. Error and Warning Messages: e.g., Error 404: File not found Providing Help: help menus, wizards, tutorials, Context-Sensitive Help

Providing Help Place yourself in user’s place when designing help Guidelines Simplicity Help messages should be short and to the point Organization Information in help messages should be easily absorbed by users Demonstrate It is useful to explicitly show users how to perform an operation

Designing Dialogues Dialogue Sequence in which information is displayed to and obtained from a user Primary design guideline is consistency in sequence of actions, keystrokes and terminology State Transition Diagram Designing the Dialogue Sequence Define the sequence Have a clear understanding of the user, task, technological and environmental characteristics

Sample State Transition Diagram Figure 7-10: State Transition Chart

The Process of Finalizing Design Specifications Deliverables and Outcome Set of physical design specifications Contains detailed specifications for each part of the system

Assignment 5: Input/Output Design Sample reports: outputs created from your prototype system OR your design Sample Input forms (Web-based) Sample of help functions See Assignment section in the BB for details.