Form Design. Software Engineering CSCI Dr. Tom Hicks Computer Science Department

Transcription

1 1 Form Design Software Engineering CSCI-3321 Dr. Tom Hicks Computer Science Department

2 Learning About Good Forms By Examining Some Really Bad Prototype Forms 2

3 About Data-Entry Forms 1. Select a form background that would be pleasant and easy to read for the person doing data-entry 8 hours at a time. White is pretty bland! 3

4 Some colors are not the best choices! 4

5 Some colors are not the best choices! 5

6 A better Some choice colors for are background better choices! colors. 6

7 About Data-Entry Forms 2. Select a font color that is compatible with your background. It should be an easy combination to read from a distance 7

8 About Data-Entry Forms 3. Select a font face, font size, and font color combination that would be easy to read for the person doing data-entry 8 hours at a time. 8 8

9 About Data-Entry Forms 4. Never make the prompt more bold or larger than the data entry. The data is more important than the prompt! 9

10 About Data-Entry Forms 5. Opt for font clarity over cuteness

11 About Data-Entry Forms 6. The fact that some API s contain a form generator that generate a starting Data-Entry form does not make that form professional or acceptable. This form is a mess. It looks like someone just threw the prompts and textboxes onto the screen. Some of the prompts are not even entirely visible. This is way better than nothing, but serves as a starting point and not a destination! 11 11

12 About Data-Entry Forms 7. It is most often a good idea to lay out your form in such a way that it has one or two major columns. 8. It is most often a good idea to place the most important info at, or near, the top! (There are certainly many exceptions). 12

13 Would Be Better done With Two Columns! 13

14 About Data-Entry Forms 9. It is generally a good idea to align all prompts and data horizontally. Many API s have alignment tools to make this easier

15 About Data-Entry Forms 10. It is not always possible, but try to avoid void/blank spaces in form. 15

16 About Data-Entry Forms 11. It is generally good idea to frame the form so that you have about the same amount of blank space around all four of the form borders 16 Don t Always Need A Prompt For Textbox Message 16

17 About Data-Entry Forms 12. It is generally a good idea to try to make the space between rows consistent and not too large. 17

18 Data-Entry Form Prompt & Textbox Stand-Alone Applications, Websites, etc. 18

19 About Textbox Prompts 1. Every Prompt Should Be Clear & Concise Supplier ID# Minimum Quantity To Stock 19

20 About Textbox Prompts 1. Every Prompt Should Be Clear & Concise There will be times when forms are cluttered with lots of data entry containers. Arranging the various controls aesthetically and logically often prove challenging. Adding Mouse-Over Text to the prompt is one way to really help clarify the request. Many API s provide mechanisms for this with some type of Tool Tips ; use it when necessary. 20

21 About Textbox Prompts 2. The Prompt Should Not End With A Colon (:). 21

22 About Textbox Prompts 3. You may place prompt over or to the left of the data entry field; most of the time it is best to select one or the other and be consistent. Prompt Name Tom Name Tom Prompt Response TextBox Response TextBox 22

23 Data-Entry Form Controls Stand-Alone Applications, Websites, etc. 23

24 About Controls 1. It is generally a good idea to left-justify the data entry controls (textbox, radio button, drop-down list, checkbox, buttons, etc.) 24

25 More Data-Entry Form Text Prompts Stand-Alone Applications, Websites, etc. 25

26 About Textbox Prompts 4. If you are placing the prompt beside the data entry fields, it is best to right-justify the prompts. 5. If you are placing the prompt over the data entry fields, it is generally best to left-justify both the prompt and the field. 6. It is generally best to keep the distance between the prompt and the data entry fields consistent. 7. It is generally best to keep the prompts the same font and size. 26

27 About Textbox Prompts 8. It is generally a good idea to capitalize the first letter of each and every word in the prompt. 9. It is generally a good idea to try to avoid all upper case prompts (unless they are acronyms). 10.It is generally a good idea to keep the distance between the prompt and the data entry small, readable, and consistent. 27

28 ID Field Searching/Matching Numerics Is Much Faster Than Searching/Matching Strings! 28

