Final Report:Group Jybz

From Cs160-sp08

Jump to: navigation, search


Each team member’s name and role in this assignment

  • Jason Wu: Functionality, Implementation, Design, Problems

  • Yang Wang: Final U.I. rearrange, buttons and fields line up, map implementation

  • Bo Niu: Design Evolution, Final Interface, What was left unimplemented

  • Zhou Li: Preference filtering, geocoding, improve searching functionality, and some bug fix.

Problem and solution overview


Many consumers from college students to housewives to even everyday shoppers are constantly looking for sales, deals, and promotions in an effort to save money. However, everyone is limited by the time they are willing to invest in coupon clipping and sale hunting. Most people don't want to put in too much time into finding the best deal possible, and only put in a half hearted search. In addition, this not only hurts consumers, but also store owners whose promotions may go unnoticed and who may lose potential customers because of that.


What Real Deal accomplishes is a software that runs on a mobile platform with GPS that allows for adding and/or tracking nearby deals filtered by a variety of conditions such as store type, distance from current position, and vote ratio. The interface will be easy to use for both customer and sellers, and moderating will be done in a Web 2.0 fashion, allowing users to rate the promotions in the database. So now, a user should be able to walk down the street and be alerted to nearby store sales that match his selected criteria. In addition, a restaurant owner should be able to quickly and easily submit his lunch special without paying for complicated advertisements; this will be instant, free, and targeted advertising.

Target user group

Anyone who spends money in storefronts, has a mobile device with position tracking functionality, and doesn't want to spend time preparing and cutting coupons home ahead of time. Some of the major user groups include:

  1. Students
    • Starving college students are always looking for a way to save money. Due to their busy class schedule, they usually don't have time to look out for promotions and coupons ahead of time. Students are also usually more spontaneous buying food between classes, and don't have time to search for promotional deals. That's why they need Real Deal on the go.
  2. Travelers
    • Visitors not familiar with the local area don't know where or how to find the cheap eats, and good deals around the area. With Real Deal, it's just like having a local guide you a round. They don't have to eat at overpriced tourist traps, and now know where to find good meals with good deals.
  3. Frequent Shoppers
    • While shopping is part of their regular routine, they still might now have all the latest information on the latest sales and deals at their favorite shopping centers. Instead of running between stores checking out the prices and comparing between brands, wasting both time and energy, Real Deal can make finding that perfect dress even easier.
  4. Store Owners
    • They will want to be able to spread their promotions and deals out to customers faster, and easier. This will maximize their sales items, and attract as many buyers as possible during promotional periods. Real Deal will provide and easy to use platform for advertising.


We decided to use the original four tasks from our Lo-Fi prototype report which covered a larger amount of our device's functionality and seemed to be a bit more useful than the other three tasks in our interactive prototype.

The three tasks described in the User Scenarios section of our contextual inquiry project covered one easy, one moderate and one hard task from the task analysis section. But the two tasks under the moderate category can be integrated into one moderate level user test case, so that was how we came up with the modified version of the moderate tasks for our LoFi prototype testing. The other easy task described in task analysis section, namely, choosing an action of interest, was used for our demo script. However, each of the two hard level tasks covers a totally different aspect of our system; while one is for all users who want to find good promotions to modify their preference, the other hard task was for store owner or any user who want to promote or share promotion to add new promotion information into the system. We felt that letting the participants perform only one of these two tasks would not cover all aspects of our system plus user feedback on both of the tasks were crucial to our interface design. Therefore, all participants were asked to perform both of these hard tasks.

Below is a list of the four tasks we asked our participants to perform:

1. View Details of Two Close Promotions (Easy)

  • Participant's goal was to view or browse through the list of available promotions within the default distance from his/her current location, then find two specific promotions to view the details and exact locations of those promotions. This task was meant to simulate the scenario in which the user wants to see what promotions are available in stores nearby as the list of promotions is constantly updated according to user's current location. After the user sees some promotion key words he/she is interested in, he/she probably wants to check out the detail and location of those promotions before deciding which place he/she wants to go to. We chose to let the participant to view details and location of two promotions, because a user of our system would probably check out multiple promotions before making a decision and this allows us to test whether a user can successfully navigate back and forth among the promotion list, detail and direction map interfaces.

