A new opportunity for cross-tabulations within Tinderbox

Not true, just use a set $InstrumentType and set values accordingly. I’ve been up this blind alley before and tend to start with sets and later add booleans for data strands I pick out later.

I note this as if the extra engineering for this is meeting the cross-cut of two Booleans, there is a solutions. also how does this scale, say for 4 overlapping smart adornments.

Tinderbox is a toolbox and forgiving of false starts in incremental formalisation, e.g. using Booleans where other data types would better serve the task. Again—from experience—the answer is often in using more than one view type and leveraging user attributes.

Thanks for the tip. I understand the use of Sets can be more elegant in this context and less prone to errors.

Unfortunately it does not affect either the results or the nature of my request. If I create the attribute $InstrumentType as you’ve suggested and modify my queries to $InstrumentType.contains("Optical") for one adornment and $InstrumentType.contains("Radar") for the other I still get exactly the same results as above.

Fundamentally I’m proposing that we treat overlapping zones of adornments as the intersection between the two. This is consistent with the use of TB in other few examples I’ve seen, to whit:

  • the recent video from Mark Bernstein on planning with Tinderbox in which the areas of overlap are used to set attributes in the planning notes. This itself was based on another post on the subject
  • the manual positioning of notes across different Adornments to indicate that it belongs or could belong to different categories (e.g. in the TB Book and others)

Or simply make an adornment with $InstrumentType.contains("Optical") | $InstrumentType.contains("Radar"). I say this because I whilst I get the intent, I’ve a sense this scales badly, The issue isn’t what I as a user intend/imagine while happen when I actually use the tool (and as so often, not quite as I imagined I did).

Re the Tinderbox video, I assume you refer to c.7:35 and the adornment grid. The reason $Venue and $Slot values change is due to the adornment’s OnAdd action. A note moved on top on N overlapping adornments will receive the OnAdd of all of those atop which it sit (or partially sits). What follows isn’t an argument for/against, but simply an attempt to explain the status quo (as at v8.2.2).

Uniquely to map view an item is inside an adornment atop which it sits. Consider this map:

and this agent query:

inside("AAA") & inside("BBB") & inside("CCC")

…which, for the above map, matches ‘note 2’.

So, why not the same with smart adornments? As it is, a note can only match one smart adornment; I’m not sure if it is the uppermost (if overlapping). Any note matching the smart adornment’s query is moved atop that adornment. Any note not matching the adornment query is moved off that adornment onto (an unadorned) part of the map, ideally so as not to overlap another note.

Note that an accidental overlap might otherwise trigger an OnAdd action, or a nesting or composite effect. Queries and actions (rules, etc.) fire in outline (i.e. $OutlineOrder) sequence. Thus, whilst on a heavily taxed map you might see a note meeting several smart adornment’s queries bounce around the map, it’s more likely you see the outcome of the end of the agent cycle - i.e. the notes are arranged as per the last query evaluated.

The outcome is that at present a note can’t be placed automatically atop more than one smart adornment. also, given the above, re-tooling to ‘just’ make such an outcome possible is probably a little more complex than presumed, as the map would have to detect all overlaps, generate the merged queries etc. and factor that into the agent cycle.

All of which is not to say the asked for behaviour may/can not happen, that’s up to the developer. I’m just explaining why it may not be a simple/quick request to meet. :slight_smile:

1 Like

We seem to be converging in our understanding and I was indeed referring to the section of the video you mentioned (e.g. changes in $Venue and $Slot depending on the location of the note above intersecting Adornments).

It is already the case that the user either needs to choose to use the OnAdd action(so as to manually and freely move the note around within the map a registering the result of the OnAdd) or work with Adornment queries (which instead automatically move notes matching the query to the Adornment location). So I don’t see a conflict there.

Since TB is not (yet) programmed to handle overlapping Adornments with queries the outcome is along the lines you describe. I’ve experimented a bit and I either see the notes picking a given Adornment where one of the queries matches or jump around between Adornments just as you’ve described.

I cannot judge in detail complexity of accommodating multiple overlapping Adornments with queries. Conceptually it should be reasonable for the following reasons:

  • Tinderbox adornments have a square or rectangular shape making the computation of intersecting areas relatively straightforward even for multiple overlaps.
  • You’ve already pointed out in your post some of the steps that would need to be taken. In areas of intersection TB will be essentially creating a new “virtual” Adornment for these areas, with queries built out of the two (or more) overlapping Adornments. In your case your new query was inside(“AAA”) & inside(“BBB”) & inside(“CCC”) built from the 3 overlapping Adornments and their original queries.

