Sorry, your browser is not supported
To have the best experience using Skillshare, we recommend that you use one of these supported browsers.

72

18

BrewerNote

Summary (Pitch)

What's the biggest problem with homebrewing? Forgetting an awesome recipe! From brewday to cracking that first bottle is at least 3 weeks, which is plenty of time to not write it down.  Why not record your recipe as you're brewing, complete with notifications for every step of the way?  BrewerNote brings this all to your phone along with brew history, recipe sharing, and more.

Description

Recipes

The recipes section will be used to store the detailed ingredients and steps to brew each recipe that the user inputs.  These will be associated with brews, both current and completed.

Current Brews

The current brews section tracks brews that are currently either being brewed (still in the kettle) or in some stage of fermentation. The main reason that this is important is for timers. These timers include:

  • Hop additions
  • Fermentation stages
  • Carbonation

Completed Brews

The completed brews section is a history of past brews.  This is helpful when, down the line, you crack open an old bottle of brew. So long as it's labeled, this section will allow you to go back and see what ingredients were used, how long it was fermenting, and how long it aged.

App Video!

I have made a video detailing the use of the Recipe tracking portion of my app.  I apologize for the skipping. I'm having an issue with my laptop where it randomly locks up for a few seconds.  Thought it may be a harddrive issue but a diagnostic didn't return any issues. I'm going to format and start over, but I wanted to get the video made and posted first.

http://www.youtube.com/watch?v=tPcoSGTvY9I

Interfaces


Main Interface Mockup

I made drew some mockups of the icons that I would like for the tab bar controller at the bottom of the main view.

The ideo for recipes is a simple notebook. I have toyed with the idea of putting an 'R' on the cover or something for Recipes, but I'm not sure that's necessary since the word will be right under it.

My idea for the current brews icon is a carboy (fermentation vessel) that has a shaded area to represent the brew that's in it. This sketch doesn't show it, but it would make sense to add an airlock to the top of it.

Finally, the completed brews icon that I have in mind is a bottle of beer, mostly shaded to show that it's full.  My other idea (not pictured) is a partially full pint glass.  I still may go with that, but we'll see.

Main Interface Build

Recipe View Mockup

Recipe Edit View Mockup

The recipe edit view will be used both for editing existing recipes and for creating new ones. It's basically going to be an editable version of the recipe view.

Below are mockups of the different custom cells that will be used in the Recipe Edit view.

This cell will be used to edit the basic information about a recipe that doesn't really fit into any of the categories below.  I'm going to build it out both as a single cell and as three separate cells and see which looks better.

The next cell will be for inputting the original and final gravity as well as the wort temperature when these gravities were taken.  This is used in the ABV calculation.

This is going to be a combination of two cells. The first cell will appear alone if you're creating a new recipe, and when you fill in the textboxes and touch the plus sign, it will add a copy of the second row below it and clear the textboxes.  When actually editing a recipe, the second type of row will be populated based on the malts already in the recipe. At some point I may modify the minus button to be some sort of edit icon which will create a popover view controller with options such as edit or delete.

The same idea as the malt cell will be used for the specialty grains, hops, and other ingredients sections of the recipe.

This cell is pretty similar to the malt cell both in look and function.  I'm debating on making the Stage textbox a label and having it change when you add stages (Primary, Secondary, etc), but for now it'll just be a textbox.  The fermentation stages are stored in an array in the Recipe class, so there can be as many as is needed.

The final cell is the notes section. Pretty self explanitory.

UPDATE - 12/8:

Edit Recipe View Build

The above two screenshots show the scroll of what the edit recipe view will look like. At the moment, the button for removing rows is the information button, but that's really a placeholder for an actual removal button (or perhaps a button that creates a popover view allowing you to remove or modify the row).  

This interface is what shows up in the app right now, but it's statically coded just to showcase (and test) the custom UITableViewCells.  My next goal is to work on actually implementing the functioning view which will include dynamically adding rows when the + buttons are pressed.

As it stand right now, every row in those screenshots is a separate class, so even the ones that look very similar or identical are different classes.  I didn't really think about it until after the fact that they could be condensed and shared.

I should probably create a single class for the rows that add ingredients and then a single class for the rows that display them.  Then, based on some variable in the class or some other indicator, update the label for what type of ingredient and add it to the appropriate category.

My current idea for how to add rows dynamically is to add the ingredient to the recipe entry associated with the view that is currently loaded and then tell the view to reload the table, similar to how the book does it's data reloading for Homepwner.  I will do some research though, because it would be nice to have some sort of smooth animation to show the cell appearing when you click the plus sign.

UPDATE 12/10:

I implemented the above design loading a recipe correctly, however I decided while doing it that I was going about it incorrectly. I decided to use a grouped table style. The first section being the general recipe information, subsequent sections being for the different ingredient types, and the last one being for the notes cell.  This will make the loading, saving, and adding new ingredients logic so much simplier.  I have started implementing this, but no screenshots to show just yet.

UPDATE 12/14:

