Permalinks

Permalinks to demonstrate learning outcomes

Explain and discuss practical and theoretical aspects of HCI interaction.

This blog entry discusses the HCI principles of different methods for UCD and the initial creative approach. It also discusses different ways of creating the persona.

http://msc-hci-project-2007.blogspot.com/2007/01/young-uns.html

This blog discusses the design principles that were discussed as a group and which were followed in the creation of the prototypes

http://msc-hci-project-2007.blogspot.com/2007/02/wednesdays-meeting.html

Whilst this blog primarily deals with research in the area of GPS systems, it also states the aims of the final prototype to fit in broadly with Fitt’s Law.

http://msc-hci-project-2007.blogspot.com/2007/02/web-space.html

This blog followed on from the discussion of different methods of evaluating the final prototype and creating some valid empirical evidence from this.

http://msc-hci-project-2007.blogspot.com/2007/03/brief-write-up-of-6th-march-meeting.html

The following blogs all look at the different types of products that are already present on the market for each of the main sections that were identified. These analyse the existing products based on various HCI products, looking at which parts of the products are though to conform well to HCI principles and which don’t.

http://msc-hci-project-2007.blogspot.com/2007/02/web-space.html

http://msc-hci-project-2007.blogspot.com/2007/03/phone-research.html

http://msc-hci-project-2007.blogspot.com/2007/03/automated-lighting-research.html

http://msc-hci-project-2007.blogspot.com/2007/03/emailbrowser-research.html

http://msc-hci-project-2007.blogspot.com/2007/03/emergency-system-research.html

Apply HCI Principles to practical problems

This blog shows the results of the brainstorming session that was held. After a discussion of the various different types of creative methods available, brainstorming was decided upon being the most effective in this initial stage, with any idea about anything being permitted. The write up for this is found at;

http://msc-hci-project-2007.blogspot.com/2007/01/2nd-meeting-30th-jan-07.html

and the photographs of the brainstorm diagram at;

http://msc-hci-project-2007.blogspot.com/2007/02/pictures-from-our-first-meeting_03.html

The following blog entries all contain various prototypes that were designed using HCI principles gained through research;

http://msc-hci-project-2007.blogspot.com/2007/03/heres-diagram-to-show-how-my-prototype.html

http://msc-hci-project-2007.blogspot.com/2007/02/prototype-pictures-lights-menu.html

http://msc-hci-project-2007.blogspot.com/2007/02/prototype-pictures-phone-menu.html

http://msc-hci-project-2007.blogspot.com/2007/03/emergency-system-prototype.html

http://msc-hci-project-2007.blogspot.com/2007/02/prototype-la-sam.html

Each of these prototypes were then analysed using various different evaluation techniques.

http://msc-hci-project-2007.blogspot.com/2007/03/heuristic-evaluation-of-phone-menu.html

http://msc-hci-project-2007.blogspot.com/2007/03/cognitive-walkthrough-of-light-menu.html

http://msc-hci-project-2007.blogspot.com/2007/03/observations-from-cognitive-walkthrough.html

http://msc-hci-project-2007.blogspot.com/2007/03/emergency-system-prototype.html

http://msc-hci-project-2007.blogspot.com/2007/02/prototype-la-sam.html

This blog entry shows some of the videos that were created as part of an immersion into the user’s world. These were created following on from the definition of the persona’s to help identify what other problems an older person may have that hadn’t been though of.

http://msc-hci-project-2007.blogspot.com/2007/02/selected-videos-of-day-in-life-of-ethel.html

The following two blogs show the creation of the two persona’s that were used as the basis for the design of the prototype. These were created using the persona design methods put forward by Pruit and Grundin.

http://msc-hci-project-2007.blogspot.com/2007/02/meeting-on-mon-5th-feb.html

http://msc-hci-project-2007.blogspot.com/2007/02/ethyl-enjoys-volunteering-in-her-local.html

http://msc-hci-project-2007.blogspot.com/2007/02/meeting-on-mon-5th-feb_05.html

http://msc-hci-project-2007.blogspot.com/2007/03/reg-scenario-analysis.html

The following blog shows the user needs analysis that was used in the creation of the above personas;