The advantages are the ones I described. In a Map with many notes the user can explore the intersection of criteria visually and quickly by defining the right Adornments and bringing them together in ways that allow for further interpretation and have meaning.

1 Like

My current thinking is that the discussion of cross tabs through overlapping smart adornments, or through smarter grid adornments, is probably a dead end. It could work, but it’s tricky: in particular (as people have foreseen), we’re going to have trouble coping when lots of notes (or very big notes) want to be in the same crosstab cell.

I think we need a new view to do this in a satisfying way — on that is in some ways like the map view, but that isn’t literally the map view. And it’s in some ways like the attribute browser, but it’s not the attribute browser either. That’s a fair amount of engineering, but it’s not our of the question.

So that’s where my current thinking is headed. I can be persuaded. I’d also greatly appreciate plausible example data, both for testing and marketing and because real data might suggest real tasks that ought to be supported.

2 Likes

Oh dear ! I have have perhaps made things more complicated that they should. I think some of the ideas can be implemented by building on the toolbox already provided by TB. Let me try an illustrate this with a somewhat different take.

We focus first on the cross-tabulation function as a new tool (or dimension) within TB to summarise the contents of notes. A promising approach based on an enhanced AB was presented by PaulWalters. A second Map-view approach I thought of over this weekend is illustrated below. It’s based on the same dataset I mention above (using synthetic data) although this time I simply include a count of the notes in each class.

It’s based on a matrix of Agents, one within each of the table cells. It tells us for instance that there are 6 notes which have the $Name of “Batman” and attribute location “Bayport”, 8 notes with “Batman” in Gotham (which is by all accounts where Batman usually does his work in real movies and cartoons), 5 notes with “Batman” in Harfang etc…A similar summary is provided for the other 3 characters (encoded in the note $Name).

I generated this through a matrix of Agents. The upper left cell (“Batman” in “Bayport”) for instance has the query inside(/Notes) & $Name=="Batman" & $Location=="Bayport", the 2nd cell to its right inside(/Notes) & $Name=="Batman" & $Location=="Gotham" and so on throughout the table. I simply set the $DisplayExpression to the count of the Agent matches and could easily add more sophisticated queries and summaries.

If this process could be formalised in TB so that the table and queries for the cells are generated automatically you would have in essence Cross-Tabulation.

Regarding examples from applications, cross-tabulation is for instance a standard tool for analysing the results of surveys. Generally, survey results are presented in aggregate – meaning, you only see a summary of the results, one question at a time (e.g. in the TB world either via the AB view or using Agents for each question). Cross tabulation takes this one step further and enables you to see how one or more notes correlate to each other. This type of analysis can reveal a relationship in your data that is not initially apparent.

There is a nice example from the following website which can serve as an example and inspiration for TB: https://www.surveyking.com/help/cross-tabulation-analysis.

As a 2nd point I come to the discussion on Smart Adornments. This goes further than cross-tabulation and needs to be thought through carefully. I agree that collecting more than a hand-full of notes on overlapping regions will be very difficult to accommodate in a sensible way. I’m wondering whether adding queries to Containers (they are currently note used) might provide a venue to think about ?

1 Like

This is interesting – thank you @mdavidson

It seems to me that container tables and table expressions, etc., can be used already to get part way to the goal. Not sure.

You are right: tables already exist in TB. In addition to container tables + table expressions, the Attribute Browser mode and Outline mode with columns enabled are essentially tables. Unless I’ve missed something a common characteristic of these views is that they provide a note by note view, with notes lined up as rows and attributes as columns. Only the AB mode provide some limited functionality to summarise based on groupings e.g. count for each group etc…