The recipe edit view has been completely implemented.  It now will load a recipe that already exists or allow you to create a new recipe.  All of the recipe data saves as well, so long as you force the simulator to the home screen.  Dynamically adding rows is also completed for all of the ingredient types, as well as removing rows by clicking on the "I" button.  Eventually that button is going to be used for things like editing rows too, but for now it's just delete.  One issue that I've run into is the lack of screen real estate on the iPhone screen. The only solution to that I can think of is implementing another view that appears when you touch an ingredient row that shows the details of the ingredient in a list.

I'm really happy with how the interface turned out. My next task is going to be getting the Recipe Detail View completed. It will basically be the same as the edit view but it won't be editable.  Something that I've thought about trying is setting everything in the edit view as non-interactable and using that as the detail view, with a button for editing the whole recipe. It's still an option, but I'm not sure it's the one that I'll go with.  Once I have the detail view completed then I'll be in a position to start figuring out how to make an app use video.

UPDATE 1/13:

I have made quite a few interface changes. I won't post screenshots of the simple ones.  Firstly I removed the red Info icon on the ingredient rows. It was a bit bulky and not streamlined at all.  Instead I have implemented swipe to delete on those rows.  That really fits with the iOS standard and makes the app much cleaner.  I also removed the F/C selector from the Specific Gravity section.  I was thinking about it, and for a recipe that makes no sense.  For an actual brew it makes sense to log what temperature the Wort was when you took your gravity reading, but for a recipe it's moot (you should assume your wort is 60 degrees).  Now on to the more major changes! :)

First I have added a Fermentation Stages section to the table view. Somehow this had escaped me, even though it's completely necessary. This will allow the brewer to document how long the brew should be in Primary fermentation, secondary, etc.  It will come into play more once the Current Brews tab is working, so that the app can notify you of upcoming transitions.

The other big UI change that was made is tied to the background code changes documented below.  I have added a cell for IBU and ABV for the recipe.  Both of these cells are under the General Information section and include a selector that allows the brewer to select "Auto" or "Manual".  Both cells default to auto, meaning that as details such as batch size, OG, FG, and hop additions are added, those values will auto-calculate.  If the brewer decides they want to enter them manually that is an option too. The manual value is saved in the background recipe code, so if they accidentally click Auto, the value won't be lost.

UPDATE - 01/14:

I finished implementing the recipe detail view (the view that you will see when you select a recipe that is already in the app, but have not chosen to edit it yet).  This view required significantly less work than the edit view.  I didn't bother to mock this view up on paper because it's essentially the same as the edit view, so that would be repetative. It just doesn't allow editing.  Making this view has actually given me some ideas for future optimizations for the edit view.

Completing this view was actually my goal for the project submission. Since it is completed I am going to work on some stylization (custom color scheme, icons, etc). It probably would've been better to determine this up-front so that I could have implemented it as I went, but live and learn.

UPDATE - 01/20:

I created a paper prototyping video for a new feature that I'm adding to the recipe section of BrewerNote.  The feature will allow recipe versioning.  The idea is to be able to track how a recipe evolves over time.

Paper Prototyping of Recipe Verisioning: 

https://www.youtube.com/watch?v=O7s24HxcxZY

Background Code

Currently I only have the Recipe class and the recipe store class created (in terms of background support code).  However, I believe that they are 90% completed.  I also already have the support classes (Ingredient, Malt, Spec. Grain, Hops, etc) conceptualized, it's just a matter of implementation and integration.

UPDATE - 12/8:

Sometime late last week I actually implemented the rest of the classes that support the Recipe class.  I haven't done much testing of them yet because I want to test them via the interface, but they're pretty simple, so I'm confident that they will function as expected.

At the moment the Recipes are coded to save via archiving.  Since it's unlikely that people will have huge numbers of recipes, it should be fine to do it that way for now.  I would eventually like to migrate to NSData though.

UPDATE - 1/13:

I implemented some background code in the Recipe class that calculates hop utilization based on the formulas by Glenn Tinseth (http://realbeer.com/hops/) and John Palmer (How to Brew).  I tied this into the recipe edit view to allow the user to auto-calculate or enter the values manually.

TODO: (Bold = Completed)

  • Implement recipe edit view
  • -- Create the edit view table rows
  • -- Implement the actual, functioning view
  • Implement background code to populate recipe edit view
  • Mock up recipe view
  • Implement recipe view
  • Implement background code to populate recipe view
  • Implement classes that support the Recipe class (can't populate anything without that)
  • -- Implement background functions to calculate ABV and IBU based on the recipe.
  • ---- Modify ABV/IBU getters/setters to automatically return calculated or static values instead of requiring the UI code to figure that out.
  • Mock up current brews view
  • Implement current brews view
  • Implement background code to populate current brews view
  • Learn about timers and notifications
  • Implement timers+notifications for different aspects of a current brew (hop additions, fermentation stages, aging/carbinating)
  • Mock up completed brews view
  • Implement completed brews view
  • Implemet background code to populate completed brews view

STRETCH GOALS:

  • Weigh pros and cons of archiving vs NSData
  • Implement a web protocol to send the data to my webserver for use with the website portion/sync between devices
  • Design/Implement iPad-specific views
  • Ability to "version" recipes
  • Include SRM calculation
  • Add all-grain (entire project in and of itself)

Comments

Please sign in or sign up to comment.