Group K Name: JAWS
Names & Roles
Ace Haidrey: participated in write-up; databases; set up messaging and most of the back-end connections between activities; worked on presentation
Sarah Huang: participated in write-up; front-end for watch face start screen and detailed search results; drew storyboard; worked on presentation; voice-over for video
Jordan Wong: participated in write-up; databases; locations services; designed most of UI XML layouts, home page; worked on presentation
-
Whitney Xu: participated in write-up; interactions between mobile and wear; drew storyboard; worked on presentation
Problem and Solution Overview
Haggling is an essential skill in many foreign markets, yet it is very difficult to master quickly and almost impossible without physical experience. After all, there are multiple variables involved, including gauging the worth of the item you want, interacting with a real vendor, and setting prices that will eventually help you purchase the item for the price you want -- all in a foreign and unfamiliar environment, with different customs, different currency, and even a different language system! Applications that teach this skill are rare (if any exist at all). HaggleMaster is an app that hopes to bridge this gap by providing the resources for users to learn this valuable skill through well-informed data on prices from other users and coaching from a more experienced confidante.
Tasks
easy task: sharing purchases
After the user has haggled and made their purchase, they can upload relevant information (e.g., title, price, image, description, etc.) to the database for other users to see and to be better informed. The user can initiate the purchase through the wear and once he/she finishes the transaction, he/she can take out his/her smartphone to upload an image of their purchase and type in other information. This task is the easiest of the three because it is one commonly found in other applications, so the user is navigating a familiar interface.
moderate task: searching for items
The user is greeted on the start screen of the smartphone application with a search option, so they can find items they want to haggle for and select items from the search results to look more in detail at other information (e.g., image of item, location of purchase, the vendor’s starting price, the user’s final offer, a timestamp, etc.) From there the user can activate the buddy system interaction if they like the item and attempt to haggle the item down to the same price. This task is a little harder than sharing purchases because while for the most part the interface is similar to other search applications, the user must engage cognitively in finding relevant items (since our app uses single-word hashtag descriptors to organize items, rather than a ‘name’ for the item).
difficult task: buddy system interaction
The user haggles while the friend / confidante sends preset or custom messages to the user via the watch to suggest possible actions for the user to do while haggling in order to get the price they want. Once the transaction is complete, the user can click ‘Purchase’ on their watch and enable the phone to upload the item. This task is the most difficult of the three because even though the user is passively receiving notifications on a watch and the friend is simply pressing buttons or typing to send suggestions, both users are not only involved in utilizing the buddy system interaction, they are also socially and cognitively involved in a scenario where they are actively talking with a third party (the vendor), and using the interaction as a tool to haggle.
Revised Interface Design
Our previous tasks included a total of four different tasks: one easy (finding local marketplaces by current location), one moderate (searching for specific items), one difficult (uploading a purchase for other users to view), and finally one that involved the smartwatch (buddy system when haggling). After a lot of discussion, we agreed to scrap a few features and streamline the entire interaction. From our first meeting, we came up with the following model:
The tricky part of our new UI design was the fact that the buddy system was not part of our original “three tasks”, since we found the interaction very complicated in and of itself. As a result, we only demo-ed this task to users, but we did not have them attempt to use it, since many of the users we interviewed were in a hurry. Now that we have streamlined the buddy system into our app, it will be interesting testing users in our next user testing session to see how they like our designs.
Thus, our main goal was to simplify the original low-fi Balsamiq prototype, retain three distinct tasks of varying difficulty, and still incorporate the buddy system. The feedback we received from users during our low-fi user test was for the most part helpful on interface, but because most of them had not been in an international bargaining environment, they found certain implementations unnecessary (including the buddy system interaction).
Our first major change was simplifying the initial low-fi menu screen. Our original menu screen had three buttons (for the three tasks) to “Find Local Marketplaces”, “Search Items”, “Upload a Purchase”, and a prominent button to “Start Buddy System”. Our new menu screen offers less options for the user, and consists only of the app’s name and a search bar, so users can enter in specific items they are looking for.
Our “search results” page followed a similar design as the Balsamiq mock-up, but based on user feedback, we only included the most important information (e.g., name, image, price), and put the details in a “search details” page for the user to access if they are interested by the item. The user can thus browse quickly through the list of items. Based on another user’s suggestion, we plan to implement timestamps for users to see how recently a transaction occurred to determine how relevant a price listing is. We removed the toolbar at the bottom of the screens for now, since we have not implemented any user log-in or profile information in any part of the app thus far.
Finally, we completely simplified the “suggestions” page into one screen. Before, the friend would be taken to different pages if they decided to send a custom message or suggest a price, which would slow down the interaction between the user and the vendor, since they are busy navigating so many different screens. We put all the buttons and commands on one screen to simplify this process.
Prototype Overview
The starting page of our app shows the name of the app and a search bar for users to search the items they want to buy. We created the search icon in photoshop by taking a previous photo from the internet, changing the color and the shape and then resizing it. The idea is to have a clean and simple design so the user knows to search for an item to get started.
By clicking the “search” icon button, the app pulls up a list of items in our database matching the item searched that other users have haggled for and purchased nearby. It shows the image of the item, name of the item, average price for this item at this location, and the lowest price the item sold for. This interface has the search query displayed at the top so the user doesn’t have to recall what he/she searched for, followed by items placed dynamically in a ScrollView (since each query will have a variable number of items relating to that search in our database). We are able to get the query from the first (main) page, search our database, and display the results from our database using the SQLite API, so this page is fully functional. There is still work to be done such as grouping information for the same location to display an accurate average price, and not have repeat locations show on the ScrollView page.
If users click on a specific item item, our clickable ScrollView items will show them detailed information on a new page, where once again the photo, name, price information are displayed. In addition, the page will display a map showing the item’s purchase location, a description that previous customers have written about this place, and in future models, a rating system of the user’s experience (where 1 signifies the vendor was unfair, and 5 that they were able to get an item for a fair price and a good experience haggling through the HaggleMaster app).
At the bottom of each of these pages is a button that says “Start HaggleHelper” to provide an option for the user to attempt haggling for that item. We use the GoogleAPIClient to enable messaging from the phone to the wear, to open up the app on the watch screen. We use some wizard of oz techniques on this page because we have a couple of things that aren’t yet implemented yet, such as using the GoogleMaps API to get the user location to display on the map.
Pressing the button will initiate the interaction on the watch, opening a suggestions page on the phone for the friend and the app on the wear for the user.The wear’s start screen informs the user that the watch is currently “waiting for friends’ input” with a spinning wheel (progress bar) to illustrate this intent.
The mobile’s suggestions page for the buddy system has several options for the friend helping the user (e.g., notifying the user to raise / lower the price they ask for, taking the item at the current price, leaving the scene altogether). The page also allows the friend to manually input suggested prices and messages to be more personal and specific to situations that can’t be captured by the simpler actions. When the user with the phone clicks on a button or sends messages, a notification opens up on the wear with the corresponding information. Not only will the notification pop up but different vibrations are set for different suggestions, so the wear user doesn’t have to look down at the watch every time. A short buzz tells the user to lower the price, a longer buzz tells the user to raise the price, two quick vibrations mean there is a personal message (so they know to glance at the watch), etc. The wear user will ideally pick up on these vibration patterns quickly to make the interaction with the vendor smoother and faster.
The wear user can notify the friend on the phone at any time when they decide they are ready to purchase the item. By swiping left, a purchase button will appear (which was implemented using an add action in the notification builder). After the user clicks on the purchase button, it will trigger a message and sends an intent to the phone (again done by GoogleAPIClient but in the opposite direction), which will end the buddy system interaction by opening up the upload page on our phone screen.
On this page, the users can upload the image of the item they bought along with the item’s name, price, address, and description. Once they click on the upload button, that information gets added to our database, and a message appears allowing the users to know that their upload was successful. Things left to implement on this page would be instead of manually having to input your address, the users should be able to press a button that auto detects their location using the GoogleMaps API. In addition, we may add more fields for the user to fill in, to make the information more detailed for other users.
What was left out and why:
Google Maps API
We didn’t have enough time to implement the Google Maps API to display the locations of the marketplaces and calculate the user’s current location (as well as the currency for that location), but we currently plan to have it in our final implementation. We also need to combine information for the same location so duplicate locations don’t display (and maybe add a lowest price at this location, to go with last price and average price). We currently hardcoded an image, to see what the design would look like. We will probably wizard-of-oz this part and tell our users whatever information they need to know about locations.
Prices
We are playing with different ideas of what types of prices we want to show the user. Currently, we have a way to show the individual prices the user has bought for an item, the lowest price for that item, and the average price. We may want to add a feature where we show the vendor’s starting price to show a comparison for how much an item has dropped in price.
Remote database
We don’t have an online database as we have our database stored in the phone due to a shortage of time, but we’re looking toward using Ruby or Flask as our web server.
Timestamps
One suggestion we received from one of our interviewees was the implementation of timestamps, so users could figure out how recently an item was purchased. We thought this was a good idea, but currently we do not have this feature in our database or on display for the “search results”. We did hardcode a sample timestamp on a more detailed information page for items to see how we would format, but we plan to implement this detail fully in the future.
Buddy System
We did add the vibrations for the notifications received by the watch from the phone in our code. However, we haven’t tested it on the real Android Moto360 yet. We also do not have a saved list of preset messages for the friend to send (they can only type custom messages so far). We also wanted a way for the lowest price an item was purchased for to be displayed for the friend on the smartphone when the buddy system is started (recognition vs. recall), but for the purposes of design and the limitation on time, we currently do not have this feature implemented. This will be implemented in the future.
Remote Buddy System
We previously had an option for the phone to receive audio from the watch, and a volume control for the friend on the audio received, in case the friend decides to be a little further from the user when the haggling transaction occurs. At this point in time, we are not sure if we will implement this feature.
User Information
We did not add a way for users to create their profiles, and there is no information about other users that utilize the app besides the information they upload (but users are not associated with their information). As of now, based on time, we are not sure yet if we will implement this feature.
Search Implementation
We had intended to search by descriptive single-word hashtags associated with the item, since we have gotten feedback from many users that items you buy in foreign countries may not have a name associated with it, so users would make up a range of very different names, making it difficult to search. However, for the sake of simplicity in this prototype, we created items with single-word “names” and an added “description” to search with. We should also be able to add filters to search results, a ratings option, and a commenting option for other users. We are not sure yet if we have time to implement this in the future.
Miscellaneous
We also haven’t added back buttons (which may not be needed given the design of the Android smartphone). We tried to be consistent with the display on the smartphone and the smartwatch, but the fonts we imported for the smartphone for some reason do not display on the watch (this is something we are still working on). For certain screens, the font was also inconsistent (did not show the imported font) because some screens were dynamically created. Lastly, we need to add exceptions, and help errors such as if a user searches for something that doesn’t exist in our database, and in case if a user changes their search, we need to clear out our previous search information, so they don’t display as well.
Ace Haidrey
Comments