http://msc-hci-project-2007.blogspot.com/2007/02/user-needs-analysis.html

This blog provides the problem definition that was used at the beginning of the project after an analysis of the initial idea to come up with a more defined problem.

http://msc-hci-project-2007.blogspot.com/2007/02/problem-definition.html

Participate in analysis and design work in HCI.

The following blogs all show the participation of each team member in the design of their own prototype.

http://msc-hci-project-2007.blogspot.com/2007/03/heres-diagram-to-show-how-my-prototype.html

http://msc-hci-project-2007.blogspot.com/2007/02/prototype-pictures-lights-menu.html

http://msc-hci-project-2007.blogspot.com/2007/02/prototype-pictures-phone-menu.html

http://msc-hci-project-2007.blogspot.com/2007/03/emergency-system-prototype.html

http://msc-hci-project-2007.blogspot.com/2007/02/prototype-la-sam.html

The final prototype was created by the team, after a discussion of each individual prototype and the final prototype is shown below;

http://msc-hci-project-2007.blogspot.com/2007/03/final-prototype.html

The blog below shows the application of design of the evaluation questionnaire that was used in the final evaluation;

http://msc-hci-project-2007.blogspot.com/2007/03/brief-write-up-of-6th-march-meeting.html

Evaluation

Overall Evaluation

We set out to design a product using a User Centred Design approach.

The following outlines how we applied the process to the design of our idea.

Idea Gathering
We brainstormed and rationalised all the ideas we came up with. The main contenders were a wheelchair for elderly, a training suit for children that would use kinetic feedback. We did this using whiteboard mind maps.

Idea Selection
We created personas, namely Reg and Ethyl, to try and envisage which idea would have the most strengths and how we could develop it further

Information Gathering:
Problem Definition
Elderly people have difficulties with technology and are less mobile in general, we were trying to minimize the effects age might have on peoples mobility and independence.
User Needs Analysis

Realising specific needs of the end user and taking these into consideration in our design.
Task Analysis

Finding out how end users perform given tasks and how our design could change this. We recorded videos setting out different scenarios as part of this.
Scenario Analysis

We conducted this on our personas, to see if we find it reasonable that the personas created, would benefit from our product
Further research into developed technology was carried out throughtout the process. We also researched potential future technolgy.

First Generation Prototypes
Creation - we designed prototypes different aspects of our interface. We purposefully did not collaborate on these so we could benefit from seeing several different designs and using different methods (paper/powerpoint/html/flash). We compared the results we got.
These were evaluated using:
think aloud evaluation
cognitive walkthrough evaluation
heuristic evaluation

Final Prototype
We discussed improvements after first generation and then decided on a overall design (coloursheme/buttons/...) of the prototype. Powerpoint was selected as the method of implementing this. We joined individual parts together and used a questionnaire to analyse what our personas and people typical of our personas, thought about our design, to help with the next stages of refinement.


If We Had More Time.....
One element we would have liked to have expanded was the use of questionnaires. In an ideal world we could have written a questionnaire shortly after the adoption of our chosen project, to receive some feedback from members of the target audience as to the viability and usefulness of the expanded wheelchair system. It also might have been helpful to have used some questionnaires after the adoption of our initial prototypes. We had, in fact, planned to do this, but we simply fell short of time and as such used a range of HCI related evaluation techniques to refine the initial prototypes.

This leads on to a second important change we would have made in the design process, namely more focus on the analysis of prototypes. Using questionnaires to gain feedback is certainly an element of that, allied with more exhaustive evaluations and real user input. The final prototype, while subjected to some questionnaire feedback, could probably have used the input of users in the target group, particularly in something like a think aloud evaluation. For example, a female in her 40s who is a wheelchair user participated in part of our evaluation at the initial prototype stage, but such input was not, in fact, as useful as exposing the prototypes to someone much closer to the target user group. The response which best illustrated this was her comments that there wasn't a great degree of flexibility and customization in the menus - the point we are trying to make being that while she fulfilled part of the user group in requiring a wheelchair, she did not fulfill the other part, namely being elderly. The prototypes were of course designed with this in mind, not for someone who is confident with computers.

