|
Gery (1991) talks about the historical movement of training away from reality and into a virtual environment, where 'training (but not job learning) became an event conducted in a classroom with images on overhead transparencies representing reality.' This was certainly the case in 1991 when Gery wrote her book. I can myself recall teaching compressed air brake air drier systems entirely theoretically because we did not have an example of a system to show the students. The topic was in the syllabus and it had to be covered. The students could not see the real components nor could they practice any skills. They had to be satisfied with the reality of coloured lines on a sheet of acetate.
Things have changed in recent times with the advent of competency based training and the requirement that students perform tasks to a competent standard on real equipment. This has certainly moved the pendulum back towards training within the reality of competencies which are performed on the job. However, these competencies are still performed within the artificial environment of a college and are generic in nature, not specific. Students are required to be able to apply these skills in the workplace. They have to apply the skills of using the spreadsheet they learned at college to that of using the spreadsheet preferred by the employer. They have to apply the skills of repairing the Ford engine they worked on at college to that of repairing the Holden engine the employer wants them to work on. There has been nothing historically wrong with this, after all it is the basis of most technical and further education. However, in an increasingly complex and technically demanding working environment is it still appropriate?
Gery (1991) comments 'many jobs today have become more complex, involve more variables, and require more analysis, synthesis, and interpretation in increasingly diverse contexts.' In this situation does the average course provide the average student with the skills required for the workplace? If they are competent in the generic skills provided by a course of study will they be competent in the more specific and complex tasks demanded in the workplace? The answer may well be that while they are not immediately competent it is hoped they soon will be by virtue of the transfer of knowledge and skills.
The next question that arises is to ask if mere competency is sufficient? Gery thinks not. She suggests that mastery is the goal that quality and benchmarking programs aim for. That the marketplace is demanding more than just the competence to take off and land. It wants the mastery that is demonstrated by aerial acrobatics. This scouring of the marketplace for high flying ability is illustrated by one of my clients who has initiated a preferred provider program for training providers. Those who have demonstrated the ability to meet specific criteria are signed up and get first choice of supplying training to meet company requirements. The merely competent training provider is left to fly a kite.
The solution according to Gery (1991) is not to provide more training or even smarter training in the form of Computer Aided Learning. The solution is to provide 'on demand access to all of' the resources individuals need to solve a problem, perform a task or - some day - to do an entire job.' This is what Gery refers to as 'living in the performance zone'.
Gery (1995) more recently has put forward the notion of Performance Centred Design which represents the evolution of performance support from an add on extra to total integration with the design of software. Some of the examples which are given include Microsoft Publisher and Quickbooks by Intuit. Her recent work has also included the development of nineteen attributes of an EPSS. This includes such things as 'Provide contextual feedback', No 11 and 'Automate tasks', No 15. These provide a very useful framework for a design methodology.
Most of these considerations focus on the system itself, how to provide information, structures and mechanisms by which information can be organised, design of the GUI, use of databases, etc. But what about the human attributes of performance which these systems are supposed to enhance? A closer look at these attributes may help us to design a better system. Gary Dickelman (1995) exhorts us to refer to the work of Donald Norman (1993) who has looked at these attributes and has some very interesting things to say. Although Norman does not write specifically about EPSS his work on 'human attributes in the age of the machine', could be useful in the design of an EPSS.
Norman's view is that the computer screen is a virtual environment made up of artefacts placed there by the designer. Performance is a function of how well these artefacts represent reality. Good design would focus on three principles.
Personally, I am very excited about the potential of a system which can enable us to live in the 'performance zone'. Professionally, I am numbed by the enormity of the task. However, I am not daunted by it. The challenge of an EPSS is not just to provide information but to fit it tightly around the context of the performance problem.
The best way to test a theory is to put it into practice. Recently I had the opportunity to do this for a client in the 'real' world of the mining industry who had a 'real' performance problem. I will proceed by describing how I applied some of the principles already discussed to the design of an EPSS.
There were several reasons for this decision.
Once a decision was taken to use an EPSS the following goal was established.
To provide graphic, textual and animated information of the operation and testing of the hydraulic circuits on a Hitachi EX3500 that will assist a tradesperson in performing testing and adjustment procedures to manufacturers specifications.It was also decided to centre the design criteria around the nineteen attributes of an EPSS as described by Gery (1995). While it was realised that it may not be possible to incorporate all of these attributes it was decided that they represented best practice and worthy of emulation. These attributes are as follows:
Even though the design criteria provides a focus for development it does not provide a methodology. The question was wether to use an existing Computer Aided Learning (CAL) methodology as developed by the likes of Alessi & Trollip (1991) or maybe a totally different methodology was appropriate. The elements of CAL are similar to the elements of an EPSS, graphics, hypertext, video, animation and sound. From this point of view a traditional methodology of analysis, design, development and evaluation would be appropriate. Gery (1991) makes the comment that 'EPSS is a concept not a technology. It takes advantage of whatever technologies are appropriate.... It is therefore difficult to define a detailed development methodology for EPSS'. Gery does however, provide some guidelines for establishing a methodology.
From my point of view there are important differences between CAL and EPSS which have to be considered.
The established goal is set out above and was able to be met quite successfully. From this point of view the goal was neither ambitious or cautious, it fitted the needs and was achieved within budget.
As far as user goals are concerned it was decided that these referred to troubleshooting. How the user determines these goals is discussed in more detail below.
The attributes of each technology and the information it can contain need to be well understood. For example why use video of an inanimate object when a still image can provide the same information.
For our project the selection of suitable technology was important from a budgetary point of view and careful analysis of technology attributes enabled a focus on user needs to be maintained. There is also the consideration that the selection of a particular technology will require necessary human resources to be able to use that technology. There is no point in selecting virtual reality if the skills required for the development of virtual reality are not available within the team or the budget cannot stretch to employing a consultant.
For our project we stayed within the boundaries of the physical and human resources that were available.
Whilst learning the content was not particularly difficult it was found that obtaining the necessary detail was more difficult than anticipated. With an EPSS getting the details right was most important. In many cases the service literature did not supply such detail and it was necessary to actually perform many of the tasks to ensure that procedures were correct.
Ideas which came out for the original design included
Identify all hydraulic components on the machine
The use of captured video frames saved as bitmaps provided the basis of the information for this task. Being able to identify components meant being able to see them so graphic information was essential. A bitmap identifying the component is provided together with a short description of what the component is, where it can be found, its function and some information on its operation. Attributes 5 and 6.
A 'Content Selection' combo box in the bottom left corner of the screen provides a pop-up list from which any component can be selected. Attribute 8.
Carry out scheduled oil sampling and routine servicing
This mainly required a table of information with servicing intervals, filter types and oil types. Information on how to take an oil sample was provided in other screens. Attribute 5.
Describe the function and relation of all hydraulic components in each circuit from symbolic diagrams
Because of the complexity of the hydraulic circuits it was decided to use a composite block diagram showing the relationship of all components and thereafter to show individual circuits separately. This worked well in reducing the confusion factor associated with complex diagrams and also allowed hot spots to be placed on the diagrams which are associated with popup text. This increased the amount of information available to the user but was embedded in the screen and only visible if selected. Attribute 5.
Figure 1 shows a screen from the 'Circuits' topic. This is the composite diagram. As the user moves the cursor over the screen it will change to a hand when it encounters a hot spot. At the same time the name of the component will be shown on the status bar at the bottom of the screen. If the user clicks on the hot spot a pop-up text box will appear providing a description of the component.
Figure 1 shows a standard screen layout for the EPSS. It contains a 'Contents Selection' combo box which provides hyperlinks to other parts of the program. It also contains a 'Description of Terms' combo box which provides a glossary. First page, last page and page forward or back buttons are provided within each topic and the page number is also indicated. A 'Main Menu' button is provided on every screen. Attributes 5, 13, 16 and 19.
Figure 1: Standard screen layout
Describe the operation of undercarriage circuits
Describe the operation of front attachment circuits
Describe the operation of swing circuits
Describe the operation of pilot circuits
Describe the operation of travel circuits
These five tasks all required a similar treatment. Each required a detailed explanation of circuit operation. Tasks a) and c) provided an introductory overview to the inter-relatedness of components and circuits whereas these five tasks, d) to h), would have to provide substantive detail. For this purpose hydraulic symbols would be necessary and animation of those symbols would clearly show circuit operation. Attributes 5 and 8.
In order to connect the operational information to the test information hyperlinks are provided to those parts of the EPSS where these tests are described. Attribute 5, 12 and 18.
Describe the procedure for carrying out individual hydraulic circuit pressure tests.
There are many pressure tests which can be carried out on the hydraulic system to determine if pressure settings are normal. The intention here was to provide the user with a list of tooling required for the test, specification data, a description of the procedure and a diagram showing where the pressure gauge had to be connected. Attribute 3, 5, 7, 18.
Once again the 'Contents Selection' combo box can be used to directly select information on any pressure test which can be carried out on the machine. Attribute 12.
Describe the procedures for carrying out implement performance tests.
This task is similar to i) and the same approach was used. For example the No-Load Travel Speed screen from the 'Performance Standards' topic shows a bitmap of how the machine should be positioned for the test and a button under the bitmap allows the specifications to be displayed. Attribute 12.
Accurately diagnose faults using a logical troubleshooting procedure
This was a crucial part of the EPSS and deciding how to structure the information required careful analysis of what the user would need. After studying troubleshooting principles put forward by Kepner Tregoe (1985) it was decided that the user need could be characterised by the question, 'Given these fault conditions what should I do'? From this a troubleshooting adviser was designed which will allow the user to select fault conditions and then enter a phase of testing where certain tests are advised, the results of which can be expressed as yes or no. This will allow a successive phase of branching until all tests have been exhausted and the fault identified.
For example if the user selects, 'The machine will not travel', as the fault, one of the tests would be to test the travel speed control pressure. Instructions on how to carry out the test would be offered, if required, an t e question, 'Is the travel speed control pressure within specification', would be asked. The yes or no answer will then branch the user to the next part of the test sequence. This process would continue until the adviser is able to suggest a cause of the fault. Attributes 2, 3, 5, 6, 7, 9, 12, 15, 16 and 18.
This part of the EPSS is still under development and has proven to be the most difficult to construct. However, early trials have suggested that it does indeed meet the need for which it was developed.
Topics can be selected as the user requires since the user may already possess some knowledge of system operation and testing procedures. The user may prefer to investigate the problem using their own logic and prior learning instead of relying on the troubleshooting adviser. In this sense the user has total control over the selection and use of information.
This aspect is designed to reflect the needs of the user in going about the task of finding a fault. The interface is simple and direct, it is also hoped that it is intuitive.
Feedback from users has indicated that the EPSS has more than fulfilled the need for which it was designed. It has become the first point of reference for supervisors and tradespersons. It has also been installed on a notebook computer which is taken out to the machine whenever a hydraulic problem is encountered. This is very satisfying and has given me some confidence in looking at ways in which the EPSS can be further improved.
I think that the original decision to use an EPSS as an enhancement of the training program has been justified. It has been used throughout the training program as well as subsequent to it and has become as much a tool as a pressure gauge in the diagnosis and repair of hydraulic system problems. It is the complete acceptance of the EPSS as an integral part of the toolkit which is most pleasing.
When I reflect upon the genesis of the EPSS I am aware that it was not only born of the stated goal at the beginning of this paper but also of a goal given by Gery (1991) which states, The goal of an electronic performance support system is to provide whatever is necessary to generate performance and learning at the moment of need.' My efforts in this direction have produced something which is useable and is being used to support performance. However, I am conscious that there is some distance to go before we can say that we have provided 'whatever is necessary' at the 'moment of need'.
Dickelman, J. D. (1995). Things that help us perform: Commentary on ideas from Donald A. Norman. Performance Improvement Quarterly, 8(1), Special edition published on the Internet by Learning Systems Institute, Florida State University.
Gery, G. J. (1991). Electronic Performance Support Systems. Boston: Weingarten Publications.
Gery, G. J. (1995). Attributes and behaviours of performance-centred systems. Performance Improvement Quarterly, 8(1), Special edition published on the Internet by Learning Systems Institute, Florida State University.
Kepner-Tregoe. (1978). Analytic Trouble Shooting. New Jersey: Princeton Research Press.
Norman. D. A. (1993). Things that make us smart - Defending human attributes in the age of the machine. Reading, MA: Addison-Wesley.
| Author: Allan Briggs Central Queensland Institute of TAFE Rockhampton College Locked Mail Bag 8065 Rockhampton Queensland 4700 Telephone: (079) 314 615 Fax: (079) 223 756 Email: abriggs@deakin.edu.au Please cite as: Briggs, A. (1996). Multimedia performance support systems for industry. In C. McBeath and R. Atkinson (Eds), Proceedings of the Third International Interactive Multimedia Symposium, 73-79. Perth, Western Australia, 21-25 January. Promaco Conventions. http://www.aset.org.au/confs/iims/1996/ad/briggs.html |