2. Search for a Promotion Using Advanced Search and Vote on The Promotion (Moderate)

  • Participant's goal was to search for promotions in a specific location using key words, check the detail of the promotion that he/she is most interested in and vote thumb up or down on that promotion. This task was meant to simulate the scenario in which the user wants to check whether a specific kind of promotion is available in a certain location before he/she actually goes there. Furthermore, after the user went to the promotion place, he/she probably would want to give feedback on the promotion in Real Deal. Out of the five available fields in the advanced search interface, we only specified the key word and location for the participant to search for. Because this would be the typical case when most users perform an advance search; they would likely to only have objectives and locations in mind. This also allowed us to test participants' responds to our advanced search interface with only two fields specified for them.

3. Edit Personal Preference (Hard)

  • Participant's goal was to change his/her personal preference setting to reflect specifications given by us. This task was meant to simulate the scenario in which the user wants to modify the default settings of Real Deal. Again, we tried to give participants general descriptions of the setting we wanted them to change instead of just using the field names we had in our preference interface, so the test would be more realistic.

4. Add a New Promotion (Hard)

  • Participant's goal was to add information about a new promotion into the Real Deal system. This task was meant to simulate the scenario in which the user wants to promote his/her store/restaurant and attract more customers as a store/restaurant owner, or the user just wants to share useful a new promotion information with others using Real Deal. A general description of a promotion (see Appendix) was given to the participants.

Design Evolution

Evaluation Techniques

The low-fi testing technique was very useful, because we could quickly came up with a prototype that we can ask users to run evaluation on. Even though the prototype was made from paper, there were many design flaws being discovered in this stage, such as the vote up/down button being confusing and user didn't know how to interact with the table of types in the change preference interface. In the end, we believe the lo-fi prototype saved us a lot of time coding functions we would eventually have to change or fix.

After we have refined our design based on the feedback from low-fi testing, we ran our pilot study on our interactive prototype. The pilot study gave us a chance to observe whether our changes made due to low-fi testing really fixed the issues that the users had. It has ensured us that many of our changes were effective and it has also revealed few uncaught flaws of our design, which gave us an idea of what to improve in the final version of the application. The interactive prototype allowed a aesthetic polishing of Real Deals and allowed the testing of more dynamic content. While previously we had pencil sketches and static content, now we could give the users a much more complete idea of how our program looked and interacted with the dynamic data. For example, while we could not really populate the list with new promotions, we could give them a better sense with the interactive prototype.

Changes as a Result of Low-fi Testing

Promotion List Menu Interface

Image:lofiprototype7zhou.jpg ===> Image:Promotion List.png

  • Changed vote up/down button to thumb up/down in promotion description screen, because users mistook the vote up/down keys with browsing keys.
  • Added a scrollable interface in case any of the fields, such as the description field, went longer than expected and filled up the screen.

Change Preference Interface

Image:lofiprototype11zhou.jpg ===> Image:lofiprototype666zhou.jpg

  • Changed type from table to check boxes in front of each type in the preference screen, because the users were not sure about what to do with these options in the original table. There was no indication of selectable option for these types, and the check boxes are much more intuitive to people.
  • Added in a save confirmation screen after the save button has been clicked on in the add new screen, because some users were not sure whether the setting modification were saved.

Advanced Search Interface

Image:lofiprototype9zhou.jpg ===> Image:Advanced Search.png

  • Changed type field from edit text to spinner with options, because the user wasn't sure about what types were valid.
  • Added in >= sign before the ratings in advanced search screen, because user was confused about whether the rating was exact or was a range. This now indicates that it is asking for a minimum vote ratio to display.
  • Added a "optional fields" note in the advanced search screen to indicate that not all the fields were necessary, because the user did not know whether he/she needed to fill in all fields for advanced search.

New Promotion Interface

