Final Post: Learning Outcomes

1. Explain and discuss practical and theoretical aspects of Human-Computer Interaction.

Group Dynamics
Using Personas
Method of Documenting Tasks
Discussion of Colour Use
Discussion of Paper Prototyping
Explanation and Application of Heuristics

2. Apply HCI Principles to Practical Problems

Personas
Persona 1 Persona 2 Persona 3

Questionnaires
Final Questionnaire Design

Prototyping
Individual Prototypes: 1 2 3 4
Initial Prototype: Hardware Navigation Features
Final Prototype: Hardware Features Navigation

Task Analysis and Scenarios
Initial task analysis 1 2 3
Task analysis of test scenarios

Mock-Ups
Initial prototype mock-up
Final prototype mock-up

Walkthroughs and Heuristic Evaluation
Persona walkthroughs 1 2 3
Blind walkthrough
Voice recognition walkthrough
Heuristic evaluation


3. Participate in Analysis and Design Work in HCI

Brainstorming
Initial Ideas 1 2 3 4
Brainstorm for final idea

Creating Personas
Personas 1 2 3

Defining Key Tasks and Scenarios
Initial task analysis 1 2 3
Task analysis of testing scenarios

Questionnaires
Questionnaire drafts 1 2 3
Questionnaire results

Creating Prototypes
Individual Prototypes: 1 2 3 4
Initial Prototype: Hardware Navigation Features
Final Prototype: Hardware Features Navigation

Testing and Evaluation
Initial ideas
Testing 1 2 3 4 5 6
Initial prototype evaluation
Final prototype evaluation

4. Demonstrate appreciation of the research literature in one subfield of HCI.

(Applicable to Matt only)

Alternatives to UCD

HCI Extended Report - Alternatives to User-Centred Design

This module has involved using the user-centred design process to create a product design, but there are a number of alternative methods. Some notable ones are as follows:

Waterfall Model

The waterfall model is one of the oldest design models, described by Royce in 1970 [1]. The model is simple, easy to understand and good for helping to maintain discipline in development (this is considered a weak point of user-centred design, where the practice of methods may not be consistent [5]), but it has been criticised for not being able to adapt to changing requirements [2]. The model also has very little interaction with users, who are only involved in the initial requirements phase.

Iterative Models

There are a number of development methods (e.g. spiral model [9], and Rational Unified Process [13]) that rely on the iterative model of creating intermediary prototypes that can be used to gain feedback. Traditional iterative methods are more flexible, but still have minimal contact with users (there is no design collaboration, but feedback can be given on prototypes), and there are still large amounts of documentation, which makes it more time-consuming to cope with changing requirements [14].

Agile Development

Agile development methods (e.g. “Extreme Programming” [10]) are similar to iterative models, but focus on very quick iterations that deliver working software, self-organizing teams with an emphasis on face-to-face communication (with less documentation), greater collaboration with users, and adaptability to changing requirements at any stage [11]. Agile development shares some common ground with user-centred design (e.g. iterative development and emphasis on communication with users), but the functionality is still the central focus [12]. This method may not be suitable for projects involving larger teams (face-to-face communication becomes more difficult with more people), or safety-critical projects that may require a lot of discipline and formal documentation.

Usage-Centred Design

Usage-centred design, as outlined by Constantine [3] [4], is a methodology that focuses around the tasks that have to be performed, rather than the users. The process is more formal than user-centred design, and has less user involvement, but can still provide good usability by concentrating on making tasks as easy as possible to perform. Key concepts of this method include “essential models” (models of the system with no assumptions about implementation) and “task cases” (abstract use cases where user input is split from system operations). A similar approach is “performance-centred design” [7], which incorporates many user-centred tools with a task focus. Usage-centred design appears to have many of the benefits of user-centred design, but it may not be sensitive to particular needs of specific user groups (e.g. the focus is on making tasks as efficient as possible, which may be detrimental to novice users who need more guidance).

Participatory Design

