Exspansion on the barcode reader

Glad I actually put this off until we had that talk on skype because it brought some more points to the surface's.

In other posts we've discussed some of the main constraints behind the barcode scanner in that it would be best if the scanner was owned and maintained by the supermarket, this is primarily to do with the fact that most supermarkets would not like there complete stock data been publicly accessible without some control on their part.

This leaves us with a very narrow avenue of how the barcode reader could be used, also applying memory and processing constraints. So the device idealy should be limited to containing only portions of the stockdatabase that pertains to the shopping list of the person adding another constraint that the shopping list, needs to directly interact with the barcode reader prior to any shopping actually taking place so the correct parts of the stock database can be selected, if the shopping list is prepared online in advance of the shopping trip, this leads to making things flow more simply if this list is then handed off to the supermarket which can prepare the barcode reader (file) in advance aswell thus allowing it to be picked up quickly and efficently, at the desk as well as allowing the supermarket to deal with cases of no stock available or to tag special offers and alternatives and specific product information such as weight and nutritional values. There comes into this the ethical issue of what the store could do to abuse this info, but that is for another post.

As the barcode reader isn't part of the primary device is only needs to come into use when locating specific items the device can either be placed in a basket or trolly to free the users hands. Though initially RF tags were discussed as a way of identing products but it was clear that the device could quite easily receive multiple signals confusing products, as there was an existing system aka barcodes already in place on pritty much every product in existance, it soon became clear that a barcode reader was the best way to go as this would indentify most ifnot all products, with only problems occurings with loose products such as vegitables which could easily be remedied by placing barcodes on the front of shelves this actually solves a problem with the use of the barcode allowing the user to simply scan up and down the shelf after the instore navigation has brought them to the general location of the product, this then allows the user to find specific products, and using a thumb button select more detailed info on the last scanned product.

Identifying the products would be as simple as the paired barcode reader returning a raw text string to jaws for to audio conversion, for names of products this should be done continously in that you can hold the scan button sweep a shelf and it will que all the products it scans then audioconverts them. Where as more detailed info will require you to stop at a product then press the barcode's detailed info button.