Ideas for Testing/Evaluation?

We didn't get time to cover this today, so I'm posting here. If anyone has any ideas of how we should test our prototype, add them to the comments. Here's a few, let me know what you think:

• Create a HTML/Powerpoint mockup of the interface, and perform either a cooperative or heuristic evaluation using the personas and/or real people.
• In terms of the mockup, we could either ask them to play with it or give them tasks based on scenarios we have come up with.
• Use my inferior eyesight skills to play a user who has difficulty seeing the interface, and perform a cooperative/heuristic evalution of the interface.
• For the voice recognition part, ask the personas/real people to come up with what they would say if we asked them to tell the device to do something, and compare the results.
• Ask someone from another team to pose as a HCI expert and evaluate our design.
• Perform more questionnaires concentrating on aspects such as the aesthetics of the product.
• Evaluate parts of the system ourselves according to literature and/or design principles already out there.

Task Analysis Part 7 to 11

Name: Setting up input devices
Initiator: User
Goal: A user friendly set up manual

Main Success Scenario:
1. Get the device out of the boxes
2. Connecting all the pieces
3. User turns the device on
4. User inputs the questions asked on the device


Possible Issues:
1. Some of the essential parts might be missing.
2. The device might need to be charged before used
3. The user might not read the manual before using the system
4. The user might input wrong information
5. The user might not know how to change the information given by mistake
6. The user might not realise that they have set the system up by mistake




Name: Inputting calories from meals
Initiator: User
Goal: To give the exact calories eaten every day

Main Success Scenario:
1. User reads the label of the foods he/she eats
2. Search for the manual on the device for the calories
3. Press the button so they can enter the data
4. Enter the calories consumed


Possible Issues:
1. What if they user eats in a restaurant or from other shops and don’t know the calories used
2. It might be difficult to find the manual
3. User might not find the button
4. What if the user enters the wrong calories
5. The user can lie while entering the calories




Name: Setting the Alarm
Initiator: User
Goal: To keep the house secure, only user has the access to do this

Main Success Scenario:
1. The user search for the alarm manual
2. User inputs the detail of their house alarm
3. The user presses a button and turns the house alarm on
4. The user turns the house alarm off by pressing the same button


Possible Issues:
1. What if the user doesn’t find the manual
2. User might not know the alarms details
3. The device might not find the house alarm system to get
4. User presses an other button instead of the alarm button
5. Setting up the alarm on the device gets too confusing.



Name: Viewing stored details (weight/blood pressure/blood sugar/calories/etc)
Initiator: User
Goal: To have an eye on the way their organ works and also to check if the calories have been set correctly before sending them to the GP

Main Success Scenario:
1. User searches for the stored details manual
2. User chooses the category of his or her interest
3. User views the details of the chosen category


Possible Issues:
1. If the user doesn’t find the manual
2. If the details required be stored in different section of the device and cause the user confusion to find each of them
3. The user can get confused if wanting to go back to the main page




Name: Sending details to GP
Initiator: User
Goal: To update the GP with the medical situation of the user and if it requires any emergency visit.

Main Success Scenario:
1. Giving the GP’s detail to the device
2. Connecting the device to send the details to the GP
3. Choosing what information to be sent to the GP
4. Sending the information


Possible Issues:
1. If the user doesn’t find the GP manual
2. If the user doesn’t have the GP details requested
3. If the User inputs wrong GP details and wants to rewrite it
4. The user might find it difficult to set up the connection
5. The user can send the wrong information or unrelated information to the GP
6. User might forget to send the details in time to the GP
7. The GP might not get the patience details

The Importance of Colour

From the age of 40 onwards the efficiency of the eye starts to decrease, objects become slightly more blurred and although bigger items are still easy to see - finer detail may start to become a problem. Contrast is also effected - as we age our sensitivity to different colours also decreases. Below is a chart that shows a trend of how our eye sight changes with age.
This is important to note as our group will be designing an interface for the elderly, thus we need to somehow limit this issue by adhering to the following rules:

• Make use of lightness differences between a foreground and a background. For example:

• Follow the colour wheel and mix colours from the top half with the bottom half for decent results (for best results avoid mixing dark colours from the top half with the lighter colours in the bottom half of the wheel).

• Finally for better results for people with impaired vision, it is useful to try not to mix colours that are next to each other on the colour wheel. Opposites seem to work well, where as colours adjacent from each other don't seem to stand out as well.

