Requirements: using methods, functions, procedures, actions, conditions and control structures effectively, checking input data for validity, input from a user, user-defined methods, functions or procedures.
This group of pages can be used to add polish to the module AS 91883Develop a computer program but its main goal is to lay down the foundation for the requirements of AS91886 Demonstrate understanding of human computer interaction.
There is a limit to how much we can add to the usability of a programme as we are still in the early stages of learning the skill of programming. However there are still some basic types of human error that we can prevent, and we shall be looking at that in these pages.
We shall begin by looking at a program with no consideration for human interface to see what errors can creep into such a program. We can then look at how some of those errors can be prevented.
For our guidance we shall be using some of the ten heuristics originally developed by Jakob Nielsen in the mid 1990's. The ones we shall be using are:
#1: Visibility of system status: The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.
#2: Match between system and the real world: The design should speak the users' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order.
#5 Error prevention: Good error messages are important, but the best designs carefully prevent problems from occurring in the first place.
#6 Recognition rather than recall. Minimize the user's memory load by making elements, actions, and options visible.
#9 Help users recognize, diagnose, and recover from errors. Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution.
Below is a simple payroll calculation program with minimum fucntionality. Despite this we can see that some of the heuristics mentioned above can be found here.
Lines 11 to 13 allow the user to enter data. At each line the input prompt specifies what data is expected and what range of values are expected for each input. This is stated in clear simple language that any payroll officer would underatand. Thus heuristic #2 is satisfied.
The same prompts also satisfy heuristic #6 because they all specify the allowed values for each item. This saves the user from having to remember such data.
Let us now look at some of the output of the program and determine where we are failing the user as regards the five heuristics mentioned above.
In the first running correct data has been entered. The value for the hours, 20, is between the limits 5 and 60. The value for rate is similarly between its own limits. Also the superannuation code has a value of 2, which is one of the four values allowed.
In the second running the values for hours and rate are still fine. The value of the super code is 5, which is outside of the given range. An error message has been printed but the program still went ahead and calculated the rest of the payroll data.
In the third running, all of the user inputs are outside the allowed ranges, but the invalid data was processed and saved to the file.
Discussion on Heuristic #1: Visibility of system status
Since we are dealing with a very simple program here, there is a limit on the interaction that we shall have with the underlying system. The sole exception in this case is saving data to a text file.
This is a very fast and silent process and therefore it happens without us noticing it. As saving data regularly is crucial to any application we must ensure that the user is always made aware if each saving to the text file. This is done by simply printing a message 'Data has been saved to the file'.
As applies to our example program here the requirements of Heuristic #1 have been met.
Discussion on Heuristic #2 Match between system and the real world
In lines 11 to 13 we have communicated with the user in jargon free everyday language. We have described the type and purpose of each data item. We have also described the maximum and minimum values associated with each data item.
Within the limitations of our example program here the requirements of Heuristic #2 have been met.
Discussion on Heuristic #6: Recognition rather than recall
If we assume a data entry person is entering data for a number of employees and is reading the data from a printout. There is always a chance that the person who produced the printout may have accidentally left out a digit or added an extra digit to a person's hourly rate. This could have the effect of changing $24 to $2 or else changing it upwards to $244. For the data entry person to spot this then they would need to know the maximum and minimum values allowed for the hourly rate. Rather than having to search their memories or go through a volumnious journal we use the input prompt to remind them what those maximum and minimum values are. For this reason each of the prompts has its own set of minimum and maximum values.
Within the limitations of our example program here the requirements of Heuristic #6 have been met.
Although our program is as simple and basic as a program can be we still have managed to apply three of our proposed five heuristics to it. This included informing the user whenever data is saved to the file and using plain everyday language when communicating with the user.
Looking at Fig 1 above we see that we have some distance to go yet to improve the user interface so that out of range data will be blocked from the user. On the next page we shall look at how that can be done.