Prototype Testing - Mockup

The link below lets you download the mockup of the input device interface that will be used for carrying out walkthroughs:

http://rapidshare.com/files/22907346/Mockup.ppt.html

The mockup has been created based on the menu designs and the scenarios outlined. It was created using Powerpoint, with hyperlinks providing button functionality. Some limitations to the mockup are:

• It cannot provide contextual navigation (e.g. if there are two ways to access a page, if you press a back button it will only go back to a default, not the actual last page you visited).
• The handwriting recognition sections cannot be implemented. The plan is to have a pen and paper ready during the walkthroughs and record what users write in this way.
• The mockup functionality is limited to the scenarios, which cover all main aspects but not the whole system (e.g. there aren't delete or edit buttons for every single piece of information as it would take too long to make). However, this should be sufficient enough for testing purposes.

Prototype Testing - Scenarios

Below are the key scenarios to be used for the testing of the touch screen interface and the watch, written in the use case style used in earlier stages. These scenarios will be combined with a mockup of the system.

Collated prototype - Menus and Navigation

Menu Structure

The image below shoes the menu structure for each main function on the main menu. The menus must incorporate the means to return to previous menus, and confirmation menus to ensure the user hasn't performed an action by mistake.


Menu Designs

The navigation system consists of menus and general information displayed on the bottom screen of the device, and contextual instructions displayed on the top screen. The user navigates using the touch screen, or by speaking commands using the microphone.

Below are examples of the menus for the system. The design principles adhered to were as follows:

• Use images as a way to help the user identify common functions (e.g. moving forwards or backwards through pages) and to group sections (e.g. all pages involved with viewing information have the magnifying glass image in the corner).
• Colours had to be consistent across pages, with light colours for backgrounds and buttons, and dark colours for text. Bright colours should be used for emphasis of particular information.
• Text should be clear and concise, with as little technical jargon as possible.
• Buttons should have a 3D effect, which affords pressing and provides better contrast with other elements.
• Clear instructions should be provided on the alternate screen for each page, which can be read out by the device by touching them.
• The user should be able to tell the device to read text on any screen by touching it (or hovering in the case of buttons).
• Pages can be zoomed in and out by placing two fingers on the screen and moving them away from or towards each other (similar to the zooming function on the iPhone).
• The user can also use the microphone to input voice instructions to perform tasks. The instructions section needs to indicate when this is possible and provide examples for the user.
  

Main Menu:


Input menu example:


List example:


Confirmation example:


Notification example:


Info viewing example:


Messages menu:


Settings menu


Instructions example (main menu):

Collated Prototype - Intro and Hardware

Health Monitoring System

Our prototype is a number of integrated devices used for monitoring an elderly person's health. The aim of this system is to help save lives through quicker response to potential problems, and to try and make it easier for someone to check their own health at home, without requiring a large number of check-ups, particularly if the person has to check their health anyway (e.g. if they have been told by their doctor to keep a record of their weight and diet). We have also outlined an optional feature to the system which provides automated home security through the exisitng setup. The system would be setup by a professional team, who would also provide an introduction for the user.

The system consists of three pieces of hardware: a watch used for monitoring the user's heart rate and movement, a portable input device for allowing easy logging and sending of health information, and an optional box installed in the home that stores a backup of vital information and can coordinate an optional security system.

Watch

• Digital watch with an analogue appearance.
• Used for tracking heart rate and location.
• Available in different styles e.g. men’s and women’s.
• Available with enlarged numbers for easier viewing.
• Built-in GPS tracking, wireless transmission (e.g. GPRS). This is under the assumption that GPS is more accurate and can work indoors in the future.
• Built-in in bluetooth for communicating with other devices in the system.
• Built-in speaker + microphone for making emergency calls.
• Waterproof.
• Easy method of replacing watch battery.
• Features one button, which performs different functions depending on how it is used (wind it to set the time, press it to make emergency call, press and hold it to set off alarm).
• Built-in in emergency alarm, activated by button.
• Built-in sensors to monitor heart rate.
• Dimensions: same as regular watches, assuming we can fit all our technology into a regular watch in the future.

Input Device

• Used for logging general health information, communicating with GP, and performing optional security features.
• Dimensions: Each panel is approximately A5 size. Device is thin and lightweight.
  
• Two touch screens. One for input, one for displaying instructions.
• Built-in microphone and speakers. Microphone is used for inputting voice commands as a shortcut for navigation. The speakers output information on the screen for users with poorer eyesight.
  
• Stylus included.
• Microphone activation button, which must be held down for microphone to work.
• Can send information wirelessly (e.g. using GPRS) or via the black box using Bluetooth or similar technology.
• Rechargable direct through mains.

Black Box

• Stores important information (e.g. contact details, security password), and provides a reliable method of sending data down the phone line if other methods not available.
• Optional extra, is not vital for the running of the system.
  
• Installed into home.
• Optionally coordinates a number of PIR sensors installed into home to create a security system.
• Built-in Bluetooth to communicate with other devices in system.

Paper Prototyping - Possibility?

There are some good articles on the web about paper prototyping, mentioned in the earlier prototyping lectures, some examples are here and here. I think paper prototyping may be useful for us in terms of testing how people interact with the hardware, but I think the menu system for the input device can be better modelled using something like Powerpoint or HTML, where hyperlinks act similarly to touch screen buttons. A point mentioned in the first article is that paper prototyping is difficult for dynamic menu components (e.g. scroll bars), which could be modelled in HTML.

Another useful way for us to use paper prototyping is for the handwriting input sections, as users could physically write out on paper what they would input.

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.

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.