Image:lofiprototype12zhou.jpg ===> Image:Add Promotion.png

  • Changed type field from edit text to spinner with options, because the user wasn't sure about what types were valid.
  • Added in a save confirmation screen after the save button has been clicked on in the add new screen, because some users were not sure whether the setting modification were saved.
  • Removed "Your Location" button in add new promotion window, because users were confused by the button's function and were not willing to try it out. Instead, we removed it and made the location field auto-complete to the appropriate location.
  • Changed preview to map preview in add new promotion window, because most users did not use the preview function we offered in the add new promotion interface; it was basically displaying the same information they just entered.

Improvements Made before Pilot Study

Working Map Interface Implementation

For the interactive prototype, we used a static screen shot of google map for our map interface. Since the map interface is used both for users to check direction from their current location to the selected promotion location and for them to check the location of newly added promotions on the map, we gave it high priority as the major functionality to implement next. As a result, google map API has been integrated into the map interface to support dynamic map checking. Although some of the map interface functionalities have not been finished, but a working version with enough structure for pilot user testing has been made available. After choosing a promotion to view the details from the promotion list, the user can now bring out the map interface by clicking on the "Map" button in the promotion description interface (Figure 1) to see his/her location and promotion location showing on the same map (Figure 2). The marker numbered 1 represents the user's current GPS location, which is set to a constant now and will be obtained from Android's GPS device simulator. The market numbered 2 presents the selected promotion's location, which is obtained via geo-coding and stored in the database when the promotion is first added into the database. User can move through the map using D-pad and zoom in or out via options available in the map interface menu. Satellite and traffic view can also be toggled in the map interface. The map interface can also brought up by clicking on the "Map Preview" button in add new promotion interface (Figure 3). The only difference is that only the promotion location is marked on the map for users to check the correctness. The driving/walking direction from user's current location to promotion location has not been implemented. We plan to have it done before the final presentation of our application. Even without the direction marked, users should be able decide whether the map interface is useful for them to locate the promotion and how easy it is to use.

Image:direction map.png ===> Image:pilotmapinterfacezhou.jpg

Personal User Preference Implementation

For the interactive prototype, we had a user preference interface with all the modifiable fields and check boxes to show the class to what extend users can customize the filtering of their promotion list in the main interface. But none of the real functionalities, namely, filtering the promotion list that shows up when RealDeal is started according to the criteria set by the users, were implemented at the time. There are 4 properties of the system that user can set in the newly implemented user preference interface: Default Radius, Promotion per Store, Vote Ratio >=, and Preferred Types. The "Default Radius" field allows the user to specify radius of the circular area, which is centered around his/her current locations, that he/she wants to view available promotions within. Users can utilize this parameter to display only promotions within the distance they are willing to walk/drive. Since there is no limit on how many promotions can be added for each store, one popular store may have multiple promotions showing on the promotion list forcing users to scroll through many promotions from the same store before seeing other stores' promotions. The "Promotion per Store" field allows users to specify the maximum number of promotions from the same store to display on their promotions list. This setting would be useful against promotion spamming problem by a single store. The "Vote Ratio >=" field would also be useful against spamming problem, since setting it to a greater value would eliminate promotions that are not validated by users or received a lot of thumb down votes. Finally, the "Preferred Types" section allows users to specify the types of promotions to display in their preferred promotion list, which is displayed when the application is started, by checking or unchecking the check boxes. The types that are currently selected would be checked when the preference interface is brought out, so the users know exactly which ones are in their currently preferred types (Figure 4). In order to save a user's personal preference setting, a table is created in Android's local database to store those information.


Improvements Made since Pilot Study

  • Button Line Up

During the presentation, we had a lot of feedback on the button and text field not lining up. We justified it such that we didn't want the buttons to mistakenly be mis-correlated to the input fields. In testing it didn't really happen, so in the final version of our product, we changed the aesthetics of our interface so that all the button and test fields are lined up.

Image:Advanced Search.png ===> Image:FinalAdvanced Search.png