Let me propose some terminology to compare and contrast with the existing capabilities of TB and respond to @eastgate’s request on ideas for marketing the new capabilities: similar to Adornments I suggest we refer to the possible new functionality as Smart Tables ! After some brainstorming I think we can defined Smart Tables to have the following characteristics:

  • The meaning of each row and column is defined and can be referenced by the SmartTable. This contrasts with the current table drawing option in Adorments in which the rows and columns are visual guides only. The current Adornment itself has no concept of columns and rows, only the user as he/she positions the notes on-top of the table.

  • Includes options for automatic labelling of the rows and columns. The labelling of my example cross-tabulation above was done by hand by identifying the unique note names (e.g. the range of $Name) and the range in $Location. I then had to type in carefully (with many “;” spacers) the row and column names. Ideally this is done automatically by TB based on the selected attributes to explore within the SmartTable or based on typical use cases e.g. weekly or monthly calendar.

  • Retrieves the paths of the notes matching the conditions for each cell within the Smart Table and applies a user defined action code (or a default action such as note count which is what I used in my example using an 2D table of Agents). This is at the core of SmartTables. I think that most users would like access to the notes that have been matched to explore further the trends that appear in the SmartTables so it would make sense for each cell to act like an Agent with aliases to the original notes (in essence it would function like a 2D dashboard). On the other hand I also like the action of Adornments operating with queries which can quickly assemble random notes in Map view into structured thoughts. In this case the SmartTable would need to create new containers one level below the current Map view (like bins) in which to assemble the matched notes for each cell. This would be useful for instance for quick brainstorming as the user types in ideas and these are magically moved to the right location.

Thorny questions relating to implementation still remain. Should it be a new view or a special object in a Map view e.g. like composites ? Complexity ? I’m not sure. I hope that by outlining what a Smart Table might look like I make the link to the wishes of other users of TB and their use of this tool.

Have you seen adornment grids? Admittedly, I think they are intended for manual placement of notes, e.g. the grid squares aren’t ‘aware’ of a smart adornment’s query. But, it does seem there is some scaffolding already in place for a table-like adornment. However, given all the ideas outlined, I’m not sure I’d not prefer such cross-tab in a separate view type lest complicated adornment tables put even more load on busy maps.

The latter possible separation also touches on another aspect of such tabulation: its current separation from action code. For instance, AB view is great except there’s no way to access/export value pairs for headings and counts, nor can you hide category items so as to only see the category label. Manual transcribing is involves a lot of scrolling - especially when your 000s of notes in scope.

Thinking of @eastgate’s question about use cases, my recent PhD researches have involved a number of projects with an initial qualitative phase, exploring the data and surfacing structures and themes. this is then followed by a more quantitative phase of collating and tabulating the findings. The latter would have been much easier with a cross-tab method.

For my part, I’m less worried about map use than the ability to do more than put the cross-tab numbers on screen. In a large project, it is very likely these figures (counts and their associated query/category) need to be exported somehow. It might be as simply as placing the data on the clipboard in tab-delim form, or it might be making exportable to the rest of the doc via action code, or combining with export code to export the data as a file.

All that said, despite the above experience in my own work, I’ve not pushed for this aspect of the app. This is because I don’t see evidence that it is something used/wanted by a significant number of users and thus the ROI for a small developer. IOW, I’d probably use such a feature but those of use doing so might be an expensive minority to service. As it is I’d rather, for instance, see Hyperbolic view properly matured before this. Improving the hypertextual tools seems more core to Tinderbox as an app, too. In an ideal world we’d have both :grinning:

1 Like

Good to hear that you too would have benefited from cross-tab methods for your TB-based analyses. It means that there are at least two of us :slightly_smiling_face: Clearly users with only a limited number of notes, or, focusing on visual placement of notes cross-tab functions are overkill. However, I suspect that for users with say 100s if not 1000s of notes, cross-tabs would be a very useful as a tool for summaries, trend analyses, correlation etc…

I’m aware and use adornment grids. They are good visual guides to placing notes and interpretation…that as far as they go. I use them quite often.

I have no idea if I’m (or we) are in a minority. Cross-tabs are a wide-spread general technique to summarise information content and tables are already part of the TB idiomatic expressive possibilities. I’ll let others make that call. A minimalist solution to me with (hopefully) reasonable R & D investment would be to start with smarter tables in adornments building on my previous home-made hand-coded cross-tab example. This would involve

  • the table cells are aware of their row and column cells, and of the row and column headers
  • an easier and more automatic method for labelling the rows and columns by the user rather than the kludgy current method in which empty cells require a “;”
  • the row and column headers can be attributes
  • the cells can have an OnAdd action associated with them
  • agents, notes or containers can easily be aligned to fit within a given cell so as to yield a regular 2D array of notes
  • a method for generating automatically an array of agents

Hey, another person in the space industry using Tinderbox! That’s out of this world.

