Would be suuuper handy to have folders (including nested folders) to manage Workshop variables; when you get to 50+ variables it gets seriously unmanageable.
It would be cool if they could display in the same way as monocle datasets i.e. sparse naming, with descriptors like ‘clean’ appearing in the path name e.g. clean/dataset_1/
Along with variable organization, variable descriptions (beyond just the name) would be great
Currently at 800+ variables could say it’s a skill issue (jk), but honestly +100 to this request, would love to have this.
800+ 
Have you tried splitting up your workshop app into multiple embedded modules?
In our engineering department we are introducing best practices that a module should be standalone for itself and only communicate through necessary interface variables. This brings couple of benefits to splitting modules
In terms of variable count we currently say
Love this practice. I just spent a couple of hours figuring out how a workshop with a particularly large number of variables works, and it had me thinking along the same lines. How can we break this down to keep things manageable and not require the next engineer to go through the same mental exercise I just did to make a simple update?
Even under 100 variables I believe folders would still be a great feature in addition to this practice. We’ve been trying to manage with naming conventions to group related variables together, but sometimes you just end up with odd combinations or unintuitive names for the sake of appeasing the gods of variable sorting.
Great suggestion! We are currently discussing internally what the best way to do this is.
Yes we are following a similar structure for variable naming. Our structure is we try to set a contextual chain (emphasize is on try):
[o] accounts - filtered by main
[o] accounts - selected
[o] selected account - linked sales
[o] selected account linked sales - filtered above X
… and so on.
Regarding folders for variables, how would you all set them up? Like, which folders would you create? Most likely i‘d create my folders by meaningful scope (a folder per page / layout that serves a specific purpose). But why then not create a separate module for that in first place?
Generally, my opinion is variable folders would rather treat the symptom not the cause. I feel like with embedding sub modules you can keep good control to have only necessary variables for the purpose of the module.
But what are the variables we mostly create? For me, I always need to create a ton of variables to extract a couple of properties from a user selected (single) object. Just to use these string values in filter variables or metric cards or such.
What I would rather prefer to have are enhancements so that we need to create less variables in first place. On example where that already happened is that metric cards by now are capable of directly using a referenced value from a single object (but only for primary value - not secondary…). If this would be supported in more places the count of variables would decrease a lot.
Or improving the usage of structs. For example allowing to fill structs within the no code variable transformation dialog. Structs are actually very cool to group meaningful groups of variables together. But they are too painful to set up. At least I tend to not invest the effort to write a custom ts function. I rather create 5 variables 
And additionally making the retrieval of values from structs more supported (just like with object set properties directly)
Or making buttons conditional visibility smarter (like on sections where you can define the true/false)… today button conditional visibility is always only checking for the false state. This means if you want to have two simple buttons where either one or the other is visible, you always have to create a second (bool negated) version of you conditional variable…
I believe there are many small things that can be improved 
maybe @eric can share some insights on PDs ideas?
These are all great suggestions but since we have things fairly equally distributed between 5 pages, each with 4-7 tabs and a substantial amount of overlays, the app is actually still pretty snappy. Anything that takes more than 2-3 seconds is typically Quiver based, which we’ve learned to avoid at all costs.
With Foundry branching, as long as we have some decent team coordination and work on separate pages, we can still parallelize most of the work. Definitely some room for improvement on rebase quality though.
None of the pages / modules we built are useful elsewhere. We do make use of Object Views and make them fairly rich though, so we’re doing that in that way.
At the end of the day, we don’t really care to look at the variable list as a whole. Navigation of the variables graph through the “Uses” and “Used by” lists is typically enough to debug and understand what’s going on. And we follow a very verbose hierarchical naming convention really similar to what you described in your reply to victor.