The World’s Simplest IS

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

2. Entity A Entity B Entity C Entity D Entity E Entity F D1 Data Store 1 2 Receive Data Present Data A Slightly More Realistic IS Output Input Output Input Data Data Input Output

3. Entity F Entity E Entity C Entity D Entity A Entity B D1 Data Store N-1 2 3 1 n Process Data Process Data Process Data Receive Data Present Data What it usually looks like Output Input Output Input Input Data Data 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. 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 System Modeling Approaches End Result: a Data Flow Diagram

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

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

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

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. 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 Dialogue Diagram Example(Perfect Pizza)

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