Admitting that I haven’t read every post above in detail, I’ll quickly add my 2 cents.

Warning! High School math ahead!

When modeling two sets of objects which share an intersecting subset I’ve also reached for adornments with the $Query attribute set and been disappointed that the adornments don’t figure out that a note matching both should be in the overlap of the two adornments. I understand why they don’t yet — this isn’t a trivial problem to solve — but composing adornments did seem like a natural solution at the time.

If I were to implement something like this my approach would be:

  1. Find all of the adornments whose $Query set contains the note in question.
  2. Extract the x_top_r, y_top_r, x_bottom_l, y_bottom_l coordinates for each adornment’s bounding box. (I’m going to assume that notes have a single point coordinate which determines their location, but the below should generalize to rectangular shapes pretty easily.)
  3. Construct a system of linear constraints (pseudocode):
for x_tr, y_tr, x_bl, y_bl in adornment_bbs:
    constrain(x_note <= x_tr)
    constrain(x_note <= y_tr)
    constrain(x_bl <= x_note)
    constrain(y_bl <= x_note)
  1. Solve the system of linear constraints, yielding a bound on the values of x and y which the note can take. Assign the note a set of coordinates freely within the box. If there are other notes in the intersection and you want to avoid covering them entirely, add additional constraints to the system above.

This is a very fast problem to solve using Gaussian elimination. If you want, you can also go the more complex route and add a linear objective function which determines the “best” point to put the note at and solve it with the Simplex algorithm, although I would imagine the constraint systems that Tinderbox would be solving are small and could also be easily optimized with a simple search over the solutions to the linear equations.

Whew! That wasn’t too hard. Looking forward to a constraint-based Tinderbox layout engine, @eastgate! :wink:

Not meaning to be a Luddite – but isn’t it simpler just to use software that was built for cross-tabs?

2 Likes

Interesting factoid: Chris Van Wyk, who pioneered a lot of constraint-based interface stuff when he was working with Knuth, had the room next to mine when we were Swarthmore freshmen.

2 Likes

My thought, since I started reading this thread…
What about R Studio for example? Perhaps TB is not the right (or let’s better say: not the best) tool for this job.

Nevertheless, this thread has a lot of useful and interesting ideas!

2 Likes

Useful to look at the advantages of cross-tabulation within TB

  • Additional and actionable insight into the content and relationships between notes directly within TB.
  • Access between notes and cross-tab is maintained ie. possible to directly scan through the notes contributing to the cross-tab results and interact with them e.g. link them to other concepts, place of top of adornments and so on. This is one of the advantages of the existing AB mode which provides both summarising/grouping capability as well as access to the notes and which a cross-tab in TB should keep. In my cross-tab mock-up I can access all the underlying notes contributing to the results and trends.

Exporting data to outside tools that support cross-tabulation (statistical software such as R, Excel etc…) would not allow for the above and it laborious to repeat for every new question.

And I thought I was the only “space” person in the TB world :slightly_smiling_face:

You’ve provided a concise summary of how to optimise layout for notes and welcome support to the idea of using Adornment overlap in a consistent and expressive way (re. in terms of information and interpretation).

What is required now from my perspective is some testing with mockups (say drawing overlapping Adornments with manually placed variable number of notes) to demonstrate the idea and the challenges. I haven’t done it yet but I agree with @eastgate that many notes and limited overlap area will be a challenge.

I was wondering if for a large number of notes the membership of an Adornment or overlapping Adornments could be implemented using links between the Adornment and the notes matching the query. It could be a step towards “clustering” of note (visually and conceptually).

1 Like

I like the thought of cross tabulation but, IMO it makes more sense in a separate view akin to AB view. In no small part this is due to the fact that the map based approach scales poorly as reflected at the tail of the post above. With 10-20 notes in the grid it gets cluttered (especially if the notes are big enough to read meaningful $Name values) Get to 00s or 000s of notes as in a mature working file and I don’t see how the visual approach works.

Thus, if creating a cross-tab function, ISTM that this is better done in a separate view but with a means to ‘read’ data back to a map. Making the cross-tab values (counts of times or of a given attribute) available to action code means there is scope to use this back in others view (e.g. map) as well as for export.

