I miss the ability to cross-tabulate notes within TB. Inspired by the recent video on planning as well as a previous discussion cross-tabulation I would like to link the two issues and propose some ideas for enhancing future versions of TB.
The video demonstrates how the attributes of notes can be modified depending on their placement within a tabular arrangement of Adornments in a column and row formation e.g. moving a note from one column to the next will change the row attribute of the note. However, the inverse approach does not work. I cannot use Smart Adornments to automatically place notes matching the overlapping areas of the adornments.
I provide an example below. The column Adornments are Smart Adornments with a query (for Column 1) :
$Column==1 , and similarly for row Adornments (for Row 1):
$Row==1.For each note I set the Key Attributes to $Column and $Row and set the values to the ones displayed in the note titles.
You can see in the example that this does not work. The arrows indicate where the notes should be placed to match both queries. I assume this is because Adornments are treated programmatically as single entities and are not “aware” of their areas of overlap. I’ve experimented a bit and depending on the size and shape of the adornments the notes are either static in the wrong positions (as for this example) or in other cases the notes will jump between the row and column matching positions.
Adding the ability to correctly match and place notes in such a fashion would be a step forward for TB in providing cross-tabulation functionality which is so far missing . In the TB context cross-tabulations could be implemented by collecting notes that matches two separate queries (one for each adornment in this case) and computing a summary of the result which could typically be:
- The notes themselves e.g. paths or on the map simply a stack of notes
- A summary metric such as total matches, mathematical sum of a particular numerical attribute, most frequent word used etc…
Having a list of notes matching two different attribute criteria would already be a step forward. To try an illustrate potential uses (for the writers among you) having for instance a list of characters as rows and chapters or sections in columns would help identify which notes involving a particular character appear where and when in the story as it develops. For the numerical summaries this is similar to the functionality provided by spreadsheet programmes such as MS Excel which refer to them as 2D pivot tables. Below an illustration of the sum total of the cost for each fruit as a function of country taken from a web tutorial.
Since agents can use the inside() function a similar functionality could be built up with the Map View by first defining smart adornments in rows and columns, defining their queries and collecting all notes matching the queries. Agents could then process the result with the help of a revamped inside().
New functionality also means new challenges to solve. From my perspective some wrinkles to address include:
The limited overlap space at the intersection between two smart adornments which limits the number of notes to be displayed. One way to address this would be to automatically move multiple matches into a container of matching notes.
How to display a summary metric. Perhaps the new containers generated can provide a dashboard style display ?
Ultimately - as an idea - it might make sense to revisit the grid feature of adornments and make them smart e.g. associated with a query, able to process matching notes and display a user defined summary.