FinalPrototype-Group:Group Made of Smiles

From Cs160-sp08

Jump to: navigation, search


Team Contributors

  • Nir Ackner - Final Interface: UI Design / Functionality
  • Michelle Au - Final Interface: Implementation Description
  • Johnny Tran - Final Interface: Unimplemented Portions
  • Jerry Zhang - Problem/Solution Overview, Target User Group, Tasks, Design Evolution

Problem and Solution Overview

When at discount retailers or grocery stores, customers often find it difficult to tell what the best deal is for a given product. Without access to a computer and internet, one must actually visit several stores (and potentially online retailers) to determine the best deals on items. It is hard to know whether the price on a bottle of sunscreen or a dress is the lowest available. Especially on impulse buys, it is either difficult or impossible to do this research beforehand. Our mission is to allow consumers to make informed buying decisions by providing instant product information to their fingertips. Our mobile price comparison system addresses our users' needs by automatically comparing prices on items at nearby stores and websites. The user can input an item and instantly see reviews and prices on related and companion items at nearby stores, allowing the user to quickly gauge the best deals around.

Target User Group

The target user group is technically savvy, price-conscious comparison shoppers. These are people who care about saving a dollar and would like to get the best deals and bargains. Whether it is a box of cereal or a new computer, they want to get the lowest prices on whatever they buy. To them, a quick and accessible way to compare prices on the go would be a valuable tool.



Compare prices: The user wants to see prices for a product at nearby and online stores and determine what store has the lowest prices. The user enters the product into the application either by taking a snapshot of the product barcode or typing in the product name. The application then shows a list of nearby and online stores, their distance, and their prices. The lowest price is highlighted on the list.


Check reviews: Prices are not everything, and the user wants to investigate a particular product further by reading reviews. After a product is entered into the application, it displays different reviews pulled from websites such as CNET or This allows the user to quickly browse reviews and user testimonials in-store without needing to perform product research beforehand.


Take Notes: After doing research or buying an item, the user wants to make a note on an item for future reference. The application allows the user to access a product and go to a note viewer/editor which stores notes per-item. At any time in the future, the user can go back to a product and view/edit the associated note.

Design Evolution


The navigational structure of our application underwent several changes throughout our design cycle. In our lo-fi study, we discovered that users were unclear as to what each of our menu buttons did. For example, it was unclear whether the History button in the home screen (for search history) was the same as the History button in the navigation menu (for a product’s price history). To address this, we renamed the home screen button to "Search History" and the menu "History" button to "Price History." Along similar lines, we gave more descriptive names to several other navigation elements whose purpose users initially showed confusion over.

Furthermore, our initial design involved a navigation system where the current view is not available as a menu choice when the navigation menu was brought up. After our interactive user study however, we discovered that users were confused by this since it seemed that the menu was different from every screen. To address this, we made all our navigation menus static. Currently, we have two sets of navigation menus: a menu for accessing product specific information, and a menu for store specific information.




Notes went through several changes. Our original conception of notes was to have a global set of notes that users can create and edit. Many notes can all be linked to a specific product and notes can also exist independently without an associated product. However from our initial low-fi study, we discovered that users were confused by such an idea. After talking to users, we discovered that users really only wanted notes to be product specific. If they wanted independent notes, they would simply use a note-taking application. As such, we removed the idea of multiple, independent notes and instead made notes have products have a one-to-one associate. This meant that each product can have at most one note attached to it. Furthermore, since each product has its own associated note, we were able to abstract away the issue of creating and deleting notes for the user. The note is created when you edit a product’s associated note and the note is deleted when it no longer contains text.

Another issue we had with product notes was the issue of saving notes. Our initial design was to have notes be automatically saved whenever the user edits the note. During lo-fi testing we found that users coming from a Windows Mobile platform, which uses a similar paradigm of instantly saving changes, were fine with our scheme. However, users not familiar with Windows Mobile products showed great confusion. They were uncertain whether their notes were saved and often spent considerable time searching the interface for a “save button”. To account for this, we added an explicit save buttons so for users to press – Users familiar with the Windows Mobile paradigm still understood the idea of a save button. Despite this addition, we discovered in our interactive prototype test that users still wanted more feedback when saving notes so we incorporated a confirmation message when notes are saved. In addition, we added a new cancel button so users can recover from unwanted edits.




Product Overview

Our original idea for our application involved a product overview page that provided a summary of all the available information on a product. This view would contain snippets from various reviews, the three stores with the lowest prices, and a list of related items the users might be interested in. However, from our user studies we found that having such a mass of information overwhelmed the user. As such, we condensed our reviews snippets into a single 5 star rating system that aggregated all the reviews associated with a product. The list of stores with the lowest prices was also condensed into an entry for the best take-home price. In addition, we found that users also had trouble navigation the view since some elements were selectable while others only displayed data. We addressed this issue by changing the view so that every displayed element is selectable and links to a related page containing more information.




Miscellaneous Changes

Store Menu

Our initial design for a store page also contained additional information for the product the user is looking up. Our interactive study however revealed that users expect a store page to only contain information specific to the store. As such, we modified our store page to be store specific rather than product specific. to stay consistent with our menu system, the store menu also now contains store specific options such as call store and map to store.






Based on user feedback, we now provide the option to sort our product/price listings by different fields.





improved view for search history/notes list

Following our pilot usability study, we discovered that users did not care to see multiple listings for a product under search history. It seemed that users only cared about each distinct products they've searched for rather than seeing each search being listed. As such we changed our search history display so that each entry displays a unique product rather than displaying multiple searches for the same product. In addition, we improved our notes list by providing better snippets for each product's associated note.





Final Interface

