Software Requirements

Hardware Specifications

After analysing each of our prototypes we have produced a list of the hardware requirements that takes what we feel are the best parts of each design.

Tris - With the combination of all of our designs, we could refine our specification a tad more for the hardware side of our device. After discussing it as a group i soon realised why an all-in-one device had so many advantages. One of the only advantages of having the gun was that it would be easier to hold rather than the PDA. I also feel the need for force feedback to play with the senses was an important point bought up. Some points were left out as we felt that didn't satisfy the user-centered design approach and were consistent with other age groups too. I was also pretty keen on the doctor interface, although a bit sceptical at first about it. It could help doctors identify what parts of a diet a client lacks, without them actually realising themselves. I also still feel there is room for the state of the art scales that simon mentioned in his post. Even if its not entirely necessary, its nice to step out of the realms of technology for the product.

Simon - i can see the usefulness of force feedback, like used in the phone, rumble pack or something, however if theyre using the actualy device theye gonna see a box pop up, they dont have to feel the thing rumble to see it. However, if we included a reminder or something in the device then it could work well, for example people with diabetes need to have food at certain time intervals or people who take medication need to have it at a certain time and if the device was kept in the pocket then the rumble would make them aware of the programmed reminder. The scales could be an add on which makes a huge difference in the functionality of the device as saying your eating cabbage could vary in amounts, however, indicating how much your eating would allow analysis of just how much nutrition your actually getting.

Prototype V - Sofware

Note: About the button design elderly people "in today's society" generally will grasp the concept of clicking buttons from similar device like TV remotes, they are probably not used to fancy menus using combo boxes etc.

Comments on design:

The back button on the the screen is a good idea as the user will generally want to go back a step if they did something incorrect.
Generally there will be quite a lot of feedback so the user knows what to do next even if they have forgot from previous times it also shows the user what the system is actually doing at the current moment in time.
This is only a prototype so the colours haven't been finalised but i thought the food group colours were ideal other than fibre as it is hard to see the text.

Prototype V - Hardware

Figure 1 - Sketch of Prototype

The basic functionality of the Hardware is as follows:

Display

• The display is one of the most important features of our design as this is the area where the program will be run. The design of the whole system can be seen in figure 1, there are also existing barcode scanner PDAs which are show in figure 2 and 3 they wouldn't be ideally suited for the elderly but still my design uses some ideas.
  


• The design of the display should combine a 'large' display so that the elderly can see the menu items etc. and an overall size which mean that the device is still portable.
  


• It must be waterproof and be easy to maintain (i.e. when food get on it, easy to wipe off). This is kind of obvious as our product is going to be used primarily in the kitchen and outdoors.
  

Device in General

• Must be durable as with product people tend to drop them which is a big problem for electrical devices. With an increase in dexterity amongst the elderly durability has to be a key feature.
  


• In my prototype idea the design is for an "all-in-one" system which allows the barcode scanner to be attached. In my initial design sketch it is located on the top. The reason for having an all in one system that is simplifies a complex design and stops components getting lost.
  


• The scanner itself although it is attached to the PDA it can be extended by means of a wire which would allow the user "to scan even the trickiest of barcodes" this design would use an idea similar to the vacuum plug, you can pull it out and press a button to retract it.
  


