Shot record metadata fields

[tadelv]

From the basecamp proposal by Enrique.

We could use the existing "free-form" metadata field to set various information.

Extraction
grinder_dose_weight [Already on DE1]
drink_weight [Already on DE1]
espresso_notes [Already on DE1]
drink_tds [Already on DE1]
drink_ey [Already on DE1]
calc_ey_from_tds
drink_brix
refractometer_model
refractometer_temperature
refractometer_technique
pour_quality

People
my_name [Already on DE1]
drinker_name [Already on DYE v1]

Beverage
beverage_type [Already on DE1, from the profile]
final_beverage_type
added_liquid_type
added_liquid_weight
added_liquidd_temperature
added_liquid_quality

Tasting
enjoyment [Already on DE1]
scentone [flavours, already on DE1 - not sure yet if this will be supported on DYE v3]
tasting_aroma_quality
tasting_aroma_intensity
tasting_aroma_notes
tasting_acidity_quality
tasting_acidity_intensity
tasting_acidity_notes
tasting_sweetness_quality
tasting_sweetness_intensity
tasting_sweetness_notes
tasting_body_quality
tasting_body_intensity
tasting_body_notes
tasting_bitterness_quality
tasting_bitterness_intensity
tasting_bitterness_notes
tasting_astringency_quality
tasting_astringency_intensity
tasting_astringency_notes
tasting_finish_quality
tasting_finish_intensity
tasting_finish_notes
tasting_flavour_quality
tasting_flavour_intensity
tasting_flavour_notes
tasting_overall_quality
tasting_overall_intensity
tasting_overall_notes

These could each have their own top level field in metadata

[ebengoechea]

I would include the following fields explicitly, not in the free-form metadata object, reason being that they are alreay available on the DE1 app either on the main app or DYE, and/or they plan to be used on DYE2 Pulak's redesign. Meaning, they have a specific place in the existing or planned Streamline.js UI.

• grinder_dose_weight [Already on DE1]
• drink_weight [Already on DE1]
• espresso_notes [Already on DE1]
• drink_tds [Already on DE1]
• drink_ey [Already on DE1]
• final_beverage_type: user-defined drink (cappuccino, espreso, latte, americano etc.). Called "final_" not to be confused with the "beverage_type" field that is already available on profiles and has a more restricted meaning. This field is critical for DYE 2 auto-favorites. It would also be good to map the values of these beverage types to the specific machine GHC functions they require (espresso, steam and/or hot water).

[tadelv]

@ebengoechea would final_beverage_type fit on pre-shot workflow data? Or do you specifically want it on after-shot data, because of "happy little accidents", where people decide to make a cappuccino, but it comes out a flat white instead?

Or maybe, have a "intended_beverage_type" (pre) and optionally "final_beverage_type" (post) can override it.

[ebengoechea]

@tadelv Primary workflow would be defining the intention, thus normally before the shot. But it should be modifiable after the shot is made, e.g. in case the user forgot to define it and wants to amend it. Not convinced 2 different variables are needed (intention and reality), can be just one.

[tadelv]

@ebengoechea the term 'workflow' in StreamlineBridge loosely represents the DYE favorite. Therefore I think it would make sense to have a pre-shot version and an after-shot version, both contained in the ShotRecord. One for referencing what was actually made and drunk - and one for referencing what was the intended beverage, as well as an option of repeating it.
Though now that I put that in words, I see your point. If you started with espresso, that turned into a cappuccino, you would want to repeat the cappuccino, not the espresso.

I am currently working on a schema draft, which is why I'm posing these questions here. I'll let you know when a branch is available for closer inspection

[ebengoechea]

@vid Auto-favorites will need to group according to only one of the 2 variables, if there are 2 that should be the after-shot version.

The before- and after-shot logic could apply, on the limit, to many other metadata that is entered manually by the user, like equipment fields. Do you need that added complexity? I'm not convinced.

Dose_out vs drink_yield is also a before and after case, but I think it's different because dose_out affects the app (stop-at-weight) and drink_yield possibly after-shot calculations, so they have to be different.

[tadelv]

I agree, there is no need for extra complexity @ebengoechea .
At least from the repeatability perspective - what was done is what matters. And if it was good, you want to repeat that, not repeat the intent. - At least that's how I explain it

[ebengoechea]

When analyzing how to incorporate these fields in the API, I would contact Miha Rekar from Visualizer and the Bean Conqueror guy. They are the 2 most widely tools that use these metadata and already have connections to the DE1 app one way or another.

[miharekar]

So Shot on Visualizer sort of organically developed and we landed on "old" / current Decent info plus some extra Visualizer stuff: https://github.com/miharekar/visualizer/blob/main/app/models/shot/jsonable.rb

After quick glance that would be: tags, roaster id, coffee bag id, user name, profile url, image url.

Then there's the big one: metadata. This one is a simple hash of key-value pairs, where keys are user defined (each user defines their own keys) and values are strings. It's quite naive, but it works. It's also only available to premium users, or people who self-host Visualizer.

Then there's Beanconqueror. It significantly predates Visualizer and it wasn't always integrated with it. So it has its own "metadata" and lots of it. Not that many BQ users upload to Visualizer so there was never any consolidation requests or anything like that, so the way it currently works I just simply store the entirety of its metadata (which they store in multiple hashes of key-value pairs) and I do not parse it (outside of decent compatible fields) I simply iterate over it when displaying a shot: https://github.com/miharekar/visualizer/blob/1a5dd124934a49a286d4100b31d5aee47238f65c/app/views/shots/_details.html.erb#L134-L142

So here you can decide what to do: either have a new key-values pair fields like Beanconqueror or go deeper and specify everything and then improve parsing on Visualizer to store this in a more structured way. Do keep in mind that this will then also require Airtable syncing changes and some users are very finicky about their airtables 😬

My experience thus far is that every user cares about different things and there is no consensus whatsoever 😅 That's why I went with completely arbitrary metadata and it has worked great so far.