Emergency system prototype and Heuristic Evaluation of E-mail prototype

The emergency services system prototype can be found here or at http://woolfben.uwcs.co.uk/prototype/interface.html if that doesn't work.

According to my research, older people generally get on well with:

Single screens - no scrollbars.
Simple language - no technical terms.
Big, easily selected icons/links - preferably distinguishable by shape and colour as well as by label.
Static menus - no moving objects or drop down lists.
Concise and obvious labels - preferably including a verb to signify the relevant task being performed.

Points to take into account are:

Failing eyesight/colour blindness
Impaired mobility
Reduced attention span

To this end, the prototype given has simple screens, with no scrolling whatsoever. Buttons are clearly labelled with explicit actions on the menu, and clear choices in the submenu. Simple language is used in large, readable font, in colours chosen to contrast strongly to the background image of the relevant button. Buttons are distinguishable by labels, shape/size, and colour, to prevent colour blindness or failing eyesight from hampering usage of the product. All objects are static and clickable, to prevent confusion and for ease of use. Buttons are also well spaced and large enough to be selected without a need for high accuracy.

Further, an heuristic evaluation of the E-mail prototype (found here or at http://woolfben.uwcs.co.uk/HCI%20Prototype.ppt follows:

Visibility of System Status

The e-mail menu satisfies this heuristic, as each page of the prototype informs the user of the current status and options available to them.


Match between system and the real world.

The e-mail menu matched the real world well, using non-technical termoniology where possible, and no system specific language whatsoever.


User control and freedom

The menus all contained a Back button to cancel the current operation, as well as a backspace on the typewriter keyboard to allow undo functionality.


Consistency and standards

The prototype was generally consistent with itself, however in some cases buttons (notably the Back and OK buttons) changed location on different pages, which should be fixed in the final design.


Error prevention

Use of the delete function came up with a confirmation dialog, as expected. Other functions did not require or provide any confirmation, as the impact of errors would be negligible compared with the decrease in usability.


Recognition rather than recall

The prototype satisfies this heuristic well, as the design clearly shows each stage of sending an e-mail, and allows fields to be completed in any order.


Flexibility and efficiency of use

The e-mail system allows storage of favourite contacts, providing easy access to frequently used addresses. Beyond this, little flexibility is provided except possibly through the Advanced options.


Aesthetic and minimalist design

The design is largely kept minimalistic, with only the basic options provided by the system. Further customisation is available through the Advanced options dialog, which is likely to confuse novice users and probably should not be made accessible in general.


Help users recognise, diagnose and recover from errors

Mistyped information is easily dealt with by use of the Backspace or Delete keys on the keyboard interface. However, incorrectly entered e-mail addresses pose a problem, as the prototype does not show an error message to respresent this. A system to check the validity of the e-mail address on sending, and pop up a simple error dialog if it is invalid, would be a good solution to this issue.


Help and documentation

No help or documentation was provided or required by this prototype, as all functions were easily explained by the onscreen prompts on each function button.

Prototype a la Sam

Sam's prototype is now available here or at http://woolfben.uwcs.co.uk/Prototype.swf if the link is being troublesome.

think aloud evaluation of 'directions' prototype:

It has been difficult to make full use of the think - aloud data gathering, since the prototype assumes moving freely in a wheelchair, so improvisation was involved to some extend.

clear large buttons made it easy for my mother to see which she should press and intuitive labeling gave a clear insight into what each button would do, however the map was much too small for her to make use of. It was also noted that, while all the 'location' links included the same destinations, clicking on them moved the map immediately, rather than indicating where she should move to from her location. However the descriptions as to where to move to were useful, assuming they will coincide with where she currently is and update accordingly should she choose/ decide to go a different direction. with no way of knowing wether the functions will give wheelchair friendly routes (ie, lowered pavement at every crossing, wide pavements over narrow ones, ignore pebbled areas) she assumed the routes were wheelchair friendly.

She made it clear that she would prefer alternative routes to and from locations, such that a " get route past 'location' " option would be sought after, the lack of options to add custom locations or custom 'topics' was also apparant, at this stage it should be noted that she is a relatively advanced computer user.

All in all the actual interface was considered good and easy to use, however some functionality seemed to be missing, and other functionality had to be assumed to be assumed to be working in good order due to the inherent difficulties in performing the analysis.

In further discussion regarding our product she suggested contacting wheelchair agencies that specify in producing wheelchair friendly routes (note: i will have to check the name for this one). This recource could also be used to store more scenic routes in the navigation system.
On another note expected travel duration / distance from target location was thought to be missing though not deemed 'essential' to her.

Prototype Pictures - Phone Menu

Main Menu

• This was how I envisioned the main menu of the overall system. Each button is colour coded for ease of recognition, and the buttons ought to have a pictoral element which is easily identifiable with the associated function (the scope of my assigment was only the Phone sub-menu so the GPS and Emergency tabs do not have pictures as I couldn't think of anything suitable).

1st Screen - Options

• The right hand side of this screen shows the number display with dial and end call options and a number pad. This format is present in most of the screens in the sub-menu so that the user can almost always access the key feature i.e. basic phone functionality.
• The number of options on the left hand side is limited to essentials, with a phone book and the option to review past calls. A button enabling the user to return to the main menu is present and essential to maintain ease of use and good menu traversal.

2nd Screen - Phone Book

• When a name or a phone number is pressed on in the 'Phone Book' section, that number is copied over to the number display on the right hand side of the screen, where it can be called if required. The same applies to the dialled/received calls section.
• This screen retains the main phone display, and also shows the phone book interface. Names are displayed with their associated phone number and the user has the ability to change the contents of the address book - by adding new people, editing existing entries or deleting people. The top three buttons and the bottom two (back and main menu) should not move, but the section in between should be scrollable.
• To edit or delete a contact the user can either press the edit/delete button and then the contact's row, or vice-versa.

2nd Screen - Call List

• Maintaining the main phone display on the right, this screen shows the call list on the left hand side. This would be the same layout for dialled and received calls. Buttons again exist to navigate back one step or to the main menu.

3rd Screen - Add or Edit contact

• This screen is the only screen which significantly deviates from the previous screens. The size required for a keyboard with large enough buttons is a full screen. The phone display is not really necessary here either since this screen will only be accessed if the user wants to add or edit a contact. Only A-Z characters and numbers are allowed since nothing else is really necessary.
• Pressing on the name or number fields selects that attribute, and 'typing' replaces what was originally there.
• When editing a contact the contact's values are copied to the name/number fields; when adding a contact those fields are blank.

3rd Screen - Delete Confirmation

• I decided this option was necessary in order to prevent an accidental deletion of an entry in the phone book.

Prototype Pictures - Lights Menu

Here's the pictures of the prototype lights menu.

Prototype Research – Automated Lighting.

An automatic lighting system has many advantages. Firstly, it removes the need for the person to have to physically move to turn the lights off. In the video clip of Ethyl, one of our personas, we can see that she finds physical movement difficult. The second clip shows how an automatic lighting system would improve the process for her. Based on this, it is clear that a user interface is required. When thinking about the functions required, I decided that the actual button to take the user into the menu had to be clear and obvious. For this reason, I decided to use a large picture of a light bulb. The first menu the user sees gives the option of all lights on or off. I decided to do this because turning off all the lights and night and switching them on when it gets dark, are probably the most difficult tasks physically because they involve moving from room to room. The system would probably be most useful in these two situations.

I decided to have a confirmation message when the user opts to turn all lights off. I did this because I thought it might be quite frightening if this was selected by accident and the user was left in complete darkness. The confirmation message reduces the chance of this occurring without significantly complicating the process.

Also on the first menu, I decided to include a “choose room” button and a “main menu” button. The “main menu” button takes the user back to the overall main menu rather than the lighting control menu.

The “choose room” menu gives the user the chance to turn all the lights on or off in each room. Again when selecting lights off for a particular room, there will be a confirmation message.

The main concern for this particular prototype is the design of the user interface. Specifically, the colours and fonts used as well as the size of the text. I propose that the buttons are large with a black background and white text in a clear font that is not italic. I then aim to test this prototype on our persona to confirm these design decisions and modify them as necessary.

Selected videos of 'a day in the life of Ethel Rose'

Ok I uploaded a selection of the videos we made today onto You Tube, links are below. I chose the before and after videos concerning the GPS and phone clips since they were the most concise and fitted within the You Tube upload limit. The featured 'elderly person' is Ethel, one of our personas, played by Max and BJ.

Phone clip pre new wheelchair:

http://www.youtube.com/watch?v=mEwxFEEs98I

Phone clip post new wheelchair:

http://www.youtube.com/watch?v=K64Ylk_olnU

GPS clip pre new wheelchair:

http://www.youtube.com/watch?v=kHNADj9hKs4

GPS clip post new wheelchair:

http://www.youtube.com/watch?v=RFC0yM9oz_k

GPS Research

Research into GPS Systems for wheelchairs.

Currently there are several wheelchairs that are already equipped with GPS systems. However, from an analysis of these it is apparent that they are primarily designed for more active users, who are looking for an ‘off-road’ wheelchair and corresponding GPS systems.

One of these systems, developed by the Fraunhofer Institue for Information and Data Processing IITB incorporates some of the features that we are planning on developing, including a GPS system and electronic health monitoring with emergency call systems.[1] However, this system is designed for a rugged four wheel drive wheelchair, and offers just a standard GPS system, so user can fin their position, rather than a system to navigate wheelchair friendly routes.

One interesting research paper provides a good review of various Assistive Device Technology (ADT) developments.[2] Whilst this paper mainly focuses on the first of the three stages in a system such as this (the stages being; inputs (e.g. joysticks, buttons); control systems (systems to convert these inputs to motor functions) and finally outputs (such as motors and displays)), it raises some interesting points about limitations of mobility for controlling a wheelchair. Obviously our system is to be designed for those who need some help walking around, however this paper cites research that shows that mobility is whole body, in that an elderly person who has trouble walking, would also have much trouble operating devices such as switches and joysticks. Thus, it would be sensible to make much use of touch-screens within these systems, to aid ease of use.

One piece of research which is of much interest is that of Monash Universities Robotics Department.[3] In this research, an indoor system for automated wheelchair guidance has been developed. Using cameras and a topological map, the system identifies key points as it moves, and calculates where it has seen these before. Using the map the system can then ascertain where it is. Whilst our system is to use a futuristic GPS system that can work inside, this shows that our initial idea of using the GPS system with a map of the user’s home to show location within the home is a feasible reality.

This idea is taken up again by Cornford of Weber State University.[4] Having already developed a motorised wheelchair that can take a user to a pre-programmed destination, his current research is in looking at methods for indoor GPS. Citing a different approach to Charkravarty, this method involves the use of radio transmitters to help position a chair. One limitation that Cornford’s current system has though is one of object detection. There is currently no method in place to detect any objects that may be in the path of the chair. This should therefore be included in our proposed system.

One are of research that is not necessarily for GPS but would be of use is that of Fitt’s Law. This effectively maps the time taken for a user to point to a target. This broadly relates the time taken to press the button (in our case) to the log of the distance from the starting position of the user and the width of the target, relative to the movement of the user. We can basically take this as meaning that the buttons should be close to the user and there should be no great physical distance for the user to cover between buttons. This would fit in with Andy’s proposal that the screen be the size of an A5 piece of paper.

[1] Unkown, (2007), “The Four Wheel Chair Drive Hybrid Wheelchair” [online] available; http://www.gizmag.com/go/5538/ Accessed 06/02/07.
[2] Arshak, K. Buckley, D & Kaneswaran, K. (2006), “Review of Assistive Devices for Electric Powered Wheelchairs Navigation”, in Journal of the Institute of Technology Blanchardstown. 13, pp13-23.
[3] Charkravarty, P. (2005), “Vision Based Indoor Localization for a Motorized Wheelchair” [Online] available http://users.monash.edu/~pcha25/indoor%20GPS.htm Accessed 07/02/07
[4] Unknown, (2005), “WSU Students Develop GPS Guided Wheelchair” [Online] available
http://weber.edu/WSUToday/050905gpswheelchair.html Accessed 07/02/07

Reg Scenario Analysis

Reg has slowly moved away from a very active lifestyle consisting of working in the mines and playing rubgy to a more reclusive one. He does enjoy meeting up with some of his peers through work in his local, however now that his age and his breathing problems are catching up with him he finds himself in situations where he calls on his children to take him back home more and more often. He particularly enjoys spending time with his many grandchildren where he pushes himself as he tries to take on more than his health will allow him to do. Smaller activities such as going to church with his wife or walking his dog Dave are beginning to be a struggle for him.

Reg is opposing the need for any technology to help him spend more time with his family, they however are strongly encouraging him to take his difficulties more seriously.

His son Simon has suggested the wheelchair as a precaution, as it will allow him to save his breath when it comes to getting to and from the pub, church or park. He feels that it will make him more independent and allow him to do the things that he enjoys more often and if something serious does happen he will have the services available to come and help him out. Something that did get Reg’s attention in this discussion has been the vital stats monitor as this will warn him to take it a little easier when playing with his grandchildren before he would notice it, which could be of great benefit to his health.

He is adamant that he cannot and will not want to learn new technologies so if he does indeed try this chair it best be as straightforward as his TV or phone.

User Needs Analysis

The intended key users of our project are elderly people who have lost a considerable amount of mobility, but none of their mental faculties. As such their physical condition is a restraint on their independence, and our proposed wheelchair should enable them to reassert their independence to a greater or lesser degree. NOTE: Aspects of this wheelchair make it of use to a much wider segment of the population - from non-elderly disabled people to those over 60 who in addition to physical disablity also exhibit mental disibilities. However the entire package is most suited to the key user group as identified above.

The loss of physical mobility comes as a shock to most people. Simple everyday activities, which the individual has done with hardly a thought over the previous years, become serious obstacles. Life outside of the home environment becomes more daunting still. While the majority will be capable of some unaided movement, they tire easily, and this ends up restricting their tasks around the house and day to day plans.

Concern about a person's health - both from the individual and their family - naturally increases as a person ages. Indeed many elderly people are put into assisted living homes because of concerns over their health. Families want the best care availible, and homes with on site medical care have many highly skilled professionals on hand. However, such is the nature of an assisted living home (in contrast to a nursing home or indeed a hospice) that the medical staff are there to be called upon, rather than monitoring their patients much like in hospitals. This is not a bad thing by any stretch - enabling older people to regain some of their independence is hardly compatible with the intrusion of constant physical surveillance. There are going to be cases though where relatively common health problems (such as a heart attack or stroke) occur while the individual is alone and perhaps incapacitated, thus unable to call for help.

Communication Issues are also present; most elderly people are likely to have a landline phone, and are likely to be comfortable using such a phone. However, anything beyond that is unlikely. It is possible that many may have been given a mobile phone, but do not use it, and internet based communication is also likely to be minimal. With email rapidly becoming one of the dominant forms of communication, old people are missing out on a fast and convenient way to keep in touch with friends and relatives.

Problem Definition

Problem Definition

As people increase with age, it is a common problem that their mobility decreases. It has been noted from anecdotal evidence that this can often lead to frustration at the loss of mobility that these previously active people suffer. Whilst still being as mentally active as they were in previous years, the lack of mobility can often lead to large periods of being stationary. This can have a variety of impacts varying from decreased sociability, decreased participation in hobbies and activities to more serious problems such as serious difficulty in reaching shops or getting help in the case of emergencies. Thus the problem has been defined as;

To design a system that will offer older people who are starting to face varying degrees of mobility impairment, a wheelchair that enables them to increase their mobility whilst still maintaining their independence. The wheelchair would operate in two main environments, in the user’s own home and outside the home in the street.

The problem has the following main components;

To offer increased mobility;
Some users will require help getting round the home. Thus the system will need to address the following problems;
The wheel chair may not be in the same room as the user when it is required.
The user may have trouble manoeuvring round their own home.
The user may have trouble reaching light fixtures of heating controls.
The user may require the system to help them with stairs.
The user may have trouble with doors/windows.

The system will also need to address the following problems the user may face when out and about;
The user may not know where they are going or how they get back home from where they are.
The user may not want to be totally dependant upon a wheelchair.

To enable ease of communication.
If confined to the wheelchair for great periods in the home the user may require some form of communication in the form of phone or email.

To enable monitoring of any medical conditions.

To enable the user greater ease of control over appliances in the home.

Wednesday's Meeting

Howdy all. Sorry for being slack in getting this up.
Mainly for Max's benefit;
We all met on Wednesday to discuss prototyping (which is what we need to get done for next week). This was a really productive meeting I felt, and we managed to get some good points raised and some good discussion on what the main UI should have and also therefore what the systems should do. The main points raised were as follows;

- Following on from the video, that even if older people are happy to adopt technology, they often just don't know what we see as basic. Thus, there should be as little user configurability as possible. It was decided that this system would have to be installed by a professional who would then show the user how to operate it. Thus, the system should be as intuitive as possible to use.

- It was decided that the main method of UI would be from a touch screen, sized about half a page of A4 paper (21x14.8). Interaction would be in the form of a large picture of the function, with text underneath explaining what it does. It was decided to have a maximum of 6 buttons on this initial screen. Initially, these were decided as;

GPS\Travel
Phone
Emergency help
Lighting/Heating

- It was decided that there could also be other buttons (such as web/email) but these would be optional, as it was argued that not many older people would require internet access whilst out and about.

- It was decided that each button should be no smaller than a thumb. This is a pretty ambiguous size but it is just a rough guide.

-We decided against using speech recognition for the main method of control, as it was felt that this could cause frustration and confusion, especially if out and about. It was also decided to try and make the functions as simple to use and as familiar to the user as possible (i.e. the phone function would be provided by an actual handset with a graphical representation

- It was also decided to follow the Three Click Rule of web design where all main actions the system can perform can be accessed within three clicks. However, despite me arguing for it to follow this, I found this; Testing the Three Click Rule which argues against it.

- It was decided to split up the design of the prototypes as follows;
Me (Sam) – GPS\Travel
Andy – phone
BJ – Emergency help
Jenny – Lighting\heating
Max – Can you do web\email mate. You’ll need to chat with us about what we decided this should be like.

- Can people add to this with anything else that was said\decided upon (I think I've prob got the last but wrong)?

- I think it might be a good idea if we follow the IBM design principles of;
Simplicity: Don't compromise usability for function.
Support: Place the user in control and provide proactive assistance
Familiarity: Build on users' prior knowledge
Obviousness: Make objects and their controls visible and intuitive
Encouragement: Make actions predictable and reversible
Satisfaction: Create a feeling of progress and achievement
Availability: Make all objects available at all times
Safety: Keep the user out of trouble
Versatility: Support alternate interaction techniques
Personalization: Allow users to customize [Sam; could this one cause extra confusion and frustration?]
Affinity: Bring objects to life through good visual design.

If people could add to this then we can get cracking.

Next meeting – Wednesday 21st. This is to try out an old person in a wheelchair. BJ is worryingly keen to dress up as Ethel and I’ll have a wheelchair so we decided to spend the afternoon starting at Andy’s then making complete tools out of ourselves in Harbourne.

Cheers.

Ethyl enjoys volunteering in her local charity shop but relies on a taxi to get there and back which is quite expensive. She would prefer to walk but can't because of her frailty. A potential scenario in which the wheelchair would be useful is for getting Ethyl to and from the shop. A motorised wheelchair would allow her to spend time outdoors and would also reduce her outgoing costs because she wouldn't have to rely on taxis. However, Ethyl worries about getting lost so the GPS system would again be very useful. If Ethyl does get lost, she could simply press the “home” button on the GPS system and be guided home. Ethyl is also concerned about being mugged but the vital sign monitoring could also be adapted to have a panic button that automatically calls the emergency services if activated by Ethyl. Ethyl also enjoys a flutter on the horses and likes to bet small amounts online so the built in internet access on the wheelchair would allow her to check the latest odds. She would also have constant access to her email. Ethyl is also enjoys attending the University of the Third Age. This organisation provides informal learning opportunities for older people or people who are not employed.

see www.u3a-info.co.uk


She could also use her internet access to check latest lecture details and visiting speakers. University of the Third Age also provide specialist fitness classes for older people at a fitness suite and Ethyl could get more information about these and attend. This might improve her quality of life despite the fact she is frail because all the exercises would be tailored to someone her age with her health problems. The wheelchair would be useful for getting there in the first place and there are also classes that improve upper body fitness whilst the people are actually in their wheelchair.

Work for this week

Howdy.
Just for Max and Bj's info, we met today and decided upon tasks for completion for next tues.
It's pretty safe to say that we have decided upon the wheelchair idea. So we now need to do some work on it. We split that up as;
Me (Sam) - Problem Definition.
Andy - User Needs Analysis.
Bj or Max - Task Analysis.
Jenny - Scenario Analysis for Ethel.
Bj or Max - Scenario Analysis for Reg.

Could you make these as indepth as possible. Also BJ, you mentioned in last meeting that you'd found loads of research on how older people are becoming more technology adept. Could you bring this in?

Next meeting is Tues 13th Feb, 3pm (after Java hand in) in front of Comp Sci and head on from there to meeting room.

Woo! Snow tomorrow!!!

Plus, I've got us a wheelchair and will have it by the week starting the 20th Feb.

Cheers

Meeting on Mon 5th Feb

In addition to the 2 personas., we also discussed our wheelchair idea further. It was suggested that the wheelchair might have different levels of functionality depending on the requirements of the user. We also decided to discuss the idea with specific reference to older people who are physically impaired / disabled rather than mentally impaired. We also decided that this idea might work best for older people rather than disabled children. Recent advances in technology such as wireless power (yes its true! check out the following....)

http://news.bbc.co.uk/1/hi/technology/6129460.stm

4G phones and Metropolitan Area Networks have made some of the functions suggested more possible. However, nothing was decided for definate and we have agreed to keep our options open for now.


Persona 2: Reg Barton

Dob: 2nd August 1938 (aged 68).

Lives: Yorkshire

Occupation: Used to be a miner but is now retired. Has just got a payment from the government for compensation. He suffers from lung disease caused by working down the mines. He has breathing difficulties.

General Information: Reg's favourite drink is Bank's Bitter and he enjoys dominos, darts and cards at his local pub. He used to smoke cigarettes but now only smokes a pipe. He used to play Rugby for the pit team and supports Burnley F.C. He is married to his wife of 40 years. He is Catholic and his financial situation was quite bad until his recent payout. He still lives in his own house which is a terrace. He has an aging sheepdog called Dave.

Children: He has 5 children and had another child who died at the age of 6 weeks. He has 12 grandchildren.

Attitude to Techology: Reg has a negative attitude towards technology. He is not interested in new technology or the latest gadgets and prefers to stick with what he knows. He is frustrated by the prominence of new technology because he doesn't see the need for it. He resists any attempts to introduce technology to his life.

Meeting on Mon 5th Feb

Aims: To discuss and come up with 2 personas.

Persona 1: Ethyl Rose

Dob: 4th February 1928 (aged 79).

Lives: In Sherborne, Dorset in sheltered accommodation.

General Information: She used to drive but has had to stop because she has become quite frail. She enjoyed driving but hasn't driven for 7 years. She was evacuated to Dorset during the war and returned there to retire. Her husband died of a stroke 2 years ago. He used to drive when she couldn't. She used to have a cat but it died so she has become increasingly lonely.

Occupation: She used to be a nurse and also spent a lot of her time bringing up her children.

Hobbies: Crosswords, countdown, volunteering in a British Heart Foundation charity shop.

Attitude to Technology: Cautiously positive. She is not overly experienced but can surf the Internet and check her email. She can also view her bank details online. However she is not confident configuring anything and cannot fix things when they go wrong.

Children: She has 2 children who pay for her sheltered accommodation.

Initial HCI Methods Discussion

HCI Methods.

Howdy all.

Following on from our meeting, here is some of the aspects of HCI that we discussed.

The main issue of HCI that this project will focus upon is that of User Centred Design

The TRUMP basic method of UCD highlights five main parts of the User Centred Design process;
Feasibility;
Requirements;
Design;
Implement;
Release.

Obviously, in this project we will only be able to focus on the first three. Within these three parts of the design process, the TRUMP method identifies two main tasks – stake-holder meeting and prototyping. In our project the main stakeholders will be us, as the group. Our primary objective before we can begin to function as stake-holders will be to come up with the initial idea.

There are several different approaches available for us in this key creative approach. Several different methods have been proposed and these essentially focus on two main approaches that we can take in our group - the refinement of an existing product or the creation of a new product. It would be sensible at this stage not to discount either of these. As we have such a broad brief, we should not limit ourselves during the creative process. However, we should be aware of the different techniques that these different approaches. One key approach is that of reversal. As an example, myself and Max briefly discussed some form of set-top TV/Internet box for elderly people. As these already exist ( although not specifically designed for older people) we could use reversal by asking “How could we make a Sky+ box harder for older people to use?” By identifying the methods and technology that would achieve this, we could therefore identify the opposite and hopefully come up with some ideas for improving upon a product.
Another approach we could take is that of SCAMPER. The Mind Tools website defines this as;
• S - Substitute - components, materials, people
• C - Combine - mix, combine with other assemblies or services, integrate
• A - Adapt - alter, change function, use part of another element
• M - Modify - increase or reduce in scale, change shape, modify attributes (e.g. colour)
• P - Put to another use
• E - Eliminate - remove elements, simplify, reduce to core functionality
• R - Reverse - turn inside out or upside down.

Taking the set-top box idea of earlier this process could be applied in the following way
• S – Substitute - This would really deal with the internals of the system – ie. Use of DVD to record instead of HDD, control via PC rather than remote etc etc.
• C - Combine – the Sky+ offers digital TV and HDD TV recording. It could be combined as part of a whole home entertainment system or include internet access
• A - Adapt – We could change the series link function to include all programs of a similar genre, actors involved etc etc.
• M - Modify – we could make the system more aesthetically pleasing for older people, hide it out pf way for those who dislike having boxes everywhere etc etc.
• P – Could this be used to record radio shows?
• E - Eliminate – Will older people really want to be able to record a program 3 weeks in advance? Or record every single episode of a show?
• R - Reverse – The system records programs automatically based on some pre-defined criteria and only shows those.
A further idea put forward by Mind Tools is that of attribute listing. Another method to improve upon an existing product, this lists every main attribute of an existing product and then we would list all alternatives to each one. This could have the potential to link into brainstorming, which will be the focus of next weeks meeting.
An alternative to this would be the use of a Reframing Matrix. This is the use of a question about an existing product and then questions poised about it from four approaches – people, product, planning and potential. However, it was argued by BJ that this is a more business orientated approach and so would probably not be the best approach for us to take.
So, once we have decided upon a product to improve or a new product to develop, how should we best go about designing it?
Katz-Haaz proposes the following questions, which we deicded to broadly use throughout the design process[1].
• Who are the users of this 'thing'?
• What are the users’ tasks and goals?
• What are the users’ experience levels with this thing, and things like it?
• What functions do the users need from this thing?
• What information might the users need, and in what form do they need it?
• How do users think this 'thing' should work?
• How can the design of this ‘thing’ facilitate users' cognitive processes?
In the answering of these questions, we will need to develop some distinct personas as we are not either 11 year old children or 65+ year olds. In the creation of these, the Design Council of Great Britain suggest two main approaches in the creation of these– engaging with the consumer (or user in our case) and user observation and analysis.[2] In the case of younger children, it may be difficult to get this access, however it was decided that this should not be a problem with older people. One idea that is stated as critical to successful UCD is that of immersion in context. For this we would need to be able to experience what problems our target users have. One idea mentioned was that of a system for wheelchair bound older people, and so for this we would need to observe older people in wheelchairs, identifying what problems they have or else do this ourselves and try to be the personas we create.
Another approach to UCD is taken from the Usability Engineering Team at NASA. One interesting difference in the approach taken by this method (designed primarily for software development) is that of creating plans for training and help systems/menus as the original prototype. This could be an interesting area of research and design when our system is being prototyped – what training will be required and what help will be available to users.
As mentioned, is we all do the reading around these topics, then we should be able to use these HCI theories in the project.

[1] Katz-Haas, R. (1998) “Ten Guidelines for User Centered Web Deisgn”, in Usuability Interface, 5(1).
[2] Black, A. (2006), “The Basics of User Centred Design” [online] Available http://www.designcouncil.org.uk/en/About-Design/Design-Techniques/User-centred-design-/