Participatory design [8] aims to involve the user as much as possible, and create a “third space” where users and designers can both learn and contribute. This is achieved using methods such as workshops (e.g. users will test a feature and then go to a workshop to discuss it with designers) and cooperative prototyping. This approach is at the extreme end of user-involvement, and appears to be very good for generating new ideas, due to the large number of outside perspectives involved. However, it may suffer the same drawbacks as user-centred design (e.g. a lack of discipline [3] and the incorporation of too many features (“Featuritis” [6]). Participatory design may be suitable for very specialised applications, where the user knowledge becomes more valuable. Principles of this approach also seem evident in websites such as Wikipedia, where the users themselves are creating the content.

Conclusion

The methods described above all try to provide a new approach to software design, but there is a large overlap in terms of the actual methods used to achieve goals, and designers could probably improve usability by simply applying compatible techniques from other methodologies into whichever one they choose. There is no clear-cut superior method, and different approaches seem to be suited to different project characteristics, but I feel that usage-centred design provides the most convincing alternative to user-centred design for improving usability in general-purpose interfaces, with a good balance of discipline and adaptability to user requirements.

References

[1] "Managing the Development of Large Software Systems" - Winston W. Royce.
[2] "Understanding the Pros and Cons of the Waterfall Model of Software Development" -TechRepublic, September 2006.
[3] "Usage-Centred Engineering for Web Applications" - Constantine and Lockwood, March 2002.
[4] "Frequently-Asked Questions about Usage-Centred Design" - Constantine and Lockwood, 2003.
[5] "A Survey of User-Centred Design Practice" - Vredenburg, Mao, Smith and Carey, 2002.
[6] "Designing Web Applications for Use" - Constantine and Lockwood, 2006.
[7] "What is Performance-Centred Design" - Craig Marion, August 1997.
[8] "Participatory Design: The Third Space in HCI" - Michael J. Muller.
[9] "A Spiral Model of Software Development and Enhancement" - Barry W. Boehm, May 1988.
[10] "Extreme Programming: A Gentle Introduction" - Don Wells, 2006.
[11] "Principles Behind the Agile Manifesto" .
[12] "User-Centred Development Process" - Hubmann.
[13] "Rational Unified Process" - IBM.
[14] "Testing Methodologies" - Microsoft, January 2005.

Evaluation

Potential Improvements/Extensions

We conducted another walkthrough and discussion of our final prototype, and came up with a number of potential improvements that could be implemented given more time:

• Although we believe we improved the usability of the watch with the final prototype, it still requires an instruction manual to learn how to perform the functions. We decided that providing information on the watch itself would require removing the analogue look and feel. One option could be to offer digital-style versions of the watch, with a screen providing information and help (similar to "Initial Prototype 1" posted by John).
• When we designed the menus, we limited ourselves to a small screen size and tried to make large buttons. This caused issues with trying to fit all the functionality on a page, while at the same time providing enough information for the user. One potential solution would be to include some general functionality (e.g. the "Back to Main Menu" button) on the help screen instead.
• In the final prototype the user can reply to messages, which caused issues with how to implement error handling. If the user makes a single mistake, they cannot erase that portion, they have to clear the whole thing. In addition, if an error occurs, they have to start the message again. This highlighted the need for an "eraser"-style method of removing text on input screens, and possibly making input errors pop-up on the same page, highlighting exactly where the errors occurred.
• The speech input functionality was not elaborated on too much, as we made the assumption that voice recognition would be accurate in the future. If we had more time, we could explore this aspect of the system in more detail.
• The input device may appear quite daunting to some users at first (e.g. people similar to the "Derek" persona), and in some cases may not be used as much as the watch. We have tried to make the interface as simple as possible, but the amount of functionality included increases the complexity. Improvements could be made in creating a menu structure which makes the simple and necessary functions obvious (e.g. adding info, viewing info, setting contacts), and some of the less necessary functions are put in the background (e.g. changing colours, replying to messages, etc).
• More "expert" customisation could be included (for example the ability to turn off confirmation messages to speed up tasks).
• Some method of showing where the user actually is in the navigation (e.g. breadcrumbs) would help to reduce confusion, as sometimes it feels like pages are being handed to the user, rather than the user is traveling through them.
• An extension out of the scope of the project aim would be to adapt the input device so that nurses who care for people at home could use it to send more detailed information directly to records.
• One aspect not considered was that there are many opportunities to abuse the system (e.g. spamming GPs, making repeat calls to emergency services, etc). We would need to find a way to deter malicious uses of the system.
  

Overall Evaluation

We feel that we have managed to achieve the task of creating a useful device for elderly people. In particular, the watch part of the system could provide an invaluable service for any elderly person concerned about their health, while the input device has varying benefits depending on the health condition of the user and their willingness to use it.

Transferring our design to the real world is difficult to envision, as not only is it based on a number of assumptions about future technological advances, but it would also require the implementation of an infrastructure between users and health professionals (e.g. another piece of software would have to be designed for the GP to manage information being sent by multiple patients).

Final Prototype - Mock-ups

Powerpoint mock-up

The final Powerpoint mock-up can be downloaded at the link below. The new mock-up contains examples of all the new additions to the interface, and gives examples for the main scenarios. As with the first mock-up, it cannot model the handwriting input or proper contextual navigation using the "go back" buttons, but still models the menu structure well.

http://rapidshare.com/files/23292430/mockup.ppt.html

Paper Mock-up

Below are some crude paper mock-ups of the device and watch, made to scale.

Final Prototype - Menus and Navigation

Navigation Structure



The image above shows the navigation structure from the main menu. Vertices without arrows indicate bi-directional paths, where the user can choose to go back to the previous menu. Shaded menu boxes indicate where navigation jumps to another section. The structure now incorporates error handling and undo functionality, two areas we found lacking during testing.

Menu Design

Here are some general points about the menus, and changes that have been made:

• Colours have been changed slightly, in terms of consistency for buttons and achieving better contrast.
• The menus no longer rely on just colour changes for making text stand out, important text is resized or in bold.
• Technical jargon has been reduced further, with terms such as "info", "delete", "settings"and "edit" being replaced by "information", "remove", "options", and "change".
• Different images are now used for buttons going back a step and those which return to the main menu.
• The user can now undo many operations, and redo them if they wish. The undo screens have verbose descriptions of what is happening, with information carried over from previous stages in the task.
• The scroll bars have been redesigned, so that the user can just move their finger along them to move text. A fingerprint is used to try and get across how to use the bars.
• Buttons have been spaced apart more where possible.
• Error messages are now produced for invalid text input, to provide feedback which was non-existent in the initial prototype. The user is provided with a range of choices for recovery, explained verbosely.
• Notification screens have been added to areas where they were missing before (e.g. changing options), along with appropriate undo functionality.
• Due to the extra functionality of being able to send to different people, the messages menus now display who sent a message.
• Logs are now sorted with newest entries at the top, and the user is able to delete the oldest entries to ensure the logs don't become too long.
  

Menu Examples

The image below contains a number of examples for the different menu types in the final prototype. The full menu system will be available in the mock-up, due soon.

Final Prototype - Features

This section defines the functionality for each device:

Watch

• The time can be changed by winding either of the buttons, the user does not need to know which.
• Tracks the users movement and location.
• Monitors the users heart rate and body temperature, and can detect if the user is wearing the watch.
  
• An emergency signal is automatically transmitted if the monitored information becomes suspicious (e.g. the watch is operating, but there is no pulse or movement).
• A manual emergency signal can be activated by pushing and holding the two buttons for two seconds. The watch vibrates for three seconds and the red light is activated. During this time the user can cancel the alarm before it is activated (by pushing the two buttons). An audible alarm is sounded, and the emergency signal is transmitted.
• The emergency services can be contacted by pushing the two buttons once. As with the alarm, the watch warns the user with a vibration and a red light, allowing them to cancel before the call is made. The call is outputted using a speaker, and the user can speak directly into the watch.
• A family member (assigned to the watch using the input device) can also be contacted, by pressing one button and holding for two seconds.
• All functions are turned off by pressing any button.
  
• Two LED lights provide feedback to the user about the watches state, allowing them to ensure the watch is functioning, or that they have not pressed a button by mistake. For example, no light means that the watch is currently not operational (e.g. if the user is no wearing it). A green light means that the watch is operational (the user is wearing it). A red light means that one of the emergency functions is currently running.
  

Input Device

• User can input general health information, which is stored in logs for each category.
• Example categories include weight, blood pressure, heart rate, diet, and exercise log.
• The user can make their own categories if they wish.
• All information stored in the device is viewable and editable.
• Information can be sent to a number of health professionals stored as contacts in the device (e.g. GP or dietician).
• Contacts can send messages directly to the device, allowing them to provide quick advice, book appointments, etc. Users can reply to these messages if they wish.
• Users are prevented from modifying or sending data that has already been sent.
• Ability to change some options (e.g. colours, units used for values, contact details, etc).
• Navigation is performed using the touch screen, with "soft" buttons displayed on pages.
• Ability to hand-write data into the device. This assumes text recognition is more advanced in the future.
• Ability to input commands using the microphone. This assumes speech recognition is more advanced in the future. We found that this function was better suited to "expert" users, as it provides quick shortcuts for tasks.
• Context-sensitive instructions are displayed on the left screen of the device.
• Text can be verbalised by clicking it (or hovering in the case of buttons). The device also provides some context about the text (e.g. it will tell the user that the text belongs to a button, and the button may belong to a certain piece of information).
• Text can be made larger and smaller by placing two fingers on the touch screen and pulling them apart (or bringing them together).
• The features for the input device have remained relatively unchanged from the initial prototype, with the exception of security-related features and some minor changes.
  

Security System

The optional security features have been removed from the prototype, to reduce the complexity for the user, and to allow us to focus on the health monitoring aspect.

Final Prototype - Introduction and Hardware

Health Monitoring System

Our final prototype is a pair 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). The user would be able to receive free assistance with set up and tutorials on purchasing the device.

