System Walkthough / Heuristic Evaluation by Andy Bennett ======================================================== + Simple and natural dialog + Simple means no irrelevant or rarely used information When the interface is initially presented, it appears to be clear and simple. The interface shows simple details for all the meetings scheduled and instructions on how to proceed with various tasks. + Natural means an order that matches the task The interface appears to contain all of the features that you might expect from a Windows application. e.g. Menus, buttons, etc. However, certain actions do not work as might be expected. For example, it is not possible to double click on meetings for more information. Neither is possible to sort the list of meetings by clicking on the headings in the table. Although the wizard provided is functional and simple, it does not follow the standard layout for wizards in the Windows environment. It may also make more sense to describe the meeting with a title before choosing a date and time for it. Common keyboard shortcuts, such as the use of the ESC key to cancel the current dialog box are not available. The interface does however provide its own shortcuts which are marked on the push buttons in the standard way. The interface exhibits some appropriate use of group boxes, such as to contain the instructions, and some inappropriate use, such as to contain the "Send meeting reminders" radio buttons. The "Send meeting reminders" use of a group box is inappropriate because the meeting reminder options are not also contained within the group box. Everything concerning the meeting reminders should be contained within this group box. It is also the opinion of the author that "Scheduled Meetings" should be another group box that surrounds the appropriate controls, rather than a floating label. This is because if some information displayed on the screen belongs to several categories then a group box should be used for each category. A similar argument applies to the controls presented on the "Address Book" tab and the "Create New Meeting" dialog. The argument is not as strong for the "Amend Meeting Details" dialog because there is no use of group boxes at all. It is generally expected that information presented in edit boxes should be editable by the user. The Club Member details on the "Address Book" tab are presented in read only edit boxes and it is necessary to invoke a further dialog in order to get the information presented in writable edit boxes. This could be confusing to inexperienced users because both types of edit box look the same. + Speak the user’s language + Use concepts from the user’s world The application has a direct mapping to the objects in the users world. The interface talks about "meetings" and "club members". The application does not provide any facility to schedule repetitive meetings. + Don’t use system-specific engineering terms The user is never presented with any of the internal structure of the data and no technical jargon is used to explain concepts. + Minimise user memory load + Don’t make users remember things from one action to the next With the exception of the wizard, all information regarding a particular task is shown on the screen simultaneously so user memory is not a problem. The wizard progresses in a fairly sensible manner, and subsequent actions do not rely on previous decisions. If the user forgets to add all the club members to the addess book before scheduling a meeting, it is possible to add them "on the fly" in both the wizard and the "Meeting Options" dialog box. i.e. it is not necessary to back out and have to reenter all the details in order to add a new member. After creating a meeting it is not possible to recall the attendees or change them. However, the system does inform all the attendees if a meeting is cancelled and it can track the numbers that have replied. Therefore in order to change the attendee list the user must delete and recreate the meeting. This would involve remembering the original attendee list. + Leave information on the screen until it is no longer needed The wizard should recap all of the information entered before going ahead and creating the meeting. This would give the user the opportunity to detect and correct mistakes. At the moment, all the wizard does is confirm, with a popup box, that the user does actually want to finish but it does not provide any information on which to base this decision. + Be consistent + Action sequences learned in one part of the system should apply in other parts Attempts have clearly been made in order to provide a common "look and feel" across most parts of the interface. For example, the screens shown on the wizard are copies of the relevant parts of the "Meeting Options" dialog. However, some things are subtly different. The order of the push buttons on the "Meeting Schedule" tab is New, Cancel, Amend. However, the order of the corresponding three buttons on the "Address Book" tab is Add, Edit, Delete. Further more, the terminology used for similar actions should be the same. i.e. one should "create a new entry in the meeting schedule" and "create a new entry in the address book", rather than "creating a new meeting" and "adding a new member". Also, the wizard and the "Meeting Options" dialog do not correlate with respect to the attendee selection method. The method presented in the wizard is the traditional way of performing the action and allows you to clearly see both the people available for selection and the people already selected, whereas the method presented in the "Meeting Options" dialog allows the user to select the attendees "in situ." This saves space but makes it difficult to gain insight into the people who have already been selected. + Provide feedback + Let users know what effect their actions have on the system The interface includes a large number of popup boxes that inform the user about what is about to happen or what is about to happen. When appropriate, the user is presented with the opportunity to change their mind. + Provide clearly marked exits + If users get into a part of the system that doesn’t interest them, they should be able to get out quickly without damaging anything It is possible to exit from any dialog, including any step of the wizard, with the exit buttons provided. However, it is not possible to use the ESC key anywhere in the interface. However, in the wizard the exit button is situated on the right and in the other dialogs it is found on the left. + Provide short cuts + Help experienced users avoid lengthy dialogs and informational messages they don’t need The interface provides keyboard shortcuts for all of the push buttons. The interface also discriminates between novice users and more advanced users by providing a wizard. + Good error messages + Let the user know what the problem is and how to correct it The interface tends to disable "OK" buttons if the data entered by the user is not acceptable. The user can find out what is required by reading the instructions presented. The instructions change as the user progresses through all of the fields on the screen. In the event of an unavoidable error, such as an attempt to delete a nonexistent meeting the nature of the error is explained clearly. + Prevent errors + Whenever you discover an error message, ask if that error could have been prevented The interface is designed in such as way as to prevent the transpiration of error messages by insuring that the user enters the data correctly before allowing them to confirm the dialog. It would be possible to prevent users from trying to delete nonexistent meetings by not allowing them to select them in the first place. This could be accomplished by removing spare rows in the "Scheduled Meetings" table.