A final task we would have liked to have had time to carry out was greater statistical analysis of the questionnaire results from our final prototype. A certain degree of low-level analysis was performed, but further analysis could have been insightful, particularly given that we did not test our final prototype on potential end-users.

Problems We Faced

The main problems we faced in this project revolved around our personas. We found it quite difficult to design the personas and think like a persona especially when it came to the evaluation of the prototype. We have all been children so could remember that time in our lives but obviously having not reached old age, it was harder to design for this group.

The second main problem we faced was putting the prototypes together. The first prototype was difficult to put together because we all designed a separate section of it in our own style. This then meant that designing the final prototype was problematic because we had five different design styles to combine whilst taking into account the strengths and weaknesses of each that had arisen during the evaluation phase.

Thirdly, we faced problems regarding the design constraints. For example, the colours of buttons and the layout of the keyboard that we needed for various parts of the system. We needed a keyboard with full punctuation for the email / internet section. However, we wanted the phone section to be simple, therefore didn't include any punctuation in this keyboard. This meant that both looked different and may have confused the user. We also wanted specific colour schemes for different parts of the system but this was difficult to decide on if we were to consider possibilities such as colour blindness and associations that people make. For example, associating red with “stop” and green with “go.” We eventually made decisions that attempted to satisfy as many of these criteria as possible.

Conclusion

We took the user centred design process and used it to design our wheelchair.

We faced quite a few difficulties along the way but found that user centred design is crucial when designing a product that is hopefully going to be mass marketed. A lot of the things we take for granted such as usability and colour schemes cannot be assumed with older people. Therefore using user centred design when designing for a specific market is not only sensible but necessary as well.

Questionnaire Statistics

CLARITY Mean Score Email and Web 5.6 Phone Menu 6.9 Emergency System 7.4 Automated Lighting 6.8 GPS system 7 EASE OF USE Email and Web 5.7 Phone Menu 7.7 Emergency System 7.9 Automated Lighting 6.7 GPS system 7 COLOUR SCHEME Email and Web 6.7 Phone Menu 6.7 Emergency System 6.7 Automated Lighting 6.6 GPS system 6.2 MENUS Email and Web 6.4 Phone Menu 7 Emergency System 8.2 Automated Lighting 5.8 GPS system 6

General Statistics

The mean age of the participants was 75.5 years of age. 50% of out participants were male and 50% were female. The average score for frailty was 5.8.

Discussion of Statistics

The scores above are out of 10 and show that the emergency system menu was rated as the clearest. This is probably because the emergency system is present on all menus and requires little effort to use or to navigate through menus. The email and web browser was rated lowest for clarity. This is probably because participants were least familiar with using email and the internet. In fact, the average score for confidence with the internet was very low(3.3 out of ten) as was confident with computers in general (4.5 out of ten). In terms of ease of use, the emergency system menu was rated as the easiest to use and the web browser scored the lowest for ease of use probably for similar reasons as above.

The colour scheme scores were all similar and this is probably because the colour scheme was kept consistent throughout all the menu systems. We also decided to use clear easy to read text on the buttons and this probably resulted in the colour scheme being less important in terms of clarity. The emergency system scored highest for the flow of the menus and the automated lighting system scored lowest. The emergency system requires little navigation where the automated lighting system can require quite a lot of navigation depending on the exact tasks the user wishes to carry out (i.e which lights / how many lights they want to turn on / off).

Questionnaire

Here's the questionnaire we used to gather opinions on the final prototype. The formatting is not the best so when describing the scales(extremely confident)(not at all confident) would relate to 1-10 for example or vice versa depending on the question. THE SCALES ARE UP TO TEN by the way.

The following questions relate to you.

1.) What is your age?

________ years.

2). Are you male / female?

3). On a scale of 1 to 10 how frail do you consider yourself to be?

1

2

3

4

5

6

7

8

9

10

(very frail) (not frail at all)

4). On a scale of 1 to 10 how confident are you using mobile phones?

1

2

3

4

5

6

7

8

9

10

(not confident at all) (extremely confident)

5).On a scale of 1 to 10, how confident are you with computers?

1

2

3

4

5

6

7

8

9

10

