Ziplink Troubles

Q & A - getting started with Tinderbox
1

When using Ziplinks, I’ve noticed two things. The first is a bug, the second is an unmet expectation.

  1. The bug. The ziplinks seem to drift off, so to speak. If I create a table and then place a ziplink on the column title, after adding a few rows and a few more tables beneath, I find that the ziplink will have drifted. E.g. If I create
    Fruits and [[Vegetables]]
    After adding a few more rows to the table, the ziplink moves to
    Fruits a[[nd Vegeta]]bles

But it still points to the same destination note. In this case - Vegetables.

  1. The unmet expectation. When I create a ziplink in a prototype in the Text field, they’re not created in the notes where I apply the prototype. I thought this would have been the case, but not.
2

OK, it’s a little unclear what you mean by ‘ziplink’ here, as there are not links that are ‘ziplinks’ only text links created by the ‘zip’ method, essentially the wiki-derived [[... style of notation. but once created you have a link that cannot (except by its creator) be known to be a zip-made link to one made by other means.

At this point you now have text “Fruits and Vegetables” where the word ‘Vegetables’ is the anchor of a text link to the note called “Vegetables”.

I can’t recreate the effect but I can guess the cause, which does look like a glitch. Essentially when the new table structure is added, it is confusing the code that updates the the drawing of the link anchors in text. Note: Tinderbox is a hypertext app stores links in a discrete linkbase separate from the notes; this is in comparison to a web/wiki based app where the link is embedded into the actual text. The anchor position should get updated. the fact is has just emerged probably reflects the fact this the first time i can recall anyone using a table in note text. Tinderbox isn’t a word processor although it has some such affordances—such a tables—via the underlying apple frameworks used to make the app.

The unmet explanation is explained in terms of a number of false assumptions. First there is no such thing as a discrete thing called a ‘ziplink’. That simple refers to a method of making a text link via typing as opposed to other methods.

When you set a prototype for a note, it inherits the prototype’s $Text only if the note currently has no $Text. This transfer occurs once only. So, if the prototype’s $Text is changed it has no effect on the $Text of the notes using the prototype. At the same time, you will have seen above that links aren’t stored ‘in’ text and links aren’t inherited form prototypes. thus even if you use the zip method and make a text link in the $Text of prototype, you should expect it to be inherited.

I think the confusion here is thinking Tinderbox is a web/wiki clone. In short: it is not. It is a much richer hypertextual tool that can create HTML (amongst other things). I’m not sure it’s stated anywhere that links aren’t inherited, because from with the app context one wouldn’t expect that, but clearly is used to web/wiki-based work where links are only possible via embedded code in text, one might think otherwise.

Meanwhile, Issue #1 looks like a glitch, so I’d contact formal Tech Support (tinderbox@eastgate.com) so you can explain the detail of re-creating the ‘moving anchor text’ problem: I couldn’t re-create it from your description.

So if #1 turns out to be an issue, any fix will need a new release. #2 is simply a case of getting use to Tinderbox’s linking and not thinking in terms of writing HTML/wiki code.

2 Likes
3

I’m curious, @fidel, what are you trying to use tables for?

Personally, I’ve found using tables in the body of the $Text to be extremely counterproductive. Essentially you intermix content with structure, which in the end creates havoc on the idea of repurposing your content, your thought and your work.

Are the tables to help you

  • think through ideas and content?
  • evaluate meta data about a concept?
  • include a report in output?
  • some other reason?

You can get the effect of tables in many ways within Tinderbox, e.g., table plots on maps, Column View, Attribute Browser, and templates. These are the primary ways.

If you think about it a table is nothing more than a structured collection of text (and possibly media, e.g., images). The most effective way to store text that you’d want to structure into a table, or any other output, is in an attribute (remember $Text and $Name are attributes). You still all your value in attributes and then you can Tinderbox’s action code and export code iterative through the values within your attributes to construct your tables for you. Again, this can be done in map view, column view, attribute view, and with templates. I’ll admit, it can take a bit of abstraction thinking to wrap your head around this, but once you’ve groked it, you’re off to the races.

Perhaps we can make working with tables the subject of this weekend’s meeutp.

4

I’d not considered text links bequeathed by prototypes, and will look into the question.

1 Like
5

What time is the meetup this weekend? I’d like to attend if possible.

I have attached two screenshots to explain what I’m using the tables for. The first is a template I found in a book on the craft of writing. The second is my attempt to recreate that template in a Tinderbox file. I want to slowly build a database over time where I analyze films according to this table, and put the analysis in a massive TBX database so I can search for relevant information over time. Does this use case make sense? How could I do it without using tables?

Thank you.

Screenshot 2023-02-09 at 15.59.42
Screenshot 2023-02-09 at 15.59.421218×1290 162 KB

Screenshot 2023-02-09 at 16.07.28
Screenshot 2023-02-09 at 16.07.281920×995 113 KB

6

The meetups are noon Eastern time, 9 AM Pacific, 1700 in London.

Those tables look great, but that’s not the way I’d do this in Tinderbox! Remember: Tinderbox is a tool for notes — and notes are informal jottings, not presentations. You can assemble notes into presentations that look like these tables, but you don’t want to write in tables, which are finicky writing spaces. (Look at your example: are names in the cast centered, or not? Why does Samwise use his full name, but not Meriadoc? Why is Saruman a Wildcard and not an Impact?

OK: some of that is doodling around, but it’s easy to imagine other things you’d want to make notes about. Merry and Pippin: why do we need two fools? Wouldn’t one suffice? How do they differ? (This is one area, for example, where the Peter Jackson crew would have benefited from better notes. Merry and Pippin are very different in the book — and even more distinct, I think, to a reader steeped in English rather than American or Kiwi fiction. In the movie, Merry is much taller!)

So: the way I’d start is to break your Story World Guide into separate notes for Cast, Story, and so forth. Then, each table line becomes a paragraph. Or, each table line becomes a note inside CAST.

7

In addition, read up on attributes: see here and here. They are akin to database fields, though don’t take that literally. Or, if used to paper think of pre-printed library cards. They come with lots of pre-printed boxes: things you might need to record, like Tinderbox system attributes). Flip the card over and add your own boxes on the back (user attributes) or just add freeform notes (a Tinderbox note’s text … which is itself a note attribute).

With information teased out into attribute values the sort of questions @eastgate poses above become much more easily addressed.

8

This Sunday. Tinderbox Meetup Sunday 12th, February 2023: Creating Tables in Tinderbox (Working with inputs and outputs)

It imminently makes sense. I’ve mapped over 2000 companies and nearly 1,000 product features using this method.

As both @eastgate and I note, embedding tables in $Text is not the way to go about this. The way to go about this is to separate notes into atomic ideas, e.g., people, events, and scenes, and then use the power of Tinderbox to find and assemble the piece depending on the type of output you’re looking to generate.

We can certainly discuss this on Sunday.

1 Like
9

I think this statement is shorting Tinderbox. If found, Yes, it is a tool for notes. However, once your notes are in there and curated, you can then assemble your notes into reports, presentations, and so much more within Tinderbox. TInderbox is a note-taking tool, a thinking tool, a creation tool, a contribution (i…e, production) tool (especially when you use it with other tools).

2 Likes
10

This is a good approach. It’s more involved but it yields deeper insights. Spent the morning working on it and had some breakthroughs. Thank you.

1 Like
11

BTW, do you have the source for these screenshots?

12

Yes. I have attached it.
Sample File.tbx (560.6 KB)

13

Sorry I can’t make today’s meet-up, as busy. But from a quick look at the file a couple of quick observations for discussion at the meet:

  • A prototype note can exist anywhere. But how useful is it to have them scattered Around.
  • Making an example note into a prototypes is a common incremental formalisation, but consider making a clean new note with the customisation in the example note. this avoids latter changes to the example whilst forgetting it is also a prototype and unwittingly causing the changes to be inherited by other notes. In a data-heavy project like this I think it pays to have prototypes not doing double duty as both a prototype and a note with actual content.
  • Atomic storage of info. The note “Do they get what they want or don’t they?” holds not one but two lists both ‘tapped’ in plain text and thus the facts therein can only be accessed via regex search.
    • In fairness, this document looks early stage and it’s find to just dump info into a note so it is ‘in’ the document but do think of a strategy to process and remove/require such info.
    • If saving rough input notes consider an archival process such the the old sources don’t get mistakenly detected by queries aimed at processed information. Consider archiving such notes into a separate file, e.g. have a folder for processed source and move notes there when done. At the end of a session select and copy the notes into a separate archive TBX and then delete the copies in the main doc.

Hope you have a useful meet-up.

1 Like
14

We cover @fidel’s topic at length in today’s meetup: Tinderbox Meetup February 12, 2023 Video.

1 Like
15

Thanks. I hope you enjoyed today’s meetup. Got value out it.

16

Sorry I did not reply sooner. The advice you give here is good. It takes a while to implement. But now that I’m implementing it, little by little, I’m seeing the sense behind it. Thank you.

2 Likes
17

I’ve found that thanks to the power of Tinderbox I’m able to study my content from multiple perspectives. It confers extreme customization to organize your thoughts, compare multiple outcomes, and so on.

A good idea is to trial new ideas in a separate temp project file - saves headaches later.

Although it can seem at first Herculean to shred apart and re-assemble your data; it pays off proportionally to the time you devote to it! Good luck on your journey.

3 Likes
18

A good idea is to trial new ideas in a separate temp project file - saves headaches later.

Wow! You’re right. I decided to do this this morning, and it has indeed saved me a lot of headaches. :sweat_smile: Thanks for the great advice. :pray:t5:

3 Likes