Image:Add Promotion.png ===> Image:FinalAdd Promotion.png

  • Add the Back Option in the Map View

There was no back option in the map window, so the user couldn't go back once reached this screen. We have added in a back option in the menu now.

Image:pilotmapinterfacezhou.jpg ===> Image:finalpilotmapinterfacezhou.jpg

  • Map Panning and Centering (navigation)

The navigation of the viewing map was not proportional to the current map scope, it's now proportional in the final version so that depending on the level of zoom, you move a certain amount each time you hit the D-pad. Also, the level of zoom is dependent now on the two locations.

  • Cursor Movement

In the pilot study we found that our cursor was moving to many unexpected buttons when the D-pad was used. Once the spinner in the an interface was selected, the left and right keys changed the content within the spinner instead of moving the cursor to other items in the layout. Although pressing down can get cursor to other element, it was inconvenient and not intuitive. Users often want to type in search key words, which is on the left side of the spinner, after they choose a promotion type. Since all users are familiar with the drop down list, which shows all the available options at once, instead of the horizontal switching, the problem for the spinner can be solved by just disabling horizontal switching on all spinners used in our application. The unexpected cursor movement issue also created confusions in advanced search and add promotion interface.

The cursor movement problem has been solved in our final version of the application. The cursor now move to the button on the correct direction next when a direction button is clicked. When there are multiple button in the same direction, the most reasonable next button is selected. For example: In advanced search window the cursor now move to save instead of cancel when click on arrow down key from the last text box.

  • Driving Directions in the Map View

The map interface was only able to gave the points of the two location but there was no route direction. Our users couldn't tell how they could get from one point to another on the map, so to make our map more useful, we have added the driving direction between the two points in our final version.

Image:pilotmapinterfacezhou.jpg ===> Image:final direction map.png

As revealed by the pilot test, the "vote ratio >=" field in user preference and advance search interface is still not clear enough in terms of the format of the number it accepts. So adding a "%" sign at the end of the text field should solve this confusion.

  • Better Search

Before it had to be an exact search match, and it was case sensitive. Now, it's a bit more capable in that it is case insensitive and can be any of the keywords. So instead of having to type "Free Beer" you can just type "beer."

Final Interface


So keeping our problem in mind, and goals derived from this problem, we decided which primary elements of functionality had to be put into RealDeal in order to save people time searching for deals and coupons. Also, we wanted it to be just as easy to put in coupons and sales so that the database was as large as possible to suit the purpose. Without actual promotions to look up, there would be no functionality at all to our program.

Therefore, we have a database which anyone can easily upload a promotion with various useful details such as type and location so that users can search effectively. At the same time, we realized there are enough trolls to input bad data and we needed a regulatory method that could scale as quickly as the problem might. Web 2.0 suggests that the only way to combat people putting in data is allowing the number of people who don't want bad data, who hopefully vastly outnumber them, to filter the results. This is why we have a voting system where each user can vote up or down depending on whether or not the promotion was legitimate or good. Each user then can set a threshold for how "bad" or "good" the promotion must be in order to show.

Obviously, we have to have the database easily searchable, so we in fact made it the main screen. Right when the user opens up the program, it does a default search around his location based on his preferences. So if the user primarily uses it to find close by food, he can set the preferences to have the main screen only show food promotions within a mile radius.

Lastly, none of this is useful if the user cannot find the store with the promotion. So the last big functionality part we had to implement was the map view, showing not only the location of the user and the store, but also the directions to the destination. In the end, all these parts of the functionality combine to form the core of RealDeal and we believe successfully answers the original problem we set out to solve.



Main Screen

Image:Main bo.png

This is the main starting screen that the user sees first off. It is the most useful screen for getting the user's most likely needed information at a glance. Here he can do a basic search based of a type of product, and keywords; these are the fields that will probably be the most useful for majority of searches. Most of the screen is used to display results in a Table with columns Type, Distance, and Keyword. It's defaultly populated by distance and promotion type according to the user preferences. In addition, if the user does a search, this familiar screen is then where the results will show. The list is by default sorted by distance, closest first. The user can click on any one of these promotions to access the Promotion Description. (Also, the menu button will allow the user to travel to other screens shown later.)

