Michael Hollander BSc Computer Science (Industry) 2006
Transcription
Michael Hollander BSc Computer Science (Industry) 2006
Enhancing Customers’ Experiences through the Integration of RFID within Intelligent Mashups Michael Hollander BSc Computer Science (Industry) 2006 / 2007 The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student) _______________________________ Summary This report details the analysis, design, implementation and evaluation of a prototype to examine how RFID can be used within Intelligent Mashups to enhance customers’ experiences. First the background of Intelligent Mashups and RFID is discussed. Following this an appropriate approach to the project is researched and decided upon, including the most appropriate methodology to develop the application. Requirements are then gathered from devised shopping scenarios and finally the chosen methodology is applied, and the resultant application evaluated. i Acknowledgements With thanks to my project supervisor, Dr. Vania Dimitrova for all her help in this project. I am also grateful to Prof. Peter Dew for his advice on the Mid-Project report as well as during the progress meeting. I would also like to thank Dr. Nick Efford, focus group participants as well as everyone else who participated in the product questionnaire, for their time and feedback. Finally, a big thanks to my family and friends who have supported me during the hard but also the good times at University. ii Table of Contents Summary.................................................................................................... i Table of Contents .................................................................................... iii 1 2 3 Introduction...................................................................................- 1 1.1 Problem Definition.................................................................................... - 1 - 1.2 Project Aim ............................................................................................... - 2 - 1.3 Objectives.................................................................................................. - 2 - 1.4 Relevance to Degree Programme ............................................................. - 2 - 1.5 Deliverables .............................................................................................. - 2 - Project Methodology.....................................................................- 3 2.1 Introduction............................................................................................... - 3 - 2.2 Chosen Methodology ................................................................................ - 3 - Background Research...................................................................- 5 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.3 4 Web 2.0 and Intelligent Mashups.............................................................. - 5 What is Web 2.0?.............................................................................................- 5 What are Intelligent Mashups? ........................................................................- 7 Why are Intelligent Mashups important?.........................................................- 7 Mashup Categories ..........................................................................................- 7 - RFID within Intelligent Mashups.............................................................. - 8 What is RFID? .................................................................................................- 9 RFID vs. Barcode ............................................................................................- 9 RFID Formats and Standards.........................................................................- 11 Example RFID Applications..........................................................................- 11 - RFID Mashups ........................................................................................ - 12 - Problem Analysis ........................................................................- 14 4.1 Online data sources ................................................................................ - 14 - 4.2 Application Scenarios ............................................................................. - 15 - 4.3 Simulation Environment.......................................................................... - 16 - 4.4 RFID technologies .................................................................................. - 17 - 4.5 Database Technologies........................................................................... - 17 - 4.5.1 Data Selection................................................................................................- 17 - iii 4.5.2 5 Client-Server technologies...................................................................... - 19 - 4.7 General Architecture .............................................................................. - 20 - 4.8 Conclusion .............................................................................................. - 21 - Iteration 1: Feasibility of the Architecture...............................- 22 5.1 Goals ....................................................................................................... - 22 - 5.2 Design ..................................................................................................... - 22 - 5.2.1 5.2.2 6 Implementation ....................................................................................... - 24 - 5.4 Unit Testing............................................................................................. - 25 - Iteration 2: Matching Application Scenarios ...........................- 27 6.1 Goals ....................................................................................................... - 27 - 6.2 Design ..................................................................................................... - 27 - 6.3 Implementation ....................................................................................... - 29 - 6.4 Evaluation ............................................................................................... - 31 Procedures and Materials...............................................................................- 32 Participants ....................................................................................................- 32 Results against Evaluation Objectives...........................................................- 32 Implications for the Third Iteration ...............................................................- 35 - Iteration 3: Interfacing with a Mobile Device..........................- 36 7.1 Goals ....................................................................................................... - 36 - 7.2 Design ..................................................................................................... - 36 - 7.3 Implementation ....................................................................................... - 38 - 7.4 Evaluation ............................................................................................... - 41 - 7.4.1 7.4.2 7.4.3 7.4.4 8 Client architecture:.........................................................................................- 22 Mashup Server architecture: ..........................................................................- 23 - 5.3 6.4.1 6.4.2 6.4.3 6.4.4 7 Chosen Database Software ............................................................................- 18 - 4.6 Procedures and Materials...............................................................................- 42 Participants ....................................................................................................- 42 Data Collection and Analysis ........................................................................- 42 Results against Evaluation Objectives...........................................................- 43 - Evaluation ....................................................................................- 44 8.1 User Prototype Evaluation ..................................................................... - 44 - 8.2 Minimum Requirements and Extensions................................................. - 45 - 8.3 Project Methodology............................................................................... - 46 - 8.4 Project Schedule ..................................................................................... - 46 - 8.5 Business Case Consideration.................................................................. - 47 - iv 8.6 9 Further Work .......................................................................................... - 47 - Conclusion....................................................................................- 49 9.1 Feasibility of Combining RFID and Mashups ........................................ - 49 - 9.2 Comparison to Other Solutions .............................................................. - 49 - 9.3 Summary ................................................................................................. - 50 - References...........................................................................................- 51 Appendix A – Personal Reflection....................................................- 54 Appendix B - Project Methodology..................................................- 55 Appendix C – Java Client Class Diagram .......................................- 59 Appendix D – Amazon and Yahoo Web Services...........................- 60 Appendix E - Transcript of Focus Group .......................................- 65 Appendix F – Usability Testing ........................................................- 68 Appendix G –Expert Interview Material ........................................- 71 Appendix H – RFID Workshop Correspondence...........................- 74 Appendix I – Product_Info Table ....................................................- 75 Appendix J – Unit Testing ................................................................- 76 - v 1 Introduction 1.1 Problem Definition Current technological advances such as the Internet have allowed people to become increasingly aware of the growing availability of data. In addition, the mobile revolution and the development of the mobile web have transformed how we gather this information. As a result, in today’s consumer-driven world customers are enduring to get the best value for their money whilst shopping. Currently, they achieve this by gathering information from several sources, such as magazines or online media, regarding a desired product. The information contained within these sources is then manually filtered by the consumer and the best product is chosen. This is a highly tedious process due to the large number of search results, thereby restricting consumers to research products before leaving their homes. The mobile revolution has now enabled users to access the internet on the go through various mediums such as mobile phones and PocketPC’s, thus removing the restriction of searching for product information prior to entering a shop. As consumers search for the best and cheapest product deals available on the market, identification technologies such as barcode scanning can help facilitate the process of achieving this. At present, companies such as Virgin [39] have incorporated this identification technology within mobile web browsing, to allow consumers to research a desired product on the go. This project aims to improve on the consumer experience when using mobile devices to retrieve product information whilst shopping. It will therefore utilise Radio Frequency Identification (RFID) technology and retailer’s merchandise data to automatically identify products and retrieve information from retailers’ databases. As opposed to other identification technologies, RFID is of automated nature and as a result allows a product to be in close proximity of a reader to be successfully identified. Having retrieved the product description, data will be pulled from multiple data sources within the internet and filtered to present the user with the most relevant information. In essence this will help bridge the gap between products contained within the physical world and data retrieved from the virtual online media. -1- 1.2 Project Aim The aim of this project is to examine how Radio Frequency Identification (RFID), an electronic tagging technology, can be used within Intelligent Mashups (Applications combining data from multiple services) to enhance customers’ experiences. This is to be illustrated with the use of a prototype. 1.3 Objectives The objectives of this project are outlined below: Research different methodologies and decide upon an appropriate one for this project Research Web 2.0 and Mashups Review existing RFID applications and formats in order to identify appropriate usage of RFID for this project Identify currently available free online data sources Apply the selected methodology throughout the project Apply appropriate analysis techniques to determine the system requirements Develop a prototype showing the potential use of RFID within Intelligent Mashups Identify and use appropriate evaluation criteria for the prototype 1.4 Relevance to Degree Programme This project draws upon several modules taught in the second and third year at the University’s School of Computing. Third year modules GI32 and SY33 were foundation modules for this project. GI32 gave the author an understanding of personalisation and ambient or ubiquitous applications which are topics relevant to this project. It also provided the author with guidance on setting evaluation criteria. SY33 provided knowledge on Web Services, JavaServer Pages (JSP), MySQL database access as well as XML based technologies, all of which are methods or technologies that have been used within this project. 1.5 Deliverables The minimum requirements consist of an Intelligent Mashup prototype which includes a single web data source and simulated RFID data with a shopping scenario. Possible extensions consist of integrating a user rating system or integrating more data sources (i.e. online price comparison). -2- 2 Project Methodology 2.1 Introduction This project involved the development of a prototype, for which an appropriate software methodology was to be chosen. A software methodology or process can be defined as “a set of activities and associated results which lead to the production of a software product” [1]. There are four activities common to all software methodologies; software specification, software design and implementation, software validation and software evolution. Consumers are the category of people who were ultimately going to use the prototype, and were therefore defined as end-users. Since no specific end-users were specified for this project, there was a need for opportunistic software development methodologies. This meant that one or more shopping scenarios were to be designed and shown to end-users in order for the author to receive feedback and to know which one will be best to pursue. The author compared different software process models in Appendix B in order to decide what the most suitable model was going to be for the scope of this project. The Waterfall approach, evolutionary development (also known as Rapid Application Development (RAD)) and reuse-oriented development have been chosen by the author as appropriate methodologies to be further looked at. These appeared to be the most relevant methodologies for this type of project, since they are popular and widely used by developers. 2.2 Chosen Methodology Using the Waterfall model for this type of project did not seem appropriate, since this project required flexible requirements change from users. Also, requirements might not have been obtained until later during the project. Making use of this approach might therefore have led to expensive post-implementation programming. RAD might have been an appropriate method to use in this project for defining system specification, through its iterative approach with regards to flexible change of requirements and system refinement. Since existing components such as Application Programming Interfaces (API) had to be used for the scope of this project, Reuse-Oriented Development seemed like a suitable methodology which could have reduced the amount of software to be developed. -3- Since both RAD and Reuse-Oriented Development were found to include features relevant to the project prototype, the author decided to produce a custom methodology where features from both models would be used effectively. Below is a diagram (Fig. 2.3.1) of the redefined methodology, which was used for the development of the prototype. Figure 2.3.1: Diagram showing the redefined methodology The customised methodology can be reflected in the final project schedule (Appendix B Fig. 2) by looking at the Problem Analysis stage. The process starts with the identification and analysis of free online data sources in order to help identify user-based scenarios which would then be the basis for a prototype enhancing customers’ experiences. Having justified the choice of online data sources, user-based scenarios would then to be constructed in the next stage, reflecting the available data sources. The last phase contained within the problem analysis section is Component Analysis, where new or existing software or hardware components are to be identified and as a result created or reused for the development of a prototype. This stage is part of an iterative cycle where a number of prototype iterations are to be developed. Therefore, at the start of each of these iterations, new or existing components can be identified and included in the iteration. Following the Problem Analysis phase, the prototype to be developed in a number of iterations is to be designed using the new or reused components identified in the previous stage. Development and Integration is the next stage, where software which cannot be reused is to be developed and integrated with the reused components. Finally, the system will be validated using suitable testing methods or through evaluations based on specified criteria. After system validation, if required, the whole process of analysing components up to system validation can be reinitiated. -4- 3 Background Research 3.1 Web 2.0 and Intelligent Mashups In order for the reader to understand what Intelligent Mashups are and where these have come from, it is important to first discuss the broader topic surrounding Mashups. Looking at the big picture, Intelligent Mashups are part of a large set of trends called “Web 2.0”. In the following sections, the author will explain what Web 2.0 is all about by giving a definition as well as the term’s origin and its general principles, through the use of examples. The author will then continue by defining Intelligent Mashups and by giving examples of existing Mashups. 3.1.1 What is Web 2.0? The O’Reilly Radar team defines Web 2.0 as “a set of economic, social, and technology trends that collectively form the basis for the next generation of the Internet—a more mature, distinctive medium characterized by user participation, openness, and network effects.”[3] The term “Web 2.0” refers to the second generation of web applications. It was invented by O'Reilly Media in 2004 as a title for a series of conferences of which the first one named “The web as a platform” [4]. The first generation of web applications can be thought of as one where a webmaster or a group of people could write as well as edit content, and then make this content available to others. This is quite similar to the way in which books are published. The Web 2.0 generation, on the other hand, can be thought of as one where anyone can add their own contents to a shared content base, and where anyone can then also access that space. O’Reilly discusses the evolution of websites, applications and companies through the use of examples [5], comparing Web 1.0 efforts such as content management systems, screen scraping and directories with Web 2.0 alternatives such as Wikis, Web Services and Tagging. Below is a comparison table, illustrating this evolution to a full participatory web where not only machines, but also humans can participate. It also shows how Web 2.0 is a two-way medium, where people are both readers and writers. [6] -5- Web 1.0 Web 2.0 Browser bookmarking Social bookmarking (del.icio.us) Content Management Systems (Britannica) Wikipedia Manual website browsing RSS feeds subscription Screen Scraping Web Services Directories (Taxonomy) Tagging (Folksonomy) Table 3.1.1: Web 1.0 / 2.0 Comparison [6] The first example of such an evolution is the use of bookmarking. Previously, users were only able to keep web bookmarks for their own usage, on their PC. With the introduction of Web 2.0, this lead to social bookmarking where users could share their favourite websites with everyone else online. Del.icio.us is a popular example of social bookmarking where people can store, share and discover web bookmarks. Web 2.0 also saw a move from traditional content management systems such as Britannica Online, towards an open collaborative system allowing participation from any user. Wikipedia is a good example of such an open system, since it is one of the most popular free collaborative systems available online. Manual website browsing used to be the only way for people to view websites of their own interest. With the introduction of RSS1 feeds, users can now subscribe to online services of high interest to them, and can easily get content updates with the click of a button. Screen scraping used to be the only way of getting data from a website into your own application. This required long lines of coding and did not always work. With the introduction of web services, this quickly changed. The use of Application Programming Interfaces (API) now allows web developers to easily utilise data from websites for use in their own applications. An API can be described as an application’s interface designed to make all or some of its functions available to other applications. Another term part of the Web 2.0 evolution is Folksonomy, which is a method of collaboratively sharing tags with the purpose of categorising content. The term was coined by Thomas Vander Wal, who believes that in the next couple of years, companies will adopt tagging widely [7]. Taxonomy on the other hand, does not allow people to contribute to the categorisation of content. It is a method of classifying content using controlled vocabulary. Yahoo Directory applies taxonomy to its website, where users search the web by choosing from a list of categories. Flickr, in contrast, is a photo sharing website which is known to be one of the first websites that used folksonomy in order to tag photos. 1 Really Simple Syndication – a format used to publish frequently updated web content -6- 3.1.2 What are Intelligent Mashups? Intelligent Mashups can be defined as “applications that combine data from multiple services to create something new” [8]. They belong to the Web 2.0 set of technology trends, gaining their popularity by emphasising on interactive user participation and by aggregating and putting together third-party data to produce a new creative work. The term “Mashup” was originally borrowed from the pop music scene, where it represents a new song that is mixed from the vocal and instrumental tracks from two different source songs. [9] Intelligent Mashups can be characterised as applications which are built using lightweight web services, in other words services easily understood by anyone wishing to use these, without the need for a steep learning curve. Combining content therefore takes a fair lower amount of time and is usually done through the use of rapid prototyping techniques. In addition to that, many Web site owners provide APIs to make their content and functionality more easily accessible to developers who often use JavaScript and Asynchronous Java and XML (AJAX) techniques to build their Mashups. 3.1.3 Why are Intelligent Mashups important? With the introduction of Mashups, fewer technical skills are needed in order to become a web developer. This means that any basic to advanced programmer can potentially turn their creativity into innovation [10]. As a result, Mashups can bring big changes for software companies, web sites and everyone else online. The web is no longer just a collection of pages, but it is becoming a sort of global operating system [11], where different components of that system can be pulled out and used together with other elements. 3.1.4 Mashup Categories There are four different Mashup genres [9] which are most prominent on the web, the most popular being mapping Mashups. The author will discuss each of these in turn, using an appropriate example for every genre. Mapping Mashups: These became popular since Google’s release of its Maps API. This allowed web developers to mash any kind of data onto maps. An example of such a Mashup is housingmaps.com [12], which locates Craigslist’s real estate “for rent” and “for sale” pages onto Google maps. Other API providers such as Yahoo and Microsoft shortly followed with their own maps API. -7- Photo and Video Mashups: Social networking sites such as Flickr provide their API to web developers who can use their metadata in order to mash pictures or videos with other information that can be associated with it. FlickrSoduku [13] is a good example of such a Mashup, and uses random pictures of numbers from the Flickr website in order to create a Soduku puzzle. The correct pictures are taken by using tags associated with Flickr pictures which represent numbers. Search and Shopping Mashups: Before public APIs were released, comparative shopping websites such as Froogle.com had to use screen scraping methods in order to obtain comparative price data from online retailers. With the release of their public API’s, popular search engine providers as well as consumer marketplaces such as Amazon and eBay made it easier for developers to easily access their contents. Early Miser [14] is a Shopping Mashup which is built on top of these shopping APIs. It offers comparison shopping as well as custom product lists, feeds and tagging. News Mashups: News sources such as the BBC or Reuters provide RSS feeds for people to subscribe to in order for them to obtain the latest news. These feeds can be used as data sources for the creation of a News Mashup. An example of such a Mashup is BBC News Maps [15], which combines BBC news feed information obtained in the last 12 hours, with Google Maps. Having looked at the major Mashup categories available on the web, the next step is to see how RFID can be integrated within each of these Mashup genres, with the aim of identifying a use case to illustrate RFID in Mashups. In order to do this, research of what RFID is, what data formats it entails, and possible applications including this technology, has to be made. 3.2 RFID within Intelligent Mashups This section will examine how RFID can be integrated within Intelligent Mashups (defined in section 3.1.2), with the intention of identifying a use case to illustrate RFID in Mashups. The review will start by defining RFID and its underlying structure, and will then discuss the advantages RFID usage has over existing Automatic Identification technology used in today’s industry. Data formats contained within RFID will then be covered, and existing RFID applications will be explored. -8- 3.2.1 What is RFID? Radio Frequency Identification (RFID) is an electronic tagging technology which allows people, objects or places to be automatically and precisely identified at a distance without a direct line-of-sight, using electromagnetic fields. [16] This proven technology has been around since the 1970s, but up to recently has been too limited and too expensive for practical use. This is why the Auto-ID Center, a centre for continued research into the nature and use of RFID, was formed in 1999, with the help of scientists at the Massachusetts Institute of Technology (MIT). [17] Their mission was to design an open source system that would connect all physical objects to the global Internet, forming an intelligent infrastructure. [18] Using an Electronic Product Code (EPC) encoded into tags, these physical objects can be uniquely identified with the use of an RFID reader device. There exist two types of RFID tags: active and passive. Active tags are powered by a battery, whereas passive tags become “illuminated” and communicate their information (a single identifying number) when these are in close presence of a reader. [19] RFID is part of a range of technologies, such as barcodes and contact memory, called Automatic Identification (Auto-ID or AIT), which are used to help devices identify objects. Out of these technologies, two – RFID and barcodes – have become most popular and are widely used nowadays. By comparing these two technologies, the advantages of RFID can be identified and its suitability for this project will be justified. 3.2.2 RFID vs. Barcode Barcode is a technology that has been around for more than three decades, and it is still being used by retailers, manufacturers and logistics as a quick and easy way to track inventory. [20] However, with the constant price drop of RFID equipment and with its technologically advanced characteristics, barcode seems to soon be replaced by this fast-growing Radio Frequency technology. In order for the reader to gain a better understanding of the advantages RFID has over barcodes, Patrick Sweeney [17] suggests comparing the two different technologies against specified criteria; Reading Distance: A big advantage of RFID over barcode is that it does not require line-ofsight for a tag to be read. Tags located inside containers or behind walls for example can still be read. Also, barcodes can only pick up a signal from a range of a few feet. RFID tags on the other hand can communicate between a few millimetres and up to more than 100 metres (depending if a tag is passive/active). The following example shows the advantage of using -9- RFID over Barcode, when combined with Intelligent Mashups. A household mirror could integrate RFID technology in order to respond to people’s presence. When a person would bring a tagged piece of clothing in front of the mirror, content would be displayed on that mirror with a description of the garment along with suggested possible accessories matching that item, taken from the brand’s website. On the other hand, using barcode would require the person to manually scan the item of clothing. In addition, it might also not provide enough information about the item for the website to return information. Number of reads at a time: With barcode, only one item can be scanned at a time. RFID allows for nearly hundreds of tags to be read simultaneously. This can greatly reduce the time required to scan a large number of items. Simultaneous tagging can prove useful with Intelligent Mashups; a consumer might use an RFID-integrated device to scan a food shelf containing RFID-tagged fruit and vegetables. With the click of a button, the tagged items could be scanned simultaneously and data about these would be used to search for possible online recipes. These would then be returned to the consumer for advice on which ingredients to buy to make up a recipe. However, this example may be too challenging and not feasible for the scope of this project. Data modification: Barcodes cannot be written to or be modified, whereas some RFID tags (Class 1 tags) are modifiable. The ability to modify data can be cost-effective (re-use), but can also be useful when additional information is obtained for an item over the duration of its production cycle. These advantages can be valuable when used together with Intelligent Mashups; having got the permission to append information to a tag in a retail shop for example, consumers could write their own reviews for a particular item they have purchased. The online link to their review could then be written to the item’s tag, allowing other buyers to later scan it and obtain the review on their mobile device used to scan RFID tags. Data storage: Linear barcodes can only store up to 30 characters, as opposed to RFID tags which can store up to 8MB of data. This allows tags to contain larger serial numbers to ensure uniqueness of an item. Data storage is a crucial element for the success of Intelligent Mashups. Depending on the amount of data and quality of data associated with a tag, it can be used to integrate with Mashups in a very innovative way. In itself, the RFID tag contains nothing but a unique ID number, but when connected to an Internet database, this anonymous number will suddenly come to life. The next section will review existing RFID formats and standards, which are essential for the development of a prototype in this project. - 10 - 3.2.3 RFID Formats and Standards Data availability plays a significant part in Intelligent Mashups. Therefore, appropriate formats and standards need to be identified in order to maximise their usefulness towards users. Having standards for new technology such as RFID can help incorporate the technology into people’s culture, with rules being defined for using it. [21] Standards are also needed to make sure information is shared appropriately and effectively. This is why the Electronic Product Code (EPC) was created by the Auto-ID Center, as a standard for this technology. The EPCglobal2 is an organisation which supports the use of RFID by determining standards and protocols, and by allocating EPC numbers to end-users. RFID tags are encoded with an Electronic Product Code, which is a globally-unique identifier for the object being tagged. When scanning a tagged item, the EPC obtained by the reader can then be used to search an EPC database for more information on the item. An EPC tag usually contains a 96-bit unique identifier, which can be structured in four separate parts [17]; the first partition is the Header, which contains 8-bit of information on the length and structure of the code being used. The EPC Manager Number partition then identifies the company or company entity, spanning 28-bit. The third partition, taking up the next 24-bit, is the Object Class which is similar to a stock-keeping unit (SKU). The last element and 36-bit of the EPC is the Serial Number, which is unique for all objects of that class. 3.2.4 Example RFID Applications RFID being a fast-growing technology has continuously been used for many different purposes, from tracking cows3 to unlocking hotel doors4. Since RFID readers and tags are becoming less expensive each year, more companies are becoming interested in using this technology. There are already a considerable number of companies in different industry sectors which are employing RFID to save on their overall company costs. This section will investigate different types of RFID applications through the use of suitable examples. RFID in Airports for baggage handling [22]: There are already a number of airports, such as Hong Kong International Airport and Las Vegas McCarran International Airport, which employ RFID with the aim of improving their baggage service. RFID allows tagged luggage to be identified without being in line-of-sight with a reader. Tags can also be updated in order to reflect on a passenger’s itinerary changes. These advantages reduce baggage mishandling 2 http://www.epcglobalinc.org Brandt: Tracking its beef with RFID - http://www.brandtbeef.com 4 Assa Abloy: VingCard RFID - http://www.assaabloy.com 3 - 11 - and therefore provide for better customer service, making sure airports obtain a return on their investment in RFID. RFID in Water Parks [23]: Great Wolf Resorts, an American firm, has this year launched RFID within one of its six water parks. New guests at the Pennsylvania resort will be issued RFID wristbands which they can use for keyless room entry, food purchase, game vouchers and other available services. The wristband will also act as a way of identifying each guest within the resort. As with the previous example, the aim of this company is to provide better customer satisfaction through the use of RFID. Guests no longer need to carry their wallets, nor do they need to have their room card handy, since payments and room entry is all done through the use of their RFID-tagged wristbands. RFID in Car Parks [24]: Hoboken, a city located in New Jersey, US has recently armed its parking-enforcement officers with RFID-enabled interrogators. The officers can easily determine whether a car is legally parked with a valid permit, by waving the handheld when standing alongside the vehicle. Previously, officers had to manually look for a permit, leading to additional processing time. Using RFID for this task will therefore save the city valuable time and a considerable amount of money. 3.3 RFID Mashups There seems to be only one Mashup which integrates RFID data – this shows that the area is not sufficiently examined and therefore allows for opportunities. This project will examine such opportunities through the identification of suitable APIs, leading to the creation of scenarios. The best suitable scenarios will then be used to develop a prototype RFID Mashup. Sherelog, [25] the RFID Mashup found to be the only one of its kind, is a system that fetches data from a popular RFID train pass in Japan named “Suica”. It will visualise personal trainride records obtained from this train pass onto Google Maps. Suica uses a read/write RFID tag which can store a small number of train-ride records. The developers of this Intelligent Mashup had two clear intentions for this system - the first one being to help people remember their travel histories and to reflect upon them. They also wanted to create unique communication opportunities by making it extremely simple to share personal travel histories. - 12 - Figure 3.3.1: Suica travel history on Google Maps [26] Figure 3.3.2: Sharelog system shown at Japan Media Arts Festival [25] - 13 - 4 Problem Analysis Having researched the topics of Mashups and RFID technology, the aim of this chapter is to provide the basis for a feasible prototype which would enhance customers’ experiences. This stage initially consists of identifying online data sources offering shopping services, such as price information or ratings for particular items to enhance the customer experience. Once appropriate sources have been identified, a shopping scenario can be devised. The scenario will be used as the basis for building an Intelligent Mashup prototype, and will be referred to during the different phases of the application. 4.1 Online data sources Having searched for free online shopping data sources, a total of nine sources listed as shopping related services were identified at ProgrammableWeb [27]. Table 4.1 shows a list containing these services. Source Service offered Commision Junction Online affiliate programs UPC Database UPC lookup service Windows Live Expo Online classifieds service Google Base Marketplace and structured data service SwapThing Community driven swapping site Yahoo Shopping Shopping Services Zazzle On-demand product creation service Google checkout Shopping cart services Amazon E-commerce Shopping Services Table 4.1: List of shopping-related services All of these services have been tried by the author to see if they would provide useful information on a particular shop item. Only Amazon E-commerce and Yahoo Shopping were found to provide useful information though their respected service, such as price information, ratings, related items as well as product images. All other services did not provide standard shopping services, i.e. consumer oriented services where information can be retrieved on retail products. Instead, they offered information intended for other purposes such as advertising, publishing, real estate, job events and others. - 14 - 4.2 Application Scenarios Now that two usable data sources have been identified (Amazon E-commerce and Yahoo Shopping), the requirements of the application needs to be devised. It was decided that the creation of scenarios would be the most suitable method to do this, as opposed to other means such as gathering requirements from a retailer or carrying out a focus group with consumers to elicit requirements. This is to some extent for the reason that a scenario gives the users a feel for what they will get from the proposed application, whereas obtaining a list of requirements from retailers or consumers does not [28]. Interactions specified within a scenario can also prove useful as a guide for producing system testing [29]. Two scenarios have been created on the basis of information retrieved from the two aforementioned web services. Both scenarios demonstrate how an Intelligent Mashup application could be used by describing a user's view of interactions with the system. By walking through these scenarios, the reader will gain a better understanding of the requirements as well as the interactions that occur within the application. Scenario 1: A user is interested in buying a book as a present for a friend. In possession of an RFIDintegrated mobile device such as a Personal Data Assistant (PDA) with an integrated RFID reader, the user may enter a bookshop and start looking at a range of books which he knows his friend already owns. Upon finding one of these books, the user would like to know what other similar items he could buy, that his friend does not possess. The user picks up the item of interest, switches on his mobile device and scans the specific item using the device’s builtin RFID reader. Once scanned, the device will communicate with the shop’s database, requesting basic information on that item. Upon receiving this information, the device will connect to a Mashup server located in a remote area, requesting more information on the scanned product. The user, unaware of these occurring communications, browses to the Mashup website with the help of the personal device. The website allows the user to retrieve additional information on an item by selecting from a list of scanned items. Once selected, the web page shows the user a list of similar items, along with an image, price and rating for each of these items. Scenario 2: A user is interested in buying a DVD player for his own interest. In possession of an RFIDintegrated mobile device such as a PDA with an integrated RFID reader, the user may enter an electronics shop and start looking at a range of available DVD players. Upon finding an - 15 - item of interest, the user would like to know what other customers have said about that particular item, and whether buying the product online would be cheaper. The shop might be crowded, and there may not be a shop assistant nearby or available to the user to ask for assistance. Additionally, an assistant would typically be prohibited to encourage customers to buy online. Bearing these factors in mind, the user instead picks up an item of interest, switches on his mobile device and scans the specific item using the device’s built-in RFID reader. Once scanned, the device will communicate with the shop’s database, requesting basic information on that item. Upon receiving this information, the device will connect to a Mashup server located in a remote area, requesting more information on the scanned product. The user, unaware of these occurring communications, browses to the Mashup website with the help of the personal device. The website allows the user to retrieve additional information on an item by selecting from a list of scanned items. Once selected, the user is presented with information on the scanned item, including online prices and ratings obtained from Amazon and Yahoo web services. Although these scenarios show usage of the application from a single customer's perspective, the Intelligent Mashup application should support a large number of shoppers making simultaneous requests. 4.3 Simulation Environment Since the prototype will be based on the aforementioned shopping scenario, simulated data needs to be produced in order to illustrate a realistic application of that scenario. Furthermore, a simulation was needed since additional equipment was purchased. Therefore, prior to the system design stage, it is necessary to consider the different components to be used within a simulation environment. Both the design and implementation phase of the prototype follow an iterative approach through the development of three prototypes. Smith RD [30] defines a simulation as “the process of designing a model of a real or imagined system and conducting experiments with that model.” In the case of this project, the model is a collection of hardware and software components which is used to mimic the behaviour of realistic shopping scenarios. For these scenarios, it is assumed that a mobile device contains an integrated RFID reader as well as an online browser, and that the considered shop has implemented RFID on its entire merchandise. One of the major advantages of simulations is that they are able to provide practical feedback to users before the actual real world system is designed. This in turn allows the developer to determine whether the design is correct and - 16 - efficient before the real system is developed. The following components will be used as part of the simulation, though additional components will be discussed later during each of the prototype iterations, as the product evolves in its functionality as well as its efficiency. 4.4 RFID technologies In order to make the simulation as realistic as possible, an RFID toolkit was purchased from Phidgets Inc [31]. The toolkit includes an RFID reader as well as eight RFID tags, and it only allows for USB communication with a paired device, using a provided USB cable. The advantage of using the PhidgetRFID toolkit is that it provides the developer with a set of APIs for different programming languages. It is also extremely easy to install, and is one of the cheapest RFID readers available on the market. The limitations associated with the toolkit are that its read distance is 7.5cm, tags cannot be re-written and two tags cannot be read at the same time. Each RFID tag contains a unique product code, which can be read by the reader and consequently passed back to an application. The product code of tags included within the RFID toolkit is however not structured in the same way as specified in section 3.2.3, where RFID formats were discussed. This is because the toolkit is intended for low-budget projects where mass usage of tags is not considered. Each product code associated to a tag is made up of ten characters, and is not structured in four different parts as in the 96-bit unique identifier contained within a standard tag. 4.5 Database Technologies 4.5.1 Data Selection The first and most important component within the simulation is the data. Without data, the system will not have any interest to the end-user. Since information is to be retrieved from Amazon ECS and Yahoo! Shopping, the author decided to look up eight different items which would each exist in both web sources, and for which at least a single user rating exists. Since the purchase of additional tags is relatively expensive, it was decided that only the available tags would be used, as mentioned in section 4.4. Out of the eight items, four were chosen to be Books and the remaining Electronics items. These were most common categories which consumers would normally consider looking up on the internet prior to making a purchase, and for which offering more details would be relevant. Furthermore, both categories match the scenarios created in section 4.2; the first scenario relates to the purchase of an electronics item, and the second relates to the acquisition of a book. - 17 - The simulation is based on the assumption that a shop contains RFID-tagged items linked to a database containing more information on each item. Therefore, a database will be created containing simulated data on items described above, in order to follow that assumption. The shop database will contain a single table with 3 columns; i) EPC – unique identifier for the item ii) Description – full product title, iii) Category – type of item. This data structure is similar to the one created on UPC Database [32], which is a public database that indexes items by their barcode. As both RFID and barcode items can be retrieved using a unique identifier, a similar structure was chosen for use in the simulated shop database. Below is a table containing two simulated entries, illustrating the way item details will be stored within the database. EPC Description Category 01023899ea J.K. Rowling Harry Potter Books and the Order of the Phoenix 010238840c Sandisk SDCZ2-512-A10 Electronics USB Flash Drive Table 4.5.1: Stored items in shop database 4.5.2 Chosen Database Software As mentioned in the previous section, a database will be created to represent a shop’s database. MySQL Server 5.0, Microsoft SQL Server 2005 Express and Oracle Database 10g Express Edition are the only three major database packages which are freely available online, which is why the author has considered these for possible use within the prototype simulation. The author also already had previous experience with all three database packages, and is looking for ease of installation, platform-independence as well as ease of use as important factors for choosing the right software for the development of this prototype. Additionally, advanced database functionalities are not required for the scope of the product. Having previously used each of these packages, the author considered MySQL Database Server to be the easiest and quickest to install. Out of the three vendors, only MySQL and Oracle provide platform independent database software. Microsoft software being platform dependent limits it usage to Windows-based operating systems only. With regards to ease of use, Oracle and Microsoft both offer a graphical interface for their database, which makes it easy to produce queries. MySQL on the other hand does not provide a graphical interface, but once the developer becomes familiar with its SQL syntax, the command-line interface turns out to be very handy and fast-responding. - 18 - Based on the author’s previous experience as well as characteristics such as ease of installation, platform-independence and ease of use, MySQL has been chosen as the database package to be used for the web application prototype. The fact that many big Web 2.0 applications such as Wikipedia, YouTube and Flickr have decided to rely on MySQL databases is another reason for using the technology within this project scope. [33] . 4.6 Client-Server technologies Java has been chosen as the main programming language to be used for the prototype simulation. It contains extensive libraries for XML processing, and can be integrated within servlets in order to provide a front-end to the user. The use of XML will be essential in order to retrieve information from the web services specified in section 4.1. Alternatives such as the .NET Compact Framework and Java 2 Mobile Edition (J2ME) have been considered for mobile development, but were unfamiliar to the author. Since the prototype is to be simulated, the author decided to have the development done on a desktop PC instead of a mobile device. Also, since MySQL has been chosen as the database software to be used for the simulation, its combination with Java can be justified for a number of reasons. Both are open source, and MySQL includes a native java driver that converts Java Database Connectivity (JDBC) calls into MySQL’s network protocol. Since Java has also been the only language extensively used by the author over the course of his studies, it was decided that this would be the best choice for developing a web application. Part of the simulation is to provide the user with a web-based front-end where information on a scanned item can be presented to the user, as stated in the shopping scenario. Since the prototype is to be used on a mobile device, it is important to have a web server which can process a considerable amount of information such that the device itself can avoid doing extensive processing. Apache Tomcat is an open source, Java-based web container that runs Servlet and JavaServer Page (JSP) web applications. As a web container, Tomcat is typically used on top of an Apache web server. It can host web applications which contain Java snippets embedded within HTML code. Microsoft Internet Information Server (IIS) is another type of web server which solely runs on a Windows environment, as opposed to Apache being platform independent. Active Server Pages (ASP) is Microsoft’s equivalent to JSP in that both technologies provide the ability to create dynamically generated web content. ASP however, does not allow use of the Java language within its framework. Instead, it does support code written in Visual Basic, C++, C# or Perl. None of these languages have been extensively used by the author. The author possesses prior practical knowledge of JSP as well - 19 - as Tomcat from a third year module (Building Distributed Systems). Since IIS and ASP were never previously encountered by the author, the choice of using the open source alternative is justified. Additionally, since Java will be used for the client-side development, using it on the server-side as well will arrange for ease of integration. 4.7 General Architecture Since the essential components for the simulation have been identified in the previous sections, a proposed general architecture can be devised for the prototype, taking the shopping scenarios from section 4.2 into consideration. The sequence diagram in Fig. 4.7 shows the interactions that occur between three different entities, namely a client, a Mashup server and a database server. This abstract diagram hides the complexities behind each entity’s interaction within the system, in order to give a general overview of the system. Figure 4.7: Abstract sequence diagram The client is the first point of interaction within the system. The user will use a PDA or Smartphone with an integrated RFID reader, to scan a shop’s item equipped with an RFID tag. Once an item has been scanned with the mobile device, the EPC number associated with the item will be sent to the shop’s database server, as stated in the shopping scenario. At that time, the client will request more information on the item from the database. Once receiving the request, the server will locate information on the product and will return it back to the client. Now that the client is equipped with useful information on the product, and not just with a 40-bit number, it can contact the Mashup server. This is a web server which accepts product information as an input parameter, and which returns ratings, similar items and price information for the selected product. Once the Mashup server receives the product information, it will obtain this information from Yahoo! Shopping as well as the Amazon shopping website. It will then return this data back to the client. - 20 - 4.8 Conclusion The analysis in this chapter led to the identification of web data sources followed by the creation of two shopping scenarios, after the decision has been made to build a prototype which would enhance customers’ experiences. A simulation environment was constructed, and hardware and software components have been discovered and added to the simulation. Once the simulation environment has been set up, a general architecture was generated to match the scenarios. - 21 - 5 Iteration 1: Feasibility of the Architecture 5.1 Goals The goal of this prototype is to validate the feasibility of the general architecture stated in section 4.7, by implementing two sets of functionalities. The primary functionalities are to have the client interact with the RFID reader, and to have the client connect to the shop’s database (to be created), passing it the results obtained from the reader. These goals are focused around client interactions only, leaving server-side interactions for later, once the client is equipped with enough information on a scanned item. The secondary goals consist of setting up a web server and having it interact with both web data sources chosen in section 4.1, displaying retrieved information back to the client’s web interface. The author is not aiming to provide a fully integrated solution as yet, but is instead focusing on having different parts of the system work correctly. 5.2 Design 5.2.1 Client architecture: Below is a sequence diagram (Fig. 5.2.1) depicting client interactions. A java program is run on the client’s PDA or Smartphone as soon as the device is switched on. The program will first enable the integrated RFID reader for incoming tag reads. When a tag is within the reader’s read range, it will be scanned, and will consequently return its EPC number (defined in section 3.2.3) to the reader. The RFID reader will then send this number back to the Java program. The EPC number along with the product information associated to the tags’ item is then written into a text file on the handheld device, after having communicated and matched the EPC code with the shop database. For every tag that is read, the process above should be repeated. - 22 - Figure 5.2.1: Client sequence diagram - the activities are shown in sequential order 5.2.2 Mashup Server architecture: The Mashup server is a web server which provides a web interface to the client, allowing for instant retrieval of rating, price and related items information. What distinguishes the Mashup server from a traditional web server is the fact that it allows the creation, deployment and consumption of web services. Interactions with the server are shown in Fig. 5.2.2. After each scanned item’s description has been stored into a text file, the client can start a web browser on the handheld device, and can then connect to the Mashup website. The website provides a text field which allows the user to input a path name, referring it to the text file previously generated by the Java program. It also provides a ‘submit’ button which, when pressed, will have the server transfer the local file onto the Mashup server. Once the file has been transferred, the server will generate a dropdown menu with a list of item names, of which only one can be selected by the user for rating, price and similar items information retrieval. Now that the Mashup server is aware of the selected product, it can access each web API individually and use the product description in order to obtain more details for the specific item. Once all of this information is retrieved from these web sources, the results will be sent back to the client browser. - 23 - Figure 5.2.2: Mashup Server sequence diagram 5.3 Implementation The first set of functionalities as stated in section 5.1 consists of having the client device interact with the RFID reader as well as with the shop database. This has been done through the creation of two Java classes contained within the mobile device (see Appendix C Fig. 1 for a class diagram); RFIDScan - this class listens for RFID tag scans by enabling the RFID reader and by listening for incoming scans. Once a scan has been recorded, the class will record the EPC number associated with that scan. ProductInfo - this class will use the EPC code obtained from RFIDScan in order to request the product’s description, to be contained within the shop database. In order to perform an SQL query to accomplish this task, the actual shop database had to be created. The database structure as well as the software to be used for it was already covered in section 4.4. Having set up the MySQL database, the SQL query was added to the ProductInfo class, allowing information to be later retrieved from the database. Finally, the Java class needs to store this information into a text file on the client’s device for later use. In order to avoid storing information twice about an item, a restriction has been put on the RFIDScan class. The class includes a list used to store EPC numbers. As soon as a new item is scanned, the class will compare the item’s EPC number with existing entries contained within that list. An EPC number which does not find a match in the list will be added at the end of that list. On the other hand, if a match is found, the program will do nothing until a new item has been scanned. This will avoid the creation of duplicate records within the text file as well as an unnecessary database query. - 24 - The second set of functionalities relates to the serverside implementation, that is, the Mashup server interacting with the shopping data sources and the display of retrieved information to a web interface. The author has therefore set up an Apache web server which Figure 5.3.1: UploadText.jsp includes the Tomcat web container, for JSP scripts. The web server can be referred to as the Mashup server, as stated in both Figure 5.3.2: ItemSelection.jsp shopping scenarios as well as in section 5.2.2. A JSP file named UploadText was created on the server, and allows for the uploading of a text file to the Mashup server. The JSP page will operate as follows, once the user is connected to the Mashup website; the user locates the text file which contains information on the scanned items by pressing the ‘Browse’ button, as illustrated in Fig. 5.3.1. Once located, the client presses the Upload button to send the file to the web server. Has the upload been successful, a message would appear on the page and the user obtains a list of product names on the next page, as illustrated in Fig. 5.3.2. The client then selects which item he/she wants to obtain additional details for. Results are displayed to the client, with information such as price and ratings obtained from Yahoo! Shopping as well as Amazon (Fig. 5.3.3). In Figure 5.3.3: Rating.jsp order for the web page to retrieve this information, two Java classes were called by the Mashup server, and contained XML parsing methods to process information from Amazon and Yahoo (See Appendix D). All JSP pages have not yet been optimised for use on mobile devices, since the first iteration focuses on making sure different parts of the system work correctly. 5.4 Unit Testing Now that the stated goal has been achieved, the author can start performing system testing prior to a further iteration. The testing aims to examine whether all parts of the system work correctly, so that the prototype can correctly evolve. The author is to inspect the different components of the application with the intention of locating errors. If all components are - 25 - correctly examined, it is likely that new errors will be identified and subsequently fixed, thereby increasing the success of the application. The testing is split into three sections; client testing (documented in Appendix J), server testing and data testing, each section relating to a single component of the application (as illustrated in Fig. 4.7). Since the system is in its early stages and given that there are no specific users for this application, user acceptance testing was not considered. Also, given that the application has not yet been designed for use on mobile devices, showing it to users would bring back inappropriate feedback. Since the stated goal of this iteration was to validate the feasibility of the general architecture, system testing was found to be sufficient at this stage. - 26 - 6 Iteration 2: Matching Application Scenarios 6.1 Goals The aim of the second iteration is to have the prototype match the shopping scenarios specified in section 4.2. The current prototype requires the user to manually upload a text file to the Mashup server, and does not consider multiple users carrying out simultaneous requests. These are two performance issues which need to be addressed in this iteration, in order to correctly comply with the scenarios. The prototype will also need to seamlessly integrate different parts of the system, by allowing communications between client and server to occur without the user’s knowledge. 6.2 Design In order to improve the efficiency of the existing system, two components will be added to the existing simulation environment; a web service and an additional database. Both components will be part of the Mashup server. To create a web service, a Java platform called Apache AXIS will need to be added on top of the existing Apache web server. This will allow the creation and deployment of web service applications written in Java. The database will be created using MySQL software, since it has already been used to create the shop database. The web service will accept the user’s login credentials as well as the scanned item’s description and its associated EPC number. The purpose of the web service is to collect the aforementioned details in order to then instantly retrieve information about the item. Prefetching the information is a considerate improvement to the first iteration, where scanned items were stored in a text file on the client’s handheld device. This meant that the client had to manually locate and then load this file onto the Mashup server, through the web browser. The Mashup server consequently had to parse the file and only then did it provide the user with a list of items, for which additional information could be obtained. The Mashup database is needed in order to store information retrieved from the Yahoo! Shopping and Amazon web services. It is also required to store details retrieved by the new web service. The Mashup server will store information discussed above in a table not specific to a single user. The reason for this can be explained through the use of a short scenario; “Imagine two users requesting a rating for a Nokia 6110 phone on the same day. At 9.00am the first user requests information for this product. Details are obtained from Yahoo and - 27 - Amazon, and then stored into the database. The information is then displayed to the user. Fifteen minutes later, a second user walks into a local phone shop and scans the same item. Since information has already been obtained for that item, there is no point in making another request. The information can simply be taken from the existing database entry.” The scenario clearly explains the need for stored information to be available to all users of the system, as opposed to having a single table for each user. It also illustrates the use of caching, which overcomes issues related to server performance and bandwidth. There will be no further need to request data from Yahoo! or Amazon web services if an item was already scanned by any user of the application on the same day. Two tables will be created within the new Mashup database; i) User_info – this will contain information retrieved from the web service, ii) Product_info – this table will contain information obtained from the shopping APIs. The user information table will contain a username entry as well as the EPC number and a timestamp of when the item was scanned (Table 6.7.1). Column Name Data Type Column Name Data Type User_id Varchar(30) Epc Varchar(10) Epc Varchar(10) Product Varchar(100) Date_time Timestamp Rating Double Date_time Timestamp Image Varchar(100) Similar1 Varchar(200) Similar2 Varchar(200) Similar3 Varchar(200) Similar4 Varchar(200) Similar5 Varchar(200) Price_amazon Varchar(10) Price_yahoo Varchar(20) Table 6.7.1: User_info table Table 6.7.2: Product_info table The product information table will contain details about the scanned item, retrieved from the shopping APIs (Table 6.7.2). The table is linked to the User_info table through the EPC field. Columns Product, Rating and Price will contain general information on the item. The Image will consist of a URL pointing to the product image located on the Amazon website. For each similar item obtained from Amazon as stated in the shopping scenario, a column named SimilarX (X being a number from 1 – 5) will contain a range of details about that item. Only - 28 - five similar items will be considered, since the system is to be displayed on a mobile device. This will avoid data overloading but it will also reduce the amount of information stored in the database. A timestamp will be recorded for each entry, in order to later observe whether stored information is recent enough or whether it should be updated. The use of timestamps is what the caching mechanism relies on, as explained in the short scenario. The use of pre-fetching and caching is illustrated in the diagram below. The diagram shows what happens from the moment the client scans an item, up to the point where information on the item is stored in the Mashup server’s database. The Mashup server connects to its database in order to check whether data on an item has already been retrieved and stored. If it has, then a message will be communicated to the Mashup server stating that no action is required. Otherwise, a message will be sent to the server stating that it needs to retrieve data from the Shopping APIs. In this case, the Mashup server will retrieve data from Yahoo! and Amazon, and will then store that information into the database for a later client retrieval. Figure 6.7.1: Sequence Diagram for item scan 6.3 Implementation The first step in this second iteration is to create a web service on the Mashup server. For this to happen, Apache AXIS had to be installed on the existing Apache web server. A Java web service called Service was then created on top of the AXIS platform. It provides a method for the submission of a scanned item’s details as well as the user credentials. In order for the handheld device to access this method, a client is needed to communicate to that web service. A Java class ServiceClient was therefore created and integrated within the existing client - 29 - application, implemented in section 6.4. It contains a method which takes in parameters from the ProductInfo class and consequently sends these to the web service. Instead of storing information into a text file, ProductInfo will now call the ServiceClient module in order to pre-fetch information to the Mashup server. Now that pre-fetching was working, some means to store the pre-fetched information was needed. A database, outlined in the design section, was therefore set up in order to store this information in addition to information retrieved from the shopping APIs. Both the Product_info and User_info tables have been created on the new database using data structures outlined in the previous section. Below are two tables containing possible information within the User_info and Product_info table. The use of caching can be explained through the scenario below, with the help of these two tables. User_id Epc Date_time tobys 01023c1182 2007-03-21 13:03:45 tobys 010238a5e4 2007-03-21 16:56:42 michaelb 01023c1182 2007-03-21 16:59:34 Table 6.8: Simulated data within the User_info table Table 6.8 shows a list of all items that have been scanned on the 21st of March. Michael (user michaelb) and Toby (tobys) are two users of the Mashup application. From the table, it can be seen that both users scanned at least a single item on that day. The table shows that one of the items scanned by Toby was also scanned by Michael, a few hours later. Each record in the User_info table is related to a record in the Product_info table, using the EPC number as a key to link the tables. Table 1 in Appendix I illustrates that item details for both scanned items have been obtained from the shopping APIs and subsequently stored into the database. The similar item columns each contain chunks of information about an item. Details stored about such items are author, title, rating, price and image URL. In order to reduce the payload of used database columns, the author decided to concatenate information for a single item into a single column. For product “Dan Brown – Deception Point”, only a single record was stored in the Product_info table. This happened directly after user Toby scanned the item. When user Michael then scanned the same item a few hours later, the database already contained an entry for that item. Since caching has been set to work on a day-to-day basis allowing stored information to be used for 24 hours, the stored database entry was still valid for user Michael. The logic for the caching mechanism can be explained using code below taken from the Java - 30 - web service located on the Mashup server. The code gets executed as soon as an item is scanned by the user, and contacts the Mashup database and Shopping APIs when needed. /** IF EPC ENTRY IS NOT FOUND **/ if (foundEPC == null) { // get information from shopping APIs // insert information into Product_info table // create a new entry in the User_info table } /** IF EXISTING EPC ENTRY IS FOUND **/ else { // check if item is already stored in database /** IF EXISTING INFORMATION IS NOT FOUND IN DATABASE **/ if (foundRating == null) { // get information from shopping APIs // insert information into Product_info table // create a new entry in the User_info table } /** IF EXISTING INFORMATION IS FOUND IN DATABASE **/ else { // check if information is recent enough // check if stored data is less than 24 hours ago /** IF RECENT RATING IS NOT FOUND IN DATABASE **/ if (foundRecentRating == null) { // get information from shopping APIs // insert information into Product_info table // create a new entry in the User_info table } /** IF EXISTING RECENT INFO IS FOUND IN DATABASE **/ else { // create a new entry in the User_info table } } } 6.4 Evaluation In order to evaluate the current prototype, a focus group was conducted with six participants. The objectives of the focus group were; to identify missing functionality with regards to the existing system, allowing for later additions or modifications to identify other possible scenarios with a combination of RFID and Mashups to identify issues which a real life application should cope with to assess the technical robustness of the application Since identifying missing functionality was the prior concern at this stage, conducting a focus group was found to be the most relevant, allowing for extensive user feedback. - 31 - 6.4.1 Procedures and Materials A focus group was arranged with active members of the School of Computing. The session was due to last an hour, and consisted of a short presentation on the author’s project followed by a demonstration of the most recent version of the application. After the demonstration the author was to gather feedback from the participants with regards to the stated objectives. The session took place in a meeting room located in the Informatics department, which was equipped with a large TV screen ideal for focus groups. The author’s notebook was used for the session, since it contained the simulated data as well as the client application modules for the demo. An RFID-reader was also used in order to successfully simulate the application, and to provide the participants with a clear view of the application’s capabilities. The feedback session was recorded with the participants’ consents, and a transcript with the summary of the feedback is available in Appendix E. 6.4.2 Participants The six participants involved in the focus group assisted voluntarily in the session. They are all part of the Knowledge Management and User Adaptive Systems reading group, to which an e-mail has been sent with regards to this event. The author did not target a specific audience for the session, though it was assumed that members of the reading group would have technical and research backgrounds, having previously attained a PhD or MSc degree. Each of the participants had prior knowledge of at least one of the following fields; Mobile Development, Personalisation, e-Commerce, Digital Libraries, Web Mashups. 6.4.3 Results against Evaluation Objectives Identify missing functionality with regards to the existing system, allowing for later additions or modifications. One of the participants suggested showing the source for a rating and price to the user. She stressed that users want to know where information comes from, so that if they are interested in buying the item from the online shop, they can instead buy it from there. Another suggestion was regarding Yahoo’s price range not including the respective shops and their individual price; “If it comes from Yahoo, can you get the exact shop that it’s coming from?” Another participant encouraged the possibility of showing the status of items, by marking them new or second hand items. This would allow the user to be aware - 32 - of the item status and to decide whether it would be cheaper to buy the item in the actual shop or otherwise online. Having gathered additions for the next iteration, the author introduced his idea of a smart rating algorithm to the participants. This was in order to know whether they would be interested in the outcome, if it was to be available to them. The idea was to collect a rating (out of five) for an item from each customer review contained within the shopping website. Depending on how many reviews a customer gave, a relative weight would be applied for that customer rating. This meant that the more reviews a customer gave on Yahoo or Amazon, the more weight were to be associated with the review. At the end of the algorithm, weights would be accumulated and a final rating would be given to the user. As a response to the idea, the participants were not too interested in knowing an item’s rating. They were rather inclined to know what the price would be for that item. Identify other possible scenarios with a combination of RFID and Mashups. Tourist information scenario: One of the participants pointed out that RFID tags have been attached to various locations in York. Tourists would walk around the open city and notice tags located on walls. If a tourist is to be equipped with an RFID reader, he would be able to “get information about that particular site” which he is seeing. This is where RFID technology comes into play. With regards to Mashups being integrated within the scenario, the participant added that it is “interesting to see what else you can pull from the web about that particular site”, referring to web sources containing additional information about the tourist site. Library scenario: A participant with knowledge on digital libraries suggested the use of RFID within bookshops. Shoppers would be equipped with a mobile RFID-integrated device with the possibility of scanning books. A customer might be interested in a specific book, but is not yet looking to buy it. His mobile device will therefore allow him to obtain “a link to all libraries” in his city that contains this book. These libraries will allow customers to “borrow a book and have a look”, and if interested, they could buy the book from the shop they were in previously. Recipe scenario: The last scenario was proposed by a participant with e-Commerce background. When a customer goes shopping, she might like a specific food item, but does not know what else to buy in order to make a dish. The potential mobile application would recommend other food items in order to provide the customer with all the ingredients required for a recipe. - 33 - Identify issues which a real life application should cope with. The first issue was raised by a participant with experience in mobile development. The issue was the problem of changing the programming environment for the prototype from J2SE to J2ME. The first environment, Java 2 Platform Edition, is a platform which was used for the prototype, and can be used for desktop applications only. Java 2 Micro Edition, on the other hand, is aimed at mobile devices. In order to translate the prototype to a real life mobile application, issues regarding the conversion from a desktop to a mobile development environment need to be considered. A second issue raised by one of the participants was the ease of extending the application to another web service. The current prototype uses two different formats to obtain data from Yahoo! and Amazon. This is because each shopping web service accepts different parameters in order to then return requested data. Adding a new service would therefore require the creation of a new format. The participant also suggested the use of UDDI (Universal Description, Discovery and Integration) within the application, in order to allow for discovery of new web services. The final issue raised by some of the participants was the acceptance of the application by companies. Since the author is targeting users of the system and not companies willing to invest in the product, the issue is not considered within the scope of this project. It is however important to accept that companies “don’t actually want you to know about the competitors”, as one of the participants acknowledged. Assess the technical robustness of the applications An important aspect in providing robustness within the application is ensuring a reliable connection between the different physical components. Wireless communications between the handheld device and the Mashup server should be reliable. Connection to the shop database should also be reliable. Another issue is the availability of a shop database, which is needed to identify scanned items. Shops might not be RFID-compliant, or they might not publish their database to the public. This is an issue that needs to be considered if the application is to be real, instead of a simulation. What worldwide companies might do in the future is transfer RFID data on their stock to a centralised database, which would be available to the public. - 34 - 6.4.4 Implications for the Third Iteration Having discussed different aspects related to the prototype, missing functionality raised by some of the participants is what should be taken into consideration for the next iteration. The last set of objectives considers other possibilities with RFID Mashups, and issues which are important if a real life application is to be released. These are important factors for making this application a real business case, but are not to play a role in the third iteration. The author has decided not to implement the smart rating algorithm in the next iteration, as a result of the participant’s response, but also because of time constraints. If enough time remains, missing functionality will be added to the prototype. However, the main focus for the next iteration is to get the simulation working on a mobile device. This will be done by converting all created web pages to a mobile format. - 35 - 7 Iteration 3: Interfacing with a Mobile Device 7.1 Goals The aim of the third iteration is to use the integrated solution, completed at the end of the previous iteration, to interface with a mobile device. Previously, information was designed to be displayed on a desktop PC, thereby making it hard to show the benefits of the application to users. This iteration will allow for mobile compatibility, thus enhancing the customer experience. The mobile interface to be created should be kept simple and should not overload the user with unnecessary data. Overall, this iteration will try to match the prototype to the shopping scenario as close as possible, turning the prototype into a sensible and realistic application. 7.2 Design Providing users with a mobile interface will be achieved by converting all existing JSP pages located on the Mashup server to a mobile web format, yet still allowing access with ordinary web browsers. Wireless Access Protocol (WAP) is the mobile services specification which controls these mobile formats. It was coined by the WAP Forum, now called the Open Mobile Alliance (OMA). XHTML-MP (eXtensible HyperText Markup Language Mobile Profile) is the mark-up language for the most recent WAP version (2.0), and it has been identified to be the most suitable for converting pages to a mobile format. Kaikkonen and Roto [34] acknowledge this by stating that XHTML-MP allows developers to create web applications viewable with both ordinary and mobile browsers. Mark-up languages such as WML and WMLScript are used for older WAP versions, which on the other hand only allow for mobile development. Since the prototype has already been built for use on ordinary PCs, the author is looking to extend it for use on mobile devices. A mobile PDA was therefore to be used as part of the simulation, requiring a wireless network card for connection to the shop database, and a Mashup server as well as a web browser to display the XHTML-MP pages. An HP iPAQ 5550 PocketPC was chosen to act as the simulation component, since it was already available to the author, and also satisfies both aforementioned requirements. With regards to input of data, it is worth noting that essential differences need to be taken into consideration when initiating the design of a mobile application, as opposed to a desktop solution. Given that the - 36 - current iteration covers the use of a mobile device, it is worth explaining these important differences. User Interface: Limited size of screen; this leads to a difficulty in the choice of font size, as users need to be able to read information from the screen. This limitation is emphasised if the PocketPC’s operating system does not have a function to increase displayed text. It also restricts the amount of information displayable on the device. The user should be provided with as much information as necessary in order to achieve a rewarding experience. Thus, information can be browsed by the user in a quick manner, thereby enhancing their experience. The interface should be user-friendly as well as intuitive. It is therefore vital for the success of an application to have a clear and fluid user interface. The added use of colour would also allow the user to easily distinguish between various content areas. Input methods: Designing a mobile application must take into account the following issues involving user input: Current PocketPC’s are equipped with a crude pointing device, such as a stylus pen, which is used for all consequent user input. The small majority of these PocketPC’s may also include an embedded semi-sized keyboard. These keyboards are inherently hard to use due to their small size. They also take up valuable space which could be used to increase display size. On the other hand, some devices offer an emulated keyboard which is used by pointing the stylus at the required key. Yet, this type of keyboard is tedious and errorprone when used. Furthermore, this type of keyboard consumes vital display space. Along with the previously mentioned issues, the above stated drawbacks must also be taken into consideration when designing a mobile application. A means to overcome these issues is to reduce user input to a minimum. For example; the user should be presented with a number of options instead of a textual input box, in other words item information can be selected from a pre-fetched list instead of being manually inputted by the user. - 37 - 7.3 Implementation A total of two JSP pages to be found on the Mashup server were converted to the XHTMLMP format; List.jsp and GetRating.jsp. Both pages first needed a Document Type Declaration in order to be later validated against the WAP standards. The added DOCTYPE declaration is shown below. <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd"> Two considerable modifications were required in order for the pages to comply with the XHTML-MP format, the first one being the conversion of all tags and attributes to lowercase. This is because the mark-up language is case-sensitive, as opposed to regular HTML code being case-insensitive. The second change was regarding tag closures; all tags must be closed properly, that is if a <p> tag is followed by content, it should be terminated with a </p> tag to specify the end of a paragraph. Tags which do not come in pairs (as a result of no content being enclosed) must be self-closed, in other words a tag representing a space should be written as <br/> instead of <br> as in ordinary HTML. List.jsp is the initial page the user is faced with after an item has been scanned and the user has connected to the Mashup website. The outcome of the change to XHTML-MP is very similar to Fig. 5.4.2 from the first iteration, although the JSP page is now compatible with the PocketPC device. The Java code fragment below shows the first step taken to provide the user with a list of scanned item. The code is contained within JSP tags (<% and %>) to allow for Java enclosure. <% // Store username String username = request.getParameter( "user" ); // Connect to the Mashup database QueryDB query = new QueryDB(); Connection c = query.getConnection(); // Query the Mashup database for information on item query.getInfo(username, c); // Store information into array lists productArray = (ArrayList)query.getProductArray(); epcArray = (ArrayList)query.getEPCArray(); %> The parameter “username” is obtained through the browser when the user has specified a username upon connecting to the Mashup website. This can be shown by the looking at the following URL. http://129.11.144.9:8000/Ratings/List.jsp?user=michaelb As soon as the username has been retrieved, a connection to the Mashup database will be performed, passing the username as a parameter in order to later obtain a list containing information on the scanned items as well as a list holding EPC numbers. The second step is - 38 - outlined below, where the list of scanned items is dynamically created on the web page, once more, through the use of Java code. <form method="post" name="myform" action="GetRating.jsp"> <select name="mylist"> <% for (Iterator it = productArray.iterator (); it.hasNext (); ) { for (Iterator it1 = epcArray.iterator (); it1.hasNext (); ) { Object product = it.next (); Object epc = it1.next (); out.println("<option value="+epc+">"+product+"</option>"); } } %> </select> <br/><br/> <p>Get Rating :</p><input type="submit" value="Submit"> </form> The JSP fragment above shows the outline of an HTML form which includes a dynamic list made up of data obtained from the two stored Java array lists. In order to obtain information stored within these lists, two ‘for loops’ are required to iterate through their entries. Within each iteration, the loop creates a list item. The example below shows an example of such item. <option value=01023878c6>Dan Brown The Da Vinci Code</option> The outcome of List.jsp can be shown through usage of the PocketPC, as illustrated in Fig. 7.3.1 and Fig. 7.3.2. The first image shows the initial screen the user is presented with upon connecting to the Mashup website. The second image shows the exact same page but after the user has clicked on the list box, displaying a list of all scanned items back to the user. Figure 7.3.1: List.jsp Figure 7.3.2: List.jsp - 39 - Once the submit button has been pressed, the user is forwarded to GetRating.jsp. This page will display information regarding the item selected in List.jsp. The information consists of a product description, rating, image and price as well as details on similar items. The java code below shows how information on the selected item is retrieved, and later used to perform a database query. The aforementioned information will then be stored after data has been returned by the database. <% // Retrieve item description from previous page String epc = request.getParameter( "mylist" ); // Connect to the Mashup database QueryDB query = new QueryDB(); Connection c = query.getConnection(); query.getSpecificProduct(epc, c); // Store product information String product = query.getProduct(); String rating = query.getRating(); String image = query.getImage(); String priceAmazon = query.getPrice(); String priceYahoo = query.getPriceRange(); %> Once the information is stored into Java variables, it can be integrated within HTML code, using colours to facilitate the display of the interface to the user. The code below applies a style sheet used to alternate between two colours to achieve this. <table border="0"> <tr> <td><% out.println("<img src='"+image+"' align=left>"); %></td> <td> <p class = "blue"><b>Product Name:</b> <%=product%><br/></p> <p class = "black"><b>Price from Amazon:</b> <%=priceAmazon%><br/></p> <p class = "blue"><b>Price Range from Yahoo shops:</b> <%=priceYahoo%><br/></p> <p class = "black"><b>Average Rating:</b> <%=rating%> / 5 <br/></p> </td> </tr> </table> Fig. 7.3.3 shows the JSP page being displayed on the PocketPC, with a clear alternation of colours. It also shows a list of related items obtained from the Amazon web service. Fig 7.3.4 demonstrates how related items are clearly separated from one another through the use of a divider, thereby providing the user with a clear interface. - 40 - Figure 7.3.4: GetRating.jsp – Similar Items Figure 7.3.3: GetRating.jsp – Item Info. Having discussed both mobile compatible JSP pages, it can be said that these adhere to the input methods provided in the design stage. Neither page requires the user to enter data into the application, therefore making it easier for the user to navigate through the application. User interface differences have also been considered, and the application now fits all content within the PocketPC screen. 7.4 Evaluation Since the third iteration is the final version of the prototype, the author has decided to perform usability testing with eight participants. The testing is qualitative in nature, and consists of gathering data from actual users through successive, in-person one-on-one interviews. The objectives of the evaluation were; to determine whether the intended audience and anyone else who might come in contact with the Mashup web interface, can use the application. to determine participants' satisfaction with the product. - 41 - 7.4.1 Procedures and Materials The eight interviews were each due to last less than ten minutes and consisted of a quick explanation of the product followed by a demonstration on how to use the application. The user was then to use the application and fill in a usability questionnaire. For same reasons as in the focus group (section 6.4.1), the author’s notebook as well as RFID reader was needed for the session. The questionnaires were provided by paper, and along with a summary of the feedback, these are available in Appendix F. 7.4.2 Participants According to Waldal and McLachlan [35], five participants can help provide trends in a product’s usability test. In addition, they believe that having three more users can help qualify the trends, thereby making eight users the bare minimum for performing usability testing. It is for that reason that the author decided to perform eight interviews, thereby collecting sufficient information in order to find trends. Due to time constraints, the testing was restricted to the minimum of eight participants. The eight participants involved in the usability testing were randomly selected by the author, although the following criteria needed to be met before testing could continue; the user had to be a consumer of electronics products or books, or at least willing to purchase items within one of the categories. This is because the current prototype only allows for these specific categories to be scanned. It was also crucial that the potential participant was to agree to use a mobile device in a shop, as this is how the customer experience was to be enhanced. Once a participant matched the abovementioned criteria, demographic characteristics were gathered about him/her. This was in order to build a user matrix, covering different types of users with varied levels of experience with mobile devices and online shopping. 7.4.3 Data Collection and Analysis Data to be collected was demographic information as well as feedback gathered from eight participants through usability questionnaires. With regards to data analysis, demographic information retrieved was to be used to categorise the different type of users. Results from the questionnaire, on the other hand, were to be analysed to determine user satisfaction with the application. - 42 - 7.4.4 Results against Evaluation Objectives A number of demographic information was asked to each of the participants. The results indicated that most of them did not have previous experience with mobile web browsing. The average years of experience that the participants had of online shopping were five years. This was similar for previous usage of Amazon or Yahoo! Shopping, as the average for this was four years. Determine whether the intended audience and anyone else who might come in contact with the Mashup web interface, can use the application. Regarding the questionnaire, the majority of the participants agreed that the mobile application was easy to use, and that information was very clearly presented to them. However, one of the participants commented on the fact that it was not clear to them that the related items displayed were user recommendations. Anther participant did not like having to scroll down the results page to find the “back” button in order to select another item. Having to reload the page when scanning an item was not liked by two of the participants. According to them the application needs to run smoothly, by automatically showing the user the last item he has scanned. Someone else commented on the fact that a list of all items should be displayed to the user, instead of a dropdown box hiding all entries. Determine participants' satisfaction with the product. All participants liked the use of colours within the application. However, one of them observed that background colour for prices being displayed was not consistent. With regards to the application providing enough information about an item, the majority of participants disagreed, stating the following; 1) the average rating was not informative. 2) a customer review for an item is missing 3) more retailers along with their prices should be displayed. One of the participants proposed to have a personalisation option, where user profiles can be stored, indicating the type of information that should be displayed on an item. When asked about their satisfaction with the application, the majority of participants were pleased with it. Finally, all participants said that they would use of the application again, if they were to be in a shop. - 43 - 8 Evaluation This chapter initially talks about the evaluation of the prototype, performed through an interview with an expert in the field of Software Engineering and Computer Security. The chapter then outlines the evaluation of the project, which will most importantly be judged against whether or not it has achieved the stated objectives, and to what extent these have been extended. Furthermore, the project methodology will be examined as it was a key constituent for the success of the project, but also identified the way the author decided to tackle the project. Part of the evaluation is to also examine the approach taken to schedule the entire project. 8.1 User Prototype Evaluation A structured interview took place with a senior teaching fellow at the School of Computing responsible for teaching programming and security modules, and with prior knowledge of Mashups. The interview questions are documented and can be found in Appendix G. At the start of the session, the expert was given an introduction on the project, and was then asked to read through the shopping scenario as well as the final prototype architecture specified in Appendix G. A demonstration of the prototype was consequently given before the interview could start. When asked about the appropriateness of the shopping scenarios, the expert acknowledged that the scenario was a good example and that it related well to the architecture. He then pointed out that the simulation approach was sensible. Feeding back on the architecture, the expert mentioned that a component which would automatically load a web page when an item is scanned, was missing. He also mentioned that a plug-in architecture should be used in order to allow for an abstract layer between the Mashup server and the shopping services. Regarding the feasibility of the application, the expert emphasised that security was an issue. This is due to the prototype not having considered the use of encryption to secure stored database information, but also other security issues. When asked about the chosen methodology method, he commented that the use of an iterative approach was a sensible for this kind of project. Finally, the expert stated that the combination of Mashups and RFID allows for automation with regards to obtaining information about an item. He mentioned that the scenario cannot be applied had there not been usage of RFID technology, as it would not be practical to bring a keyboard and manually start typing item information. - 44 - 8.2 Minimum Requirements and Extensions The project aim was to examine how RFID can be used within Intelligent Mashups to enhance customers’ experiences. In order to meet this aim, achieving the minimum requirement was of great importance. The requirement was defined as “an Intelligent Mashup prototype which includes a single web data source and simulated RFID data with a shopping scenario”. Since only a single minimum requirement was stated in the introduction chapter, it shall be split up in order to be able to examine how each individual requirement was met. A shopping scenario Two shopping scenarios have been considered, and these can be found in section 4.2. The scenarios have been the fundamentals for the design and implementation of the prototype, seeing that they acted as the requirements. Simulated RFID data Since obtaining real RFID data used in retail shops was not possible due to a different RFID format being used in this project as outlined in section 3.2.3, RFID data was simulated by having set up a dummy shop database. The database accommodated for RFID tags of the format specified in section 4.6, and product information was gathered from two different shopping sources chosen in section 4.1. The choice of product categories has been identified and together with the number of items used in the simulation, these have been justified. An Intelligent Mashup prototype which includes a single web data source The interactions specified in the shopping scenarios as mentioned in the above requirement, were used to build a general architecture for the prototype. Once the simulation environment was set up to include the simulated RFID data, the first prototype iteration was developed. The prototype consisted of two data sources, Amazon E-Commerce and Yahoo Shopping!. The initial integration of a single web data source was to be as generic as possible, in order to later add more data sources. This allowed for the troublesome addition of the Yahoo Shopping! service. The prototype extensions were additional requirements set for the completion if the project, if the author was to have enough time as well as the available resources. Integrating more data sources (i.e. online price comparison) As mentioned in the evaluation of the third minimum requirement, an additional data source was added to the prototype. The Yahoo Shopping! API was used in order to provide prices - 45 - associated with its affiliated online shops, as well as to present product ratings. Both data sources however were already used within the first prototype iteration. Therefore, instead of integrating more data sources, it was decided that more data was to be pulled from the Amazon E-Commerce service in order to allow for compliance with the scenarios. Integrating a user rating system Having carried out a focus group after the second prototype iteration, the idea of extending the prototype by adding a smart rating system was presented to the participants, as stated in section 6.4.3. The participants however did not like the idea of such extension, and said they would rather be interested in price information than rating details. This was taken into account in third the iteration, where the author focused on providing a mobile interface to turn the prototype into a realistic application. As the application was shown to the participants on a regular PC, it was not clear to them how the application was to be of real use. 8.3 Project Methodology Chapter 2 and Appendix B summarise research which was performed on different software development methodologies, varying from the traditional Waterfall approach to other more flexible models. It was decided that a mixture of two models would be used for this project, as these contained features relevant for the development of the prototype. The customised methodology (illustrated in Fig 2.3.1) enabled the use of iterations, allowing the prototype to evolve through stages of user feedback or testing. The use of these iterations integrated well within the project as each of these allowed for a set of new or existing components to add value and functionality to the product. However, the problem with the implementation phase is that restricting the choice of functionality to be fitted into a single iteration proved to be a difficult task. To try and avoid this issue, detailed goals have been set at the start of iteration along with required functionalities. 8.4 Project Schedule Time management is essential for the success of any type of project, and was therefore evaluated for this project. As pointed by the project assessor, the initial project schedule (Fig. 1 in Appendix B) strongly resembled the use of a Waterfall model approach. This was due to the schedule not having appropriately illustrated the use of iterations. The initial project schedule left all implementation work to be done after the allocated Easter break, and as a result the schedule was criticised for being rather ambitious. The final schedule is illustrated - 46 - in Fig 2.3.2 and was compiled after having received project feedback on the Mid-Project report. It differs from the initial schedule by having partitioned the system design, implementation and validation stages into smaller tasks which would allow the use of stricter deadlines. Looking at the initial schedule, disambiguation occurred with regards to the system design stage. As identification of online data sources and the shopping scenarios belonged to a stage called “Design”, it added confusion to the schedule which already contained a System Design stage. This was reflected upon in the final schedule by changing the Design stage to Problem Analysis. 8.5 Business Case Consideration Turning the prototype into a business case was not taken into consideration in this project, as the prototype was aimed at consumers and not companies willing to invest in the product. The project scope was therefore scaled to only accommodate for the users needs. Although companies’ interests in the prototype were not considered, it is important to discuss the issues they would have with the application. The prototype developed in this project provides users with product prices from online competitors. This would benefit the users, but is something companies would not approve, since it defeats the purpose of buying from their shops. Therefore, a suggestion for an alternative use of the application can be given which would be of use for both companies and consumers. The potential mobile application would recommend food items to users after they have scanned grocery item, in order to provide them with ingredients required for a recipe. Recipes would be gathered from different cooking sources on the internet. This alternative application would benefit the shop by pushing the consumers to buy other food items in the shop, but would also be beneficial for consumers since they could be offered suggestions on what kind of dish they could make with scanned items. 8.6 Further Work Personalisation – As suggested by one of the questionnaire participants, the application could evolve to allow the storage of user profiles. Each profile would indicate the type of information that should be displayed for a user about an item. Another feature would be to allow the user to choose from a list of shops he would like information on. Conversion to RFID-integrated phone – Since the prototype is built around a simulation, future work might be to develop it for a real mobile device with an integrated RFID module. - 47 - NOKIA has already released two of its phones with RFID integration [36], and other phone suppliers are likely to do the same, knowing the clear benefits RFID technology has to offer when combined with phones. The author has applied to participate in a 5-day RFID workshop in the Netherlands where RFID equipment will be available and a proof of concept is to be designed and developed. Exchanged e-mails between the author and a representative for the workshop are documented in Appendix H. - 48 - 9 Conclusion 9.1 Feasibility of Combining RFID and Mashups Three different perspectives were taken on the feasibility of RFID integration within Intelligent Mashups, and on whether both technologies are suitable to enhance customers’ experiences. Each of these are be summarised below. i) The opinion of the author, who has developed a working RFID Mashup prototype. ii) The perception from the focus group participants who have seen a working version of the prototype. iii) The view from an expert in the field of Software Engineering and Security who also had detailed knowledge of Mashups. Author’s viewpoint Having developed an RFID Mashup prototype for a shopping scenario, the author believes that the two technologies can work together effectively to enhance customers’ experiences. This would not only apply to shopping situations, but could be useful for different circumstances, such as household appliance use, as mentioned in section 3.2.2. Focus group participants’ viewpoint Participants acknowledged the fact that merging RFID technology with Mashups can bring added value to users. They mentioned the use of three alternative scenarios to illustrate the possibilities that are available when combining both technologies with useful sources of information. Data about tourist attractions, libraries and recipes were sources of information discussed in the focus group (section 6.4), which could be used to bridge the gap between the physical world and the virtual world thereby enhancing people’s experiences. The participants also mentioned the issue of reliability such as wireless communication between the Mashup application and its web data sources located on the internet. This problem is especially applicable to mobile applications requiring wireless connection to the internet. Expert’s viewpoint When asked about the feasibility of combining both technologies, the expert only gave an answer with regards to the shopping scenario. He mentioned that the merging of RFID and Mashups can lead to the automation of objects or devices, but that security should be considered when building such applications. 9.2 Comparison to Other Solutions In this section, similar solutions to the prototype developed in this project will be compared. As explained in section 3.3, there seems to be only a single commercial Mashup application - 49 - making use of RFID data. The application however cannot be compared to the prototype, since it does not offer shopping services. However, research projects as well as pilot tests by companies have been undertaken on RFID-based shopping assistants [37] [38]. The author has chosen to compare fully deployed solutions offering similar services to the prototype, making instead use of alternative technologies. Virgin Mobile Shopping Assistant – Virgin has launched a mobile shopping service [39] allowing its customers to search and compare products over their mobile phones whilst shopping. Features such as product comparisons, other retailers’ prices and live purchasing are included within the service. The service has the disadvantage of requiring users to manually type in products they wish to obtain more information on, as opposed to the prototype allowing for automatic product scanning. Features such as product purchasing and retail prices are useful characteristics which are not addressed in the prototype. SmartWorlds iShop Books – iShop Books [40] is a free software designed for use on a PocketPC that can act as a personal shopping assistant for books, using the device’s wireless or cellular connectivity to obtain information from Amazon.com’s web services. The application can provide customer reviews retrieved from Amazon, in addition to this project’s prototype features. Relevant book information is retrieved after the user would enter a ten digit book identifier known as the ISBN. Again, compared to the prototype, this software requires manual input from the user, but is also restricted to Amazon-related books information only. 9.3 Summary The project aim was to examine how RFID could be integrated within Intelligent Mashups in order to enhance customers’ experiences. Research on RFID technology as well as Mashups has been undertaken in order to form the basis of a prototype. The problem analysis section allowed for a set of scenarios to be identified based on previously chosen online data sources. Different user opinions have been gathered throughout the prototype development, thereby allowing for useful feedback regarding feasibility, functionality and usability of the application. Comparisons to other solutions have showed that other technologies can equally enhance customers’ experiences, although manual intervention would still be required. In essence, the final product confirmed the feasibility of combining the two technologies to allow for the enhancement of customers’ experiences. - 50 - References [1] Sommerville, I. Software Engineering Sixth Edition, Addison-Wesley, 2001 [2] Bocij P, Chaffey D, Greasley A, Hickie S, Business Information Systems Second Edition, Prentice Hall, 2003 [3] O’Reilly Media Inc. Web 2.0: Principles and Web Practices, http://www.oreilly.com/catalog/web2report/chapter/web20_report_excerpt.pdf, Nov 2006 (as of Nov. 8 2006) [4] O’Reilly Media. Web 2.0 Conference, http://www.web2con.com/web2con (as of Apr. 20, 2007) [5] O’Reilly, T. What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software, self published on http://www.oreilly.com, 09/30/2005 (as of Nov. 8, 2006) [6] Porter, J. Introduction to Web 2.0, http://www.squidoo.com/introtoweb20/, 12/12/2005 (as of Nov. 8, 2006) [7] Fitzgerald, M. 2006. The Name Game: Tagging tools let users describe the world in their own terms as taxonomies become "folksonomies." CIO, Apr 01. [8] Chase, N, The ultimate mashup -- Web services and the semantic Web, published on http://www-128.ibm.com/developerworks/edu/x-dw-x-ultimashup1.html, 22 Aug 2006 (as of Nov. 15 2006) [9] Duane M, Mashups: The new breed of Web app, published on http://www128.ibm.com/developerworks, 08 Aug 2006 (as of Nov. 8, 2006) [10] Berlind, D. Mashup Ecosystem poised to Explode, http://blogs.zdnet.com, 27 Jan 2006 (as of Nov. 8 2006) [11] Hof, R D. Mix, Match and Mutate, http://www.businessweek.com, 25 Jul 2005 (as of Nov. 8 2006) [12] Rademacher P. Housing Maps, http://paulrademacher.com/housing (as of Nov. 15 2006) [13] sudoku.com.au. FlickrSoduku, http://flickrsoduku.com (as of Nov. 15 2006) [14] Thalasar Ventures. Early Miser, http://www.earlymiser.com (as of Nov. 15 2006) [15] O’Neill B. BBC News Maps, http://benedictoneill.com/content/newsmap (as of Nov. 15 2006) [16] Want R. 2004. The Magic of RFID. Queue 2, 7 (Oct. 2004), 40-48. [17] Sweeney II, P J. RFID for Dummies. Wiley Publishing,Inc., ISBN: 0-7645-7910-X, 2005. [18] Cole, P H. and Engels, D W. Auto ID - 21st Century Supply Chain Technology. (Sep. 2005) White Paper, Ed.1. - 51 - [19] Borriello G. 2005. RFID - Tagging the World: Introduction. Commun. ACM 48, 9 (Sep. 2005), 34-37. [20] Dargan G, Johnson B, Panchalingam M, Stratis C. (2004). The Use of Radio Frequency Identification as a Replacement for Traditional Barcoding. http://www.andrew.cmu.edu/user/cjs (as of Nov. 22 2006) [21] Matrics Inc. (2004). EPC and Radio Frequency Identification (RFID) Standards http://www.scansource.com/rfidedge/Future_Trends_Opportunities/Legislation_Standards/EP C_RFID_Standards.pdf (as of Nov. 22 2006) [22] IATA. Radio Frequency ID (RFID) for aviation. http://www.iata.org/stbsupportportal/rfid/ (as of Dec. 06 2006) [23] RFID Journal. Great Wolf Water Park Launches RFID. http://www.rfidjournal.com/article/articleview/2211/1/1/ (as of Dec. 06 2006) [24] RFID Journal. Hoboken RFID-enables Its Parking Permits. http://www.rfidjournal.com/article/articleview/2421/1/1/ (as of Dec. 06 2006) [25] We Make Money Not Art (WMMNA). Sherelog: Suica Mashup. http://www.we-makemoney-not-art.com/archives/008164.php (as of Dec. 06 2006) [26] Smartspace. Sharelog and Suica. http://smartspace.squarespace.com/smartspace/2006/3/13/sharelog-and-suica.html (as of Dec. 06 2006) [27] John Musser. ProgrammableWeb. http://www.programmableweb.com (as of Mar. 28 2007) [28] Glinz, M. (2000b). Improving the Quality of Requirements with Scenarios. Proceedings of the Second World Congress on Software Quality. Yokohama. 55-60. [29] Ryser, J., Glinz, M. (1999). A Practical Approach to Validating and Testing Software Systems Using Scenarios. QWE’99: Third International Software Quality Week Europe, Brussels, Nov 1999 [30] Roger D. Smith. Simulation: The Engine Behind the Virtual World, eMatter, (Dec. 1999) http://www.modelbenders.com/papers/sim2000/SimulationEngine.PDF (as of Apr. 22 2007) [31] Phidgets Inc, http://www.phidgets.com (as of Mar 29 2007) [32] The Internet UPC Database, http://www.upcdatabase.com (as of Mar 29 2007) [33] MySQL. How MySQL Powers Web 2.0. (Aug. 2006) White Paper http://www.mysql.com/why-mysql/white-papers/mysql_wp_web20.php (as of Apr. 22 2007) [34] Kaikkonen, A. and Roto, V. 2003. Navigating in a mobile XHTML application. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Ft. Lauderdale, Florida, USA, April 05 - 10, 2003). CHI '03. ACM Press, New York, NY, 329336. - 52 - [35] Waldal, L. and McLachlan, E. Ready, Set, Go: Usability Testing. (Aug. 2003) http://www.adobe.com/devnet/articles/usability_testing.html Adobe Developer Article (as of Apr. 18 2007) [36] NOKIA. Nokia Field Force Solution. (2007) http://usa.nokia.com/NOKIA_BUSINESS_NAM_38/Products/Mobile_Software/Field_Force _Solutions/Nokia_Field_Force_Solution_Datasheet.pdf (as of Apr. 22 2007) [37] Lee, K. J. and Seo, Y. H. 2006. A pervasive comparison shopping business model for integrating offline and online marketplace. In Proceedings of the 8th international Conference on Electronic Commerce: the New E-Commerce: innovations For Conquering Current Barriers, Obstacles and Limitations To Conducting Successful Business on the internet (Fredericton, New Brunswick, Canada, August 13 - 16, 2006). ICEC '06, vol. 156. ACM Press, New York, NY, 289-294. [38] Cisco Systems. Japanese Retailer Deploys Intelligent Fitting Room. (Aug. 2006) http://www.cisco.com/web/strategy/docs/Mitsukoshi_CS.pdf Customer Case Study (as of Apr. 23 2007) [39] Virgin Mobile. Virgin Mobile Unveils Shopping Assistant Powered by digitalRUM. (Feb. 2001) Press Release (as of Apr. 23 2007) [40] SmartWorlds. iShop Books. (2003) http://www.smartworlds.com (as of Apr. 23 2007) - 53 - Appendix A – Personal Reflection My year in Industry has given me a considerable amount of experience in developing database systems. During that time, I came across the concept of RFID technology. Throughout the year, I regularly visited RFID-related news articles on the web, and became extremely impressed with the range of applications that can be used when combined with this fast-growing technology. It can potentially be used for everything, from tracking cows to unlocking hotel doors. This was one of the main reasons I chose to use RFID within my project. My initial idea was to allow for a shop item to be scanned and for prices about physical shop competitors (unlike online shops) to be consequently displayed on a customer’s mobile device. As the customer would select the cheapest price presented by the device, he would be shown how to get to the shop offering the cheapest deal. However, the idea turned out to be unfeasible since retailers’ websites were found not to be offering web services to allow for ease of product retrieval (thereby requiring the tedious use of screen scraping). Because of this, the choice of the actual application to be developed in this project was delayed until December, thereby leading to less product functionality being developed. I would strongly recommend any future project student to ensure that they enjoy the subject area of their project, as it will take up a vast majority of their time during their final year. Furthermore, it is extremely important to quickly decide on the problem needing to be tackled, and to check that it is indeed feasible. Having chosen a project that has not been previously pursued in the School of Computing, along with the notion of RFID being an expensive technology which has not sufficiently been taken advantage of has provided me with a clear opportunity. The modules split I have chosen in my final year was a 50-30 split, which meant more resources were to be available for my project in the second semester. In my opinion this has worked well for me as I was able to commence research during the first University term, thereby leaving more time for product implementation in the second term. The fact that no breaks occurred within the implementation phase allowed no time to be wasted in reviewing previously undertaken practical work. Another issue with regards to project schedule was the fact that coursework deadlines were not taken into consideration, and therefore I advise any student to consider these into their project schedule. - 54 - Appendix B - Project Methodology The Waterfall Approach The Waterfall approach uses a traditional development model where the developers and the users move logically from one stage to the next one. A stage cannot start until the previous one was completed. Each phase includes a key deliverable which is typically produced on paper. The Waterfall model is a well-established and widely used model for practical systems development, but can lead to the following problems: • Commitments have to be made at an early stage in the process, which means it is different to respond to changing requirements from customer. • The Waterfall model should only be used when requirements are well understood. • If the developer misses important requirements, expensive post-implementation programming may be needed. RAD / Evolutionary Development Rapid Application Development (RAD) is a method of developing systems which use prototyping in order to achieve user involvement and faster development compared to traditional methodologies such as the Waterfall model [2]. Its objectives are to deliver a working system to end-users by starting with user requirements which are best understood and which have highest priority. The main idea behind RAD is to develop an initial implementation, exposing this to users for comments, and refining this through many iterations until an adequate system has been developed. The advantage of a software process based on an evolutionary approach is that the system specification can be developed in stages. As users better understand their problem, the software system can later reflect on this. There are two clear drawbacks with this method; the first one is reduced scalability, since a RAD application starts as a prototype and ends up as a finished product. However, scaling a prototype to predetermined goals can avoid this issue. Another problem with RAD is reduced features, seeing that application features need to be pushed to later versions due to time boxing. These two problems however are not critical to this project, since the author is not aiming for a finished product. - 55 - Reuse-Oriented Development [1] This process model is also sometimes referred to as Component-Based Development. It relies on a large base of reusable software components which can be later accessed. It also relies on some integrating framework for these components. The initial stage as well as the validation phase of this model is very similar to other software processes. However, the intermediate stages are different as they accommodate for components integration. A list of these stages follows; 1. Component analysis: the developer searches for components in order to implement the requirement specification. 2. Requirements Modification: requirements are analysed using the information provided about the discovered components, and are then modified to reflect available components. 3. System design with reuse: Design a new or reuse an existing framework. Organise framework to cater for reused components. 4. Development & integration: Software which cannot be reused is developed and integrated with the reusable components. This methodology has got clear advantages over the previously mentioned process models: 1. It reduces the amount of software to be developed which leads to reduced risks. 2. It usually leads to faster delivery of software. However, using this model means that control over the system evolution is lost as new versions of reusable components are not under the control of the developer. Additionally, components functionality may restrict the application so that it would not be able to satisfy all of the user requirements. - 56 - Initial Project Schedule Figure 1: Project Schedule - 57 - Final Project Schedule Figure 2: Final Project Schedule - 58 - Appendix C – Java Client Class Diagram Figure 1: Class Diagram - 59 - Appendix D – Amazon and Yahoo Web Services AmazonInfo.java – Java Class for Amazon information retrieval /** * This class will get product information from the Amazon e-Commerce * web service. An XML parser is used to retrieved the desired information. * * @author Michael Hollander * @date 17th Mar 2007 **/ public class AmazonInfo { private private private private private ArrayList simArray; String image; String price; String avgRating; SimilarityItem sim; public AmazonInfo(String desc, String cat) throws Exception { simArray = new ArrayList(); String requestAccessKeyID = "13S0F4DPEDXCE8AMZXR2"; String requestSecretAccessKey = "ZO4vmDnoDHZ9drz9MWi0ZbXifJFsEPb9Li4eOBt2"; String description = desc; String category = cat; // XML file location String docString = "http://webservices.amazon.com/onca/xml?Service=AWSECommerceService"+ "&SubscriptionId="+requestAccessKeyID+ "&Operation=ItemSearch"+ "&SearchIndex="+category+ "&Keywords="+description+ "&ResponseGroup=Reviews,Small,Images,ItemAttributes,Similarities"+ "&ReviewPage=1"; Document doc = null; // reset document try { // Get the document builder factory DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); // Using factory get an instance of document builder - 60 - DocumentBuilder db = dbf.newDocumentBuilder(); // Parse using builder to get DOM representation of the XML file doc = db.parse(docString); } catch (java.io.IOException e) { System.out.println("Can't find the file"); } catch (Exception e) { System.out.print("Problem parsing the file."); } // Get the root element Element root = doc.getDocumentElement(); // Store whether results were found for the query Element successElement = (Element)root.getElementsByTagName("IsValid").item(0); // If results were found if (successElement.getFirstChild().getNodeValue().equals("True")) { // Get a nodelist of elements NodeList results = root.getElementsByTagName("Items"); // Get the first Item element Element resultsElement = (Element)results.item(0); /**============= IMAGE INFORMATION ================**/ // Get the Item Image element for the first Item Element MediumImageElement = (Element)resultsElement.getElementsByTagName("SmallImage").item(0); // store product image URL image = MediumImageElement.getChildNodes().item(0).getFirstChild().getNodeValue(); /**============= END IMAGE INFORMATION ============**/ /**============= PRICE INFORMATION ================**/ // Get the Item Price element for the first Item Element itemAttributesElement = (Element)resultsElement.getElementsByTagName("ItemAttributes").item(0); Element listPriceElement = (Element)itemAttributesElement.getElementsByTagName("ListPrice").item(0); Element amountElement = (Element)listPriceElement.getElementsByTagName("FormattedPrice").item(0); // Store product price price = amountElement.getFirstChild().getNodeValue(); /**============= END PRICE INFORMATION ===========**/ /**===== CUSTOMER REVIEW SECTION ======**/ - 61 - // Get the Customer Reviews element for the first Item Element customerReviewElement = (Element)resultsElement.getElementsByTagName("CustomerReviews").item(0); // Store average rating for the first item avgRating = customerReviewElement.getChildNodes().item(0).getFirstChild().getNodeValue(); /**=== END CUSTOMER REVIEW SECTION ===**/ /**===== SIMILARITIES SECTION =====**/ // Get the Similarities element for the first Item Element similarProductsElement = (Element)resultsElement.getElementsByTagName("SimilarProducts").item(0); NodeList similarProductElements = similarProductsElement.getElementsByTagName("SimilarProduct"); int numberOfSimilarProducts = similarProductElements.getLength(); // Get the number of similar products System.out.println("There is a total of "+numberOfSimilarProducts+ " similar items."); for (int thisProduct = 0; thisProduct < numberOfSimilarProducts; thisProduct++){ Element similarProductElement = (Element)similarProductsElement.getElementsByTagName("SimilarProduct").item(thisProduct); // store similar product's ASIN number, in order to later obtain information on similar item String asin = similarProductElement.getChildNodes().item(0).getFirstChild().getNodeValue(); // Loop through all similar items available, and obtain information on each of these sim = new SimilarityItem(asin); simArray.add(sim.getAuthor()+sim.getTitle()+"|"+sim.getAvgRating()+"|" + sim.getPrice()+"|"+sim.getImage()); System.out.println("Similar Item "+(thisProduct+1)+ ": " + sim.getAuthor() + " - " + sim.getTitle() + " with average rating of "+sim.getAvgRating()+" and price of " + sim.getPrice()); sim = null; } /**=== END SIMILARITIES SECTION ===**/ } //end if results were found // If no results were found and an error occured else { System.out.println("The request did not process properly."); } }//end constructor }//end AmazonInfo - 62 - YahooInfo.java – Java Class for Yahoo! Shopping Information retrieval /** * This class will get information related to a product, given its * description, from the Yahoo e-Commerce web service. * An XML parser is used to retrieved the desired information. * * @author Michael Hollander * @date 17th Mar 2007 * **/ public class YahooInfo { private String price; private String avgRating; private String catalogID; public YahooInfo(String query) throws Exception { String requestAccessKeyID = "UAEr3czV34FRLmGCALNzyDzUiqVA.nWpwrUyBOkNoPqAr0nR22orlpQ7P2uGOuk"; String keywords = query; // XML file location String docString = "http://api.shopping.yahoo.com/ShoppingService/v1/productSearch?"+ "appid="+requestAccessKeyID+ "&query="+keywords+ "&results=1"; Document doc = null; // reset document try { // Get the document builder factory DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); // Using factory get an instance of document builder DocumentBuilder db = dbf.newDocumentBuilder(); // Parse using builder to get DOM representation of the XML file doc = db.parse(docString); } catch (java.io.IOException e) { System.out.println("Can't find the file"); } catch (Exception e) { System.out.print("Problem parsing the file."); } // Get the root element Element root = doc.getDocumentElement(); - 63 - // Get a nodelist of elements NodeList results = root.getElementsByTagName("Result"); // Get the first Item element Element resultsElement = (Element)results.item(0); // Get the Catalog element for the first Item Element CatalogElement = (Element)resultsElement.getElementsByTagName("Catalog").item(0); catalogID = CatalogElement.getAttribute("ID"); /**============= PRICE INFROMATION SECTION ====================**/ Element PriceFromElement = (Element)CatalogElement.getElementsByTagName("PriceFrom").item(0); Element PriceToElement = (Element)CatalogElement.getElementsByTagName("PriceTo").item(0); price = PriceFromElement.getFirstChild().getNodeValue()+" - " + PriceToElement.getFirstChild().getNodeValue(); /**============= END PRICE INFROMATION SECTION ================**/ /**============= CUSTOMER REVIEW SECTION ====================**/ // Get the Max User rating, Total Ratings and Average Rating for first Item Element userRatingElement = (Element)CatalogElement.getElementsByTagName("UserRating").item(0); Element avgRatingElement = (Element)userRatingElement.getElementsByTagName("AverageRating").item(0); avgRating = avgRatingElement.getFirstChild().getNodeValue(); /**============= END CUSTOMER REVIEW SECTION ====================**/ }//end constructor }//end YahooInfo - 64 - Appendix E - Transcript of Focus Group List of users: User1 = Mobile Development Expert / frequent mobile user User2 = Personalisation Expert User3 = e-Commerce Expert User4 = Digital Libraries Expert User5 = Mobile Expert User6 = Developer of Personal Travel Assistant Mashup User1: “Now, you have 2 formats, from Yahoo and Amazon User2: You need to know the protocol to communicate to the new data store. So Yahoo communicates in one way, Amazon communicates in another” User1: Now, you use a java program on the desktop, and in a mobile. When you use the mobile, you want to change to, or create the application on the mobile. How do you do it? Michael: I think the best way to do that would be to use J2ME, or some other mobile java software. I am using Eclipse at the moment to do the Java coding, but I will probably need to change it into java mobile format. User1: That uses J2SE (referring to the current system), and this one is J2ME (referring to potentially converting my system for use on mobile devices). User2: You are evaluating a simulation, and then one of the points you have to discuss is; How to make it a real life application. So what are the issues with the real life applications should cope with. One of them is changing the problem of environment; changing to J2ME. The other one is awareness of the technical robustness of the system; if the connection may not be reliable. Issues which are not related to your simulation now, but are issues which are related to the real life and you have to comment on these at the end of your project. User3: Extending to another mashup. There is UDDI which is developed for web services. Do you think the future is, if people vote for UDDI, you just go to that directory, and you can find new services. User2: Will the shops actually accept this application? They don’t actually want you to know about the competitors. User3: This project is about possibilities Michael: There is a physical world and a virtual world, and you want to combine them together. User2: You came up with one shopping scenario. But they may think, are there any other possibilities, where RFID and Mashups could be mixed, for future work? You are evaluating how well they mix together. User2: RFID tags attached to some places in York. York is like an open city, so you walk around and you see these tags on the wall. If it has an RFID reader, then you can get information about that particular site which you are seeing. It’s interesting to see what else you can pull from the web about that particular site. - 65 - User4: It’s a library scenario, when I buy a book for someone else; if I find that this book is interesting, I say hmm well, you want to read it, but you don’t want to buy. So would it be possible to have a link to all libraries in your city that contains this book. User2: Where can you find this book, all the other shops. User4: Well not only shops, but libraries where you can borrow a book and have a look, and then you can buy the book. User5: I am using a PDA, and I found myself many times somewhere. For example, two nights ago we were just shopping at Tesco and you look at something and you want to know more, then I will go home, and Google it… User2: I find for example very often; I go to a shop and I’m looking for a present for somebody, and I know what they like. I don’t want to buy this, because they already have it. And then I think, what else can I buy for them? And it’s a huge shop. And they have no idea. They go to HMV, plenty of DVDs, and you could pick one or two DVDs which you know they’ll like and you could say, well, show me the related ones, and that’s, I mean, again, I can buy from the shop, because I’m there to buy, but it’s just, I haven’t got a clue how to find those things. [Assuming the company implements RFID within all of its items.]: User3: One thing now I realise, for Tesco to do this, it may be, a recipe; so, oh, I like this artichoke, but I don’t know what else should I buy from Tesco. Michael: That’s what I have put in my report, I talked about the recipes, where you scan a food item, and then it tells you, I think it scans all the other items within the same shelf, and it tells you what else you can buy to make a dish. User3: The current system, can the user actually see, oh, these are from Yahoo, these are from Amazon? Michael: No. User3: So they don’t know. So if somebody finds a cheaper one from Amazon, you want to go and buy from Amazon. User5: If it comes from Yahoo, can you get the exact shop that it’s coming from? User6: But even Amazon, they have like many shops from other people, not from Amazon. So the price might be different. User5: Yes, Second hand, new… User3: It is important to know where one gets the message. User5: If you can find Amazon fifteen pounds, but it’s second hand, then you will buy the new one or you will not buy? User1: So maybe you can have a link to eBay. Michael: What do you think of the rating? The thing is, with the rating it’s doing a really smart algorithm on the server side where it’s compared all the ratings and put small weights depending on how many reviews one gave. But the in the end, the user just gets one rating. So is it worth it to do all - 66 - of this for the user, in comparison to just getting the average from Yahoo and Amazon and take the average of that? User3: For shoppers, they want to know what’s cheapest, not average. - 67 - Appendix F – Usability Testing Questionnaire Questions Demographic Information Experience web browsing on a mobile device (how many years?) Previous experience with online shopping Previous usage of Amazon or Yahoo! Shopping service 1. How easy do you find the mobile application to use? Very easy Easy Somewhat easy Difficult to use Impossible to use 2. What do you think of the colour scheme? Excellent Good Average Poor Terrible 3. How clear is the text presented to you? Very clear Clear Unclear Not clear at all 4. Does the application give you enough information to make a decision on whether or not to buy the product? Too much information Enough information - 68 - Not enough information No information at all 5. Are you satisfied with the system? Extremely satisfied Very satisfied Neutral Very dissatisfied Extremely dissatisfied 6. Would you use this application again, if you were to use it in a shop? Yes No 7. User comments - 69 - Questionnaire Results Demographic information: A – Previous experience with web browsing on a mobile device (in yrs) B – How many years of experience with online shopping? C – Previous experience with using Amazon or Yahoo! Shopping Service? (in yrs) Outcome: User 1 0 3 4 5 6 7 8 A B C 0 0 4 0 0 4 0 0 9 0 7 2 3 8 8 1 9 1 4 2 1 7 3 1 Questions: How easy did you find the mobile application to use? Very Easy – 12.5% (1) Easy – 75% (6) Somewhat easy – 12.5% (1) What do you think of the colour scheme applied in the application? Excellent – 37.5% (3) Good – 62.5% (5) How clear is the text presented to you? Very clear – 75% (6) Clear – 25% (2) Does the application give you enough information to make a decision on whether or not to buy the product? Enough information – 37.5% (3) Not enough information – 62.5% (5) Are you satisfied with the application? Very satisfied – 62.5% (5) Neutral – 37.5% (3) Would you use this application again, if you were to use it in a shop? Yes – 100% (8) - 70 - Appendix G –Expert Interview Material Technical Questions for Interview 1. How appropriate do you find the shopping scenario (with regards to the architecture)? 2. How appropriate do you find the simulation (RFID reader, components, web service, JSP, XML, XHTML-MP, tomcat, MySQL and data used)? 3. Could you feed back on the architecture? (Appropriateness) 4. What do you think about the feasibility of the architecture? (Implementing it for a real product) 5. What do you think of the chosen approach (Iterative approach, 3 iterations)? 6. What do you think about the combination of Mashups and RFID (to enhance the customer experience)? - 71 - Shopping Scenario A user is interested in buying a book as a present for a friend. In possession of an RFID-integrated mobile device such as a PDA with an integrated RFID reader, the user may enter a bookshop and start looking at a range of books which he thinks might be of interest to his friend. Upon finding an item of interest, the user would like to know what other similar items he could buy for his friend, and if buying it online would be cheaper. The shop might be crowded, and there may not be a shop assistant nearby or available to the user to ask for assistance. Additionally, an assistant would typically be prohibited to encourage customers to buy online. Bearing these factors in mind, the user instead picks up an item of interest, switches on his mobile device and scans the specific item using the device’s built-in RFID reader. Once scanned, the device will communicate with the shop’s database, requesting basic information on that item. Upon receiving this information, the device will connect to a Mashup server located in a remote area, requesting more information on the scanned product. The user, unaware of these occurring communications, browses to the Mashup website with the help of the personal device. He is then faced with a list of items he previously scanned on that same day. The website allows the user to select one of these entries in order to obtain more information on an item. Once selected, the user is presented with information on the scanned item, including price and rating obtained from Amazon and Yahoo services. The webpage also shows the user a list of similar items, along with an image, price and rating for each of these items. - 72 - Prototype Architecture – Deployment Diagram - 73 - Appendix H – RFID Workshop Correspondence -----Original Message----From: scs3mh@leeds.ac.uk [mailto:scs3mh@leeds.ac.uk] Sent: 26 March 2007 19:02 To: deborah@mediamatic.net Subject: RE: Hybrid World Lab Hi Deborah, … About my project, I have actually already implemented a simulated mobile application using an RFID Phidget toolkit. Once an RFID item is scanned, more information will be gathered from Yahoo Shopping as well as Amazon ECommerce web sources. The workshop really caught my eye on the fact that it is, just like my project, focusing on narrowing the gap between the 'physical' and the 'virtual' world, thereby enhancing the customer experience. So I believe the workshop can be a step further for me to make my application more realistic (using an actual RFID-integrated phone), but also to improve my knowledge on the subject. Regards, Michael From: Deborah Meibergen - Mediamatic [mailto:deborah@mediamatic.net] Sent: 26 March 2007 09:51 To: scs3mh@comp.leeds.ac.uk Subject: Hybrid World Lab Dear Michael Hollander, I received your registration for the workshop, the deadline for enrolment is April 27. As soon as I have more details / information about the workshop I will inform you about this. … Your project sounds interesting, I'm sure this workshop can give you a extra set of 'tools' for your project. If you have other questions, please contact me. Best regards, Deborah Meibergen Workshop co-ordinator MEDIAMATIC [T] +31 (0) 20 638 99 01 [F] +31 (0) 20 638 79 69 [W] www.mediamatic.net - 74 - Appendix I – Product_Info Table Epc Product Rating Date_time Image Similar1 Price_amazon Price_yahoo 01023c1182 Dan Brown 4 2007-03-21 http://ec1.images- Dan Brown|Digital Fortress: A $9.99 2.95 - 139.95 13:03:46 amazon.com/images/P/14165248 Thriller|3.0|$7.99|http://ec2.images- 00.01._SCTHUMBZZZ_.jpg amazon.com/images/P/0312995423.01._SC $999.99 319.95 - 525.00 Deception Point THUMBZZZ_V47013259_.jpg 010238a5e4 Toshiba HD-A1 HD DVD Player 4.35 2007-03-21 http://ec2.images- null|Casino Royale [Blu- 16:56:43 amazon.com/images/P/B000M6X ray]|4.5|$38.96|http://ec1.images- KEK.01._SCTHUMBZZZ_.jpg amazon.com/images/P/B000MRA5NS.01._ SCTHUMBZZZ_V46853516_.jpg Table 1: Simulated data within the Product_info table (discarding unnecessary columns) - 75 - Appendix J – Unit Testing Test Id Section Module Description T0 Client Testing RFIDScan When starting the application, the system awaits RFID attachment. Expected result T1 When an RFID reader is attached to the mobile device, the reader gets activated. Expected result T2 When an item is scanned for the first time by the reader, the program calls the ProductInfo class to obtain more information on its tag. When an item is scanned for a consecutive time, the program does the same as in test T2. Tag in close proximity to reader Expected result Tag in close proximity to reader ProductInfo should not be called for already scanned items When initialised, method call_db() will be called. It will connect to the shop database, retrieving and storing the EPC number, product description and category for the item. Method write_file() is called after connection to the database has completed. The method writes the stored information (T4) into a text file. New session – an item is scanned; text file contains a single line of text. Existing session – another item is EPC number obtained from RFIDScan module Expected result T3 T4 T5 T6 T7 Client Testing ProductInfo Input - 76 - Results Expected Results Expected Results Expected Results Remarks The LED on the RFID Reader is turned on during scanning, and the EPC number is displayed on the console. A list of scanned items should be stored. When an item is scanned, it should be compared to that list. Database connection information is displayed to the console to confirm connection/discon nection status. Each line in the text file contains information on a scanned item. T8 scanned; text file contains 2 lines of text. New session – an item is scanned; text file contains three lines of text. - 77 - Text file should be cleared when a new session occurs. A variable should be passed from RFIDScan in order to know whether a scanned item belongs to a new session or not. This will in turn help ProductInfo determine whether the text file should be overwritten or appended.