GRP03

Team Members: Roles

• Ace Haidrey: Prepared the scenario to act out. Competed and submitted the writing portions for GRP03. Acted and helped create the video in iMovie.
  
• Jordan Wong: Acted and help direct the scenes. Created the mockups in Balsamiq, and helped hash out the details of our app. 
  
• Sarah Huang: Did the voice over for the video. Took shots on the camera for the scenes. Created mockups on Balsamiq. Helped with details for our app.
  
• Whitney Xu: Acted as the vendor in the video. Helped with details for our app. Did the photoshopping to superimpose the mockups with our images. Helped create the video on iMovie. 
  

Mission Statement: HaggleMaster

First, we'd like to redefine our target users from last week's group brainstorm (GRP01) to be a bit more specific: non-native travelers, visiting foreign countries with a large haggling culture. There is not much incentive for native people to need this app since they're already familiar with the price range for most products, and they most likely know how to haggle since it's part of their culture.

There are two main goals of this app: 1) to help our target users become more familiar with haggling and bargaining for goods in foreign countries, with the aid of a friend who can support, encourage, and advise the user without doing the haggling for them, and 2) to protect target users from getting taken advantage of in a foreign place as well as making them more knowledgeable of what kind of prices to expect.

Prototype Description:

Generic Scenario:

The app is based on a buddy system between two friends who are searching for a product of interest. One friend (friend 1) has a smart watch on while the other friend (friend 2) has a smart phone in hand. They approach a vendor, and friend 2 would open the app on his phone to check what recent and average prices are for this product as well as what other vendors with the same product nearby are selling their product for. Friend 1 is the user who would be engaging in haggling with the vendor, and after friend 2 see's the price information, he/she would send that information to friend 1's wear device. It would give friend 1 the idea of what range he/she should aim for. As friend 1 and the vendor are haggling, friend 2 would send advice and suggestions to friend 1 through the handheld/wear connection, until they settle for a price with the vendor. While friend 1 is buying the item from the vendor, friend 2 can immediately upload an image of the product, a small title and description, and the price of the item, to let future consumers know what the last sold transaction was. 

Details: 

• Easy Task: Viewing the app on the watch once notifications come, which will either be price information or suggestive messages. This is considered easy because you simply glance down at your watch screen and receive information.
  

• Intermediate Task: Searching the app to find a product you're interested in, and scrolling through results to select the marketplace or store you want to go to. This is considered a intermediate task because the user has to input text into the search line and scroll through the results to identify a place they'd like to go, which requires a little effort. 
  

• Hard Task: Sending/uploading items that they recently purchased onto the app. This is considered a hard task because it's much more involved on the user's end. They will need to take a quick snapshot, write a label for the item by hashtags, and include the price they purchased it for so it can be relevant for future users who go to that same location. 
  

On top of the three main task views, here are other views users will come across while using our app on the wear and the handheld. 

Video Prototype:

Discussion of Video Prototype:

How did you make it?

• We used three softwares and a Cannon T4i Rebel camera to produce our video. First, we brainstormed the scene that would capture all three of the tasks, and demonstrate how the app would work. We then captured the shots in Ace's house, to make a slideshow of our story. To make the UI mockups, we used Balsamiq and then superimposed them onto the photos we took through Photoshop. We then imported the new images into iMovie, creating a movie, and finally voicing over it, completing our video project.

Any interesting techniques you came up with?

• None of us have ever used Photoshop or Balsamiq softwares, which has given us a new skill set in creating quick and easy prototypes. It's very efficient and not labor or time intensive, making it that much more useful. 
  

What was difficult?

• The difficult part was planning out exactly how we would portray a scene that would capture all the different views and functionalities our app would have to offer, while still keeping it simple enough to not overwhelm users. This process took us the majority of the time and after that everything became smooth. None of us had experience creating mockups or photoshopping images, but luckily the softwares were very useful friendly and easy to pick up on (with the help of a couple of online tutorials). 
  

What worked well?

• Once we had all of our ideas in place in terms of what scenes we wanted, taking the pictures of the different scenes was very easy to do. We also quickly learned that the Balsamiq software was extremely intuitive and useful to use, which helped a lot in the creation of the different phone and wear interfaces! 
  

Implementation Strategy:

Will the smartwatch provide input only, output only, or both? 

• The smartwatch will provide both input and output. The watch takes the messages from the phone and outputs them to the user. The watch also communicates to the phone whether or not the user has bought the item, which requires user input. The majority of the functionality will be input only, such as receiving messages and suggestions from the phone, but there will be an output functionality, where the user can upload the price and it'll also send their location to the phone, allowing the user to upload photos and a description at a later time.
  

Will you be using any APIs? 

• We may be using the Google Maps API to represent the locations of shops. We also will need a database to store user inputs. The majority of our app such as sending messages between the wear and phone, sending notifications, and using sensors, like in the case that the user with the watch disagrees with the suggestion, will be using the Android API, which we have learned through PRG02.
  

What problems might you encounter? (How feasible is it to build this?) 

•  The biggest concern we have right now is implementing the search function via hashtags. As a result, we may need to build a database in order for this project to reach full functionality. Other than that the project should be feasible, since we've had good exposure through PRG02.