tom_hampton
Grandmaster Brewer
- Joined
- Oct 8, 2011
- Messages
- 929
- Reaction score
- 0
Beersmith is great at documenting and storing recipes. Beersmith provides almost every calculator a brewer might conceivably need while developing or executing a recipe. The new look and feel is what people expect in a modern windows app (Win7 / Office 2007-ish).
Other than providing support for new techniques that develop (eg. no-chill) and other new "lazy brew" methods, its hard to envision what more BeerSmith could do regarding defining recipes.
I think there are two (maybe three) areas where BeerSmith could expand:
[list type=decimal]
[*] Features to support the recipe development PROCESS (separate from simply documenting the recipe)---recipe version control and comparison, reasons for changes, etc.
[*] Features to support brewhouse process control --- expanding the brewlog from "receipe on date" to documenting outputs of each process step, process measurements, etc.
[*]Streamlined UI and tighter integration of the calculators and the data entry forms--- difficult to summarize in a phrase.
[/list]
Recipe Development:
Developing a recipe involves lots of trial and error. Its important to be able to see the changes from one step to the next. Many people have touched on this, and I've seen Brad's responses. I don't think the current work-around of appending the version number to the recipe name is sufficient. But, I wanted to highlight it again...as I think it could be a key differentiator from alternative products.
Bewing process control:
A "recipe" doesn't really define the output of the brewing process. Each step in the process has the recipe intent as an input, but the output of every step is SG/Temp/Color/Volume/odor/taste/conversion%/etc, recipe alterations/substitutions, mistakes, etc. At every point in the process there is something that can be documented and perhaps used to adjust either the recipe of the brewhouse "procedures" as needed...depending on the final outcome (good / bad). THIS is the normal intent of a brewlog (outside of beersmith).
For example, a mash profile doesn't define an expected SG for first runnings, or SG of the mash after sparging. However, that first-runnings SG defines the conversion efficiency of my mashing process. The SG of the unused wort (left in the mash after sparging) defines my extract efficiency. There's nothing in Beersmith that drives me to take these measurements, nor does it provide a place to record or monitor these measurements. Without them, though, how do I know what part of my process needs improvement? Efficiency into the boil kettle by itself doesn't point to the part of the process that's lacking.
Collecting this data implies a need to analyze it, too. Pretty charts and graphs, filtering, ...etc.
There are lots of ways this could be done, but I think the recipe and the brewday should be separate concepts...that are LINKED rather than combined. This leads into....
UI Steamlining / Integration
The process outputs (measured/actual data points) make the recipe form overly busy, and could be considered confusing. I think the recipe should document the intended profile (color, ABV, IBU, OG/FG, body, etc), and leave the process documentation to that discussed above. This would clean up the recipe form significantly---only documenting "ideal" leaving actual for an alternative location. EG: They could be linked with a "batches" list to entries in the brewlog, by recipe version.
Secondly, when working with the recipe form frequently we substitute one ingredient for another. This is often done with the intent of holding some constancy (IBU, OG contribution, etc). There are calculators available for working all this out, but I have to go use them manually. Hops are a good example that has been mentioned before. There are calculators for age and ibu, but if I make a substitution I have to use the age/ibu calculators to work out how to alter the hop weight additions to hold a constant IBU. Obviously, similar examples could be made for Grains, water additions, etc.
A "Prepare to brew recipe" step involves checking inventory, and possibly altering it slightly based on "on hand" inventory...even if that just means adjusting for hop age. Flagging these things based on on-hand quantities and "offering" to substitute would be useful.
Entering SG at a temperature: 1.046@118 automatically adjusts the SG to 60F (or whatever my calibration temp is).
whew! Well, that's my ramblings....lots or broad concepts that would need lots of flushing out for sure....
I think the key point in all of it is to allow the brewer to spend more time doing (thinking and brewing) and less time just manipulating the tool while providing all the benefits that a high-powered multi-core CPU can provide (and minimize the detractions that a database/forms driven application is prone to).
Other than providing support for new techniques that develop (eg. no-chill) and other new "lazy brew" methods, its hard to envision what more BeerSmith could do regarding defining recipes.
I think there are two (maybe three) areas where BeerSmith could expand:
[list type=decimal]
[*] Features to support the recipe development PROCESS (separate from simply documenting the recipe)---recipe version control and comparison, reasons for changes, etc.
[*] Features to support brewhouse process control --- expanding the brewlog from "receipe on date" to documenting outputs of each process step, process measurements, etc.
[*]Streamlined UI and tighter integration of the calculators and the data entry forms--- difficult to summarize in a phrase.
[/list]
Recipe Development:
Developing a recipe involves lots of trial and error. Its important to be able to see the changes from one step to the next. Many people have touched on this, and I've seen Brad's responses. I don't think the current work-around of appending the version number to the recipe name is sufficient. But, I wanted to highlight it again...as I think it could be a key differentiator from alternative products.
Bewing process control:
A "recipe" doesn't really define the output of the brewing process. Each step in the process has the recipe intent as an input, but the output of every step is SG/Temp/Color/Volume/odor/taste/conversion%/etc, recipe alterations/substitutions, mistakes, etc. At every point in the process there is something that can be documented and perhaps used to adjust either the recipe of the brewhouse "procedures" as needed...depending on the final outcome (good / bad). THIS is the normal intent of a brewlog (outside of beersmith).
For example, a mash profile doesn't define an expected SG for first runnings, or SG of the mash after sparging. However, that first-runnings SG defines the conversion efficiency of my mashing process. The SG of the unused wort (left in the mash after sparging) defines my extract efficiency. There's nothing in Beersmith that drives me to take these measurements, nor does it provide a place to record or monitor these measurements. Without them, though, how do I know what part of my process needs improvement? Efficiency into the boil kettle by itself doesn't point to the part of the process that's lacking.
Collecting this data implies a need to analyze it, too. Pretty charts and graphs, filtering, ...etc.
There are lots of ways this could be done, but I think the recipe and the brewday should be separate concepts...that are LINKED rather than combined. This leads into....
UI Steamlining / Integration
The process outputs (measured/actual data points) make the recipe form overly busy, and could be considered confusing. I think the recipe should document the intended profile (color, ABV, IBU, OG/FG, body, etc), and leave the process documentation to that discussed above. This would clean up the recipe form significantly---only documenting "ideal" leaving actual for an alternative location. EG: They could be linked with a "batches" list to entries in the brewlog, by recipe version.
Secondly, when working with the recipe form frequently we substitute one ingredient for another. This is often done with the intent of holding some constancy (IBU, OG contribution, etc). There are calculators available for working all this out, but I have to go use them manually. Hops are a good example that has been mentioned before. There are calculators for age and ibu, but if I make a substitution I have to use the age/ibu calculators to work out how to alter the hop weight additions to hold a constant IBU. Obviously, similar examples could be made for Grains, water additions, etc.
A "Prepare to brew recipe" step involves checking inventory, and possibly altering it slightly based on "on hand" inventory...even if that just means adjusting for hop age. Flagging these things based on on-hand quantities and "offering" to substitute would be useful.
Entering SG at a temperature: 1.046@118 automatically adjusts the SG to 60F (or whatever my calibration temp is).
whew! Well, that's my ramblings....lots or broad concepts that would need lots of flushing out for sure....
I think the key point in all of it is to allow the brewer to spend more time doing (thinking and brewing) and less time just manipulating the tool while providing all the benefits that a high-powered multi-core CPU can provide (and minimize the detractions that a database/forms driven application is prone to).