Final Design


Our final design allows users to store and compare any product with a UPC. Users can compare prices between different stores offering the same product. We also provide the ability to get store information like address, phone number, website, and map to location.

Quality-focused users can also read reviews from a variety of online sources offering a product. The ability to take notes on a per product basis is also offered, as is suggestions for companion or competing products. (products that compliment the functionality of the current product and products that offer the same features as the current product)

More advanced users can look at the price of the product over time, for products whose prices regularly fluctuate.

Users also have the ability to globally keep track of their recent searches, notes, and favorite products.

UI Design

When the user enters the Price Comparator application, they see the home screen shown below. (figure 1) We decided to make entering an UPC digit pop-up an entry field(figure 2), which can be escaped by deleting all the digits entered so far or by hitting back. If the user chooses to do an image capture, this will launch a separate photo Intent, due to space constraints on the home screen.

The home screen also provides access to lists of favorites (figure 7), previous searches (figure 10), notes about specific products (figure 11), and a settings page (figure 12). This allows the user quick access to the products they are most likely to be viewing, and to change variables like sort order of stores, etc.

When the user has scanned in an item, say an iPod, they are taken to the Product Overview screen (figure 3), which summarizes all the data about the product. They can select the prices (figure 4), reviews (figure 5), and notes (figure 6) about the item they are viewing. They can add the product to a favorites list (figure 7) or view price history (figure 8). They can use the back key, on screen selections, or the menu (figure 9) to navigate between views.

Figure 1


Figure 2


Figure 3


Figure 4


Figure 5


Figure 6


Figure 7


Figure 8


Figure 9


Figure 10


Figure 11


Figure 12



The price comparator application was implemented using a variety of views and a database backend in the Android SDK.

The home page was implemented using an AbsoluteLayout with a scan prompt and four ImageButtons. The buttons use images that we created using Photoshop. Each ImageButton has an onClickListener linked to the associated Activity. All these activities are global functions and do not require a product association. In order to implement the text box to enter the UPC number, onKeyDown() was overridden to swap the scan prompt image with a text box whenever an alphanumeric character is entered. After entering a UPC number, the application will query the database with the UPC and if a product is found, will return a ProductRecord that contains the sku and name of the product.

To help pass product information between Activities, we created a ProductHelper class that globally stores the current product. This class has a getProduct() and setProduct() method that respectively accesses the current product and sets the product. All product pages call getProduct() at the beginning of the onCreate() to load the current product. setProduct() is called from all the global pages when there is a successful UPC query or a product is selected from a list. It is also called from the product overview page if a suggested item is selected. ProductHelper also is important in implementing the lifecycle methods. During onFreeze(), all product pages will call ProductHelper.onFreezeHelper() which stores the product sku in a Bundle. Similarly, store information is also stored in ProductHelper with a getStore() and setStore() method, as well as onFreezeHelper() to help with lifecycle methods.

To eliminate duplication of menu code, we created a MenuHelper class that provides methods to set menu options and actions. For each product page, onCreateOptionsMenu() and onMenuItemSelected() is overridden to call these methods in MenuHelper.

The product overview, prices, reviews, store, global favorites and search history pages are implemented using a ListView. We wrote our own ListAdapter for each page to handle the data specific for that page. The onListItemClick() method is overridden for each page to implement linking each list item to its associated Activity.

The product notes page is implemented using a LinearLayout with an EditText to store the note and a Save and Cancel button. Each button has an onClickListener that respectively saves the text to the database or reloads the text saved in the database (to cancel the changes). onKeyDown() is also overwritten to cancel changes when the Back key is pressed. The lifecycle onPause() method is overwritten to save changes made to the note text.

The database was implemented with two interfaces. One interface performs generic database operations on a SQLLiteDatabase such as insert, update, delete and query given a table name and other operation specific information such as row id, values, columns and selection criteria. The second interface provides specific queries and database operations that our views require and translates the query results into more meaningful results for the views (such as product name, store name, price). Each Activity is associated with a database table. The tables in our database include: Product (sku, name, picture), Store (store_id, name, phone, address, website), Price (sku, store_id, cost), Review (review_id, sku, snippet, source, rating), Note (note_id, sku, note_text), Favorite (fav_id, sku), and History (his_id, sku, timestamp).

What Was Left Unimplemented

The only feature of our UI that is unimplemented is the scanning feature and a complete product database.

What was left out and why

We were unable to implement barcode scanning in our application due to deficiencies in the Android emulator, which is unable to emulate a real camera. Camera support is limited to a fixed animation that does not include barcodes, so it is impossible to either implement or test a barcode scanning feature. We therefore decided to leave barcode scanning unimplemented so that we could focus on the rest of the UI, which Android fully supports.

This is not a limitation, as our application is designed to support two input methods for entering product barcodes: by camera and by typing in the barcode. Typing in the barcode is fully supported in our application, so any product that could be accessed by camera can be accessed by typing in the associated barcode. We made the design decision to support two input methods because not all users will have mobile devices with built-in cameras, but all devices support the ability to type in alphanumeric characters.

The UI is designed to work well with typing in barcodes, so our application's usability is not detrimentally affected by the absence of barcode scanning.

Our application does not have a complete product database. It contains a sufficient amount of data that our users were still able to effectively use our application and perform all tasks without any perceived tasks. We decided not to pursue adding additional product data because it would not have contributed to the usability of our application.

Any wizard of oz techniques that are required to make it work

Our application does not use any wizard of oz techniques. All implemented features in our application are fully functional and do not require human intervention to simulate.



[Poster - Powerpoint]

[Poster - Screenshot]

[Poster - PDF(lower quality)]

[add comment]
Personal tools