The system consists of two pieces of hardware: a watch used for monitoring the user's heart rate and movement and a portable input device for allowing easy logging and sending of health information.

Watch

The watch is used for real-time monitoring of the user's heart rate, movement and location. It is designed to require as little input from the user as possible to function correctly.

• The watch is digital, but has an analogue appearance.
• Available in a variety of styles for both the watch strap and the face.
• Available with larger numbers for easier viewing.
• Built-in GPS tracking and wireless transmission using GPRS. This is under the assumption that GPS is more accurate in the future, and can work indoors.
• Built-in bluetooth for communicating with the input device automatically (e.g. to store a log of heart rate averages).
• Built-in speaker and microphone for making emergency calls.
• Waterproof.
• Takes regular watch batteries, replaceable without the need for a screwdriver.
• Two buttons used for performing different actions: Either button can be used to wind the time, pressing both buttons together makes a call to emergency services, pressing and holding both buttons sends a panic alarm, and pressing and holding a single button makes an emergency call to a family member.
• Built-in red and green LED lights to indicate different states: green if the watch is being worn and is operating, off if the watch is not operating, and red if an emergency call or alarm has been activated.
• Built-in vibration capability to notify the user when emergency functions have been activated.
• Built-in sensors to monitor heart rate, body temperature, movement, and detect if the watch is being worn.
• Dimensions: same as a regular watch, assuming all the technology can be fitted into a device the size of a regular watch in the future.

