Form Design Guidelines Software Engineering CSCI-3321 Dr. Tom - - PowerPoint PPT Presentation

• Dr. Tom Hicks

Computer Science Department

Form Design Guidelines

Software Engineering

CSCI-3321

1

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

2

About Data-Entry Forms  Guideline # 1

• 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

Some colors are not the best choices!

4

Some colors are not the best choices!

5

A better choice for background colors.

Some colors are better choices!

6

About Data-Entry Forms  Guideline # 2

• 2. Select a font color that is compatible with your
• background. It should be an easy combination to

read.

7

About Data-Entry Forms  Guideline # 3

• 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

About Data-Entry Forms  Guideline # 4

• 4. Never make the prompt more bold or larger than

the data entry. The data is more important than the prompt!

9

About Data-Entry Forms  Guideline # 5

• 5. Opt for font clarity over cuteness.

10

10

About Data-Entry Forms  Guideline # 6

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

11

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

About Data-Entry Forms  Guideline # 7 & 8

• 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

Would Be Better done With Two Columns!

13

About Data-Entry Forms  Guideline # 9

• 9. It is generally a good idea to align all prompts and

data horizontally. Many API’s have alignment tools to make this easier.

14

14

About Data-Entry Forms  Guideline # 10

• 10. It is not always possible, but try to avoid large

“void/blank” spaces in form.  Guideline # 1

15

About Data-Entry Forms  Guideline # 11

• 11. It is generally a 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

About Data-Entry Forms  Guideline # 12

• 12. It is generally a good idea to try to make the space

between rows consistent and not too large.

17

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

18

About Textbox Prompts  Guideline # 13

• 1. Every Prompt Should Be Clear & Concise

Supplier ID# Minimum Quantity To Stock

19

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

About Textbox Prompts  Guideline # 14

• 2. The Prompt Should Not End With A Colon (:).

21

About Textbox Prompts  Guideline # 15

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

Name Tom

Prompt Response TextBox

Name Tom

Prompt Response TextBox

22

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

23

About Controls  Guideline # 16

• 1. It is generally a good idea to left-justify the data

entry controls (textbox, radio button, drop-down list, checkbox, buttons, etc.)

24

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

25

About Textbox Prompts  Guideline # 17- #20

• 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

About Textbox Prompt  Guidelines # 21- #23

• 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

ID Field

Searching/Matching Numerics Is Much Faster Than Searching/Matching Strings!

28

Numeric ID  Guideline # 24

• 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

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

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

31

About Data-Entry Forms  Guideline # 25

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

About Data-Entry Forms  Guideline # 26

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

About Data-Entry Forms  Guideline # 27 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

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

35

About Data-Entry Forms  Guideline # 28 - #29

• 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

About Data-Entry Forms  Guideline # 30

• 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

About Data-Entry Forms  Guideline # 31

• 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

About Data-Entry Forms  Guideline # 32

• 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

About Data-Entry Forms  Guideline # 33

• 21. It is often a good idea to provide the user with a multi-

line 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

Wouldn’t a combo box,

• r 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?

About Data-Entry Forms  Guideline # 34

• 22. Use Drop-down Combo Boxes To Validate Data Entry

Selections Whenever Possible; This Will Help Reduce Data Entry Errors.

41

About Data-Entry Forms  Guideline # 35- #37

• 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

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

43

About Form Buttons/Menus  Guideline # 38

• 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

About Form Buttons/Menus  Guideline # 39

• 2. Button should generally be well organized in an orderly
• fashion. (Remember to frame the form). There will be

lots of possible options.

45

About Form Buttons/Menus  Guideline # 40- #41

• 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

About Form Buttons/Menus  Guideline # 42

• 5. We have found that menus on the right are not nearly

as effective as menus on the bottom.

47

About Form Buttons/Menus  Guideline # 43

• 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

About Form Buttons/Menus  Guideline # 44

• 8. Include mouse-over tool tips with graphical buttons.

49

About Form Buttons/Menus  Guideline # 45

• 9. The Navigation Buttons & Menus on all of the

forms in an application, or website, should have a common feel/style.

50

50

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

51

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

52

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

53

About Edit-Add-View  Guideline # 46

• 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

About Edit-Add-View  Guideline # 47

• 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

About Edit-Add-View  Guideline # 48

• 4. The Edit Mode (when either editing an existing record,
• r adding a new record) should be noticeably different.

I don’t recommend this color combination.

56

About Data-Entry Forms  Guideline # 49

• 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

About Data-Entry Forms  Guideline # 50

• 6. The Edit Mode should work with a copy of the data;

this way the user can Cancel without destroying the

• riginal data.

58

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

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

60

Navigation  Guideline # 51

• 1. Most of your High Level subsystems should have an
• ption for the “novice users” to scan through the data

with Next and Previous buttons.

61

Not An Acceptable Primary Navigation Form

Student View User Form: “User Suppose To Enter Any Info They Know – with tabs – when they hit ENTER Key Shows Users”

62

Goal: “No Manual & No Training” Great to have a Secondary Navigation Form that is Search-Oriented for Power Users!

62

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 &

• ptions!

63

Navigation Quick Links  Guideline # 52

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

Navigation Quick Links  Guideline # 53

We have 10,000 Users! Make it useful. “Divide & Conquer”

• 4. Most Sub-Systems should include Navigation Filters to

reduce data sets.

65

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

Navigation Filters  Guideline # 54 - #55

• 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

Navigation Filter Example

68

Order By  Guideline #56

• 7. Most Sub-Systems should take advantage of an Order

By combo box to provide logical order (as opposed to physical order).

69

Order By Example

70

High-Level Navigation  Guideline # 57

• 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

High-Level Navigation  Guideline # 58

• 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

High-Level Navigation  Guideline # 59

• 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

High-Level Navigation  Guideline # 60

• 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

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

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

78