Hey there, thanks for the update! Looks like you're making good progress. 🚀
I've been thinking about Brain Brew and what it could bring to Ultimate Geography in the long term, so I thought I'd share some long-term ideas. (@aplaice, this might interest you as well.)
The problem
Over the years, users of UG have asked for a number of extra fields to be added to the deck -- most notably IPA and audio pronunciation, but also languages, currencies, flag descriptions (vixillology), links to Wikipedia, etc.
These requests have so far been rejected or put on hold for various reasons, ranging from lack of user interest to maintenance burden (single CSV, long-term support, etc.)
IMO, the key to maintaining a good-quality open source project in the long term is to avoid scope creep - i.e. doing a few things really well rather than doing every possible thing poorly. So I've always been careful about keeping the deck as simple and uncluttered as possible. I prefer to have a vast majority of really happy users rather than to try-but-kinda-fail to satisfy everyone.
Brain Brew will obviously solve the CSV limitation, but the other issues remain... If a field has strong user interest and people are willing to maintain it in the long term, it would make sense to include it in the deck's repository, but then including the field in one or more note templates can still be problematic as it impacts every user. And this still leaves fields that don't have strong user interest or guaranteed long-term support...
If I understand correctly, the Personal Fields feature you've been working on will at least let users add more content to their deck while still allowing them to re-export or re-import it. This is a great step forward, but eventually, we'll need a leap, and I think Brain Brew can make that leap.
What we need
What we need is a way to make decks fully composable, extendable and customisable.
Users need the ability to compose, extend and customise a core deck in whichever way they want without having to actually modify that deck.
Let me start by explaining what I mean by those terms.
Composable
This is about allowing users to create, modify and remove templates from a deck.
A basic example of composability is UG's extended deck (confusing... 😄), which combines fields in two additional templates.
But there are plenty more use cases for composability. Who knows, perhaps somebody would like to have a template with capitals on the front and flags on the back? 🤷 Or perhaps they're sick of seeing Flag similarities and want to remove the field from the flag templates. Or perhaps they'd like to turn the Country info field into a hint field?
Going even further, perhaps a user has extended the deck with another field (see next section) and they'd like to create a template with this field, or modify one of the templates to include the field as additional information?
Extendable
This is about adding new content - i.e. fields, for instance currencies or IPA. Pretty straightforward.
Customisable
This is about customising the styles of the templates (font, color, spacing, etc.) People may find some fonts easier to read, or they may want to add icons to help them understand the cards faster.
A note on translated decks
Translated decks are perfect examples of both extendability and composability: new fields that are combined into new templates. (Technically, the templates in UG are the same for all languages, but that's just because Anki DM doesn't support translating templates.)
How do we get there?
Extension repositories
The way I see it, the first thing we need is a way to store "extended" fields in separate repositories. Yes, perhaps even translated fields!
The advantage of having "extension" repositories separate from the main deck's repository is clear: each "extension" repository would be free to live its life, to have its own maintainers, its own opinions (e.g. stylistic choices, simplified vs traditional Chinese characters, etc.), and so on. If an extension repository were to no longer be maintained or to become too opinionated, people could fork it, create an alternative version of it, or simply stop using it. Either way, the core deck would remain unimpacted.
Deck configuration
Then we need a deck configuration schema that allows:
- referencing a core deck's repository,
- referencing any number of extension repositories,
- adding/removing/replacing the core deck's templates (either with custom templates or with templates provided by an extension repository),
- customising the core deck's styles.
Ideally, the configuration schema would be "Brain Brew-agnostic", in the sense that it would not contain configuration specific to Brain Brew. Some sort of high-level format that could be processed by any tool.
People would share their deck configurations in their own repos, in Gists, or whatever.
Brain Brew support
Obviously Brain Brew would need to support this deck configuration format. 😄
Tooling
Users would then need an easy way to generate decks from shared configurations.
Installing Python, setting up Brain Brew, copying a deck configuration file, running the build command, importing in Anki, etc. It's way too much for most users. We need tooling to help, perhaps a desktop app. That's long, long term... 😄
What do you think?
First, what do you think about the general idea/plan/whatever the hell this was...? 🤣 Am I making any sense? Do you think extension repositories are the way forward? It felt good to try to identify which issues extendability, composability and customisability could resolve for us deck maintainers...
Obviously, this whole thing makes no sense if Brain Brew can't support it. It's already built for composability, so I guess the complexity is more around extendability. Do you think referencing and pulling content from other repositories is doable? I mean, the idea would really be for Brain Brew to run potentially outside of the core deck, in a folder without any content but a configuration file. Is this even plausible?
Hey there, thanks for the update! Looks like you're making good progress. 🚀
I've been thinking about Brain Brew and what it could bring to Ultimate Geography in the long term, so I thought I'd share some long-term ideas. (@aplaice, this might interest you as well.)
The problem
Over the years, users of UG have asked for a number of extra fields to be added to the deck -- most notably IPA and audio pronunciation, but also languages, currencies, flag descriptions (vixillology), links to Wikipedia, etc.
These requests have so far been rejected or put on hold for various reasons, ranging from lack of user interest to maintenance burden (single CSV, long-term support, etc.)
IMO, the key to maintaining a good-quality open source project in the long term is to avoid scope creep - i.e. doing a few things really well rather than doing every possible thing poorly. So I've always been careful about keeping the deck as simple and uncluttered as possible. I prefer to have a vast majority of really happy users rather than to try-but-kinda-fail to satisfy everyone.
Brain Brew will obviously solve the CSV limitation, but the other issues remain... If a field has strong user interest and people are willing to maintain it in the long term, it would make sense to include it in the deck's repository, but then including the field in one or more note templates can still be problematic as it impacts every user. And this still leaves fields that don't have strong user interest or guaranteed long-term support...
If I understand correctly, the Personal Fields feature you've been working on will at least let users add more content to their deck while still allowing them to re-export or re-import it. This is a great step forward, but eventually, we'll need a leap, and I think Brain Brew can make that leap.
What we need
What we need is a way to make decks fully composable, extendable and customisable.
Users need the ability to compose, extend and customise a core deck in whichever way they want without having to actually modify that deck.
Let me start by explaining what I mean by those terms.
Composable
This is about allowing users to create, modify and remove templates from a deck.
A basic example of composability is UG's extended deck (confusing... 😄), which combines fields in two additional templates.
But there are plenty more use cases for composability. Who knows, perhaps somebody would like to have a template with capitals on the front and flags on the back? 🤷 Or perhaps they're sick of seeing Flag similarities and want to remove the field from the flag templates. Or perhaps they'd like to turn the Country info field into a hint field?
Going even further, perhaps a user has extended the deck with another field (see next section) and they'd like to create a template with this field, or modify one of the templates to include the field as additional information?
Extendable
This is about adding new content - i.e. fields, for instance currencies or IPA. Pretty straightforward.
Customisable
This is about customising the styles of the templates (font, color, spacing, etc.) People may find some fonts easier to read, or they may want to add icons to help them understand the cards faster.
A note on translated decks
Translated decks are perfect examples of both extendability and composability: new fields that are combined into new templates. (Technically, the templates in UG are the same for all languages, but that's just because Anki DM doesn't support translating templates.)
How do we get there?
Extension repositories
The way I see it, the first thing we need is a way to store "extended" fields in separate repositories. Yes, perhaps even translated fields!
The advantage of having "extension" repositories separate from the main deck's repository is clear: each "extension" repository would be free to live its life, to have its own maintainers, its own opinions (e.g. stylistic choices, simplified vs traditional Chinese characters, etc.), and so on. If an extension repository were to no longer be maintained or to become too opinionated, people could fork it, create an alternative version of it, or simply stop using it. Either way, the core deck would remain unimpacted.
Deck configuration
Then we need a deck configuration schema that allows:
Ideally, the configuration schema would be "Brain Brew-agnostic", in the sense that it would not contain configuration specific to Brain Brew. Some sort of high-level format that could be processed by any tool.
People would share their deck configurations in their own repos, in Gists, or whatever.
Brain Brew support
Obviously Brain Brew would need to support this deck configuration format. 😄
Tooling
Users would then need an easy way to generate decks from shared configurations.
Installing Python, setting up Brain Brew, copying a deck configuration file, running the build command, importing in Anki, etc. It's way too much for most users. We need tooling to help, perhaps a desktop app. That's long, long term... 😄
What do you think?
First, what do you think about the general idea/plan/whatever the hell this was...? 🤣 Am I making any sense? Do you think extension repositories are the way forward? It felt good to try to identify which issues extendability, composability and customisability could resolve for us deck maintainers...
Obviously, this whole thing makes no sense if Brain Brew can't support it. It's already built for composability, so I guess the complexity is more around extendability. Do you think referencing and pulling content from other repositories is doable? I mean, the idea would really be for Brain Brew to run potentially outside of the core deck, in a folder without any content but a configuration file. Is this even plausible?