agreed. i also love that @satikusala atikusala has created a method that allows him to work with, manipulate, and analyze data so he can sell the results of his work, but keep the tool for himself.
all three demos today were powerful and inspiring!
2 Likes
Really enjoyed our meeting today as well. I look forward to rewatching the video. Will you be posting a link to the recording at the very top of this thread?
Many thanks
Tom
1 Like
We’ll post the video URL either at the top or bottom of the thread.
1 Like
Hi All, the meetup yesterday was super fun! Learned a ton. I really enjoyed sharing the progress I’ve been making.
I learned a ton
Can’t wait to figure out Alfred integrations. Thanks @amahabal
@CSH Boxpress is way cooool! The immediate takeaway is I learned that you can pull in images for the local drive for export. I’ve applied this to my ecosystem mapping and am now pulling in org and product logos. Here is the code, pulled from a 2017 post:
<img src="file:///Users/Me/Desktop/MyImage.jpg"/>
I created a new attribute OrgLogo and am pulling in the logo name into the string within the HTMLExportTemplate.
I also learned you can trigger macros. This led me to learn that you can write code in a note and then pull the body of the text of that note into a stamp, action, or rule. It is WAY easier to write the code (especially for longer code with conditions) in a note and not in the attribute.
Have some TechDebt now that I have to work on to clean up old stamps and notes to be inline with my new learning. Should be fun.
Putting my kids to work
Someone had a great question about how to share Tinderboxes with someone else in a workflow. Mark suggested using a watch folder. I really like this idea; I’m going to try a couple of others and report back. To this end, I got a hold of Mark today and he was able to quickly help me upgrade to a family license and a couple more Tinderbox licenses set up for me today so that I could put the kids to work. 
.
Objective: streamline the grunt work of pulling in org and product logos, metadata for org and producta.
Solution: High my kids
Execution:
I took the following steps.
- Created a new tinderbox file
- Setup a google drive to share our files and set up the watch folder
- In the file I pasted in all the prototypes from my main TBX
- Create a new prototype in the kid’s TBX with adornments to make it easier for them to create relevant notes, i.e. the Orgs and sub notes related to the Org’s offerings, business practices, use cases, etc. The adornments automatically add metadata to the notes, e.g. $Type, $Cateogry, $Prototype, etc.
- Created a Photoshop file with the logo template (all they need to do is copy and paste in logos, resize them if needed, and export to the watch folder.
- took 20 minutes to show them how to pull data from select websites and reports
That’s it. They are off to the races. They’ll get to learn Tinderbox, over time, make some money from Dad, and I’ll save myself hours!!!
Thanks again for a great session.
3 Likes
Thanks for this interesting follow up and the innovative take about outsourcing elements of document production.
I would suggest that this is actually the norm in Tinderbox, not an exception. Image embedding is quite recent. If you are writing primary for an exported format, I think using externally stored documents is more flexible approach.
Embedding images, unless very small also adds bloat to your doc file (the image bytes have to go somewhere); that does no harm but it’s a bit like going for a walk and having rocks in all your pockets—it’s a choice, so you don’t have to embed.
Embed or not, choose as you see fit. 
This confused me. Action code can call a macro but, within Tinderbox a macro a is slightly different from the second case of use a code note, something I was documenting back as early as 2009. I mention the latter as reading through the supplied and documentation reveals functionality you might never see in a video.
1 Like
Thanks @mra. I agree with you on the bloating. My first attempt was to include the logos in the file. It got HUGE and unwieldy. Linking to the images is much more elegant, streamlined and improves the workflow in many more ways. For example, with the images stored externally to the TBX they are easier for me to manage and use elsewhere, like in a PowerPoint.
As for the Macros, this is probably a vocabulary thing. Like all, I still have a lot to learn.
1 Like
My comment on vocabulary isn’t judgmental. Trying to map incoming perspectives with the internal design concepts of the map is challenging.
I’ll admit I try to nudge people to Tinderbox because within the app context I think it’s reasonably consistent (and I’m always happy in my docs to make it more so). This is for two reasons. Firstly, I think it helps the learner and it makes it easier for them to ask questions. Secondly, moving to think and talk about the app in its own vernacular rubs away at unhelpful comparisons to things not in the room (e.g. other apps). In the latter context, over the years I’ve noticed that the act of internalising the app vocabulary often helps some users ‘get’ aspects they hitherto misunderstood … because they had a perspective which didn’t match the reality of the tool they were using.
There’s no right/wrong or smart/dumb here, just difference.
Glad the info on pictures was of use. Though I use the term bloat I’m’ll admist to some discomfort with an unintended negative there: ‘bigger than needs be’ perhaps.
1 Like
I would like to see this video. (Was not able to attend; had to be out all day, on other matters.) Could you let us know if/ when it is available? Thanks.
1 Like
My comment on vocabulary isn’t judgmental.
I totally agree with you and did not take it as a judgment at all. I also completely agree with,
I’ve noticed that the act of internalising the app vocabulary often helps some users ‘get’ aspects they hitherto misunderstood
As I reflect on the idea of learning any language, like Italian Vs. Japanese or San Franciscan vs. New Yorker, this internalizastion idea is important. In the later, while they both are using English the dialect, style, and cultural influences and differences between the two often make true communication and exchange harder than one may think. There is HUGE value in learning the native language and terms of a tool or a specific culture. As I write this, I think I’ll add to the Tinderbox for Dummies effort a Rosetta Stone guide. This may help the newbie map their familiar terms to the native language of Tinderbox. Again, specific and native terms are important. As laungauges evolve and specfic terms begin to be used the get specific so that those specific terms, once understood, can be packed with meaning, nuance, and clarity of purpose.
2 Likes
I think one useful thing we can do, prompted by this discussion is perhaps map some of the more popular vocabulary misconceptions differences. It can’t be exhaustive, but I have a sense of several discrete ‘types’ of new joiners. It is a mix of terminology, e.g. someone’s ‘card’ is likely a note (or note text? or both?). On a more structural axis, a note is like a database records and its attributes are like a record’s fields. In broad database terms a TBX is like a flat file database - every record has every field, or for the older, less tech folk, like a pre-printed library index card or rollodex item†.
†. Anyone have a good pic of either of those - might be good illustrations for the proposed docs.
Something useful that might flow out of this is a way to tease out these different starting perceptions so that we can, in broad terms say "if your frame of reference is in these term then you want understand these Tinderbox terms as a rough equivalent and these Help docs, aTbRef pages, etc would help you get started. The point being these will likely differ slightly depending on your start point.
Another axis to capture is the stating task perspective: “I got it as it seems cool and I like what others do”, “Need to build a X” (X being zettelkasten, class schedule, reporting matrix, etc.).
Another angle is coders vs non coders. The former are often confused by what Tinderbox doesn’t have, whereas the others are overwhelmed by what it does have. So yet more start paths.
I’ve no idea if such an approach will work but it might and it may be some of the starting points for some groups don’t exist yet, but we’ll know the useful things to write for that.
1 Like
Yes, I think that would be very helpful. I think all you approaches are applicable.
As noted on the Saturday call, the breakthrough for me was to realize that a note could have and in fact does have all attributes. Once you understand this you can then better understand the use of prototype as they are helpful in tailoring the visualization and values of a notes’s attributes for a specific note’s context, as in my case organizations vs. features vs. products vs. benefits ecosystem map project. Put another way, all notes are existentially the same, they’re “stemcells.” It is when you put them into context and into purpose that they become a “heart-cell” “muscle cell,” etc.
I especially like the idea of start with a problem, i.e. a “job to be done.” I encourage people to frame their problem with the three Ps: Big P, Med P, SM P. Here is an example, from my personal project,
Big P - Build an industry ecosystem map (orgs, products, features, benefits, people, etc.)
Med P - How do I use conditional queries and actions to manipulate my notes, i.e. use multiple capabilities to perform an outcome.
SM P - how do I use links to pass data back and forth between notes, i.e. how do I sue a specific capability for a specific discrete purpose
1 Like
Another thing I’m coming to see is lots of people don’t understand (why should they, before the fact) that views are essentially different visualisations of the same underlying data and this cements them unnecessarily into their use of a particular view or subset of views.
So perhaps views also need more explanation in the getting started phase. Not in terms of what they portray but how they simply show the same data in different ways.
1 Like
Yes, I think that is a good idea. That is one of the points I brought up in the demonstration last Saturday. For instance, for me, I use the different view to visualize the same data and by so doing I can 1) see errors in the data that I would have missed by just using one view, and 2) draw, stumble upon, new insights that I would have missed by just staying in one view. Personally, I find a lot of value in the different views. I still have to play more with the crosstabs and hyperbolic view.
1 Like
One AHA moment thanks to what @CSH has done: realizing that prototypes are views. All the attributes defined by the Tinderbox system and user are available to each note and so users can ‘view’ attribute sets using different prototypes. A note need not be fixed to one prototype, different facets of the ‘attribute space’ can be activated by selecting a desired subset. @JFallows has often spoken about the value of the ‘attribute browser’ view. We can activate different ‘attribute browser views’ by swapping out different ‘lenses’ . I come from a programming background - it was easy for me to ‘forget/overlook’ that a prototype doesn’t remove any attributes from a note - it just filters a subset of attributes.
Thought I would ask whether there is a video of the meeting. Would like to check it out! Thanks.
We’re having a little trouble getting it uploaded. @Sylvaticus: could you send me that dropbox link?
At last! The video of this excellent Tinderbox meetup: Tinderbox Meetup 19 September (good!) on Vimeo
2 Likes
Thanks! Am looking forward to checking this out. Will try to be on this Saturday’s session as well.
I can’t emphasize strongly enough how amazing this meetup was! Three demoes that wowed us all! 
NB: @CSH Scott Heftler is going to present again this Saturday.
2 Likes
Me too. Absolutely loved the recording, sorry I missed the meet-up. Not one but three demo, all advancing the existing usefulness of the app. Excellent and 
stuff.
Thanks to everyone, and especially the demonstrators.
1 Like