Good Example:
Bad Example:


On a final note, I think it is important to mention the other side to using colours. Although the yellow and blue flag was a good example, I would not think it a sensible colour scheme to use in our project as it could just look visually displeasing.

For more information please look at the following links:

How old age affects eyesight -
http://www.everyeye.co.uk/htms/oldAgeVision.htm

Contrasting Colours and the Visually Impaired:
http://www.lighthouse.org/color_contrast.htm

Task Analysis for points 2-6

Name: Wearable wrist device

Initiator: User

Goal: Device is wearable around the wrist, and is small enough to be unobtrusive.

Main Success Scenario:

1. Device is able to operate normally when worn around the wrist

2. The device does not hinder the user in any way

Possible Issues:

1. User may go out of range of the device

2. The device may inadvertently raise alarm when the user is asleep

3. The device may irritate the user

Name: Sensing location/movement

Initiator: User

Goal: Device monitors the movement rate of the user and checks their location.

Main Success Scenario:

1. Device is able to detect when there is a period of inactivity

2. Device is able to locate the user within the house

Possible Issues:

1. User may go out of range of the device

2. The device may inadvertently raise alarm when the user is asleep

Name: Monitoring pulse

Initiator: User

Goal: User takes a measurement of their pulse rate and stores it in the device, ready for viewing and/or sending to their GP later.

Main Success Scenario:

1. User takes pulse rate on a separate device (e.g. pulse rate tester)

2. User navigates through the device to the section for inputting pulse rate

3. User inputs their pulse rate

4. User saves the information

Possible Issues:

1. User may have difficulty finding the relevant section

2. User may input the incorrect amount

3. User may forget to save the information

Name: Logging and inputting blood sugar level

Initiator: User

Goal: User takes a measurement of their blood sugar level and stores it in the device, ready for viewing and/or sending to their GP later.

Main Success Scenario:

1. User takes blood sugar level on a separate device (e.g. blood sugar tester)

2. User navigates through the device to the section for inputting blood sugar level

3. User inputs their blood sugar level

4. User saves the information

Possible Issues:

1. User may have difficulty finding the relevant section

2. User may input the incorrect amount

3. User may forget to save the information

Name: Logging and inputting blood pressure

Initiator: User

Goal: User takes a measurement of their blood pressure and stores it in the device, ready for viewing and/or sending to their GP later.

Main Success Scenario:

1. User takes blood pressure on a separate device (e.g. blood pressure tester)

2. User navigates through the device to the section for inputting blood pressure

3. User inputs their blood pressure

4. User saves the information

Possible Issues:

1. User may have difficulty finding the relevant section

2. User may input the incorrect amount

3. User may forget to save the information

Prototype 4

My prototype consists of two main components - the watch for monitoring heart rate and location, and the input device for logging and sending general health information.

Watch Monitor

The watch is capable of monitoring the user's heart rate, as well as tracking their location using GPRS. The watch has built-in bluetooth, allowing it to communicate with other devices in order to send information (e.g. a computer or a mobile phone). When unusual behaviour is detected (e.g. no or very low pulse combined with no movement) the watch automatically notifies either the user's GP, or the emergency services directly. This is the most important part of the system, and has the potential to save lives. This part needs to be usable by as many elderly people as possible, and preferably should be completely automated as well as not creating any added inconvenience to the user.

• The watch should look like a regular analogue watch, and should be available in different styles (e.g. men's and women's). The watch should also be available with larger digits to allow easier viewing. Good examples of the look of the watch can be found at the "Low Vision Watches" section of the Independent Living Aids website.