(not confident at all) (extremely confident)

6)How confident are you with using the Internet?

1

2

3

4

5

6

7

8

9

10

(not confident at all) (extremely confident)

The following questions relate to the product you were asked to use and the different sections of the product.

EMAIL AND WEB BROWSER

7). On a scale of 1 to 10, how clear were the buttons?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

8) On a scale of 1 to 10, how easy to use was the product?

1

2

3

4

5

6

7

8

9

10

(not easy at all) (extremely easy)

9) On a scale of 1 to 10, how clear was the colour scheme?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

10) How comfortable were you with the menu system?

1

2

3

4

5

6

7

8

9

10

(not comfortable at all) (extremely comfortable)

11) Would you use this product?

Yes / No

PHONE MENU

12). On a scale of 1 to 10, how clear were the buttons?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

13) On a scale of 1 to 10, how easy to use was the product?

1

2

3

4

5

6

7

8

9

10

(not easy at all) (extremely easy)

14) On a scale of 1 to 10, how clear was the colour scheme?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

15) How comfortable were you with the menu system??

1

2

3

4

5

6

7

8

9

10

(not comfortable at all) (extremely confident)

16) Would you use this product?

Yes / No

EMERGENCY HELP SYSTEM

17). On a scale of 1 to 10, how clear were the buttons?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

18) On a scale of 1 to 10, how easy to use was the product?

1

2

3

4

5

6

7

8

9

10

(not easy at all) (extremely easy)

19) On a scale of 1 to 10, how clear was the colour scheme?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

20) How comfortable were you with the menu system?

1

2

3

4

5

6

7

8

9

10

(not comfortable at all) (extremely comfortable)

21) Would you use this product?

Yes / No

AUTOMATED LIGHTING MENU

22). On a scale of 1 to 10, how clear were the buttons?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

23) On a scale of 1 to 10, how easy to use was the product?

1

2

3

4

5

6

7

8

9

10

(not easy at all) (extremely easy)

24) On a scale of 1 to 10, how clear was the colour scheme?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

25) How comfortable were you with the menu system?

1

2

3

4

5

6

7

8

9

10

(not comfortable at all) (extremely comfortable)

26) Would you use this product?

Yes / No

GPS NAVIGATION MENU

27). On a scale of 1 to 10, how clear were the buttons?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

28) On a scale of 1 to 10, how easy to use was the product?

1

2

3

4

5

6

7

8

9

10

(not easy at all) (extremely easy)

29) On a scale of 1 to 10, how clear was the colour scheme?

1

2

3

4

5

6

7

8

9

10

(not clear at all) (extremely clear)

30) How comfortable were you with the menu system?

1

2

3

4

5

6

7

8

9

10

(not comfortable at all) (extremely comfortable)

31) Would you use this product?

Yes / No

Final Prototype

The final prototype is now available here or at http://woolfben.uwcs.co.uk/hci_combined.ppt if that doesn't work.

Final Meeting Write-up

Those Present: Andy, BJ, Jenny, Max, Sam


Issues Addressed:

• Integration of final prototype
• Usage of a questionnaire on the final prototype
  
• Write-up of a project evaluation

Decisions Made:

• Integration of the final prototype ought to be a relatively painless exercise, mostly requiring links to be updated between different sections. The various sections should all have been redesigned with a uniform style in mind. It was decided that BJ would take the various sections away to finish the integration process and post it as soon as possible.
• Once the final prototype is finished it will be subjected to a final questionnaire so that we can gain a certain degree of feedback; it should be noted that this is NOT another round of evaluation and re-design as we do not have time to incorporate any changes from this round of feedback.
• Having completed the previous two tasks we will write a final evaluation of our whole project. This will be split into sub sections, assigned to different group members, and then put together once each section is written.
  

Heuristic Evaluation of the Phone Menu

Visibility of System Status

The phone menu satisfies this heuristic quite well. The user can see what is happening as they navigate through the phone system’s menus. However, one problem that arose was what was displayed when a call was in progress. This caused some confusion because the user was not sure if a call was being made or not.

Match between system and the real world.

The phone menu satisfied this heuristic well. Users understood the terms used and did not have a problem. The only aspect of this that was raised was the term “contact”. It was suggested that “phone number” or “person” be used instead.

