At first glance, this seems to me to be a fairly typical (although slightly complex) hierarchical structure. Which would suggest you should be able to create parent-child relations between tables and come up with a common set of screens.
Would you mind showing me some screenshots of your tables so that I can get a better visual?
From top to bottom is the relation.
This case, I have sports in the category, which has 5 categories (a, e, i, o, u). Each sound has a list of vocabulary. Each has definition, translation, etc.
Sorry, I meant your Data Tables. ie. what it looks like in the Glide Data Editor.
I’m trying to get a better sense of how your data is currently structured.
The above suggests that you have separate tables for each of the vowels - is that the case?
Assuming that’s true, then I’d imagine that’s an immediate opportunity to optimise and cut down on the number of distinct screens required. What I mean by that is you could combine all five tables into a single table, and include a column for the vowel. Then create a multiple relation from the parent category, and use that as the source of the collection rather than pointing to 5 distinct tables. Straight away, you will have reduced the number of screens required just in that category by 80%.
If that’s a common theme throughout your App, then with a little bit of data re-organisation you could make your App infinitely easier to manage, and I doubt that you would even need the Independent Screen Configuration functionality at all.