• The watch should incorporate an emergency alarm, designed to contact the emergency services immediately. It needs to be activatable easily, but not so easily that it could occur by accident (e.g. if there are two buttons on the watch, the user could push and hold both buttons to turn the alarm on/off.


• The watch would be battery powered, so the batteries need to be easy to change. Traditionally changing batteries in watches is more difficult than the average battery-powered device.

Input Device

The input device acts as a way for the user to input information about their health (e.g. weight, blood pressure, daily diet, etc). It also allows the viewing of previously entered information, and the ability to send the information direct to a GP, hopefully reducing the amount of check-ups required, as well as freeing up GP time. Some examples of possible information stored include:

- Weight
- Blood pressure
- Cholesterol
- Body fat
- Lung capacity
- Blood sugar
- Daily diet log
- Daily exercise log

The idea is that if a user has the equipment at home for checking certain information (e.g. many elderly people have blood pressure checkers, particularly if they have high blood pressure), they can send it directly to their GP, reducing the number of times they need to visit.The device can also receive messages from the GP (e.g. appointment times, recommendations based on sent information, etc).

My interface design is based upon that of the Nintendo DS games console, which incorporates touch-screen technology and a built in microphone, allowing for more intuitive functionality.

- The device has two displays. The input screen is used for navigation and input of data, while the instruction screen constantly displays advice relevant to the section the user is in.

- If the user touches the instruction screen, it reads the instructions out loud through the speakers.

- The user is able to hand write instructions into the input screen at various points (e.g. when inputting a value).

- The microphone activation button is held down to allow the user to speak instructions into the microphone. Example instructions include "Add weight", "view blood pressure", or "help me with sending". The software needs to be able to take into account variations of instructions. The button must be held for the microphone to work, and ensures the device doesn't interpret talking as instructions constantly.

- The speakers are used for for outputting textual information as sound and also providing any other audio clues to aid the user.

- The input device also has built-in bluetooth, to allow information to be sent to a GP over other devices.

- The device should be lightweight and portable, but large enough to accomodate large screen sizes.

- The input device runs on rechargable batteries, and must be easily chargable using an adaptor.

Menu Examples

Below are some examples of the menu structure. Some general points about the menus:

- The user can zoom in on a menu by placing two fingers on the touch screen and pulling them apart, as if they are pulling out the information. The reverse is done for zooming out.

- If all the information cannot be viewed in a single screen, there should be bars on the sides that can be operated using the stylus.

- If any piece of text is touched, the device should read out the text using the speakers.

Main Menu

- The main menu displays four main performable tasks. All other tasks need to be reachable from these.

- "Add info" lets the user input different health information. "View info" lets the user view information that is already stored. "Messages" lets the user view messages from their GP. "Options" lets the user customise the software (e.g. colours, date formatting, metric/imperial measurements, etc. This option would probably only be used by more comfortable uers.

- The buttons should look like they are meant to be pressed (e.g. using a 3D effect), and should have clear labelling.

Adding info - Weight

- The above screen would appear if the user cliked the "Add info" button on the main menu.

- The user is able to hand write what they wish to add. This provides a much more intuitive interface for elderly users. Alternatively, the user can choose from a list of ready-made options, or speak the instruction into the microphone.

- The interface needs to allow the user to recover from mistakes (e.g. erasing what they have written, or going back to the previous menu).

- The menu for adding the actual value would behave in a similar way, allowing the user to hand-write the value.

- Once the user has added the info, they can review what they just added, correct it if necessary, and choose whether they wish to send it.

Viewing Example - Weight Log

- The user accesses this section in the same way as adding information, using the stylus to write where they wish to go.

- The device stores a record of values that were entered by the user, along with the date they were added and indicating whether this value was sent to their GP or not.
- All text must be enlargable, using the method described earlier.

Instructions Example - Main Menu

- The above diagram shows an example display for the instruction screen.

- Instructions should be clear and uncomplicated, with high-contrast colours used.

- Text should be enlargable using the method described earlier, and clicking on the screen will make the device read out the instructions.


Optional Device - Installed House Hub

If the user does not have internet access or a mobile phone, they need another way to send information. This could be achieved by installing a small box which acts similarly to a modem, using the phone line to send messages. The box would be able to communicate wirelessly with both the watch and the input device. In an outdoor scenario, the watch should be able to communicate with existing wireless internet hubs to transmit information in an emergency, if the user does not have a mobile phone.

Technological Assumptions

1. Speech/recognition has improved, and offers at least close to 100% accuracy.
2. The technology required for the watch monitor can be fitted into a device the same size as a regular watch.
3. GPRS accuracy has improved, and is capable of tracking positions indoors.

Similar Product?

Hey guys, my prototype will be up soon, I just thought you'd like to see this. A company called
"Wrist Dreams" has already made a watch capable of monitoring heart rate and using bluetooth to send the information. Looking at the picture, I'm not sure if anyone would want to wear such a bulky (and ugly) thing all the time. Obviously we need to make the assumption that we are able to fit all of our technology into a regular watch.

Prototype 3

Monitoring:

The monitoring device like the other prototypes is to be a watch; its functionality to the user will simply be a watch, which tells the time:
Behind the scenes the watch will have the ability to monitor the users heart rate/pulse.The watch will have a GPRS transmitter, which is connected to the black box, the black box will store the information transmitted by the watch. So it stores the users heart rate/pulse over time and there location.

The system will have software with the following capabilities:

· Ability to learn users daily movement pattern
· Ability to learn users heart rate pattern
· Ability to identify unusual activity

This will enable the software to detect whether the user has suffered a heart attack, fall etc. For instance if there is no movement for an unusual amount of time and the heart rate is critical or even gone then the system should detect this and notify the emergency services. The ability to learn users daily patterns should mean that if it is 1 am and there is a lack of movement then the system should know that this regularly occurs at this time, as the user is asleep.

Inputting/Viewing/Sending Data:

To input data such as weight, calories eaten, blood sugar levels etc, which have to be read using devices, which are not provided by the system, I propose that we use a touch screen pad as an input device.This is intended to enable the user to interact with the system as intuitively as possible using simple and minimal menu options:

The First Screen:

The screen has 3 simple options representing all options, which are available to the user. The options are colour coded and the colour scheme is carried out through the program.

Inputting Data:

The input option screen is green as this was the colour of the input option. Again we have simple options, which describe what the user is trying to input.

The input screen:

Depending on which option selected there will be text, numbers or both. Here we are inputting weight and so we have numbers and keeping with the colour scheme weight is orange and so the screen is orange.

The display shows what the user has typed. When the save button is pressed the data is saved to the system.

Sending Data:

The sending option screen is yellow as this was the colour of the send option. Again we have simple options, which describe what the user is trying to send.

The send screen:

Simple options, which consist of who the user wants to send the information to, software sends the required information to the chosen recipient.

The screen here is white as the user has selected to send their heart rate.

Prototype 2: Monitoring Health & Providing Safety

The idea is similar to the one below. However the watch would have no interface apart from one button situated at the side of the watch. The main function of the watch would be to just tell the time (whilst in the background monitor certain health conditions).

Fig 1.0 A Digital Watch

The side button would communicate with a security system placed around the house. When a elderly user leaves the home, they can press this button to alarm their property or deactivate the alarm when they re-enter. PIR Sensors would do the job of monitoring unauthorized movement within the house and send a silent alarm off to security centre. They will also have the job of monitoring the 'elderly watch-user' - if no movement is detected for a prolonged period of time and the watch has detected a health anomaly - then the emergency services will the notified.

Fig 2.0 A PIR Sensor

Finally there would be a need for a device to set the system up and also to view statistics stored from the watch. I propose a touchscreen/graphics pad for this job - large icons can be displayed that the user can easily see. Also rather than typing any setting - a graphics pen can be used to write them in (most elderly can still write).

Fig 3.0 A Graphics Pad

Each device will communicate with each other through Bluetooth technology and powered by rechargeable batteries.

Prototype - A touch screen watch

Case first entered the touch screen market in 1991 with their data bank watch.

1991: Databank with touch screen

Simply point to the function you wish to use and touch the screen. The display enables access to a telephone book, an organizer,a notepad or an 8 digit calculator.

The idea was to have a large touch sensitive display that you could interact with. There was no need for external buttons, everything was done with 'soft buttons'.

I have devised a similar idea for our first prototype, but using more upto date technology. There is a full colour screen, which is capable of drawing complex objects and shapes. The onboard computer is able to process a number of different tasks, including inputs from sensors and an external base station.

Questionnaire Results

Here are the persona results of our questionnaire:

Derek:

Fiona:

Maureen:

Notes and Evaluation

• An important part of our design must focus on how to encourage users such as Derek to use at least the bare minimum of the system, who have no confidence with technology and do not see their doctor often.
• Inversely, the system also needs to be able to handle the needs of Fiona-esque users, who would demand a lot more functionality.
• The results for previous use of technology are mixed. It is unlikely that many advantages would be gained from relying on familiarity with computer icons or menus, and more intuitive interfaces should be used.
• All personas already have some form of security in their home. Our brainstorm mentioned that security could be integrated into our idea, but this could be an optional feature if users already have security.
• The personas had trouble understanding some of the questions, in particular, the questions using a scale of 1-10. It was not clear how the scale worked, and in hindsight the questions could have been more descriptive.
  
• Question 14 could have been worded slightly better, as the use of "always" in some options tended to confuse the respondants, as they wanted to say that they sometimes did an option.
• Questions 5 and 12 could have been clearer with the options, as there was too much grey area not covered.