User control and freedom

There are clearly marked “main menu” and “back” buttons ensuring the user could move around the menu easily. However, the system could have benefited from an additional “clear” button the deal with mistakes when inputting phone numbers or contact names. When users made a mistake with the current prototype, they had to “dial” and then “end call” to start again. Similarly, when entering a new contact, users had to go “back” without saving and then select “add new contact” to start again if they had made a mistake.

Consistency and standards

The prototype passed this heuristic well. Users were clear on the meanings of all terms such as “add”, “delete”, “call” and “save”. There were no terms that were ambiguous or unclear.

Error prevention

The phone prototype had a good error handling message when the user was deleting a contact. The confirmation screen was clear and reduced the likelihood of users deleting contacts by mistake. The prototype seemed to have a good balance between usability and error handling. For example, it would have negatively impacted on usability if everything was confirmed by a message simply to present errors. A good example of this is adding a contact. There would not have been much benefit gained from a confirmation message here and the impact of entering an incorrect contact is not as great a deleting one.

Recognition rather than recall

The design of the phone menu satisfies this heuristic well. It is designed to look like a normal telephone so is immediately recognisable to users. The user also does not have to remember what order things need to be done because the keypad is always present on the right hand side of the screen. The presence of “back” and “main menu” buttons also ensures that procedural knowledge is not necessarily required.

Flexibility and efficiency of use

The system did not have much in the way of flexibility but this is not a bad thing. Many users of the system are going to be novice users and as such will not require any modifications. The system does have recent call lists and this allows frequent numbers to be accessed quickly. However, there is not a way to tailor a favourite numbers list.

Aesthetic and minimalist design

The prototype served this heuristic well. Clear language is used that is not overly technical. The delete contact confirmation message is clear and not presents the message without confusing the user. All buttons are clearly labelled with sensible choices of words that are self – explanatory.

Help users recognise, diagnose and recover from errors

The prototype encountered a problem with this heuristic. One of the users I observed added a new contact but mistyped the phone number so that it had an extra digit, so that consequently when attempting to telephone this contact, the user was presented with an error on the phone. The system had not dealt with incorrect data entry. The user became quite confused as to why the error was occurring until they spotted the mistake they had made. A solution might be to limit the number of digits a phone number can have, or have an additional confirmation message to allow the user to double check the phone number they have entered. Another possible solution might be to have the system present an error message when an incorrect number is dialled suggesting that the user checks the phone number and dials again.

Help and documentation

There was no documentation to accompany the phone menu. However, the simplistic and clear design meant that this was not a problem. All users were able to make call and end calls because they recognised the design of the keypad as being similar to normal phones. Documentation may have been useful for users wishing to add and delete contacts but not necessary.

Walkthrough of Light Menu

Just the walkthrough that Andy did at the moment.

Initial button;
Very clear symbol of a light bulb - very clear what the option means.
Black and qhite colour scheme could be made more helpful with colour.
Lights written clearly, good pictorial and with large text.

Main Screen
Quite a lot of options which makes it slightly confusing as to where to go.
All lights are on\off button are at the top, but the layout is a bit confusing.
Large buttons which are clearly labelled as to what exactly they do.
Button "Choose Room" is a little confusing - choose room for what?
Confirmation is god - when go to click all lights off – clearly explains exactly what is about to happen.

Room option
Very clear and simple menu – only options are on and off. Clearly described what they do.
Needs some form of background colour that give continuity and make things stand out more.
Helpful this room on or off feature.

Other Points
Back button does indeed work.
Click noise when pressed gives confirmation of action.
Graphics confusing and take away form action.
Raised buttons may be useful for this.
Lights respond instantly – know that if you’ve heard the click and lights don’t go on then there is a problem
However what do you do in this situation – failure handling?

Observations from a Cognitive Walkthrough Evaluation for the Emergency Help prototype

