Robot Prototype Design Principles

The Robot Prototype is designed to test the user knowledge in term of understanding the task requirements to be performed. It tests the user in terms of the reaction, which may conclude if the user found enough information in the interface to deal with requirement.

Three Prototypes are generated to test the user performance. The first Prototype (Prototype 1) is a command line prototype which is, an interface showing the user the relative position of the cave walls (up, down, left or right) and requiring the user to take action to move the Robot to avoid colliding with it. The second Prototype (Prototype 2) interface shows the user the relative position of the Robot and gives instructions how to avoid the cave walls. The third Prototype (Prototype 3) is a graphical interface, which shows the user picture of the relative position of the Robot and the cave wall and gives instructions on how to act on it.

Design Principles and Rules

Design principles are high level of recommendations based on well knowledge about human behaviour. Some of these principles are that ‘know the user population’; which can be difficult to achieve, especially when a diverse population of users has to be accommodated or when the user population can only be anticipated in general term. Knowing the user include being sympathetic to different user needs by, providing program shortcut and promoting the ‘personal worth’ of individual by allowing user to perform tasks in more than one way. Achievement of this principle in the Robot Prototype is by creating a menu of three Prototypes in one program and made the user to choose shortcut to play Prototype 1 to 3, which allow the user to perform task in more than one way.

The second principle is ‘reducing the cognitive load’, which concerns designing so that users do not have to remember large amount of details to follow. This is achieved in the Prototype by reminding the user about the keys if wrong key pressed (e.g. message used ‘Oops, you crashed’).

The third principle is ‘engineer for error’, which concerns to provide the user with a good error massage which allows the users to correct their errors and provides a large number of explicit diagnostics. This has been performed in the Prototype by outputting error massages if the user presses a key which is not part of the command keys.

A design rule is an instruction that can be obeyed with minimal filing out and interpretation by the designer. For example, to play the Prototype 2, 4, 6 and 8 keys should be used.

The visibility principle:

Relevant data and functionality ought to be as visible as possible to a tool user. This principle is predicated on the assumption that the human capacity for recognition is more powerful than recall [Preece 94, pp. 118-121]. The programmers in our studies experienced severe visibility problems due to the proliferation of windows and hidden functionality. Unfortunately, much of the visibility problem is inherent in the task: a star diagram planning tool is intended to help programmers to discover relationships amongst syntactically separated pieces of code. Because there is no restructuring engine, the programmer must also revisit all of these related program locations in order to carry out the actual restructuring changes. Other visibility problems were due to design. For example, on tool start-up only a tool bar was displayed. Each button on the bar invoked a pop-up window that was responsible for some aspect of the tool’s high-level operation.

The consistency principle:

Things that are similar should look similar, and things that are different should look different [Brown 88, pp. 9, 21-24, 32, 101]. When successfully applied, a user interface is easier to understand because the user can reliably respond to visual cues of similarity and difference in the interface, aiding recall and also the ability to guess how unfamiliar parts of the tool might behave when used. The problem with dismissing windows is a prime example of inconsistency in CStar. The challenge in applying the consistency principle lies in making decisions about what “typical” tool users will judge to be similar, and what they will judge to be different.

The clear and concise language principle:

Names or images given to functions and displayed data should be easy to understand without cluttering the interface [Brown 88, pp. 21-24].

The streamlined scenarios principle:

Common patterns of work should be recognized and then streamlined to avoid awkward interactions such as repetitive clicking or keyboard entry [Carroll 91, pp. 293-5]. Repetition leads to fatigue, mistakes, wasted time, and forgetting of key information. However, streamlining should not increase the number of ways to carry out a task, which can confuse the user. In the programmer study, programmers had to select a node and perform two pull down selections to trim an arm, a relatively common activity.

Graphical User Interface (GUI) Design

Graphical User Interface is a program interface that takes advantage of the computer graphics capabilities to make the program easier to use. A well-designed graphical user interface can free the user from learning complex command languages. On the other hand, many users find that they work more effectively with a command-driven interface, especially if they already know the command language.

The GUI design represents the Robot and the cave walls and is designed to give the users overall knowledge of the Prototype and what they expect. This Prototype becomes easy and user friendly when the user has a variety of options, e.g. the decision of how many players want to play the Prototype, and what Prototype they want to play etc.

The algorithm which will be used to implement the prototype program will be as follows:

Packages random, system, calendar

Start

Read system time (in seconds)

While not count completed

Generate random position

Display position

Wait for response

Score accuracy

Count ++

Read system time

Calculate average time

Write to screen

Measure average time

Combine results from different users

Take user suggestions

Principles of HCI (by Sutcliffe)

* consistency

* compatibility

* adaptability

* economy

* guidance not control

* structure

Interaction types

* menu selection

* command languages

* direct manipulation

Task Analysis

The task analysis diagram of this Prototype would looks like this:

Select

If ‘Yes’ If ‘No’