29 Numeric ID 1. Most Classes/Structs/Tables should have a unique ID which can be used to identify any one record. 2. Most databases have an auto incrementing field just for this purpose, but it can be implemented in any programming language. 3. It is best to use auto incrementing mechanisms for unique primary keys! 29

30 Numeric ID 4. If creating your own auto incrementing integer fields, these unique ID's should never change! 5. Since these auto incrementing integers are not going to change, then the user should not be able to change it. It will often be displayed on forms, but the user will not be able to change it. 6. A label often appropriate to display the value; if a textbox were used, the user would try, in vain, to change it. 7. These auto incrementing fields preserve relationships. 30

31 More Data-Entry Form Recommendations Stand-Alone Applications, Websites, etc. 31

32 About Data-Entry Forms 13.Each form should contain a clear statement of title in the title bar; the title should describe the form. (This is a great place for a commercial!) 32

33 About Data-Entry Forms 14.All of the forms in an application, or website, should have a common feel a) Consistent navigation and/or buttons b) Consistent fonts c) Compatible, or consistent, background colors 33 33

34 About Data-Entry Forms 15.The Data Entry should be sufficiently large to hold the maximum size value (current font). 16.If the largest Title is 70 characters big, the data entry field should be large enough to handle 70 characters; use multi-line if needed! 34

35 Complex Data-Entry Form Recommendations Stand-Alone Applications, Websites, etc. 35

36 About Data-Entry Forms 16. The use of lines, boxes, panels, and/or tables will enable you to place more information on a form. 17. Organize the information in some logical pattern. 36

37 About Data-Entry Forms 18. You may use multiple font faces and font sizes and font colors on a form; normally this will decrease the usability of the form. Have a reason for those changes. 37

38 About Data-Entry Forms 19. Consider using tab frames when your form has a lot of data. Organize it logically. Label the tabs. Use tab colorization to help user recognize each tab. 38

39 About Data-Entry Forms 20. Include enough duplicate information on each of the tabs to assure that the user never has to guess which record they are viewing. 39

40 About Data-Entry Forms 21. It is often a good idea to provide the user with a multiline textbox in which to store information that may be needed later in the software life cycle; a database memo field might be used to store things that may not have even been considered during the analysis. Note that the contact name 40

41 About Data-Entry Forms 22. Use Drop-down Combo Boxes To Validate Data Entry Selections Whenever Possible; This Will Help Reduce Data Entry Errors. Wouldn t a combo box, or a spinner, which contained only the acceptable values be better for verifying the birthday? Wouldn t a drop-down combo box, containing only the acceptable abbreviations for the states be better than the user selection? 41

42 About Data-Entry Forms 23. Do not select a background that forces one to strain to read/enter text and utilize the buttons. 24. Do not use too many colors on the same form. 25. Keep colors consistent throughout the many forms of an application. 42

43 Data-Entry Form Buttons/Menus Stand-Alone Applications, Websites, etc. 43

44 About Form Buttons/Menus 1. Button names should be extremely clear (btnexit) and the button face text should be as clear as you can make it within the space available. (Exit) 44

45 About Form Buttons/Menus 2. Button should generally be well organized in an orderly fashion. (Remember to frame the form). There will be lots of possible options. 45

46 About Form Buttons/Menus 3. We have found that Next works best on the bottom right and Previous works best on the bottom left. 4. There will be times when you make more frequently used buttons larger. 46

47 About Form Buttons/Menus 5. We have found that menus on the right are not nearly as effective as menus on the bottom. 47

48 About Form Buttons/Menus 6. Power Users often don t want big buttons. 7. It is perfectly all right to have different button layouts for users with different skills. 48

49 About Form Buttons/Menus 8. Include mouse-over tool tips with graphical buttons. 49

50 About Form Buttons/Menus 9. The Navigation Buttons & Menus on all of the forms in an application, or website, should have a common feel/style

51 All Of These Came From The Same Project! Do These Look Compatible/Complementary & Consistent? 51

52 All Of These Came From The Same Project! Do These Look Compatible/Complementary & Consistent? 52

53 Data-Entry Form About Edit-Add-View Stand-Alone Applications, Websites, etc. 53