• To enter the emergency screen the user presses a big red button, the function of which is obvious
• In the main screen the buttons are slightly confusing, being of different sizes and styles
• The font used is quite small, it's a bit of a struggle to see
• The depictions used on the emergency services buttons are inconsistent, some are photos some symbols
• Each button has a different major colour. The fire button seems particularly large
• The cancel button is green, which gives the impression that it should make the programme continue, not halt
• Having opted to contact one of the emergency services a clear message is displayed informing the user what action has been taken.
• A slight irritation is that after calling for help there is no way of returning to any of the menus.

Emergency system research

Emergency help systems on the market today generally use a similar system:

1) The user is provided with a wearable "emergency" button, usually on a neck chain or wristband.
2) When the button is pressed, the system uses the home phone line connects with a central response centre, which attempts to contact the user and ascertain their status.
3) If contact is made, the appropriate course of action is determined and taken. If contact cannot be made, emergency services are alerted and dispatched to the home of the user.

Link or at http://www.ftc.gov/bcp/conline/pubs/services/pers.htm

Examples of emergency help systems:

Phillips Lifecare or at http://www.lifelinesys.com/content/how-lifeline-works/index.jsp
Redi-Safe or at http://www.redisafe.net/

This system would be inappropriate for our purposes, as the wheelchair is intended to provide mobility to people whose freedom would otherwise be limited.

Useful modifications to the system would include monitoring of the user's vital stats, both to provide useful information to the emergency services in case of contact, and to enable an automated emergency call in the case of the user falling unconscious without pressing the contact button.

Systems to determine a person's health remotely have been in development for some time, with a radar-based system similar to Star Trek's tricorder and "smart fabrics" being two possible options.

Radar system link or http://www.llnl.gov/str/pdfs/01_96.2.pdf and Smart fabrics link or http://news.bbc.co.uk/1/hi/technology/6460033.stm

To contact the emergency services whilst not at home, the phone functionality of the wheelchair could be combined with the built in GPS system to pinpoint the user's current location. Alternatively, wireless internet could be used to contact the emergency services and transmit the vital data, whilst triangulation based on signal strength could locate the user within the wireless zone.

Spread of wireless technology across Britain or at http://news.bbc.co.uk/1/hi/technology/4993038.stm

Automated Lighting Research

Automated lighting systems in various forms are currently available quite widely. However, many automated lighting products seem to be focussing on the environmental reasons for implementing such a system. Technology at the moment is being used to control lights as a person leaves a room to conserve energy. http://news.bbc.co.uk/1/hi/technology/6067900.stm).

This is clearly worthwhile, but this project is concerned with using this technology to aid the lives of elderly people who perhaps find it physically difficult to get up and move around to switch lights on and off. Automated lighting would also allow lights to be switched on in a room before the person moves there reducing the chance of an accident happening such as a trip or fall. Such products already exist in some forms and it would be worthwhile to adapt existing technology to fit on our wheelchair.

There are schemes that have looked at energy efficiency and home automation in combination. One of these took place in the Netherlands and found that automated lighting systems that are triggered by movement are not very popular with elderly residents because they are often triggered to come on when the resident does not want it to. (http://mail.mtprog.com/CD_Layout/Day_2_22.06.06/0900-1045/ID193_Kester_final.pdf). There are benefits to the environment of this kind of system but a better approach would be to have a user controlled automated system.

www.uk-automation.co.uk has details of products that are currently on the market. This website also outlines the steps needed to convert a home so that the lights can be controlled via remote control. Three components are needed to install the system described by www.uk-automation.co.uk. A transceiver module is needed to receive the signal, wall switches need to be adapted and a remote control is also required. The estimated cost of such a system is around £75 for the first room then around £25 per room after that. For this project, much of the existing technology could be used. The changes needed would be to have the control system as part of the user interface on the wheelchair. The remote control currently on the market (http://www.uk-automation.co.uk/handheld-remote-control-p-1091.html) is probably quite good but it would be easier to have the controls clearly labelled and always available on the interface. The advantage of having such a system as part of the overall interface is that the remote control would not get lost as may be the case with the above system.

The above approach requires quite a lot of electronics knowledge to implement. It may be better to consider out automated lighting system in the context of future homes that could be built with this technology in mind. Specifically, it may be efficient to take advantage of the use of Bluetooth technology. This is widely available in mobile phones and laptops and is relatively cheap to implement.