Thanks Sumner
with that further detail I now get it a lot more. I’ve already invested in script debugger as I think applescript might become more important to me so I’ll look at the tinderbox dictionary. Inspecting the word dictionary was helpful to get me going.
I use shortcuts on my phone but will have to investigate more on my mac and the other ways of accessing were unknow to me before you pointed them out.
thanks for your help
aTbRef’s notes on AppleScript are here: Applescript.
I commend AppleScript Debugger (AD). It’s not cheap (edu discounts are available), but I find it makes AppleScript far more accessible. Apple’s own AppleScript tools have long remained unchanged as part of deliberate neglect and lack some of AD depth. For most us, I suspect, AD had more depth than we need. But we don’t have to use every menu in an app to get value from it. 
. I keep my AD updated, even though my use is now occasional.
This is a very common approach with DEVONthink. Recall, too, that it’s not necessary to use DEVONthink’s internal editing features. Instead, using DEVONthink as the repository and then use “Open With” to temporarily open a document into an editor or app that is more adept than DEVONthink for handling that particular file type. (Personally, I never edit documents in DEVONthink, despite having used DEVONthink extensively for as long as it’s been on the market. I always send the document from the database into external apps.)
There’s some suggestions upstream of this that call out literally dozens of apps as candidates for a toolbox for daily use. I would tread carefully, and guard your budgets: time and money and patience.
Word of advice. You do NOT want to import the raw material into Tinderbox.
Wow - a lot of different levels to consider
I started using Tinderbox in 2022 but drifted away. I did just dive in as is often recommended but I think I got caught out by not knowing what was possible. Which meant I did not really know what questions to ask either in this forum or of the the various documents that help. I didn’t know what I didn’t know.
I’ve come full circle mainly after reading the tinderbox way. Almost two books in one really. One about using Tinderbox specifically and one about the whole domain that tinderbox is trying to be a support tool for. I loved the book and have now read it twice. So I now have the beginning of a sense of why use Tinderbox (and when not to), how Tinderbox works and how to work it.
I might rephrase slightly Map view vs. outline view thinking and say it as thinking with Map view vs. thinking with outline view and enrich it a little with not just views but also some of the other significant Tinderbox components such as attributes, containers, agents, prototypes etc. That’s what I missed through ignorance first time round.
As an aside my experience of people using something like MS Word is that most people use it in an impoverished way. I think for two intertwined reasons mainly. First because they are unaware of the rich capabilities it has and second because it takes a certain programming frame of mind to understand and utilise those capabilities. Most people still produce ok documents but nothing like what is possible. That may also apply to Tinderbox and also to some of the apps you list below.
your next few points:
seem to be the outline of an approach to using Tinderbox at a high level which is most helpful.
This community is pretty amazing. This thread is an example but having read many others I’m in awe of the level of support given to people such as myself. And thanks too for the invite to your patron session although I’m in the UK so would be joining at 2am my time so sadly I will miss out on that.
Your apps list is pretty extensive and a number of those also have that sense to me as I described above for Tinderbox. i.e. why use app x (and when not to), how app x works and how to work it. To add to that list I already use keyboard maestro and Alfred and both of those require those same questions to be faced and also somewhat of a programmer’s mind.
Finally turning to one of your first points - work backward from the type of contribution I wanted to make, i.e., I focussed on the outputs and thinking through through the inputs that I needed to get there. That’s definitely how I’ve ended up back with Tinderbox. What I would add is that in between the desired output and the required inputs is what I would describe as relating (connecting various things together in different ways) and computing (reasoning and creating with the inputs, and relationships). The connecting, reasoning and creating is where I am hoping Tinderbox will be really helpful for me. I got hung up on zettelkasten for a while but your video with the smart notes author helped me to understand it’s not so much the note taking as the connecting, reasoning and creating process that is the difference that makes a difference.
Might I suggest that, instead of using ChatGPT, you give Google’s new NotebookLM a try. The advantage of this AI program is that it only works with material which you submit to it, so any queries you run will return results from your own work. I tried ChatGPT soon after it was released and the experience was significantly less than inspiring. Asking some specific questions, I received adequate responses; but when I requested citations so I could read original papers that had been drawn upon by ChatGPT, I was given a bunch of fictitious titles for studies that didn’t exist! Checking with one cited author, Dr. Edvard Moser, I had my suspicions confirmed: none of the articles he had been cited as having written had ever actually existed. ChatGPT was simply making things up and pretending to have reference materials to back up its answers — and when I tried to press this AI on the matter, it insisted the papers it had cited existed and that perhaps they had simply been retracted. That’s not very likely, of course, given that Dr. Moser is a Nobel Laureate.
Where I’ve found NotebookLM really helpful is in finding gaps and shortcomings in my own research: If I receive an inadequate answer to a query, I know that I have not addressed that topic in enough depth — but by checking the citations NotebookLM gives, I can find precisely where I need to develop my material more fully, and can then expand my research exactly where further work on a topic fits best.
Thanks for the reference to NotebookLM which I didn’t know of.
Whilst not an academic I do set great store by papers rather than newspapers and blogs etc. I apply this to my work with children that have neurologically rooted movement issues, to my own health which has deteriorated significantly and unexpectedly and to the project I refer to above.
Wih the introduction of chatGPT plugins and the scholar plugin in particular I have found chatGPT to be much more effective in its output.
Unfortunately I have had to be in and out of hospital over the last few months with some rare and unusual issues related to my arteries. I used chatGPT with the scholar plugin to research the condition in general and also a particular operation. Then I checked that research out with the head of vascular surgery at a leading hospital here in the UK (luckily he is my son in law). He was surprised by the accuracy and detail of the material I had got. I don’t want to generalise from one example but it was personally reassuring for me.
I did a simple test of using AppleScript in a Shortcut as a way to jump from Tinderbox to a bookmark within a Word document. Haven’t tried it at scale, as lately I don’t use Word that much, but I think it is quite practical, very likely easier than trying to convert lots of existing Word files to pdf, etc.
I added three String type user attributes as displayed attributes in a WordRef prototype. DocPath is populated in the WordRef prototype on the assumption most notes will refer to Word docs in the same path (that path, of course, needs to be changed to incorporate the correct user name on another machine). Note 1, Note 2, and Note 3 use that prototype. DocName and Bookmark are entered in each of the individual notes, which each inherit the DocPath from the prototype (unless changed locally in a note).
This script is placed in a Run AppleScript action in Shortcuts.
tell front document of application "Tinderbox 9"
tell selected note
set docPath to value of attribute "DocPath"
set docName to value of attribute "DocName"
set bookmarkName to value of attribute "Bookmark"
end tell
end tell
set pathAndName to docPath & "/" & docName
tell application "Microsoft Word"
activate -- shift GUI focus to Word
open pathAndName
set bkMarks to bookmarks of active document whose name is bookmarkName
try
select (item 1 of bkMarks)
end try
end tell
The working Shortcut is here (click the link using Safari to open it). For easy access Shortcuts allows you to pin it to the menu bar here (click the circled i):
Thank you so much Sumner.
I already really appreciate the knowledge and lengths this community goes to in helping others.
Yes, good points. You may want to watch the video from Saturday: Tinderbox Meetup Saturday 13 JAN 24 Video: Project Orientation - Map View vs. Outline View - #2 by satikusala. We delved into map view vs. outline view. Good conversation. Critial Tip:
Map View: Maps are built from notes and aliases that are that are in a single container (which could be the root). The second you put a note into a container, i.e., nest it into an outline hierarchy, its positioning in the original map view will get lost as it is adopting a new relationship within the new container. I’ve found that as projects get bigger and bigger my use of map view changes…I rely on visualizing smaller and smaller parts of the project and use aliases in the map view rather than original notes. This brings up a new challenge as the links between original notes and their alias (for many good reasons) don’t automatically regenerate; you need to use action code if you want them. Summary: Map view is AWESOME, but its use requires some thoughtful consideration in larger files.
Outline View: Fantastic for organizing and structuring your writing and resources. Especially if you keep in mind that the nested layers equate to HTML headings, e.g., root is H1, next layer is H2, not layer is H3, and so one. Once you figure this out, you leverage this in your published document structure to the web, Word, or Google Docs. Note that you can use an action code to reset these layers on the fly. Let’s say you have a note that is 10 levels in from the root, when you go to publish, you can have Tinderbox take the top level of your project folder, which is at level 10 from your root, and make it H0 (your title page) and then progress from 1, 2, 3, and so on within the specific project tree. This took me quite a long time to figure out, but once I did, it revolutionized my use of outline view.
Another Tech Tip: Keep your media files (images, video, audio) on your hard drive and pull them into your files with attributes and export code. You certainly can pull images into Tinderbox, that is fine, but if you goal is publication and output, I’ve found it is most efficient (cognitively and practically) to maintain a media director and have Tinderbox link to the paths of these files (this is why I develop the TBXConfig note concept that maintains the general paths that every note can draw upon). More on this later, if you’d like.
Where I’ve found map view useful is making several smaller maps with aliases, such as in the project below, where I mapped out the relationship of variables in over 50 technology adoption theories.
My call is Friday at 6:00 AM PST, not 6:00 PM PST, so that would be 2:00 PM for you, not 2:00 AM.
Yes! This is why I refined my 5Cs approach (Collection, curration, creation, collaboration, and contribution). Collection is input, contribution is output. Curration, creation, and collaboration lead to more collection and refinement of the notes, which ultimately leads to your being able to contribute your insights in whatever output you want (doc, spreadsheet, podcast, video, etc.).
Thanks for your thoughts Michael
I did take the time to watch the meetup video and actually the Bryan Jenks video that followed.
Both were fascinating but for very different reasons. I’ll hold off my thoughts on Bryan’s but the meetup really helped me clarify some things.
Having coding standards seems important as things grow in complexity. In fact, it seems to go beyond coding standards to other conventions too. When writing Python code we often use the expression “pythonic” which for me fits into another way of evaluating which is:
is it effective - it does what it aims to do
is it efficient - it does it with the least use of resources (e.g. use an edict if change is infrequent)
is it elegant - this is the pythonic bit I think - beautiful code - maybe the tinderbox way?
And I think that evaluating with those three can be applied to creating and using views, action code, use of adornments vs containers, where and how to store assets etc. To write pythonic code seems to come from experience but also very much from experienced “pythonistas” and it seems to me that’s what this forum helps to bring.
One of the things that came out of the meetup for me was about maintenance through time. Where is the code that updates the week number was one of the issues and provided a good example.
Another was the issue of DRY (don’t repeat yourself) came up when building a set of agents. Whilst not explicitly mentioned it seems like there are patterns to be made explicit that can then be used repeatedly. In a few of the Tinderbox videos I’ve watched a $Type attribute seems to be commonly used.
A final thought is testing. The Tinderbox Way refers to the transformation in the underlying code once tests where systematically written and used. I haven’t seen that yet at the level of the Tinderbox app itself.
Maybe I’m leaning too much towards a developer view here but It’s probably better for me to bring it up now rather than when I am getting lost in a a few thousand notes and wondering what I’ve done.
The countervailing force here is what developers call YAGNI — “you ain’t gonna need it.” It’s tempting, but often inefficient, to try to anticipate now what you’re going to want when you have a few thousand notes. Some things, of course, you can foresee!
But it’s easy to read too much into where you think you are headed, which is seldom exactly where you will end up.
Tinderbox does its best to make it possible — even easy — to add functionality and structure to those thousand notes, even if you didn’t anticipate things working that way. So, plan ahead — but don’t overthink.
Love this…“Is it effective? Is it efficient? Is it elegant?”
Absolutely! In the forum we often refer to this as “incremental formalization.”
Love this! Will use it in the future. Is there a citation I can refer to?
I’ve not really seen others use this yet; I believe this is a conversion I started within my process and has manifested itself in my videos. For me, the $Type trigger is REALLY important, it is one step removed from $Prototypes and triggers many of my underlying template inclusion methods. I can explain later if you’re interested.
Yes. Yes. Yes. Testing of close and retesting within different contexts is so crucial. This is something that has taken me a long time to really grokked. @mwra has been constantly reinforcing this for me and the community “Use smaller test files. I isolate the behavior you want and test it.” But this also goes beyond testing to “Build code in incremntal bocks.” Test the individual pieces and pull them together. As you pull the pieces together, it is easier to find what piece may not be working within a given context if the functions are in different blocks of capability.
If we write a small test, the first comes along for free. By paring away what’s not needed for a test, the focus of the problem becomes clearer. Indeed, occasionally, just the thinking about hoe to make the text draws forth the nature of the problem. Especially in larger, mature, documents there is lots going on: even with minimal automation, there is lots of text and lots of notes populating the view. So in a small test there is also less business in the UI allowing the mind to focus on the problem at hand.
We tend to feel “one more try, that should fix it” forgetting the many failed previous attempts to ‘just’ fix the problem. Doing a separate test might seem to be breaking one’s flow. But, abstracting the problem into a test document gives focus. At worst, it shows the problem isn’t even what we thought it was, so we can start to look at a different test scenario.
DRY came from a book called “the pragmatic programmer” I think. Quite old now but very well worth studying.
I guess I have watched mainly your videos Michael 
hence the $Type observation. I guess questions would be how do you decide when to use a prototype and when $Type? or maybe also when not to use each? are there other things that fit in this area
In case everyone looking into DRY didn’t already come across this …
But I see there’s also WET!
And DAMP.
And AHA.
Here is a great example. $Prototye==“pMedia”. I use pMedia to distinguish media notes from the notes. $Type== “Figure,” or “Image,” or “Audio,” or “Video,” or “Table”. They type value will trigger different templating renderings. For video, I have sub-time: VideoLocal, YouTube Embedded, “VimeoEmbeded,” and “KalturaEmbeded,” all of which service up different code to properly render the videos.
This is just one of several uses I have for $Type.
To be clear, $Type is a user attribute. As it’s not a system attribute, you can call it what you like of your system. That said ‘Type’ is nicely descriptive.
The underlying point is that if you see an attribute referred to a lot and it isn’t a system attribute (I’ve a list of them you can check here) then people are talking about a user attribute and so you’ll need to create such an attribute it in your own TBX documents to use methods/code based around such attributes. If in doubt about such attributes, just ask; the name might be obvious but it might be less clear the data type. If there’s a demo file using the attribute you can open the Document Inspector User tab and see the configuration.
HTH
For example, including $Type, some of my files have a few hundred, if not more, user attributes.
