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.
