Took me a darned long time - and additionally frustrating as it means focusing on structure for extended periods while (mostly) resisting the temptation to delve in and tweak content - but I’ve finally been able to whittle my diverse UA collection to around 36 common Attributes across all 8 of my key/active Tbx projects. In fact, of these 35 I’m routinely using under 20.
One step closer to total portability of Notes between Projects! Additional benefit is that Rules/Edicts/Agents set up in one project can easily be applied in another… huge timesaver! #humblebrag
Tip: I now maintain an excel file listing my UAs across projects, with the intention to update upon making any edits to the list.
Thanks for that useful feedback. Attribute proliferation is partly an outcome of Tinderbox easy support for incremental formalisation. Pruning back is arguably another layer of the same, albeit it feels like nugatory work. The upside is, as you report, more easily re-usable patterns.
Now action code can make notes, agents, attributes, and attributes, it should be easier to make code to quickly configure a new doc. Functions also make it easier to put the code somewhere accessible via other than the Inspector. In the past we needed to use a pre-configured bare TBX, which can work just as well. But, I think using action code makes it easier to maintain for the long term, if at cost of a little more time/effort at the very start.
One method I use is my TBXConfig note. I use it to store common attributes so that when I copy it into a new file it is easier for me to create quick and add the attributes I need into the new file. Still refining the process, it is getting better. At my worst I was up to about 50 prototypes, 500 attributes, 40 templates, 30 stamps, and 20 functions. I’m down to about 7 common prototypes, 100 attributes, 10 templates, 4 stands, and 7 functions. The refining process has taken a while. I’ve yet to go about and clean up a lot of the kitty litter, maybe some day I will. For now my unused pieces are appendices, unused organs.
Yes, the housekeeping effort was cathartic - it’s interesting (and on occasion, embarrassing lol) going back and looking at the winding paths I’ve taken to get to my current level of Tbx-fu. Housekeeping has also been helping as a refresher of the various tools & techniques I’ve picked up along the way - the TbxConfig file that @satikusala uses, the logging function, my kit of Agents and Rules.
Completely agree about the leverage gained from all the powerful new tools! The way my brain works, I love the way I can start on a new Tbx project as a completely blank slate. I’ve tried templating but it’s so much fun to jump in and purpose-design from scratch, knowing I can dip into a previous project and pull out that 3/16" hex wrench-Agent I built months ago!
I love the TBXConfig file! TBH I had accumulated multiple and differing such config files and cutting down my UA’s was the first step to re-building a fresh and lean one
I’m planning to create and maintain a Tbx project file that only contains my current (and past) TBXConfig Note/s. Hopefully that’ll do the trick in preventing future duplication. I can’t do that sort of work with my Agents/Rules/Stamps, because I’m invariably generating those as I go - and they are usually specific to the task. The ones (some search Agents, or Dashboards) I create that are general-purpose, I’m usually fairly efficient at proliferating across projects. Can’t catch 'em all, of course.
Force of habit - I maintain a lot of my data file housekeeping in a Numbers file that sits in iCloud. My TBX defaults simply occupy a couple sheets in that file.
Visual efficiency - I’m accustomed to scanning large spreadsheets containing disparate text blocks, and have developed a set of syntaxes, cell colouring/commenting, font-wise demarcation, and so on.
To some extent, it’s also old-school caution - I instinctively house-keep app-specific notes externally. Numbers has worked well for this, as it allows multiple discrete tables on a single sheet. These types of mini-databases will never need to be worked on or drilled into for insight, so it works more like an infinite classroom wall.
Note the only the first method allows additional aspects like setting up tabs and/or saved tabes as automation doesn’t currently address those aspects of the documents.
But in terms of setting up notes and adding/configuring user attributes all work. Which any individual uses will be down to personal choice. Those averse to ‘code’ will likely go the specimen file route as essentially you manually configure the features you need then save the file. Those familiar with programming & action code may prefer the latter options. The addition of action code functions means you could have a library note (or the contents of its $Text saved somewhere) that you could run to configure most of your starting needs.
Anyway, my suggestion is pick one method with which you personally feel comfortable and don’t worry if others use a different method. There is no one ‘right’ method!
Haha you’ll notice that I had commented on that thread! Definitely a great idea, but I had since decided to reduce the number of project files I work in, and therefore the excursion involved in getting to grips with Ruby and so on seems not worth the distraction for the benefits, when all I need is an 8x36 spreadsheet. That may change of course
Personally I like the practice of regenerating bits of code; it helps me familiarize myself with syntax and usage scenarios, as well as customize to the need of the day. I’m also envisaging a scenario where I set up my ‘fresh’ layout/structure/geometry in a new project file, then drop the Notes thus far created into a Template file.
