1. The World’s Simplest IS 1 Receive Data 2 Present Data Another Entity An Entity D1 Data Store Input Data Output

2. A Slightly More Realistic IS Entity AEntity BEntity C 1 Receive Data 2 Present Data Entity D D1 Data Store Input Data Output Entity FEntity E Input Output

3. What it usually looks like Entity AEntity BEntity C 1 Receive Data n Present Data Entity D D1 Data Store Data Entity FEntity E 2 Process Data 3 Process Data N-1 Process Data... Input Output

4. Where to start? Two schools of thought: –evolution: start with current system and identify changes –revolution: start from scratch Either way, there are two approaches to modeling: –data-driven - identify relevant data first –process-driven - identify relevant functions first

5. System Modeling Approaches Data-driven: Develop ER diagram Translate to data stores Fill in processes between data stores Define data flows and external entities Process-driven: Identify major tasks or processes Identify the inputs and outputs to the tasks Translate to processes and data flows Identify data stores and external entities End Result: a Data Flow Diagram

6. Data Flow Diagrams Context diagram Level 0 diagram Child diagrams Physical diagrams Partitioned physical diagrams Current diagrams Proposed diagrams Analysis Design

7. Four parts to a system design System architecture Interface design Database design Process design

8. Elements of the design Entity AEntity B Entity C 1 Receive Data n Present Data Entity D D1 Data Store Data Entity FEntity E 2 Process Data 3 Process Data N-1 Process Data... Interface System Architecture Database Process Output Input

9. Developing the Design Elements System architecture: set of processes in the Level 0 DFD of the proposed system (functional decomposition of system) Database design: derived from the ER diagram and data stores on the DFD Interface design: determine form and content of all input and output data flows on DFD, as well as overall interface Process (software) design: add logic and timing to all processes on DFD (logic models)

10. Interface Design Inputs and outputs –data flows to and from external entities –data flows into and out of processes that are manual or not fully automated User interaction –how the user communicates with the system –mechanisms for navigation, feedback, control, security, etc.

11. I/O Design Issues Audience –What tasks are they doing? –What level of detail do they provide or need? –How technology-literate are they? –How much time will they spend with the input or output? –How often will they provide the input or generate the output?

12. Media For a given input or output, you must decide whether it should be: –paper or electronic (or something else) accessibility of computers to system users portability expected life expected frequency –on-line or batch timeliness required underlying hardware and support software

13. Designing Layout Consistency is key! Throughout the system: –use the same colors for the same purposes –use the same highlighting or borders to convey similar meanings –use terminology and acronyms consistently –put similar pieces of information in the same location

14. Designing Layout (cont.) Color and highlighting –First of all: CONSISTENCY! –Second: Moderation! –Best combination: black on yellow –Worst combination: red on green –Strong techniques such as blinking and audio should only be used in the rarest occasions, and then only temporarily

15. Designing Layout (cont.) Bias –Your design outlives you! –Sorting - more attention is given to things listed first –Ranges - make sure they’re the right ones –Graphics: color and appropriateness scale user training –User customization - a double-edged sword –User involvement - required

16. Designing Layout (cont.) Use plenty of white space Plan for screen and page breaks Include administrative information Top to bottom, left to right Use “Submit” and “Clear” buttons

17. Input Accuracy and Efficiency Layout –top to bottom, left to right –group related items together –separate titles from body from instructions –clear titles and captions –don’t be stingy with white space Eliminate typing –checkboxes, pull-down menus, icons –default values Checking accuracy –check reasonableness of combinations –predefined acceptable values –check for proper format –check for missing values

18. Assessing Usability Can assess an entire system for usability, or just one form or report User involvement in usability assessment is necessary Some measures: –learning time –user speed –user accuracy –user’s ability to remember system operation –subjective assessments

19. Interaction Methods Command language - necessary on some older systems, but pretty much outdated Menus - most common at this point –drop-down, pop-up Forms - good if the interaction consists of specific pieces of information Object-based (icons) - intuitive and space- efficient, but can be designed poorly Natural language - not there yet

20. Conventions When designing the overall user interface, you must decide on some conventions to be used throughout the system, e.g.: –what different colors mean –what certain symbols mean –navigation mechanisms –terminology –artwork and logos

21. Navigation Always make the next step clear Don’t overly restrict the user’s movement No dead ends Navigation mechanisms should be used consistently Let the user know (or choose) consequences of leaving a form

22. Dialogue Diagrams Map out the overall user interaction with the system Represents the expected use of the system Doesn’t necessarily capture all possible scenarios Represents the inputs and outputs and the order in which they will be accessed

23. Dialogue Diagram Example (Perfect Pizza) 0 Main System Screen 1 New Customer Screen 2,0 2 New Order Screen 3,4,0 3 Delivery Instructions 4,0 4 Cook Order 3,0 5 Weekly Sales Report 0

24. User Feedback Status –always let the user know what’s going on –don’t let “no news be good news” Prompts –tells the user what is expected of them –convey as much guidance as possible within reason Errors and warnings –convey importance –suggest resolutions –be careful of jargon

25. Providing Help Provide different levels of help Test a lot under realistic conditions Use a variety of terms to help in searching Starting point should always be visible Navigating help should be simple

26. Security Often not considered part of user interface design Helpful to choose security mechanisms at user interface design so that the user’s role in security can be integrated into the interface Mechanisms: –Views and authorization rules - restrict access according to who the user is –Authentication schemes - establishes identity of user –Encryption procedures - protects against access from outside

27. GUIs GUI - Graphical User Interface Allows different parts of user interface to be active at the same time Complicates dialogue design Common components: –data entry boxes –check boxes –radio buttons –drop-down menus or list boxes –command buttons –message windows –tab control dialog boxes

28. Special Considerations for Web Interfaces Test using different browsers Use and reuse other sites as examples Navigation - no dead ends! Form is not enough Plan for maintenance Using a metaphor can be helpful Use keywords in text Beware of background patterns Home page should load quickly