The task analysis is the process of investigating a problem by breaking down tasks that potential user of a system do or would do into sequences of actions and objects. The above diagram shows the stages a user will have to go through before he/she can actually start playing the Prototype. The reason why the structure is important is to make sure the user is comfortable and safe when he/she is playing, the environment is enjoyable and all the user requirements are met.

To play the Prototype user will get two options: Yes or No from the Playing Options menu.

Playing Options Menu

The controls which an operator is to use will not be chosen. Keyboard is the main data entry device which will be used in the Robot Prototype. A keyboard is good for fast data entry and extensive data entry. It does have some limited pointing capabilities e.g. cursor keys, but the cost of a keyboard is cheap.

Other input devices in comparison to the keyboard, do not function appropriately for this prototype program, such as a mouse, touch screen and a joystick. A mouse is a pointing device, which carries out some simple actions it is good for the intuitive point of device, which fits comfortably with human capacity. Despite it being cheap, it is not suitable for our program as data is required for input. Touch screen allows the user to input information into the computer simply by touching an appropriate part of the screen but due to resource constraints this will not be used. A Joystick operates in two dimensions and is often used for task where a direction and speed is to be indicated, rather than a location so again, it will not be correct input device at this occasion.

Users will be given the actual specification of the Prototype and will also be explained how to play any one of the three Prototypes through instructions about the Prototype and the required keys to use. This will guide the users to play the Prototype successfully.

Users will have the option to choose which Prototype they would like to play. The description of each Prototype will be provided from where the user can decide which Prototype they want to play. When the user has chosen which Prototype they would like to play the instructions to play the Prototype will be given.

Select Prototype Menu

In Prototype One, the interface will prompt the relative position of the obstacle requiring user decisions to be made and will not be informed how to avoid it. In Prototype Two, the interface will prompt the user of the relative position of the Robot and also instruct the user what moves to make. In Prototype Three, the user will be shown the obstacle and the Robot through graphical interface and will also be informed what move to make.

Users will be provided with training. Before they can be tested, they will be able to operate prototype one together with my help. This will ensure that the users are a bit familiar with the interface. The consistency principle has been applied to three of the prototypes. The instructions and layout of rules are kept consistent which will be useful to the user and make the prototype easier to operate whether it’s one, two or three.

To conclude, from the feedback of the task analysis that the users overall thought that the changes made improved the Prototype and made it more efficient and user friendly. They were satisfied with the layout of the menus and how the suggestions they made were used to improve the overall Prototype structure. Finally although there were not significant changes made to Prototype but by just improving the user interface has given the Prototype a complete different response from the users. Due to shortage of time no graphics were imputed in the Menus as requested by the users.

Evaluation of the Prototype

Evaluation is a process through which information about the usability of a system is gathered in order to improve the system or to assess a completed interface. One way to this is to collect information from the users, build the prototype, show the prototype to the user and make changes to prototype and so on. The prototype should go around in a cycle where the interface is evaluated, adapted, changed, enhanced and then interface goes around again. When all’s said and done, the target is to get a good clarity and usability.

Clarity is dependent on the users understanding of the task and usability is the user satisfaction and performance. These are linked, if the user is comfortable with the interface then they will find it easy to understand and use.

According to the clarity evaluation 100 % of the users suggested that the clarity of the prototype is very helpful for them, which suggested that the interface is effective and allowed the user to operate the prototype with a clear understanding of what is purpose of the prototype.

75% of the tester found prototype 2 the easiest to operate. This is mainly due to the fact that the instructions provided were very clear. The layout of the instructions was easily readable. 25% of the users found prototype 3 the easiest to operate. This is due to the fact that graphics were used, as the user was able to visual the Robot, which made the selection of the movement easy.

The layout of the instructions in prototype 3 was not as clear as in prototype 2 which was the main reason why the 75% of the users found prototype 2 easier. The users did not use just the graphics, they were relying on the instructions provided as well as the graphics in order to operate the prototype efficiently but due to the layout of the instructions, they did not respond as quickly as expected.

In the refinement of the prototype the other two prototypes have to be modified perhaps including sound effects and better graphics in order to make the prototypes more enjoyable.

25% thought there was a need to improve the graphics, especially the graphical representation of the Robot. It was suggested that the graphics of the Robot should be made smaller in size. However, due to feasibility constraints I will be unable to meet 100% of the users’ requirements. Therefore a compromise has to be reached.

All the users were satisfied with the number of menus used in the prototypes. They did not create any confusion for the users. The interface was found user friendly by all users.

The users found the numeric keypad quite awkward to use. The key to deploy lasers and emergency button confused the users. It was said that due to the fact that the keys were so close to each other, it was hard to maintain speed and accuracy at the same time which resulted in more collisions. 25% made a suggestion that they would prefer the first letters taken from making them semantically correct. E.g. R = Right, L = Left, U = Up and D = Down. For user requirements, they keys to operate the Robot should be re-considered.

All the users operated in a safe and a comfortable environment, which means that the ergonomics environment suited the task. This fact would have aided in the overall interface in being effective and efficient even though the lack of an effective command set would have had an adverse effect.