Función trayecto de latencia

This is a major step in testing for the validity and suitability of the model. Developing a computerized version of the model is actually testing it. This is so, because the system itself was tested by the lecturers and students in actual settings. Feedback from both students and lecturers was then analyzed to prove the suitability of the model. In developing of the system, the Open Source Software – PHP, MySQL,

NetMeeting were used. The approach used in the development was the prototype approach, which allows gradually building of the system, and in conjunction/parallel with the model building phase. At the end of the system development, a heuristic evaluation of the software was conducted. Heuristic evaluation is one of the usability inspection methods that was used to evaluate the interface specifications and design (Nielsen, 1994a), and studies show that it is capable of discovering usability problems better than user testing sometimes; although it is similarly true vice versa (Nielsen, 1994a). The evaluation of the system is based on Nielsen‘s 10 usability principles: visibility of system status, match between system and the real world, user control and freedom, consistence and standards, error prevention, recognition rather than recall, flexibility and efficiency of use, aesthetic and minimalist design, help users recognize; diagnose; and recover from errors, and help and documentation (Nielsen, 1994b). Those principles are expanded into detailed criteria in the form of questions with answers as ‗yes‘, ‘no‘ or ‗n/a‘ by Xerox corporation. The heuristic evaluation form by Xerox (http://www.stcsig.org/usability/resources/toolkit/toolkit.html) was used to evaluate the system. However, it is too long as there are around 300 questions/criteria to be checked. After the discussion with the supervisor and with the software engineering professionals, it has been suggested to reduce the total number of questions/criteria, to make the evaluator‘s task manageable without affecting the overall theme. The original form was given to the supervisor for feedback and comments. The simplification was carried out by the researcher and a software engineering professional- who has knowledge about the system developed by the researcher. The task was carried out individually by both the researcher and the software engineer. Each simplified forms have been exchanged from either party to compare their work with one another. Then a joint session/meeting was arranged to reach an agreement on what to be taken out. The agreed upon simplified list was then given to the supervisor

for the final approval. The final form consists of ten (10) sections, as shown in Table 3.3. The complete list that has been used in the evaluation can be found in Appendix A.

Table 3.3: Usability Principles

Principle Description # of

questions 1) Visibility of

System Status

The system should always keep user informed about what is going on, through appropriate feedback within reasonable time.

11

2) Match Between System and the Real World

The system should speak the user‘s language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

7

3) User Control and Freedom

Users should be free to select and sequence tasks (when appropriate), rather than having the system does this for them. Users often choose system functions by mistake and will need a clearly marked ―emergency exit‖ to leave the unwanted state without having to go through an extended dialogue. Users should make their own decisions (with clear information) regarding the costs of exiting current work. The system should support undo and redo.

6

4) Consistency and Standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

20 5) Help Users Recognize, Diagnose, and Recover From Errors

Error messages should be expressed in plain language (NO CODES).

10

6) Error Prevention Even better than good error messages, it is a careful design which prevents a problem from occurring in the first place.

6

7) Recognition Rather Than Recall

Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

18

8) Flexibility and Minimalist Design

Accelerators-unseen by the novice user-may often speed up the interactions for the expert users such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Provide alternative means of access and operation for users who differ from the ―average‖ user (e.g., physical or cognitive ability, culture, language, etc.)

6

Source: Nielsen (1994b), ten usability heuristics. Retrieved from http://www.useit.com/papers/heuristic/heuristic_list.html

Table 3.3, Continue Principle Description # of questions 9) Aesthetic and Minimalist Design

Dialogues should not contain information, which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

8

10) Help and Documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user‘s task, list concrete steps to be carried out, and not be too large.

10

Nielsen (1994c) suggests using between three and five evaluators. Having more evaluators would be good, but depends on the cost-benefit analysis; and recommended only if usability is an important issue (Nielsen, 1994c). The evaluation request was originally sent to fourteen (14) experts. Nine of the fourteen experts responded and completed the evaluation. The evaluators were given the evaluation form and the link to the system. They were asked to visit the system website, create their own accounts as lecturers and students, and browse the system as well as try it out by themselves. This is based on Nielsen (1994c) recommendation that when the evaluators are domain experts; it is possible to let them do it themselves. However, a very brief description was given to them, and one of them asked for a demonstration of the system by the researcher before engaging in the evaluation. The evaluators were asked to fill in the evaluation form after they have finish browsing and using the system, and then email it back to the researcher. The individual evaluation results were combined to identify usability problems. This is in line with what Nielson (1994a) suggests for heuristic evaluation as it is to be carried out individually; then reports are combined to find out the usability problems.

The result of the evaluation revealed that the system usability is high, with 78% of the criteria being met i.e. 77% answers were ‗yes‘, 16% ‗no‘, and 7% of the answers were ‗not applicable‘. If the ‗not applicable‘ answers are not considered, then we will get 83% ‗yes‘ and 17% ‗no‘ answers. Details of the analysis are presented later in chapter

five (5). Once this task is completed, the new system was uploaded to the website. By completing the upload and setup of the system, it was finally ready to be used/ tested by lecturers and students. This takes us to the next sub-phase.