InteractivePrototype-Group:100 Proof
From CS 160 User Interfaces Sp10
Contents |
Team Members
- Esther Cho: Interactive Prototype Coding.
- Calvin Lin: Interactive Prototype Coding.
- Brandon Liu: Graphics and PowerPoint support for all aspects of the assignment.
- Nathaniel Baldwin: Report write-up.
- Matt Vaznaian: Interactive Prototype Coding.
Problem & Solution Overview
With the explosion of popularity of the craft beer movement over the last few decades, there are literally thousands of different beers that a beer enthusiast might encounter over the course of a few years. Not only that, but even an attempt to narrow things down by category won't help much; at the Great American Beer Festival (America's largest), they recognize beers from 75 different categories. Herein lies the beer drinker's dilemma; they'd like to try samples of many of the exciting new beers out there on offer, but they'd also like to remember which ones they liked the most, and why. This is a problem not only because of the wide variety of beers and the ephemeral nature of taste, but also because the very act of enjoying a beer has the unfortunate side effect of memory impairment! Classic, hand-written notes may be an acceptable solution to the determined connoisseur, but is too troublesome for the average drinker. Our app aims to solve this problem by providing a portable, natural, elegant, and fast method of jotting down the most important notes while the taste is still fresh in the drinkers' minds.
Presentation Slides: File:PresentationSlides.pdf
Source Code (w/ README): File:100Proof IAmBeerApp SourceCode.zip
Video Demo: On-Device Demo(YouTube)
README.rtf
Operating Instructions
Upon first loading the app, click the "NEW REVIEW" button. Here, go through each tab and perform the functionality. When satisfied with your review, click the "I AM BEER" button on the top bar to return to the home page.
Next, click the "RANK BY CATEGORY" button. Select "Location" on the menu bar, and then select "Jupiter" from the table. Here, you can scroll through the list of beers that have been tasted at Jupiter restaurant, and rank them. To rank a beer, click the re-order icon on the right of a table entry and drag it to the desired spot.
Limitations
The 2 other buttons on the home screen currently have no functionality. These do not fall under our 3 tasks, so were left unimplemented.
The "take a photo" feature of a review was hard-coded. Clicking the button just fills the space with an image, as if the user had taken a real photo.
Our prototype does not include persistence of data yet. Creating a new review does not cause it to show up in the category lists for the "Ranking" task. Using dummy data still allows users to test out the functionality.
For the "Rankings" task, only the "Jupiter" entry under the "Location" category has data. Selecting a "Tag", "Brewery", or any other "Location" produces a "No Beers Found" popup.
Tasks
Task 1: Record Information About a New Beer
This "easiest" of tasks is also the most vital: adding a brand-new beer to the application's database. This task includes the absolute basics: the beer's name and brand. It also includes entering some important details - price, location had, and seasonality - as well as a few ratings, including an overall score and notes on a beer's color and aroma.
Task 2: Rank Beers Within a Specific Category
Our task of "medium" difficulty involves ranking a beer within a particular category. With the goal of flexibility in mind, we decided to let the user pick a category - which can be a brand, a location, or for ultimate choice, a 'tag' (which can be user-defined) - and sort beers within that category. In this way, the user can not only give beers absolute ratings, but also rate them subjectively, relative to each other.
Task 3: Taste Wheel and Tags
Our most "difficult" task involves users inputting a number of different pieces of information about the beer they are tasting through the use of our Taste Wheel and Tag features. These features go beyond the offerings of most other similar apps out there, and use a somewhat novel interface to do so. The Taste Wheel allows the users to interactively rate eight key aspects of a beer's taste, while the Tag screen allows users to "tag" a beer with either pre-populated or custom tags, to allow essentially limitless ways to organize beers based on user desires.
Revised Interface Design
Changes and Their Rationale
Overall, our low-fi testing sessions went quite well. While this is certainly heartening from the standpoint of how well our app was designed by the time it was presented to our low-fi testers, it does leave us with a dearth of changes to discuss. There were a few things that came up, however.
Perhaps the most prevalent concern was that the users kept looking for a "save" button, or some sort of validation that their data was being saved. Our team spent some time in consideration of this issue, and proposed several solutions. We thought of putting in "save" buttons in all the screens, but not only would they have taken up valuable screen real estate, they would have done literally nothing, since all data is saved as it is entered. We then considered having the app display a "saving..." notification when the user either inputted data or transitioned between screens / tabs. However, we felt that this would be problematic in two ways. First, it would quickly become unnecessary, and therefore intrusive - the user doesn't want to see that over and over again once they realize that it's the case. Second, it would have taken valuable coding time to figure out how to do that, time which was at a premium. Finally, we were struck with a realization: at this point, one of the affordances of the iPhone is, if you will, simplicity. It is an inherent feature of iPhone apps that the old, clumsy "save" feature, so prevalent on standard computers for decades, is all but obsolete. People expect their iPhone apps to auto-save their data for them, without even a second thought. We decided that our users had likely been thrown by the awkwardness of the low-fi interface, and that, had they been working with an actual iPhone, this issue would not have come up. So in this case, we left our implementation as it was, but not without careful consideration.
Another concern that came up during our lo-fi testing was the lack of a way to input two oft-noted aspects of a beer: Alcohol By Volume and International Bitterness Unit. IBU is an objective measure of how bitter the beer tastes that is calculated based on what hops are added to the beers, taking into account both their weight and the point in the brewing process when they are added. Not only is it a popular measurement that so-called "hop heads" take note of, but it serves as an interesting counterpoint to the more subjective measures that our app allows users to input. ABV, of course, is a measure of how alcoholic a beer is. This is quite an important thing to know, and not just because beers have a wide range of ABV percentages (from a low of around 3% for some light beers all the way to a record-setting high of 41%). It's important for a person to take note of how strong the beers they are consuming are, so they can get an idea of the right amount to consume, based on their desired level of inebriation. Because both of these factors were important, we decided to add them. However, screen space was at a premium, and we ultimately decided to sacrifice "Country of Origin" to facilitate their addition. We picked "Country of Origin" because it was judged less important, and because it is information that, in our experiences, is harder to find than ABV and IBU.
Lo-fi Prototype
 | Interactive Prototype
 |
