Designs

Sally is a college freshman. She notices that she spends a lot of time walking to and from her dorm and classes, and so she decides to purchase a bike. She doesn’t know much about them, and isn’t interested in spending a lot of time looking up reviews at home; instead, she simply goes to the nearest bike shop.

With assistance from a salesman, she tries a number of bikes, and eventually narrows down her options to several different brands and models. She likes all of them, but she can’t decide. Sally would like a very quick and efficient way of looking up information about the bikes she is interested in, comparing specifics about the bikes, and a getting a decent recommendation for which bike to buy.  Sally does not want to go home to her computer and search; she would like the opportunity to try out the bikes as well.  She takes out her iPhone and opens Schnap It!

Design A

Sally individually takes a picture of each bike:

And then quickly identifies where in the picture the bike is by using gestures to draw a bounding rectangle, ellipse, circle, or freehand hull.  Specifically, this will be a touch and drag interface specifying exactly where the principal points of the shape should be in the picture taken.

All her pictures are aggregated into a grid, where she can select multiple to review at the same time:

Having selected the bikes of interest, the program opens a “reviews” shopping cart, which contains a row for each selected bike, along with it’s automatically-determined brand and model number, it’s lowest price from a reliable vendor, and it’s rating from a reliable reviews site. Sally notices that although the Schwin (bottom row) is only $99 online (it’s $169 at the store), that it is also only rated one star.

She decides to get more information about the expensive, but highly-rated Trek bicycle. To do so, she simply taps on the arrow in the Reviews Shopping Cart. This brings her to a page that shows price, description, and collections of reviews. After looking over it, she is decides to buy the Trek, there in the store.

Analysis - Design A

Efficiency

In this design, the user has a different screen for each decision.  The user also must take one picture of each object individually.  Then when all of the pictures have been taken, the user decides which object to review.  This choice seems to be irrelevant, because the user should not have spent time taking pictures of object he/she does not want to review.  Efficiency can be improved by aggregating the 'snap picture' and 'choose objects to review' subtasks into less screens.  For instance, one picture could be taken and the very next screen shows the shopping cart with information about each object specified.

For the purposes of this application, the user must spend time annotating the picture to specify which object to review.  The method of annotation in this design is very quick and efficient.  The method of comparing objects is somewhat efficient; if the user wants to compare a specific detail about two objects the user must travel back and forth between detail screens.  The user does not have the ability to move that detail to the shopping cart screen where all objects and main details (such as stars) can be viewed.

Learnability

Given this application starts by going right to the camera, the user will not know exactly what to do at first.  Only after taking a random picture and going through the process will the user figure out how the application works.  This detracts from the initial efficiency of learning the application, because there are no blatant instructions for the user to read.  In the long run, the user does not have to bypass a start screen or instruction screen that tells the user what it already knows.  The application efficiently starts right out with a camera.  After taking a picture, the user can touch randomly to learn exactly how to specify which object they are interested in.  After specifying, the application reinforces exactly how to take pictures of object and annotate by allowing the simple process to be repeated.  This also gives the user practice.  Selecting which objects to review is fairly easy to learn.  The pictures selected will highlight in some way to show the user exactly what is selected.  The arrows on the shopping cart are very good affordances that indicate more details.  In all, the learnability of this design is fairly good.  It allows the user to play on their own and its not too verbose.

Safety

Since the efficiency of iPhone applications is very good, the user can correct an issue fairly quickly by hitting the back button to move up the screen hierarchy.  Software architecture on the iPhone make this ability very easy to implement and allows the user for efficient error correction.  The user cannot modify information displayed about the objects, separating the backend model from the user model.  To the user, the application merely allows a way to quickly look up products for a simple way of comparing specifics.  Errors may occur in the backend, such as the object being recognized is not the object being pictured.  This design of the application does not account for this possibility.  Modifications should be made for the case when a new object is specified that is not in the database or when the picture taken is not of high enough quality to work for the object detector.

Design B

This time, Sally can collect information about all the products she’s interested in more quickly by taking pictures that each have multiple bicycles in them:

For each picture, she indicates where each bike by outlining them with her finger:

She is automatically taken to the scrollable Reviews Shopping Cart, where the bicycles of interest are aggregated, and show best, reliable online prices and reviews.

As before, she can look up more detailed information (description, multiple reviews and prices) about each bike by clicking on the arrow.

Design C

Rather than take a picture of the bike, she simply takes a picture of it’s barcode. This does not require any annotation.

Once Sally has taken pictures of each barcode, she can compare them in a table by price, reviews, warranty, etc. Since the software can determine that bikes are being compared (based on the product classification of each bar code), it can also provide additional values that can be compared on, such as construction materials (e.g. tire type). Sally is most interested in comparing the warranties for each bicycle, so she taps that:

...And is taken to a table where each bike she imaged is compared.

Epilogue

Armed with the knowledge of external reviews and competitive pricing, Sally is confidentally able to select the bike that best fits her needs.