Evaluation: Heuristic Evaluation

Adapted Generic principles for heuristic evaluation:

1. Feedback: The child should be aware of what is happening.
2. Everyday child language: Use language that a child would be comfortable with.
3. Consistency: Responses should be the same when similar options are selected by the child and it should share conventions currently in use.
4. Recognition not recall: The child should be able to recognise what they should/can do at a particular step.
5. Simple design: Keep things crisp and simple and aesthetically pleasing.
6. Error recovery: Prevent errors from occurring, but if they do, provide a suitable response and an appropriate solution.
7. Documentation: Any documentation should be simple and concise, as a child will not read it.

General scope of the system:

The system displays a 'scanning' message when the Scan button is pressed. This feedback makes it obvious what is happening. Perhaps a prompt is needed after the word is scanned so the child realises that they can now select the functions that interests them.

The language the system uses is simple and easy to understand for children between 7 and 11, which is especially important for the Dictionary definitions and the Thesaurus entries.

Everytime a word is scanned, the options in the menu remain the same. This ensures that the system is consistant. The system also shares conventions found in devices such as pocket translators/personal organisers and mobile phones, where you scroll through the menus.

As I mentioned under feedback, after a word is scanned the system should prompt the user to select a menu or make it clear that is what is required next. However, due to the system's consistancy and simple design, the next step is easy to recognise.

The word scanner provides only two input controls, namely the scan button and the clickable scroll wheel. This makes interaction simple. The design of the menus is also crisp and simple, avoiding any unecessary clutter.

The system displays an error message when a word failed to scan and also tells the user what to do next, so that they can recover from what they did.

The documentation is short and concise and should only really be required when the user first attempts to scan a word.


Specific interface elements:

The system should prompt the user to select one of the menu options after a scan.

On the menu, the words Dictionary and Thesaurus are ambiguous, they suggest that by clicking them you will be presented with a full system of words/definitions/entries, but this is not the case. They need to be made more specific like Dictionary definition and Thesaurus entries.

Principles from Russell's list that we eliminated:

Undo: The team decided to eliminate this principle. For the word scanner a possible undo function could have be provided for when the user clicks scan after scanning a word, thus losing the word from the device. However, the time it takes to rescan a word is trivial and so the function is not required and for children, adding it may make things more complicated.

Expert use: The word scanner does not have any place for shortcuts or accelerators of any kind, due to the simple scroll interface that the team designed.

Questionnaire Analysis

The questionnaires filled in by our target audience flagged up a few issues with our initial design.

One of the more important and serious points that was rasied was usage by left-handed people.
Currently the whole device is designed to be used in the right hand, but this could be a problem for approximately 12% of the population. We need to look into developing either 2 different devices, or 1 that is somehow usable by both groups of people.

The test subjects also commented that the size of the device could be increased, both to provide a larger, more readable screen, and also for ergonomic reasons.
The device was reported to be quite "square" and therefore more difficult to hold than it could be if it had added grips or curves. A suggestion would be to "mould" the device around the natural curves of the hand to ensure maximum comfort for users.

Admin: Meeting 10

The eighth meeting is scheduled for Thursday 8th March from 3-4pm (just before C++).

In this meeting we will discuss the evaluations done by everyone and then redesign the prototype.

We should also discuss the time of the next meeting, especially as a 2 hour meeting may be a good idea to try and re-analyse/re-evaluate the redesign and to fill any gaps in our development processes depicted on our blog.

Admin: Meeting 9 Summary

Attendants:

Ashley Harris
Elliot Hyde
John Saunt
Adele Tyler

Apologies:
Mark Mitchell - Busy buying WHAM! tickets for him and Ashley.

In this meeting we breifly discussed the responses to the second questionnaire on the prototype and listed a few of the problem areas that were highlighted in the results. Mark will write the analysis of the questionnaires which will show these problem areas. This has led us to a group decision that the prototype needs to be redesigned to attempt to rectify the issues found in the responses.

We then discussed how we were going to evaluate the product and decided that we would attempt to do as many of the evaluation technics as possible.

Ashley will write up the Cooperative Evaluation, with input from the team to assist him.

Elliot will write up the Heuristic Evaluation.

John will write up the Cognitive Walkthrough.

Case: Fitts Law

One thing to consider when designing UI's is Fitts Law. Fitts Law is a complicated looking formula which describes the amount of time it takes a person to move a pointer to a target. For example pressing a button with your finger or clicking a button with a mouse.

"MT = a + b log₂(2A/W + c)

where

• MT is the movement time
• a and b are empirically determined constants, that are device dependent.
• c is a constant of 0, 0.5 or 1
• A is the distance (or amplitude) of movement from start to target center
• W is the width of the target, which corresponds to “accuracy” "

From http://www.cs.umd.edu/class/fall2002/cmsc838s/tichi/fitts.html

Put simply Fitts Law shows that it is easier to target larger objects which are closer to you. This may seem intuitive but it is an important consideration when designing.

What Fitts Law implies is that buttons used most frequesntly should be biggest, as these are easiest to target. Not only that but also that the most frequestly used buttons should be located in close vicinity to each other.

This may seem obvious but there are many example of designs where this is not the case. When designing for children this idea is even more important. In my opinion the most commonly used button on a hand held device must be 'thumbable' without risk of pressing other buttons.

Examples of good and bad button layouts:

Key : 1 - Main Function button
2 - Secondary Function button (Menu)
3, 4 - Scroll buttons

A Bad Button Layout.

This layout might be acceptable for a sleek looking device aimed at the majority of the population. Notice however that two key buttons (1 and 2) and set far apart and also that all buttons are the same size not distinguishing their importance.

A better layout.



Here the main buttons are emphesised by being made larger. The buttons are also grouped appropriately.

Our initial prototype follows this law very well. The scan button is large (like number 1 above) as it is the first button that will be used for each use case. Also the button needs to be held when scanning the word, so by making it big, we have made it easy for children to scan words. Our scroll wheel has been positioned away from the scan button, which ensures that the two are not mistaken. The scroll wheel position means that the child can hold the pen horizontally and read the text with ease.

Case: Hick's Law

We've placed a menu system on our word scanning device, which means we need to make sure that the design of it is appropriate. A way to calculate the time it takes for the user to make a decision, such as selecting a menu item, was outlined in Hick's Law.

The law takes into account the probability of certain menu items being selected; as not all the menus will have an equal probability. For example, with our design, the 'Read word' menu will be clicked more times that the Sound On/Off menu item, as it is a fundamental part of the system.

By ordering the menus (like we have) in order of the probability that they will be clicked, we are ensuring that the time it takes for the user to make a decision is shorter.

Link to the website I got this information from is available here.