I think Claude has some valid points regarding the use and longevity of Excel for the graphing work. I work as an ecological data scientist and if you really want to make sure data are likely going to be readable in the long-term, you write to .csv format. These .csv files don't support formulas and macros though, so Excel files are the next best choice since Excel is probably going to be a thing for the long haul, due to the fact that Microsoft software runs a god-awful number of critical business processes. However, I recently had the lovely experience of having the Office 365 version of Microsoft Word refuse to open a Word file that I created in the late 90s, suggesting there is at least one way MS has already screwed things up just with their
own legacy document formats. Regardless, the disappearance of Excel would mean the disappearance of Microsoft, which seems unimaginable to me, at this point in time. Could one make a similar argument for Airtable? Certainly not.
Airtable has been around for 8 years though, so it's out of the start-up phase and has managed to persist. In this light, I liked the online nature of it and the fact it has an iOS app, and a free account offering. I monitor fruit production on a number of trees around Boulder from which I forage fruit or would like to forage fruit (300+ trees). I mapped each of these trees using an EpiCollect form I made, and I have some R code for taking the mapping data from EpiCollect to create a GoogleMaps layer that I then use when I am biking/walking around town to check on specific trees throughout the growing season. As the growing season progresses, I use the Airtable iOS app to record fruit set data for trees I have mapped (e.g., fruit abundance, likely ripening month), and then pair these data with SG and Total Acidity data from past years so it is efficient during harvest time for me to target high-quality trees that are likely going to have a lot of fruit and be ripe when I show up.
After I made this system for keeping track of trees and juice data from those trees (much as it seems Claude does with a database), I thought it was natural to begin tracking batches I made from those trees in a relational way (e.g., the proportion of each juice used, the blend pH, blend TA, etc.). It was then easy enough to make another relational 'fermentation' table to keep track of fermentation from the batches, including SG, FSU, ABV, etc. through time. I then realized I could code something with R/Shiny to automatically make and display the graphs of SG & FSU through time for each fermenting batch. Up to this point, I was using Excel to manually make graphs. Maybe there's a macro for this? Not having a macro (or knowing of one), I found that manually making these graphs over and over again was tedious. The R/Shiny approach made graph production a simple matter of a click once I developed the code. All this said, if I went to Vegas to bet on it, I would bet Excel will outlive Airtable (and hence my whole approach). Because of this, I have some code I run periodically that downloads the Airtable data and saves it all as a .csv, just in case.
The final reason I like the R/Shiny approach is that I was able to create separate tabs for the Sulfite and Bottling calculations that I found myself routinely doing. It's completely true that these calculations can be readily performed by a good spreadsheet routine, which I believe Claude developed as companion software to his excellent book (which I consulted when making this app, along with Andrew's excellent book). But since I had already gravitated to addressing these other tasks with Airtable and R/Shiny, I figured I would incorporate the functionality in a code-driven way, and put a different UI on the calculations that fit my workstyle a little better. Which is only to say, I think people should use the tools they like best to produce the cider we all enjoy, so long as the different tools produce calculations that are equal and accurate!
Cheers,