The final change of note concerns our "natural language" results screen, an idea we originally came up with during the implementation of our low-fi prototype. This screen gives a quick rundown of how a particular beer has been rated and tagged using plain English. Originally, this screen had been displayed after pressing a "done" button on the taste wheel screen. However, during the interactive prototype implementation, we began to question that decision. Why would the "done" button be on the taste wheel screen? Why not another screen - the user can enter data in any order they wish, and the natural language screen displays tag-related info as well as taste wheel info. Our original choice seemed arbitrary and possibly confusing to the user. Therefore, we decided the most straightforward way to implement the natural language screen would be to have it as the final tab in the "new review" tab window, after the tagging tab. This ended the confusion as to where the link to the natural language screen was. It also eliminated the need to have (as we had originally intended) an "edit beer" button on the natural language screen, which is unnecessary now that the user can easily switch back to one of the editing tabs.
Lo-fi Prototype
 | Interactive Prototype
 |
Though both our "Taste Wheel" and "Tags" screens could be considered somewhat non-standard interactions (relative to the basic iPhone elements that are provided in Interface Builder), we decided to keep them both. During our low-fi testing, none of our users was confused about how to interact with either screen (though we did some minor tweaking to how the taste wheel was interfaced with based on how they approached it). In addition, we feel that they provide a very robust way to enter ratings in a relatively small amount of space, and furthermore, give the app some visual flair that would otherwise be lacking.
Unimplemented Features
Storyboard of Tasks
Bob enjoys drinking beer, but he's always forgetting which beer's he's had and how he felt about them. One day, he stops by Henry's to grab a few pints. He orders a Fat Tire, and, as he's waiting for the bartender to pull his pint, remembers that he just downloaded a cool new app, I Am Beer. He pulls out his iPhone and loads the app. Little does he know that he's about to embark on Task 1: recording information about a new beer. He presses "new review" from the main menu, and is presented with the general information screen.
 |  |
He starts out by entering the name of his beer, as well as the bar that he's at. Just then, the bartender arrives with his beer, and tells him it will be five dollars. He pays and tips the bartender, then takes a sip of his beer. Ahhh. Looking back at his app, he sees the photo button, and uses it to snap a picture of his almost-full pint. Before he forgets, he also punches in that the beer cost five dollars. He then takes a slow, refreshing sip of his beer. Thinking about it, he decides the beer merits about a seven and a half . . . maybe a little less. He adjusts the slider, and, seeing that he's finished with this tab, clicks on the next one.
 | |
