Tinderbox Forum

A Contact can either be a Note, or an Attribute Value, or both. How to best connect them?

Musing about this project I’m re-structuring…

I have Event Notes with a User Attribute ($Player) - a set whose values are derived from a bunch of Contacts/Players Notes.

In structuring the project, I don’t need to see Links between the Events and Players. it’s enough that I can (via Agents) collect Events that test for one or another $Player value. But I keep getting the feeling I could further optimise this 1:1 relationship between a Container of Players and another of Events.

What do those of you building projects involving such 1:1 relationships usually do with that affordance?

I suppose as the project gets more complex, with more Events and perhaps categories of Players or some such granularity, Tinderbox’s own tools will keep pace and I can figure ways to optimise.

Could also set an Agent that will cross-populate Player Notes with the Events they’ve attended.

I’d not build extra structure unless you have a purpose for it. Or, test by testing an agent to one relationship. If it doesn’t yield any useful information, I’d avoid building in more work (automation) that has to be run but doesn’t contribute.

Also, for review, AB view may also help. Remember you can save tabs in a doc so it’s easy to add a fully/partly customised into a doc, get your info and delete until needed again.

I find once I’ve added an agent, I’m always dilatory about deleting it once not needed.

A suggestion is to make a small exploratory doc with the needed customisation and some real or dummy data and list questions you want to resolve and the community here might give you some more focussed suggestions (and even code!).

1 Like

Solid points, thanks. I guess what I’m feeling is some form of “spreadsheet/database withdrawal” symptom, in which the go-to structure is usually an x-y axis link between Event and Player.

As Tbx operates on an Attribute:Value pair structure - although there is a link between the Events and Players, it doesn’t have that cause-effect familiarity (in that sorting/filtering along one axis immediately reveals the values on the other).

As mentioned above though, there is no need to build extra structure unless one needs it - and when it’s needed, Tbx has ample horsepower to help construct whatever devices I might need.

Another way to show that grid relationship is to use outline (y -axis) with column view (x-axis). If you you this a few tips:

  • a tab [sic] remembers its current columns. You can toggle column view on/off and re-showing columns uses the last-used column(s).
  • If a tab is closed the above settings are lost, so consider a hoisted outline with a container or agent listing one attribute and a column for the other. By setting the $Sort for the parent container you can sort on X or Y data. Save the tab and close it when you don’t needed it.
  • if using column view in large outlines, e.g. root level on a large document, it is better to toggle column view off when not needed as it’s more data to draw so depending on your Mac and other things running may make scrolling less responsive than normal. IOW, leaving it no when not needed might be self-inflicted extra load). Tip, see not above about using a separate tab for this tasks—background tabs have no UI impact: rules, etc run but the UI isn’t being drawn/updated until the tab isa selected.
    • The latter is why with a very busy tab, you may see the tab’s label text briefly show in red, which means Tinderbox is forking on initialising the tab (usually the work happens so fast the red text is never seen).

If you want the x-axis to be one value per column and you’ve only 10-15 items you might try out cross-tabs, though the view is mainly meant for numerical and not categorical data, IIRC.

But unless there is only player per Event (or vice versa) you Excel start-point just makes like harder . For instance for even #4 if there are 5 players you have to scan horizontally to find a marker value in the cell, track up to get the column head, back down to the row, track right, etc., all whilst remembering the values already found. That is an area where AB view, if you take a moment to learn it (there is always some learning!) abstracts much of that away.

If you have per-value notes for each discrete player and event, then you can easily use action code (stamp, edict, agent, etc.) to set the second when applying the first. So, if note ‘Event4’ has player value “Player6” your action can look for note ‘Player6’ and give it an event value “Event4”. Or you could choose to use a linking action to link to or from that note. Lots of choices! If doing this , do be aware of the fact that you may be seeding extra values into the global set of notes using $Player or $Event and thus ‘polluting’ existing queries with irrelevant matches. In such a scenario, prototypes are a boon. Even if the prototype itself has no customisation, items using that prototype are essentially an ad hoc selection of items easily found without having to use a multi-term query argument.

Lastly, whilst you might do any/all of the above, I’d just park the ideas until you have a real question. Testing what might be a question is far harder than testing an actual question as success—or the nuance of how successful—is far harder to judge.

If after all that you really, really, need a spreadsheet just export the data to a CSV or Tab-delimited file and opening it in Excel (or Numbers, Google sheets, etc.). You only have to build the export once. Indeed, you don’t ned to emit a file. Just make the template, view the exported data table in the ‘Export’ pane (not the Preview pane) select all (⌘+A), copy (⌘+C), then paste into your spread sheet.


All EXCELLENT points, thanks @mwra! This is exactly the mental exercise I was hoping to engage in.

I’m structuring as I go, and (as advised) parking the ideas I don’t think I’ll need. Designing some tables in Excel/Numbers is a good idea as well, as I can pull together a few basic wireframes to later implement in Tbx.

Thanks for the great reminder on using Prototypes, it’s nuts how many great features are built-in and ready to deploy :smiley:

You can also use cross tabs, depending on what you’re trying to do. I also use table templates for me to get a view of relationships. Finally, to enhance the benefit of one-to-one and especially one-to-many relationships, e.g. a person to multiple events, I use links action code to pass data back and forth. In your context, I’d have one player that would then send a headshot, email address, and categories from that player to the multiple events they’re associated with.

1 Like

Smart idea! I am thinking I’ll set up something that links and sequences Attribute values via Agents, so as to generate minimal redundant data.

Also playing with linking my Events via Attribute value to an external database, as a great deal of my Player Information is superfluous to the Tbx project, and would actually display more practically on a dbase form.

Google sheets is also interesting as an external linkable resource - turns out each cell in a gsheet possesses an unique URL; this could be very useful.