I know the idea feels right from a visual thinking perspective but my long-term experience of map use is for all bar smaller maps you run out of space. Either everything’s too small to read (icon size and/or zoom level) or there is insufficient screen space to see enough of the map (physical screen size/zoom level). IOW, unless there is a display method that can usefully show more than a few notes the overlapped smart adornment approach seem to be over optimistic as an approach. In our mind’s eye we tend to elide these visual issue of scale; what seems appealing in thought can be less so in a live view.

If things did go down an adornment route, I’d suggest a single gridded adornment (configured via properties pop-over) rather then manually placed overlaps as the latter gets tiresome to construct for more than a few rows/columns.

A further thought or two on the intersecting-smart-adornment approach:

  1. In principle, the set of constraints doesn’t seem onerous, though I’m worried that in practice the intersections are going to be too small to contain the notes they need.

  2. If some notes are large, they might extend from the intended adornment into other adornments where they are not wanted, triggering the wrong OnAdd and OnRemove actions.

  3. Of course, all these issues are under the user’s control. And they’re all readily visible; if your notes are too big, make them smaller!

  4. If we have N adornments in a map, I believe we might have N!/2 intersections to consider. 15 is not a priori an unreasonable number of adornments; 15! is 1e12. I’m pretty sure we can be more clever about this, and we already have quadtrees under the hood; still, this could get nasty in a hurry.

  5. For many analytical tasks, it’s OK to think about timescales of milliseconds or even seconds. A big attribute browser view that classifies a few thousand notes takes a second: that’s not ideal but it’s fine. But the timescale for some map tasks is much shorter; anything that needs to be done during a drag must be done in a millisecond — certainly in less than 10ms.

  6. A deeper issue is that, in Tinderbox, items have a place on the map. This note is here and not there, just as it is big and green, and not small and black. I expect that the objects we’re crosstabing will often need to be aliases of notes that reside somewhere else; that’s a further complication.

  7. I acknowledge that some people dislike the idea that notes have a place and identity, and would prefer a different dispensation.

  8. There’s a separate, but related. request for better coverage of co-occurence, and this might conceivably use the same new view.

  9. New views have significant engineering overhead, but it’s not intolerable. They do have a lot of variance; some new views work quite nicely, others have been less satisfactory. It can be better to isolate experiments.

1 Like

All good points. I suggest to focus on the functionality that is required regardless of implementation in TB. This should include (as per other posts here):

  • The selection of notes to be analysed using cross-tabulation
  • The selection of at least 2 note attributes and their ranges
  • To define what information is required in the cross-tab (e.g. count, average, max, min, most frequent, number of unique notes etc…)
  • To display the cross-tab results
  • To provide the TB user with access to the notes and their contents selected for each cross-tabulation result (e.g. table cell)

I’ve visualised this within TB and then link the function to some options that we proposed for each of these steps. In addition I’ve tried to estimate the R & D footprint for such implementation work and colour coded the options accordingly (with many many caveats as I don’t know the details. In general the close to existing functionality the lower the R & D). The result is provided below:

On the left is a minimalist cross-tab for 2 attributes each attribute with two options (e.g. like a boolean). Further to the right the functionality and then implementation options.

I’ve come to the conclusion that the most efficient implementation could be via the idea of a Super Container or a container of containers which builds on many of the expressive idioms already available in TB. This is illustrated below:

The super container has access to all the notes for the cross-tab analyses and has an updated display option in the note that supports cross-tables. Each cell in the cross-table is a container of it’s own with alias to all contributing notes and displays the cross-tab cell summary based on the user function selected.

The advantage of this approach is that - apart from the details of selecting attributes and the new table functionality and its display - existing TB tools and idioms can be used. It is essentially a TableView summary (improved) which summarises the contents of the notes rather than list them as currently the case.

All to be taken with a grain of salt of course. However I hope that by presenting an outline of an implementation I can give some impetus to zero in on possible implementation of this new functionality.

It will be necessary to use aliases in such a cross tab, unless List or Set type attributes are excluded. Multiple-value type attributes can match more than one cross tab cell, so would require at least one instance in the grid to be an alias. Rather than have a mix of aliases and originals it would make more sense to have all aliases.

If the grid is a container’s viewport, bear in mind that not all the visual affordances are drawn in the viewport.

Not mentioned in the last summary but as important, for analytical work, as other factors is being able to access the cross-tab data via action code, both for use elsewhere and for export. Having to manually copy data or set up a host of new queries just to re-tabulate the cross-tab grids output would be frustrating duplication of effort for the user.