Used to his iPhone's interface, he continues alternating sips of his beer with entering details about his beer. He finds out from the bartender that Fat Tire is made by New Belgium and is offered year-round. The bartender isn't quite sure about the ABV and IBU numbers for the beer, but luckily, they're on the menu. He fiddles with the sliders a bit, deciding the beer is a little darker than average, but taking a whiff of it confirms that it's got a fairly mild, caramel-y aroma. Looking at the next tab, he's intrigued - what's a taste wheel? He clicks it, heading into Task 3: Taste Wheel and Tags.
 |  |
Bob looks at the taste wheel, and sees a number of taste characteristics he remembers beers having. He taps at the wheel to see what happens, and finds that he can adjust the "fullness" of each segment of the wheel to input an impression of that characteristic, either by tapping or sliding. The app even tells him in real time what an adjective that corresponds to his input is. Between sips of his beer to refresh his taste memory, he sets each of the wheel slices to the spot he thinks is right. Satisfied, he moves on to the tag window.
 |  |
Again, Bob sees an interface that, while unfamiliar, seems intuitive. He assumes he can directly manipulate the tags by dragging them with his finger - yep! He drags one around, lets go, and it snaps back into place. Then he realizes that the tags need to be put somewhere - in the bag! He tosses a few in for fun, then clicks the button to add one of his own. Bob is impressed at the balance his beer has between hoppiness and maltiness, and wants to remember this, so he tags it "balanced". Forgetting what tags he's thrown into the bag, he taps on it to find out. "Burnt" is in there, but that was a mistake. He clicks edit, taps on the red wheel next to Burnt, and deletes it. Done. He takes a sip of his beer, then wonders to himself if there's a way to summarize this information he's just inputted. Then he sees there's one tab left - results! He clicks it, and finds exactly what he was looking for. Smiling, he finishes his beer, confident that he'll remember it - or rather, his phone will.
 | |
A few months later, we find Bob at Jupiter. He's been using I Am Beer for the past few months, and now has a bit of a database of beers that he has accumulated. He's just finished drinking Jupiter's Quasar, and has inputted all its info as he drank. Suddenly, he realizes: this is the best beer he's had at Jupiter! If only he had a way to note that. Looking at the main screen of his beer app, he sees a function he hasn't used before. As he presses the "Rank by Category" button, he slips into Task 2: Rank Beers Within a Specific Category. He clicks the "location" button, and from there picks Jupiter, to rate beers from there. This gives him a screen where he easily grabs Quasar from the list, then slides it right up to the top. Simplicity itself!
 |  |
