Agreed, though in aggregate that’s actually fairly experienced user stuff and with quite a few moving parts (templates, queries, etc.). I know from my experience in this community that well-intentioned giving of such a structure to a less experienced user generally comes with a long tail as every tweak of not-yet-understood code causes new issues (and the support/help engendered). I don’t say that to insult anyone new to the app, but without some coding expertise, a lot of more complex aspects of the set-up isn’t obvious before the fact. I still think it’s a nice idea - for those who know how!
As well as the code itself, consider context. Once you’ve 000s of notes, there’s scope for editing one note’s (inherited) rule and then forgetting which. So the learning point is using prototypes to hold/run code where possible and learning to be diligent on selecting the prototype before editing the code (I get the latter wrong to often!).
Looking back at how I gained confidence with the app over the years, most of my code-saving plans gathered dust* whereas putting more time into getting familiar with the action (and export) code syntax and methods has paid off. Plus, solving other folks code problems helps as it throws up genuine problems which one can try and learn from without a success/failure burden. Forums like this, and its predecessors, have driven much of the fine detail of aTbRef and most of the demos I post (tutorials and demos of theoretical scenarios are much more effort).
*Not least because what I generally forgot was to annotate the code somehow. Coming back to some useful code months/years later I found I generally wanted a slightly variant on the code so a copy/paste wasn’t a substitute for understanding what the parts of the code did. Plus, Action code continues to evolve often making some old complex code replaceable with a newer function. Knowing the how/why of the code functions is very useful and I’m very open to suggestions of improvements/omissions of that knowledge in aTbRef.
So a task like “I need to know which left-handed authors collaborated during the early 20C” might be more easily approached by thinking of it in functional terms. "I need a (sorted?) Set of notes (or
List.unique) within a certain date range (
years()?) filtered for a left-handedness (which attribute has that?). This approach makes the moving parts easier to comprehend and also helps spot if you don’t have good enough data. Thus you might $Tags with a value of “left-handed” but in some projects, it might make sense to have $IsLeftHanded (so the default value (false) is correct for most notes) or a $HandedNess (values: left, right, or ambidextrous). The example is deliberately simplistic and unreal but I hope the wider point is thus easier to see, we’re not now looking at sample code so much as the task the code needs to do.