Tinderbox provides 8 “Views” of your notes. Which views do you use “frequently”? Lets say, in a typical document, the views you might keep available in tabs or windows. Or the views you activate most often. This is an informal poll. You can vote for as many options as you wish.
0 voters
Now that I’ve figured out in my mind the abstraction that action codes give me I find that I rarely need a map view, that is unless I’m building a visual model that will go into a report. On this note, I’d find map view more useful if there was a “flatten” concept where I could flatten the map view, i.e., visually see and move items within a container on a flat surface. This would enable me to write my reports in outline mode with containers but also visually see the flattened relationships. We’ve discussed this a bit on backstage.
I’ve come to LOVE the Attribute Browser and use it daily. Timeline is awesome for literature review and organizational analysis.
I’ve never seen much need for Chart, so I am unsure how to get value out of it. Treemap has some intrigue, but it too escapes me.
I think the most underrepresented view is hyperbolic. I see the potential, but without filtering or flattening, I find it hard to use.
Frequently: Outline (+ column view), AB view
Regularly: Map,
Infrequently: Hyperbolic view, Timeline
Rarely: Chart, Treemap, Crosstab
Want to use more: Hyperbolic view with link-type filters
Both Outline and AB view allow a column view - IOW showing, as columns, more than the $Name per line item
I’d note a big but here. What gets used is very task-dependent. Map view is the most powerful for early stage exploration but unhelpful at a later stage where scale grows (not enough room to see everything) and or linearisation is needed for output (output is tightly coupled to Outline structure). A lot of my TBX files are tests for other users, e.g. questions in this forum, and unless the issue is specifically Map-based the outline is way faster clearer for putting together a trial/demo. However, for quick exploration of a topic, Map is peerless and despite my relative use it a key part of Tinderbox’s USP.
I keep trying Hyperbolic view but IMO it is feature-incomplete as we need better control of link visibility/inclusion/filtering and of overall scale. In the latter sometime you want to see a lot of notes and labels are of less help. Other time you do want to se titles. A key limit on hyperbolic view use for me is the lack pf a filter you remove link types: be that to filter out notes only linked via unwanted types or simply to not draw that type of link (if the only link), e.g to see where link-typed linkage is not as expected. Sadly the focus keeps going elsewhere and Hyperbolic view sits on the spike. I still maintain it has the potential to be one of the key views. Currently there is a chick and egg in the needed features are missing so its hard to show to the novice its potential power.
Timeline/Treemap/Crosstabs fall in the task-dependent category. Timeline is clearly related to date/time info and is great, though like Map view it works best with small numbers of notes. Crosstabs is the same - for when you need to cross-tabulate (rare for me!) Treemap is much overlooked if doing quantitative work. I guess it lacks a kick-ass demo to give people the ‘aha!’ moment. IIRC within a box (container) each child has equal space, i.e. the $ChildCount is being visualised. But, the value can be any attribute or even an (action code) expression set in the view’s setting’s Treemap Expression (note: that not an attribute).
I suspect treemap is much under-used. If unfamiliar, tale a look at the ‘Actions and Dashboards’ PDF on the Tinderbox Help menu, starting at page 60.
Chart? I’m aware that some people use it but I’ve never had the need and I’m not sure of its raison d’etre. It’s essentially a less space-compact outline.
Everyone’s use is different. I’d not want people to misread what, as an experienced user, I use as implying those as being the best. As said what’s most useful is very context/task dependent. Don’t worry if others use, and sue deeply, features your work doesn’t need to use. Conversely, at least once in your use of the app, try out all the views. In part, making data to use in a view and configuring the view should give you some idea of whether it is a view you can or should use.
Some subtle points to bear in mind:
Part of the problem is that, short of using a sorted line or grid—which rather feats the idea of a free-form map±’order’ on the map is highly subjective (remembering it needs to be an order than can be encoded without a human brain in the loop to interpret ad hoc spatial layout to an order).
The outline of the map container is the flattened view of the map. I think the limitation is the user, not the app. The user needs to think how changes in map position/purpose can be ‘mapped’ (no pun intended) to $OutlineOrder. To make maps usable {X,Y} location is not linked to $OutlineOrder. Instead, the map z-order (which is on top when overlapping) does map. A possible kludge is to set $Caption to $OutlineOrder. Then notes will show their ‘order’ and by using ‘bring forward/send back’ or send to front/back) commands the $OutlineOrder can be amended. Or, populate a 1-based number attribute in your map notes and use that to set map item’s $SiblingOrder, as that will also update the notes overall $OutlineOrder number.
Bottom line: how does the computer code in the app know that users ordering intent as ‘hidden’ within the visual render of the map’s content?
I agree, it is a thorning issue, which we can discuss in the backstage. My use case is quite specific. I want to create and document process flow diagrams. I want to have a map view that shows all the processes in a flattened view. Here is a VERY simplistic example:
But for documentation purposes I want:
Currently, this can’t be done.
One thought, maybe there could be an attribute on an adornment that would tell Tinderbox to treat the adornment like a container.
As to ‘seeing’ sibling order in the map, this quick & dirty demo shows some approaches. A rule is used to set $Flags and $Caption to show $sibling order. Of course in reality you’d use one, other or neither—or some a similar but different solution.
sibling-display.tbx (126.2 KB)
In the TBX, select not ‘bb’ and View menu ▸ Arrange ▸ Move note down†. Note how ‘bb’ is the same {Y,Y} position but is now sibling #3. Select Outline view, select ‘bb’ and use Cmd+Up arrow to move ‘bb’ above ‘cc’ and switch back to map view. Again, ‘bb’ is unmoved on the map but is once again sibling #2.
This is a very simple proof-of-concept to visualise the relationship of map items to $OutlineOrder. I don’t use outline order as it might be big. As a map only shows one container, $SiblingOrder is shorter and clearer (yet changes to it are reflected by a change in $OutlineOrder). Note that adornment are map-only and always list after all notes on the map. IOW first-by-sibling-order adornment is always a higher $SiblingOrder than last-by-sibling-order note.
I’d likely not use a rule for this but an agent *for more control) noting that as it would work on aliases, we’d need to change $SliblingOrder(original). But, for instance, a boolean in the agent could affect the rule so that it either populates captions or sets them to the default empty giving to a way to toggle visibility of sibling numbers. Turn the agent off when not needed. Want to work on a different map? Change the agent query!
We can talk about this in the meet-up on Sunday as this map vs outline seems to be of general interest. I think one stumbling block is that we tend to assume/intuit that the order we ‘see’ in the map is the outline order of the container although it both likely isn’t and we’ve done nothing to record out desired outline in a way that the app can meaningfully interpret.
†. Look at the menu to see these 4 front/back commands all have keyboard shortcuts for those in a hurry.
It can be done, now. Admittedly, it’s a bear.
First, you can get a list of note atop System 1 using inside(System 1).
Next, you want to use the links to assemble these notes into a partial order. (It’s a partial order because you can’t know whether Note 2 precedes or follows Note 3.). Assuming the links are acyclic, this is a straightforward recursive function. (“Straightforward” in the sense that the algorithm is well known and familiar, but it’s not going to be a ton of fun with my cough.).
Essentially, pick any note, and put it in the list. Now, pick some note that’s linked to your note: add it after your note. Recurse, and move on to the next link whose destination hasn’t already been handled.
Then pick some note that links to your note; add it before your note. Recurse.
Ya, thanks. My concern is the fragility of the post. For my purposes, I’d need to have some guarantee that the map view positions and outline order remains consistent. For instance, in Map view, I don’t want to accidentally create containers and destroy my outline, or in outline, I don’t want to make containers and destroy my map (my process flow or architectural diagram).
But they do! Map {X,Y} position is not related to $OutlineOrder, but rather to the map’s Z-order (Z-axis, i.e as in {X,Y,Z}).
However, in testing, ‘accidentally’ nesting a note does destroy its existing {X,Y} location even if the new host map has no conflicting items at the added notes ‘old’ {X,Y} position. I _think _ the change is to not only avoid overlap (not needed in this case) and to ensure the note is in the new container’s viewport. But, testing whilst exposing {X,Y}, shows little consistency when nesting. My hunch is the algorithm deciding the new location does whatever it does without consideration that retaining {X,Y} info - if present should be persisted. Put another way, the logic does worry about a problem it wasn’t designed to take account of.
Also, if de-nesting a note by dragging back out of the container, regardless of to where on the map it is dragged, it becomes the next sibling of the erstwhile container. I think this is undesirable, but what else can the app do? It has no idea of the previous sibling order.
In summary, barring accidental nesting which does destroy current {X,Y} data, and moving between containers also affects sibling/outline order. This suggests accidental nesting is more of a problem for some users (you!) than previously supposed.
Otherwise, re accidental container creation. If this is accepted to be a problem, even if only in some use cases, perhaps needs a ‘no nest’ boolean for the map to avoid this. I don’t think there is a user kludge for that as action code can’t get ‘inside’ the accident event context.