Prototype Overview
Overview of the Implemented UI
As noted above, we implemented functionality to enable the same three tasks that we worked on with our low-fi prototype. The app begins at a main screen that offers the users four main options.1 We've implemented the "New Review" and "Organize Tastings" features of this screen, which enable the three tasks that we are focusing on. Clicking on the "new review" button will bring the user to a screen that asks for the basics of their beer2, including name4, price5 and an overall rating6. It also allows the user to take a photo3 of their beer. From this screen, the user has an array of tabs available which enable entering further details about the beer and the drinker's impressions of it7. The first two tabs constitute our "Task 1," while the second two are our "Task 3". (The final tab is a display of results, discussed below) In the first two tabs (general information and details, respectively), the user enters information about their beer that we determined to be the most salient of the facts about any given beer. This is done using the familiar methods of editable text fields8, a UI picker9, and slider bars10.
Once the user has entered whatever details they care to in the first two tabs, they can move on to the second two - "Taste Wheel" and "Tags". (Of course, the user is free to move about the tabs and enter information in whatever order they desire; this is simply how we envision the average user interfacing with the app). The taste wheel11 offers the ability to enter a subjective assessment of eight important characteristics of a beer. Each of the eight "slices" of the wheel can be tapped or slid12 to assign a score to that slice's aspect of a beer. Closer to the center of the circle (octagon, actually - see below) is a low score, and closer to the edge is a higher one. The user can adjust the sliders as they see fit, including leaving it empty13 for a characteristic that is not present.
Next, the user can head to the Tags screen14. Here the user is presented with a number of floating "tags", which they can associate with the beer they are drinking by dragging and dropping them into the "tag bag"15, because rhyming is cool. The screen is pre-populated with popular tags, and also gives the user a button to click with which they can add a custom tag of their own16. They can tap on the bag itself to see what tags it contains and/or edit those tags17. The idea here was to give users an easy way to categorize beers in whatever way makes sense to them. Perhaps one user likes to keep track of "summery" beers, while another is more interested in beers she thinks are "flavor explosions". Whatever way the user wants to describe that beer, they can tag it that way. The system then remembers that tag, so new beers that fit the category can be easily linked with the same tag. To delete a tag, the user taps on the bag to display its contents, and then clicks "edit". This adds a button to the tag listing that enables deletion of tags18, using a standard iPhone interface19.
Finally, the user can click on the "results" tab20, which will bring them to a screen that displays a summary of their feelings about this beer, as well as a list of tags associated with it, in plain English.
The other feature of our app that is currently accessible from the main menu is the "Rank by Category" feature21. This feature works in concert with data the user has already entered to allow just about any category of beers to be organized based on the user's subjective opinion of the relative merits of the beers in that category. Using a segmented button22, the user picks what they'd like to arrange beers by, whether it be the location they tried the beer at, a tag they've used, what have you. They then pick the specific category of beers by clicking that from the resulting list. This takes them to a new screen23 where, using the familiar iPhone table view, they may drag24 the beers in that category up and down to rearrange them into the order that corresponds with the user's feelings on the beers.
What Was Left Out - and Why
As previously mentioned, not all of the functionality that our app advertises on its main screen has been implemented. Because our tasks did not include the use of either the "search beers" or "group evaluation" functionality, and because we had a very limited amount of time to work on the app, neither of the buttons that lead to those features has been implemented. See above for storyboards of how we envision those parts of the app working and fitting in with the app as a whole.
Although it is a minor point, it's worth mentioning that what was designed as a circular "taste wheel" ended up being octagonal. This was due to the fact that we found it easier to work with triangles (which make up the octagon) rather than odd-shaped pie pieces while writing our code. While we hope to overcome this hurdle in future iterations of the app, for now we simply did not have the time to devote to such a cosmetic concern.
Speaking of the taste wheel, we ideally would like to make it configurable - we don't want to assume that our 8 beer characteristics are the ones that are the most important to every beer drinker. However, this is a feature that could have proven tricky, and certainly time-consuming. Therefore, for the moment, the taste wheel characteristics are static and unchanging.
We also did not include any link between the tasting organization (the in-category ranking of beers) and the natural-language description page for the beer. While in the future we plan to have the natural language page list information about category rankings as well as taste-wheel rankings (e.g. "This beer is ranked third in the 'Belgian' category"), this was an idea that we came up with too late to add it to this interactive prototype. It is also an idea that fits more with the "search beers" functionality - the user will have the option to see the natural language information for beers that are the result of searches they perform.
Another sacrifice we made to the limitations of time was persistence. Though storing user data is, of course, of utmost importance for an app such as ours, we simply couldn't get this functionality into our interactive prototype within our time constraints. As this is largely an exercise in interface design, we felt that our time was better spent putting together a functional demonstration of our app's interface, and so persistence, for the moment, fell by the wayside.
Finally, on a note related to persistence, the two sections of the app do not share data as they would in the final app. That is to say that the "rank by category" section of the app is not updated with the information that is entered during the "new review" section of the app. Rather, it has hard-coded sample data, as discussed below.
Wizard Of Oz
Our interactive prototype does not actually require a human to be "pulling the strings" behind the scenes, so to speak. There are, however, some aspects of our app that do a bit of "cheating".
In the "general" tab within a new beer review, we have the option to take a photo of the beer you're reviewing - a popular feature among all the interviewees for our previous two assignments. Unfortunately, this poses a few problems. One, it's a coding challenge, and two, neither the simulator nor loaner iPod Touch have any camera functionality. This being the case, clicking the "add photo" button currently does not pull up the camera interface as it ideally would. Instead, it causes the app to display a pre-prepared "photo" of a whimsical fish, wearing a snorkel and living in beer. (The fish picture is courtesy of the webcomic Goats )
The other main "cheat" concerns the "rank by category" feature of the app. Though in a fully-featured version of this app the data in this section would be pulled from the app's internal database of already-entered beers, this is unfeasible for a demo. Because of this, the data in this portion of the app is pre-populated by hand. This cut down on our development time and at the same time allowed for an easy demonstration of how the app would behave with already-entered data.
Prototype Screenshots / Scripts
| | |  |  |
 | | |  |
 | | |  |
| | |  |  |
 |  | | |
 | |  | |
