Summing up our new findings

As promised, today I will make a few posts.

This post is dedicated to summing up our new findings when we tested with Mike. I won't regurgitate what Mark posted but instead add my own thoughts to this.

The first thing that stands out in my mind as an issue is the system's level of detail that it gives to the user. We quickly discovered that what we thought would be 'the norm' information for users isn't always going to be what they want and we should therefore revise how this section of the system works. Personally I believe the system should be revised as follows:

Within the settings menu there should be a set of fields which can be turned on and off and these would contain various topics of information such as "Product Weight" and "Nutritional Information" which can be turned on and off as the user requires. This settings menu should be peripheral device specific and not store/location specific because users will tend to want the same settings when using that particular device more than their current location because the peripheral devices will tend to be activity orientated and as such are barcode the barcode reader settings used at one supermarket will almost certainly want to be used in other supermarkets.

Further to what I have just said, there will need to be a 'standard' set of information that all supermarkets provide to the system for this information section. This information is very much standard already across all supermarket firms as all have pretty much the same information in their barcode databases thanks to the standardisation of barcodes (they follow the Universal Product Code, see http://www.av1611.org/666/barcode.html for more information) and software for such system being of a more generic industry setup rather than tailored for each individual company. The system could include a number of fields that are specific to the company/store they are visiting but I would limit this (to say 4) as companies may go 'overboard' if given too much leg room.

Another feature this section of the system will need is the recognition of different types of store, for example, nutritional information is hardly useful when you are looking for a new door bell at your local DIY store (a British term for your local hardware store, if DIY confuses you). Also, at such a store, getting more information about products (such as product dimensions) is very important and all these different fields would make a settings menu list that is laid out the same way as the IPod list huge and extremely difficult to navigate. I therefore suggest that using an idea taken from barcodes, different types of store are standardised in a store type ID database, built into the Brain which then makes a request to the device (such as the bar code scanner) when they are pairing as to what type of store is it in. From this the Brain can customise the information settings menu. With a finite number of types of store the Brain can store each individual menu setup and after the initial configuration of each menu, every time in encounters that store type it could just restore that store type information settings for the Brain to use and for the user to customise as they see fit. Finishing this, when linking the Brain with a PC the computer software for the device can allow the user to see all the settings at once so they can quickly setup all the menus on their new device before they leave the house.

At this point I will start a new post...