Input Device

The input device is used for logging, viewing and transmitting general health information about the user. This device allows people whoc regularly have to check various health heuristics (e.g. weight, blood pressure, diet, etc) to easily keep a record of recorded information, and send it immediately to a GP or other health specialist without requiring an appointment.

• Dimensions: device is approximately the size of an A4 sheet of paper (A5 sheet when folded), and thin and lightweight.
• The device is laid out so that the user opens it like a book, as this was found to be an intuitive method that people used.
• Two touch screens: one for input (right hand side), and one for displaying instructions (left hand side).
• Built-in microphone and speakers for performing speech input and speech output of text.
• Stylus has been enlarged, and is now stored in clear view in the device.
• Stylus is attached to the device by a retractable cord, to prevent it from going missing.
• Send information wirelessly using GPRS.
• Can communicate with the watch using bluetooth.
• Rechargable directly through mains.
  

Security System

The optional security features have been removed from the prototype, to reduce the complexity for the user, and to allow us to focus on the health monitoring aspect.

Prototype Testing - Overall Evaluation and Improvements

The initial prototype performed fairly well on the whole, but there are a large number of possible improvements. The navigational method can remain relatively unchanged, with a few minor tweaks to the presentation and structure, and the devices themselves also do not need a major overhaul. The issues that must be addressed are the usability of the watch, making the stylus more robust, and adding error prevention/management.

Potential Improvements