• Size of device should be slightly bigger than a PDA as there average size is roughly
  75mm x 130mm x 15mm (http://www.palmbyal.com/). This would allow for a larger screen but again it can't be too much bigger as it will lose its portability factor.

Buttons

• Generally should be used over other methods such as a scrolling button, touchpad or other form of new interaction mainly because the majority of elderly people don't understand how they work and will just lose faith/patience in the product.
  


• Another very important feature in the design the button generally should be arranged in a logical way some research should be done into TV remotes and other forms of remote control the elderly use.
  


• The buttons should also be limited in number as the common phrase goes "less is more".
  


• The buttons should also be large and have a happy medium of sensitivity when pressed. This is because the elderly general have poor eye sight and general movement so making the buttons large allows for the person to comfortably press the button.
  

Barcode Scanner

• This has been chosen over any other input device because it seems the most logical you can scan in food and it will tell what food automatically and combined with the system can enter amount with ease.
  


• The device should have a button on it as it can be extended with a wire thus the person will want to press a button to scan.

Figure 2 & Figure 3

Prototype IV

Just some sketch ideas for a prototype with some writing and points included on each.

Prototype III

So far the proposed products are all made from existing technologies, however, our project outline does not mention such a restriction. We are not required to create this product, but only approach it in a HCI aspect and so using futuristic technologies could aid in designing a product that

benefits the end user most.

I propose a device that has scales in which the user places the food into, allowing an exact measurement to be taken. The packaging can be intact as i believe it to be negligable. This is a quick and easy way for the computer to measure how much of the food is going to be consumed in the meal - offering advice to whether you need such a big amount/small amount. Kitchen scales can be found in most homes and are very easy to use, so there is no new technology for the user to learn. However, being able to weight the food tells the computer nothing about the nutrition content of the food. This is where scanner comes into it.

The scanner will be able to detect exactly what is in the food, so it could be a home baked cake and an accurate measurement of what the cake contains can be extracted. This would then be able to calculate down to the carb/calorie what your intake should be. A bit out of the realm of science at the moment but such an invention would prove invaluable to such a device.

The information is then retrieved and processed in the digital display, whereby the user can view how much they have eaten that day and what they need to eat more/less of. The display has to be clear and easy to use, possibly with a touchscreen so no external devices are needed to navigate round it. This will save on space, but will mean that no skills needed to use a mouse/keyboard are required.

There are several other opportunities for addons that could be included. An example of such a thing, would be a handheld device which can be carried around on the person and used to scan what food is eaten throughout the day. The weight will have to be entered and not measured, however, most packages hold such information on them.

Another idea is for another scanner to be included which scans your skin and detects its current state. It is widely believed that your diet is reflected on your weight and skin condition. By being able to detect the hydration and other characteristics of your skin, the computer will be able to reajust your diet to ensure you stay healthy, or even suggest contacting a doctor if certain conditions can be detected.

This design may stretch our imaginations a tad too far, however, i think it brings several ideas to the table that we should take into consideration. Something to discuss in our next meeting.

Meeting 20th Feb

Due to unforeseen circumstances the meeting yesterday was cancelled as Simon was ill and some of the other group members hadn't quite finished their prototype ideas.
Tris, Dave And myself decided to have a mini meeting still looking at some of the aims of the meeting and tried to address them. The prototype could not be discussed in great detail as we felt it necessary to have all group members present as we felt that finalising the prototype would take ideas from everyone. The questionnaire also couldn't really be started as it is going to be based on decided for the final prototype.
Although we did get around to allocating a few different tasks for this week with Dave actually finalising the problem definition, Tris will be doing the questionnaire when we have discussed the different prototypes of our product. I decided that i will create a more defined task analysis to help our product solve the tasks at hand.
We will meet tomorrow to discuss the different prototype design so that we can press on with finalising the product.

Rough Prototype Stuff

I've just done some quick drawing the graphics package that I said to one or two of you about. The product I did here was quite simple but it should give you an idea of what can be done on it. So not sure but was thinking when we decide on a final design I could do a full 3D modal, all I would need is some rough measurements.

Prototypes I

Meeting / Reminders

Hi Everyone this is just a message to remind people that we are going to have a meeting tomorrow at 2pm. The aims of the meeting are entirely based on the prototypes that we are supposed to have done this week so REMEMBER TO DO THEM.
Aims of Meeting 20th Feb 2007:

• Run through prototypes - discuss ideas
• Finalise Prototype - Get a final design prototype based on the different ideas
• Talk about questionnaire
• Posting on blogs - more comments / regular posts
• Extend Personas / Design Ideas
• Product Research
• Problem Definition - What is it that our product is going to solve.
  

(feel free to add to list if there is something you which to discuss)
Also just a reminded mainly for Dave that HCI lecture is today at 5pm.

Task Analysis - Food Nutrition Device

Wikipedia Defines Task Analysis as:
Task analysis is the analysis or a breakdown of exactly how a task is accomplished, such as what sub-tasks are required. This information can then be used for many purposes, such as improving the design of tools or procedures that aid in performing the task. These tools can be either physical implements or software.

The task analysis below is based on the product definition formed earlier in the blog. It has feature that could possible be extended but take a look.