54 About Edit-Add-View 1. Rather than create one form/prototype for an Edit Mode, one form/prototype for an Add Mode, and one for a Normal View Mode, it is often possible to design a system to use one format for all. 54

55 About Edit-Add-View 2. In the Normal View Mode, the user would enter the Edit Mode by selecting Add or Edit; buttons Save & Cancel buttons are disabled! 3. Add & Edit can often use the same form! 55

56 About Edit-Add-View 4. The Edit Mode (when either editing an existing record, or adding a new record) should be noticeably different. I don t recommend this color combination. 56

57 About Data-Entry Forms 5. Note that only buttons Save & Cancel are enabled! When editing, or adding, the only two choices available to the user should be Save or Cancel! 57 57

58 About Data-Entry Forms 6. The Edit Mode should work with a copy of the data; this way the user can Cancel without destroying the original data. 58

59 Not An Acceptable Primary Data-Entry Form 7. The column-tablular style might be ok format to use as a second data entry form for power users. 59

60 Data-Entry Form Navigation Stand-Alone Applications, Websites, etc. 60

61 Navigation 1. Most of your High Level subsystems should have an option for the novice users to scan through the data with Next and Previous buttons. 61

62 Not An Acceptable Primary Navigation Form Student View User Form: Goal: User Suppose To Enter Any Info They Know with tabs when they hit ENTER Key Shows Users No Manual & No Training Great to have a Secondary Navigation Form that is Search-Oriented for Power Users! 62 62

63 Argument Against Next-Previous We have 10,000 Items! Therefore : This would take forever Not Useful If this is the case, we need to bundle Next & Previous with other controls & options! 63

64 Navigation Quick Links We have 10,000 Users! Make it useful. Divide & Conquer 2. Use Quick-Link search buttons such as A, B, C, 3. Select B to navigate to first User whose Name starts with an A 64

65 Navigation Quick Links We have 10,000 Users! Make it useful. Divide & Conquer 4. Most Sub-Systems should include Navigation Filters to reduce data sets. 65

66 Navigation Filters? Filters might be used, to partition or subdivide the data; what type of things might we use in an elementary school library application to subdivide the Users? Teachers Librarians Students First Grade Second Grade Third Grade Fourth Grade Fifth Grade Sixth Grade First Period Second Period Miss Wilson Mr. Smith Ms. Jones 66

67 Navigation Filters 5. Most Sub-Systems should take advantage of navigation filters to isolate traffic. 6. Filters should also be used to isolate printed data; the same report layout, with variable titles, can be used for multiple listings. 67

68 Navigation Filter Example 68

69 Order By 7. Most Sub-Systems should take advantage of an Order By combo box to provide logical order (as opposed to physical order). 69

70 Order By Example 70

71 High-Level Navigation 8. The user should always know where they are, where they need to go, & how to get there! (Many Systems Will Need More Than A Few Tab Frames!) 71

72 High-Level Navigation 9. Although not very clever or creative, you might have a set of controls that sit on the desktop to access each of your sub-systems. 72

73 High-Level Navigation 10. You can use.net to create an application environment with upper level menu strip controls at the top; the forms beneath may be all button related. 73

74 High-Level Navigation 11. There are a number of API s that provide menu-strip controls; you might have an upper level menu-strip control your sub-system forms (which also have menu strip controls) 74

75 High-Level Navigation 12. Continue To Ask Yourself Why Did The User Get Here Example : Garage Application : User Is Looking At Customer Record : They Wanted To Do A Service Order For That Customer and then provide the user with the tools to get to where they need to go efficiently & quickly! Example : The Software Engineer Should A Button On The Customer Form Maybe Create Service Order? Forcing the user to close the User Form Select the Service Order Sub-System Select create new order Require the user to type in Name, ID, Address, etc. for a record that the user was just looking at is not unusual, but really lame! 75

76 The Navigation Choices Must Be Obvious! Obvious is not Right Mouse Click On The Form & Select 76

77 Each Of Your Major Sub-System Stand-Alone Application Forms Must Include The Following Navigation Buttons: Next Previous Each Of Your Major Sub-System Stand-Alone Application Forms Must Include The Following Controls: Select Order By 77 77

78 78