• Remove the security aspect, as it over-complicates the system and may not be considerate to users' current situations.
• Change the orientation of the input device, so that it folds out like a book, which is more intuitive to the user.
• Make the stylus larger.
• Use a cord to attach the stylus to the input device.
• Ensure there are error messages if input is invalid (e.g. an information category written does not exist).
• Enable calls to a designated family member to be made using the watch.
• Make important functions such as zooming in and verbalising text more explicit in instructions.
• Remove tech-speak from text and buttons.
• Allow the deletion of logged and sent information past a certain amount of time.
• Display the sender of a message.
• Remove the function to modify date/time and perform it automatically.
• Provide "undo" functionality.
• Make watch functions easier to use, but harder to perform by accident.
• Enable sending of information to different people.
• Ensure the watch knows if it has been taken off.
• Add a light to the watch which can inform users about the current state (e.g. green means it's working, off means it's switched off, red means it's in alarm mode).
• Enable replying to messages.
• Distinguish between "return to main" and "go back" more clearly.
• Verbalising of text needs to be made more contextual, and distinguish between text and buttons.
• Disable "continue" button if no input provided.
• Let the user change relevant options contextually.
• Improve the contrast of text and background in problem areas.
• For text relying on differences in colour, make them bold as well.
• Add more images to buttons.
• Make notification screens consistent across all changes to information.
• Make the scroll bars more intuitive.
• Order information with newest information first.

Prototype Testing - Usability Heuristics

Based on usability heuristics defined by Nielsen and Tognazzini we performed an "expert" heuristic evaluation on the user interface for the input device. The results are as follows:

Visibility of System Status

There is room for improvement in this area for the input device, in particular making notification messages consistent across all changes and providing error messages for invalid input. There should also be feedback for incomplete information (e.g. a weight value was specified without any indication of units).

The watch is particularly weak for this heuristic, as there is no indication on the watch of its current state (e.g. is it making a call, is it actually working, etc).

Match between System and Real World

We found that the Derek persona could not understand some of the words which didn't seem too technical at first (e.g. settings, edit, main menu, etc). These need to be replaced with more suitable terms.

User Control and Freedom

Confirmation screens are used to help the user recover from a mistake, but undo could also be used after a user has saved information, to ensure they don't have to navigate menus.

Consistency and Standards

The system overall is pretty consistent, with colour coding and images used to group tasks. The use of back buttons could be made clearer, and a distinction should be made between going back a page and going all the way back to the main menu.

Error Prevention

One example we found where error prevention could be implemented is by disabling the "Continue" button if an input screen is blank, forcing the user to write something.

Recognition rather than Recall

The menus carry over important information from one screen to the next (e.g. confirmation screens contain information about what is actually being confirmed). Instructions are also available on the second screen on every page.

Flexibility and Efficiency of Use

The speech input aspect can be seen as a way to increase efficiency, particularly as our walkthroughs showed that more confident users are more willing to use it. The operation of this feature should not be made obvious to novices, so they don't get bogged down in different navigation methods.

Aesthetic and Minimalist Design

Text on screen is kept to a minimum, with more elaborate descriptions available in the contextual instructions.

Help Users Recognise, Diagnose, and Recover from Errors

As mentioned before, the initial prototype did not take into account error management for irregular input, and this should be an important part of the revised prototype.

Help and Documentation

There is a large amount of contextual help, but the initial prototype does not mention the main instruction manual. This needs to cover the operation of the watch, as well as how to perform basic multi-screen tasks using the input device.

Colour Blindness

The web application Vischeck lets you see how images appear to people with three different types of colour blindness. Some colour blindness issues were found in the interface, in particular the use of different colours to highlight important text. As an alternative, this text should also be made distinctive in another way (e.g. bolding or italics). Below is an example menu ran through Vischeck:


Fitts' Law

The interface is less vulnerable to Fitts' Law due to the use of a touch screen, so a user can access any part of the screen equally quickly.

Learnability

We found that general navigation was very easy to learn, and improvements in text language and consistency should reduce the learning curve further. The watch however had a steeper learning curve considering the small amount of interaction required.

Visible Navigation

There is limited visible navigation in the interface, with images used to remind the user of the section they are in, but they cannot view information about where exactly they are, they have to remember it.

Prototype Testing - Voice Recognition Scenarios

For this test, we decided to see how personas would use the microphone to input commands, and compare results. We asked them to say how they would instruct the device to perform each scenario.

Maureen

Logging Weight Information - "Add my weight... ummm.. its 12 stone seven."

Viewing Weight Information - "View my weights? This is strange..." (she forgot to let go of the microphone button).

Viewing an Unread Message - "View my messages... ummmm..." This task couldn't be pweformed in one go as the user needs to know what the unread messages are.

Modifying Date and Time - "Change the date to the 18th of March and the time to 2:50" A problem here is that the time could be 02:50 or 14:50.

Turning on Security - "Turn my security on please." She felt a bit silly saying "please" afterwards.

Maureen eventually got the hang of the speech input, but it seemed a little odd at first, and possibly made her feel a bit embarrassed.

Fiona

Logging Weight Information - "Insert my weight, 49 kilos."

Viewing Weight Information - "Show my weight."

Viewing messages - "Messages."

Modifying Date and Time - "Date, 18th of March, 2 fifty."

Turning On Security - "Security on."

Fiona was very comfortable with the speech input, and she liked the efficiency of the process. She also perceived it to be a very high-tech feature, and something she could show off. One important point to note is the use of kilos, the device must be able to handle different units.

Derek

Adding Weight Information - "Hello? Do I speak into here? ADD MY WEIGHT... TWELVE STONES AND SIX."

Viewing Weight Information - "SHOW ME MY... I don't need to shout? Why can't I do this the other way?"

Viewing Messages - "Show me the messages. Is that okay?"

Modifying Date and Time - "18th of March, five and twenty past three."

Turning on Security - "Turn on security. Is that the last one? Thank goodness for that. Oh, I haven't let go..."

Derek found this method very odd, even more odd than using the touch screen. One thing to notice is the old-fashioned way of saying "twenty five past three".

Conclusion

The speech input mechanism was not effective for all personas, but it did achieve its goal of efficiently performing tasks in some cases. For it to be effective, the speech recognition software needs to be able to filter out junk words and be able to handle the numerous ways of saying the same thing. Another important point is that the user needs to know when they can use it, and clear notification needs to be provided if more information is required to perform a task.

Prototype Testing - The Blind "Expert" Walkthrough

In this test a member of the group posed as an expert, and attempted the outlined scenarios using the mockup. However, we decided to impair the expert's vision by either removing their glasses (Matt) or wearing someone else's pair (Rana and John). Another team member read out the text or buttons that the user was hovering over, similar to how the real device would behave.

In addition to issues already covered by the persona walkthroughs, our findings were as follows:

• Some pages have a large number of buttons performing the same action for different pieces of information (e.g. viewing messages). The verbal output of text needs to be extended to provide contextual information for each button.
• The "Continue" button on input screens should be disabled if the user has not inputted anything, to prevent errors.
• The verbal output needs to make a distinction between buttons and text.
• When changing the date, on the confirmation screen the date is not in the same format.
• The green and red arrows for navigating forward and back can be seen even with very poor eyesight.
• The contrast between text and background was poorer with some colours (e.g. the pink buttons and darker blue backgrounds).
• The notification messages were not consistent across all changes (e.g. turning off security, or editing options).
  
• Some buttons were difficult to distinguish from each other, and should be placed further apart, or have some sort of unique feature (e.g. an image).
• Some of the options should be made contextual, as it is too time-consuming to discover where an option needs to change, and then go back to the settings section and change it (e.g. displaying values using certain units).
• Its difficult to tell the difference between "Go back" and "Back to main menu".
  

Prototype Testing - Derek's Walkthrough

Here are the results from our prototype walkthrough with Derek, based on general points mentioned and performance during the scenarios given.

General Points

• Derek liked the concept of the watch, as he could just leave it alone, and it was inconspicuous. However, he wasn't so sure about his location being monitored all the time.
  
• As with Maureen, Derek had trouble using the small stylus, and almost lost it through dropping it.
• Derek was very cautious with using the technology, and always read through the contextual instructions. He also explained to us that he normally wouldn't bother trying to use something like this, but was giving it a go as his feedback could make the system better.
  

Inputting and Logging Weight Information

• Derek read through the instructions very carefully, and would always ask us before he did anything. We urged him to try not to ask us and just do what he thought was correct.
• Derek didn't own any scales, and hadn't weighed himself in a long time (he claims he has been the same weight for many years), so we asked him to add any weight in.
• Some of the writing was too small for Derek to read, but he had figured from the help how to zoom in and out. However, it was not as obvious that the scroll bars needed to be used to move the view around, and he thought you had to zoom back out and zoom in on a different part.
• "Does this thing not trust me?" Derek felt that there were too many confirmation and notification stages.
• Derek was also confused by some of the terms, such as "info" and "main menu". It was not clear to him what these meant.
  

Viewing Weight Information

• "Choose what from list?" It wasn't obvious to Derek that the "Choose from list" button let you choose a type of information.
  
• Derek slowly managed to complete this task. Unlike other personas, he was also very careful not to press buttons by mistake, and wrote in capital letters.
  

Access Messages and View an Unread Message

• "Who are these messages from?" As with Fiona, Derek noticed that there is no indication of the sender of the message.
  

Modify the Date and Time

• It took a while for Derek to find the appropriate place to change the date and time. Firstly, he was confused by the use of "Settings", and then "Edit".
• As with the other personas, Derek wasn't sure that he had successfully performed the task. He thought he hadn't, and decided he wanted to go back to the beginning and start again. However, there was no clear way of going straight back to the main menu (i.e. skipping any intermediary menus).
  

Set off the Watch Alarm

• Derek has read the instructions carefully, and so set off the alarm on the first attempt.
  
• At one point during another task, Derek rested his arm on a table, and set the watch alarm off by accident. This put him off wanting to wear it, as the accidental setting off of the alarm would be bad for his heart.
  

Make an Emergency Call Using the Watch

• As with the other personas, Derek was confused as to whether the call was being made or not. This lead him to press the button repeatedly, which in turn repeatedly made and stopped calls.
  

Send Previously Saved Information to the GP

• Derek remembered that there was an option to send at the end of the "Add Info" task, but he knew that he didn't want to add information again. He eventually found the right section through trial-and-error.
  

Turn On/Off Home Security

• We explained to Derek that the security was an optional feature, and would require installation of devices into his home. This put him off the idea, and he didn't want to bother with learning how to do the security.
  

Evaluation

Derek is an example of someone who would require some learning before using the device. I was very hard for him to fathom things initially, as he has such little experience with similar devices. A particular area of difficulty was with words that seemed very tevhnical and lacked meaning to him. However, he was more comfortable using the watch, which is the most important part of the system in terms of the life-saving aspect. Some new potential improvements based on this walkthrough are:

• Try to remove the use of technical terms or terms which have become familiar through use of technology (e.g. "settings", "main menu", etc).
• Make the functions on the watch harder to activate by accident.
• Improve the stylus design, and make it permanently attached to the input device to prevent it from being lost.
• Ensure there are buttons on every page allowing the user to return to the main menu, and distinguish these from regular back buttons.
  

Prototype Testing - Fiona's Walkthrough

Here are the results from our prototype walkthrough with Fiona, based on general points mentioned and performance during the scenarios given.

General Points

• Fiona did not like the appearance of the watch. It is important that we try and offer different styles.
• Fiona also raised a key point we missed in the watch prototype. She explained that she would rather wear her expensive watch at social events, and asked what happens if the user takes the watch off? In our current specification, this would cause an emergency signal to be sent, as it believes that there is no movement or pulse.
  

Inputting and Logging Weight Information

• Fiona seemed to cope very well with the navigation, and got the hang of it quickly. However, she put in a wrong weight value and didn't realise until after she had added it. There was no easy way to undo the addition, instead she had to access the log and delete the entry there.

Viewing Weight Information

• "I don't want to look at this huge list, where's the one I just added?" Currently the list is ordered with earliest ones first, which means the user has to scroll down to view the most recent. Also, there is no way of deleting information if it has been sent to the GP, no matter how old.
  

Access Messages and View an Unread Message

• "Who are the messages from?" There is no indication of the sender of the message.
  
• As with the logs, information is stored with earliest entries at the top.
• "How do I know which ones are important? I'm too busy to look through them all." Fiona wanted urgent messages to have priority over others.
• "Can I send replies?" Currently, there is no way to reply to a message.

Modify the Date and Time

• "Why doesn't it know the time already? My phone does." Fiona questioned the point of having to change the date or time, particularly as it could potentially be synchronised. However, this is the example for changing an option, so we continued.
• By now Fiona was comfortable with the interface. However, as with Maureen, she was unsure as to whether the date had been changed as no notification was provided.
  

Set off the Watch Alarm

• Fiona was initially confused, as it is not obvious what to do. She assumed that you have to perform the same action to turn off the alarm, but this isn't the case.
  

Make an Emergency Call Using the Watch

• "Isn't that what you do to turn the alarm off?" Fiona noticed that the same action is required for turning off the alarm and making an emergency call.
• "How do I know its working?"
  
• Fiona felt that the emergency call could be set off too easily by accident with no knowledge of it occurring, and she didn't want to clog emergency services with her false alarms.
  

Send Previously Saved Information to the GP

• "Why the GP? Can't I send information to my fitness instructor? Or Dietician?" Currently, the information is automatically sent to the GP by default. It may be better to allow the user to send to more than one person (e.g. a dietician would be more interested in diet logs).
• It wasn't completely obvious to Fiona at first where to go to send information, as it is located in the "View Info" section.
  

Turn On/Off Home Security

• "Does this mean everyone has to leave the house as soon as this comes on?" Fiona activated the security with no issues, but she was worried that people still in the house would set off the alarm.
  
• Fiona also had similar issues to Maureen with inputting the password, where she couldn't see what she was writing.

Evaluation

Fiona was already used to similar devices, so she handled the interface well. Most of her issues were to do with appearance or functionality to suit her life. Some potential improvements arising from this walkthrough are:

• Ensure the watch knows if the user has taken it off.
• The watch needs some method of informing the user of its current state.
• Enable sending information to different people.
• Enable replying to messages.
• Have a countdown screen after turning security, which allows a certain amount of time before the security is activated and the device is locked.
• Make the watch functions more obvious and less conflicting.
• Provide "Undo" functionality for easy removal of added information.
• Remove the need to modify date and time.
• Ensure the user knows the sender of a message.
• Allow the deletion of old information.
  

Prototype Testing - Maureen's Walkthrough

Here are the results from our prototype walkthrough with Maureen, based on general points mentioned and performance during the scenarios given.

General

• Maureen had trouble both using the stylus due to her arthritis and placing it in the storage compartment on the side. She suggested that the stylus should be larger and easier to remove and put away.
• When we first explained the device, Maureen got excited about it, but for a different purpose to what was intended: "I'm always getting into silly situations where I'd need to call someone, like just the other day, the stairlift stopped midway and I was all alone in the house..."
  

Inputting and Logging Weight Information using the Touch Screen

• This was the first task, and so Maureen was not sure what to do at first. However, she was very inquisitive, and once she had read the instructions she knew what to do, and pressed "Add Info".
• Once on the input screen, she asked what it meant by "write". We showed her that she could scribble text on the screen, and she knew she could write what she wanted.
• She spelt "weight" wrong the first time, and we had not defined any form of error message to recover.
• She didn't want us looking as she put her weight in, but she did it fine.
• "Added, where?" It wasn't clear to Maureen where the information had been stored, as it wasn't visible on the screen.

Viewing Weight Input

• "Do I do this the same way as before?" Maureen was starting to get the hang of the navigation.
• "The writings a bit small, I'll have to change my glasses" We showed Maureen how to zoom in on text, she was impressed.
• Maureen pressed the send button on one of the pieces of information by mistake. Initially she panicked, but after she looked at the confirmation screen she pressed "No - Go Back".

Modify the Date and Time

• "Do I go to Add Info?" The wording of the task and the main buttons confused Maureen, it was not obvious that the date and time settings would be in the "Settings" section (although the instructions did mention it, she wanted to figure it out on her own). Eventually she tries "Settings", and sees the option.
• She writes the date as "18th March 2007", and the time as "2:16". The date on the confirmation screen was not displayed in the same format, so it took longer for her to figure it out. Also, AM or PM was not specified, and no consideration for this was taken by the device.
• "Did it do it?" There was no notifiation screen like with adding info, which confused Maureen.

Access Messages and View an Unsent Message

• "This one's easy!" Maureen pressed the right button immediately.
• Maureen tried the same method for zooming in worked successfully.
• Maureen pressed "delete" by accident, but the confirmation screen appeared like before, and she knew what to do.
• Views a message successfully - "This ain't my doctor!"

Set off the Watch Emergency Alarm

• "Looks like I'll have to read the instructions."
• Maureen set the alarm off after reading the instructions, but panicked as she hadn't read how to turn it off. She has to read through the instructions while the alarm is going off, and eventually finds how to do it. However, she mistakenly presses the button too many times, which activates the emergency phone call feature. At this point we had to step in and sort it out.

Call the Emergency Services using the Watch

• "Did it work?" After Maureen pushed the button, there was no indication that the watch was actually making the call.

Turn On/Off Security

• "But I don't have security" We explained to her that it was just for testing, and that she could have a security system installed if she wanted to when the system was finished, but she was reluctant to this idea.
• "I remember that in settings!" Maureen goes straight into the Settings section to find the security part. She presses the right button ("Turn On" instead of "Edit"), and presses "Yes" at the confirmation.
  
• "I can't see what I'm writing" To protect password security, the users writing isn't displayed when entering the password. However, this caused Maureen to make many mistakes.

Evaluation

Overall, Maureen did fairly well with the system. Her main problems were with the stylus and the watch, and also she tended not to read instructions. Some potential improvements based on this walkthrough:

• Extend the watch to be able to make calls to other people in a less serious emergency (e.g. a family member).
• Make the stylus larger and easier to place in the device.
• The security system was not popular, removing it is a possibility.
• Make some of the functions only mentioned in instructions (e.g. zooming in, reading text, etc) more explicit.
• We need to handle erroneous conditions and provide the user the means to recover from them.
• Change some of the wording of buttons.

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.

New Fabric

Guys take a look at this article on the bbc some interesting new technology which could be of relevance somehow maybe???

BBC Artical

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.

Final Prototype - FEATURES

-Watch

* Tells the time, user can change the time by twisting the button.
* Monitors heart rate.
* Tracks users movement and location.
* Automatically sends emergency signal if strange occurrences happen
(e.g. the user has stopped moving, and the pulse has dropped).
* User can activate emergency alarm by pushing in and holding the
button for a certain amount of time. This puts them directly
through to the emergency services, and they can talk to them
through the watch.
* Also activates/deactivates their home security if they have it
installed. This is done by pressing the button once.


-Input Device

* User can input general health information, which is stored in the
device.
* Examples: weight, lung capacity, blood pressure, diet log,
exercise log, etc.
* User can view information they have entered, and edit if necessary.
* The device lets you send information to your GP.
* GP can send messages to device (e.g. providing advice, arranging
appointment times, etc).
* Ability to customise some options (e.g. date format, colours,
metric vs imperial values, etc).
* Stores a list of common foods with their nutritional values. If
the user is creating a diet log, they can use these instead of
typing in calorie values manually.
* Navigate using touch screen “soft buttons”.
* Ability to hand-write instructions (text recognition) or speak
instructions (speech recognition). Speaking instructions can act
as a short cut method to perform tasks. Assumes text and speech
recognition in the future are accurate enough for this purpose.
* Relevant instructions are displayed in left screen.
* Ability to zoom in and out, using two fingers to “stretch” the screen.
* Ability to change store and change contact details for user and
doctor.
* All text on the screens can be read out by the device by hovering
over the text using the stylus.
* Ability to set a security password for the optional security
system, which can be used as an alternative to the watch method
for activating the security alarm.


-Black Box

* If for some reason the user cannot send data using GPRS, they can
send it via the black box using their home phone line. This is
performed automatically, and only works if the user is within
Bluetooth range of the black box.
* The box stores the user’s details, the doctor’s details and
security passwords, as well as a back up of information stored on
the input device. In the case of a serious emergency, the details
can be extracted from the box by emergency services if they are
unavailable any other way.
* The box acts as a central hub for the optional PIR sensors, and
sends a silent alarm to emergency services if the security is
violated (as well as sounding a regular alarm).
* The user requires no direct interaction with the box.
* Optional extra, can be installed if the user wants better home
security.

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.