Promotion Description

Image:finalPromotion List.png

After a user clicks on a promotion, it takes them to a separate description screen. This screen has information such as the store's name, type of store, description, location, distance from current position, and the number of positive votes over total votes. At the bottom, there are thumb up and thumb down buttons allowing the user to rate the current promotion. We figured to stop the elevator button effect, we added some vote button feedback to indicate the vote up or down after a button press. Some small interface changes were setting the default cursor position to "back" before and after vote button presses for easier navigation (since "back" is probably the button they want to hit next). The back button will take you back to the original results screen, while the map button will obviously take you to the Map screen showing you a map of how to get to the store.

Map Screen


This is the Map view of your current location and a path to your selected store. To get the maximum map viewing area, all of our options are in the menu rather than being floating buttons. The map centers on your current location, and finds a good zoom level based on your distance to the destination. It also tweaks the panning granularity based on the zoom level, which you can also manually manipulate. There's also a traffic and satellite view of the same area. Lastly, the back button obviously takes you to the page you were previously viewing.

Menu button options

Image:finalMenu 1.png

Now if the user hits the Menu button, they have access to three more vital screens: Preference Setting, Advanced Search, and Add Promotion.

Preference Setting


This is where the user can set his preferences for what results to show. So he can only have promotions in a certain radius show up, the max number of promotions to show per store (so that a single store cannot flood your results), the minimum vote ratio (so that bad promotions won't be seen), and types of stores you want to allow. By popular demand, the save button now pops up a dialog to tell you that it has been saved before taking you back. Awesome! The cancel button will take you to the previous page without saving changes.

Advanced Search

Image:FinalAdvanced Search.png

This is where you can do a more advanced search than the default one on the main page. Here you can not only look up keywords, but also search for only a specific type of store, distance away from you, location, or have it have a certain vote ratio. In here, all the fields are optional.

Add Promotion

Image:FinalAdd Promotion.png

Here, users can add their own promotions by filling in the store's name, type, description, keywords, and location. After they hit the save button, it will go into the database where it can be searched, voted on, and more. The map preview button will show them the location on a map beforehand to verify the correctness of the location. Finally cancel does what one would expect and not save the store to the database, and instead go back to the previous page.

Implementation and its Difficulties

As RealDeal evolved, so did the implementation. Unfortunately the changes caused some more difficult problems to allow the improved UI.


Keeping the functionality we wanted in mind, we needed a database to hold all the information for Real Deal. We chose a local database for ease of testing. We also use a database for holding user preference settings. Add New Promotion is the screen used to input into this database holding information such as a store's name, type, description, searchable keywords, and location. On this screen, we had a button to go to the MapView of this store. The location is auto-filled with the current location to help the input. The database is then used in the basic main screen search, or even the advanced search where any number of those fields for the store can be searched.

Main Page Display

Aside from the obvious functionality that needs to be implemented on our main page, the design was actually a little tricky given the limited and canned UI design options from Android. We originally designed a table, not knowing that Android didn't have a great way of managing tables of data. So we started off looking for lines, or dividers which were absent. Instead for the rows we used alternating linear layouts with alternating background colors to represent the columns, which had the side effect of looking pretty cool. Unfortunately since our user had to be able to scroll through and select options in this table, each background color needed a "highlighted/selected color" too, which not all background colors had.

Cursor Movement Via D-pad

So we realized a problem was that with our D-pad movement of the field selection was kind of buggy; pressing left on the D-pad didn't always move you to the left input field. This was due to problems like the spinner trying to change its content when you hit left. Initially we thought we could just disable the left and right choice selection for the spinner, but we couldn't find a way to do that. Instead, we've hard coded the left and right arrow keys to switch fields for the spinner fields. A lot of our interface actually had to be similarly hard coded.


The map was one thing we assumed had to be a natural functionality of our application, however from user tests, it didn't seem that essential. However, we figured since everyone expects it we should implement it anyhow because Android had GPS/MapView/Geocoding fun already. Unfortunately, we realized that for the emulator we have to emulate the GPS (not that fun or interesting anymore), the MapView was not initially easy to deal with, and the Geocoding function that Android provided was just a mockup - the "geocoding" was just pulling information from a local text file that we have to create ourselves. Regardless, we did the maps from the address along with walking/driving instructions.

Once getting the map to show up, the initial problems were small things like getting the zoom, where to put the back button (floating, or in the menu), and redraw. One of the weirder quirks was that initially we didn't think our code was working when we didn't see our walking path on the map, and just a single mark for our location. It turned out we were simply very much zoomed out and we were seeing our starting point and destination point right on top of each other. So to fix that, we have to dynamically figure out the right amount of zoom based off of the distance between the two points, and to center on the point that's calculated to be in the middle of them. (Though later on we are telling it to set to center on your current location instead) Also, the panning had to be adapted to move the square root of the zoom level per click - so that when you're zoomed out it doesn't take forever to move, and when you're zoomed in you still have fine grain control. In the end, the map was actually one of the hardest things to implement and polish off.

Preference Setting

We almost finished other parts of the system before we started the preference setting page. As the result, it was one of the more difficult interfaces we have implemented. We had to create a new table in database to store the preference fields, then filter out the main interface list every time it is loaded according to those preference also update the table when click save in preference interface. Also, for the types, we originally thought of using a list of types. But it was both confusing and lacking usability. Thus we changed to checkboxes for the type fields. This helps users to understand the purpose of the type fields as checkboxes clearly indicated the selection. It also enhanced the visualization for the type fields and let user to easily select any combination of type fields.

What was left unimplemented

Local database instead of central online database server

While most of the prototype is coded as expected, we have used a few minor tricks to simulate the functionality of Real Deal. Since we won't have a database server to process and query all the promotion data, we will just store this information locally on computer. This decision was made because we think that the main focus of this class is on the UI design of our application. The database server itself can be a stand alone project in a database class, and we just don't think spending such long time on something that's out of the scope of this class is necessary. So we decided to use a wizard of Oz technique to fake this functionality and use our time wisely on improving other essential part of our application.

Wizard of Oz

We will store all the coupon informations that are suppose to be handled by the central database in a text file, make Android read from the text file, display the result. When a user wants to input new promotion into the system, instead of going to server side, we will just append the local file to indicate the new record.

Hard coded current location instead of GPS current location

Since we don't have the actual android phone or the GPS API, we could not detect our location on our simulator that's running on our computer. So instead we used a fixed location near the bay area to represent the current location. With the correct hardware, this is a pretty easy fix, as we can use the location resource GPS from android API to easily solve this problem.


Google has not finished their geocoding session of code. There is a geocoder included in their API; however, the only address contained there right now is the white house, which is pointless for our application (unless you are going to find promotions there) So we had to supply the coordinates for each shop in our database right now. This is also a pretty easy fix as we can easily use Google geocoder to search the stores' address and get the correct coordinates.

Image for Promotions

We had the idea to let user also submit a picture from android for each promotion. The visual image for the promotion could be much more descriptive than a couple line of sentences. However, there were also a few problems with this, first of all, with such a small picture we could afford into our interface it wouldn't be too helpful to show the item. Also, we don't have much control about what kind of pictures that user submit to the server. Users may submit unrelated images that we wouldn't want our users to see into the system.

Bar Code Book

Originally, the idea of our system is to eliminate the classic coupon mailing. Thus, we had an idea of coupon bar code book kept per user. Stores can mail their coupon bar code to each user. When users are shopping, they can just open up phone and let the store to scan the bar code. During the user test, however, we found out this idea is pretty pointless. As if the store can identify which user he is sending the coupon to, the bar code is meaningless, as store can easily limit the coupon usage it sent to users just by asking for phone number during checkout. Also, scan bar code on a digital picture may or may not work in real world. As the result, we gave up this implementation.



Zipped Code


Zipped Poster

[add comment]
Personal tools