Multiple map arrangements of the same set of notes

Q & A - getting started with Tinderbox
4

Correct. Bear in mind that any map view is broadly defined by attribute values†. All map view, regardless of tab/window context use the same attributes. Thus, as a user we might choose to store 2, even 20, variants of $Shape, but all maps of a given container will draw a note’s icon in the shape defined by its current $Shape value. So, whilst we can swap out values for $Shape we can’t tell a map (per tab) to use a different attribute for the value of its Shape definition.

This is why working back from an (imagined) visual outcome may offer rich ideas but ones which imply significant and complex re-design of what you see, i.e. the view. That doesn’t imply such ideas are bad, far from it. But, often those ideas might but not tractable in the current design.

My 2¢ is that the concept here is nice but it would need map view to be re-coded such that some c.50 attributes needed to make the view might need a per-tab abstraction rather than simply use per note values. …And, if they were, what existing behaviour would that break? It’s also easy to overlook that Tinderbox is now 21 years old and has plenty of docs happily still around that were made a long time ago; arbitrary changes for today’s new ideas need to be considered for unintended effect. Lest that appears to be a rejection of the new, I’m currently beta-testing (betas are not public) improvement brought about by user comments within the last week. Some things are easily do-able others far more complex: there’s no antipathy to improvement.

One practical test, that someone wanting this could do, might be to make a document with a developed map, then save a copy and make a different map. Then annotate what changes to the original (attributes, view settings etc.)‡. I’m not sure anyone’s actually done that before. not a 5 minute task by any means but if proposing this change something perhaps useful to try. Though the forum can’t do the first part (maps are highly subjective in layout/meaning), with two different maps of the same data, albeit in different files, experienced users here might be able to help figure how much change is involved.

I think two agent related factors are getting mixed here. What is/is not on a map is controlled by the query. The map is updated every agent cycle: that is a continuous process but can be throttled back pr turned off entirely so the map stopes being (agent) updated. See $AgentPriority](AgentPriority). That is what get on a map.

How agent map contents are arranged is a different and separate process controlled by the agent’s $CleanupAction. It too can be turned off (from the default auto grid layout).

Does that help clarify a bit?

†. Some more recent Tinderbox view types, e.g. Attribute Browser and Crosstabs, define more in the view settings than in note attributes. But, as at today, a Map view is closely tied to attributes of the items shown on it (plus a few from the parent (container) note)

‡. To makes maps dynamically switchable (i.e. same UI area showing a different map render), for N different renders you’d want N+1 attributes for a feature. So $Xpos, the X axis position on the action map, $XposA and $XposB to hold the same for Map version A vs. Map version B. Rinse and repeat for about 50 other attributes. IOW, 50 existing attributes with A and B version of each. For 20 different map versions you’d need 21 ‘versions’ of each affected attribute. At that scale you might make a List-type for each of the 50 with 20 different list items. But it’s all a job for the user at this point. something this process can’t sustain is link line (and link label) placement. Initial layout is auto by the app but many like to manually tweak that but those settings aren 't saved—at least not in a user-accessible manner.

5

I did try now, as apparently this has not been brought up before.

What I wanted was: Get the note highlighted in red to automatically appear, where the thin red line is. So basically an Agent that effectively acts, as if include() would also pull the children of notes.

image
image1224×316 37.5 KB

Actually what I did not know yet was, that an Alias can never have a child, nor can it be an Agent itself. What confused me for a while was the fact, that an Alias nonetheless has $AgentQuery and $AgentAction attributes I can set.

However, just using an Agent with $AgentQuery set to include(MyTestContainer) got me pretty close to what I wanted: I get auto-updating aliases of everything inside MyTestContainer and in the map-view of MyTestAgent I can arrange them in a new way.
The limitation remains, that only in the original map i can go inside shown containers, as their contents will not be caught by the Agent. But I guess that is what I will decide to call good enough for now. I prefer this way of doing it, because it allows having two TBX windows open side-by-side and comparing the two maps (unlike the “switching approach”).

I imagine it would be causing less trouble (none, I believe) if one would not change how maps work. Instead one could create a new type of view, which is like a map, but is like an “empty shell” – it does not have it’s own notes inside it, instead one would set it up, so that it pulls in the notes of another container. When pulling in notes, the “empty shell” would just disregard the map-relevant attributes from the notes it pulled – those attributes would be the only actual data present in the “empty shell”, so that it can use everything from a target container, except for those map-relevant attributes.

6

My suggestion is that you set aside some time to read how the app works before experimenting further. most of your problems stem from simply assuming that all apps are alike. Easily done, that’s not to judge.

This has, in fact recently been suggested albeit for a different purpose. A non-trivial ask at is has nothing, in common, bar attribute values, with the current Map view.

Meanwhile, I’ve taken a first crack at a dynamically alterable map. There’s a bit more to do to make the demo usable to a general audience. I’ll post it when done.

7

I think, that my general assumption atm is, that TBX is capable of anything I’d ever want. Stuff like this is not there in any of the other apps I’ve tried neither.
Nothing I’ve used previously even has the nested maps (does anything capable of that even exist, besides TBX?).

On the forum or elsewhere/private? If on the forum, I’d like a link :slight_smile:

Excited to see what you come up with!

1 Like
8

I forget. It’s scattered over various conversations. The genesis was making a map and being able to ‘preserve’ a certain presentation. The problem is that as a doc moves from map-based (flat outline) discovery to the likely export phase, where structure (outline) is needed, nested items disappear form the map. Yet the original map (withi visible link lines) is often still desired. This circle is still being squared.

Thanks, I’ll put it in a separate thread (and drop a link here). Almost there, just doing the ‘read me’.

9

See Dynamically change map styling

1 Like
10

Responding to the OP, I have wanted to do exactly the same thing for some time. I raised the issue twice I think in the forum, but in the context of having “replicants” or “hard links” that were upgrades from aliases, because they were handles to the same note. On the view I advanced, you could have Map A with a mixture of notes and replicants x,y,z placed in such and such a structure and Map B with a mixture of notes and replicants a,b,c. The key idea was that x,y,z and a,b,c all refer, respectively, to the same underlying note, call each p,q,r. A change to x would be reflected via p in a and vice versa. This is why I say they are a bit like hard links in some Unix file systems.

There was not much support for my idea. One, to my mind valid, concern was that you would still need to mark a difference between intrinsic and extrinsic attributes as you do with aliases. So the implementation would have to draw the line of demarcation differently and whatever that new demarcation it would have to offer enough additional value over aliases to make it worthwhile.

The second concern was that few people saw the use cases. In my case, the use is and was, the desire to make maps of conceptual inter-relations, and more specifically to arrange the same sub-elements in different ways to think about different potential inter-relations. (You could call these different or partially different holisms, if that term helps.)

At the time there was no action script way to create notes, so I trialled an approach in which I had a master container of notes, which several other containers monitored. When a new note was added to the master container, a new note (a copy) was made in each of the other containers. Then I could arrange the map for each container as I liked. It did scratch the itch a bit but the system proved very fragile. Moreover, I had wanted to edit the notes’ text in whatever view I was in when some new insight occurred. Replicating these changes to the original or derivative notes proved far too difficult. I’m not sure it was impossible, but I felt the effort involved would be like trying to eat soup with a wrench.

So for this particular purpose I am back to using paper and pen, which is no great hardship.

2 Likes
11

Useful exposition here, though you’ll also understand why I placed caveats as to intent on the linked demo above. It’s not because I disagree with the other contingent ideas but because they aren’t tractable in the app as currently designed. For instance, until/unless Tinderbox gains a notion of ‘replicants’ (orriginally a DEVONthink notion?)

The kludge my demo uses is to save, for all affected attributes (the demo only uses some of that possible range), the attribute value(s) per map version in a separate attribute. This allows the a ‘set’ of saved values to be read an applied to the notes in the current map view, bearing mind that for a given container there can only be only one map visual variant at a time. IOW, my demo doesn’t mean you can have N tabs/windows open showing at the same time differently rendered maps of the same notes.

This is very interesting aspect of PKMs. Are map variants each a full-blown thinking space or are we really looking to save diagrammatic snapshots for export/comparison/… ? I don’t claim to know the answer here, thus the question. Plus, despite my moderator/admin role here I say that as just one of many users of the app. It’s different to explore this subject as most PKMs are text-based so, experientially, many users have little by way of practical example from which to work. What’s imagined is not necessarily easily made manifest.

This is not—I think—bad or ill-observed. However, it does start from a different view implementation that the current map view. An entirely innocent error in a lot of map view ‘improvement’ is to misunderstand that the proposal is in reality not an improvement to an existing but rather a whole new view. There’s nothing wrong with the latter, but it better exposes the degree to the work for the developer to ‘just’ manifest the desired change. Most PKMs are not made by corporations and time/resource are finite, which as users of an app we easily forget: what we don’t understand is inherently how easy/simple to those changes are to effect.

I’m not sure if that moves things forward, but is my understanding and I hope the (linked) demo is an indication that new ideas are not ignored here and users are exploring the envelope of what is possible. :slight_smile:

2 Likes
12

BTW, RE this, I agree. I backstage I’ve been calling for a new view “Diagram View” to accomplish exactly this idea. @eastgate, @mwra, @PaulWalters have been contributing to the refinement of the feature request.

13

Note my linked demo doesn’t address the latter, or being able to display two different maps of the same notes at the same time. These are all discrete use cases/requests.

14

Thanks Mark, I pretty much agree with everything you said. You’re right that as currently implemented, what I am thinking of is more like a new view. But the differences may go deeper than that and my own ways of putting it and thinking sort of obscured the difference.

The current way that Tinderbox works I’d say is roughly that there is a single large structure of notes with attributes. Each view offers particular affordances in relation to some attributes of the notes in that structure. So the Map view focuses on spatial attributes and renders those visually. Outline view disregards spatial attributes and gives priority to the order attribute and the hierarchy attributes. And so on. The note is the atom and it is its attributes that are fundamental.

(This is one reason that links do not have an independent existence, each is an attribute of a note. This point has come up in past forum discussions where I suggested they might be made “first class” or independent entities because they were themselves a kind of semantic content.)

What I described and which I think the OP described would imply some kind of duplication or overloading of some attributes which would be indexed to a particular view. So map view A on notes p,q,r would show them according to some spatial attributes (e.g. xpos,ypos). Map view B on the same notes p,q,r would show them according to different spatial attributes. But a note can only have one set of spatial attributes at a time in the present implementation. So what is implied for this to work is that note p in fact has a two-dimensional array of spatial attributes roughly like this p:{[A(xpos,ypos)],[B,(xpos,ypos)]} where A and B stand for map views. In fact, it would have an array whose first dimension was as large as the number of relevant views in which it appeared. My point is that this is non-trivial and in a way more than just another view and there is a serious question to answer about which attributes should/could be indexed to views of any kind. (You can see that replicants as used in Devonthnk are there to solve part of this problem because they facilitate the presence of the same entity in more than one containment hierarchy.)

This connects to your well-observed points about PKM software and thinking-assistance software. If you think of Tinderbox as a PKM tool, then the use case I described is probably out of scope. DevonThink seems to me a clear-cut PKM tool: it stores knowledge and facilitates finding, managing and annotating it. Somehow I’ve never really thought of Tinderbox that way, which I know is a personal view, even though it can be thought of that way. Tinderbox’s appeal for me is that it is a kind of “doing” space where you can do things: think with them, think through them, make connections, and create in a surrounding of contextual content. To make a crude analogy, Tinderbox can be in thought like one of those exoskeletons that people can wear to enhance their strength, reduce their fatigue, even increase their reach.

At any rate, that is a kind of personal hope for Tinderbox (and I am not aware of any other software close to doing what TB does). I’m a second-rate user of TB compared to some people on the forum and its first appeal to me was that it reminded me of Hypercard because of how one could “automate” notes. Hypercard was great but was still mainly, in my view, about traversing a body of content with some dynamism in the content and the traversal. Tinderbox can do that, but seems to me also to hold out the promise of augmenting the thinking about that content.

1 Like
15

Note quite! The outline is actually the primary view and represents the stored XML structure of a TBX (see The XML TBX format). The order of notes in the outline ($OutlineOrder) is key to a number of behaviours in Tinderbox, e.g. selecting a single match from several where Tinderbox uses the first match as sorted by $OutlineOrder.

Meanwhile, a map only ever maps a single container within the outline. See more on map vs outline considerations.

Actually, this is not so. Unlike many apps that ape the Web style of embedding links into documents, Tinderbox cleaves to the older, more powerful, hypertextual notion of a linkbase. Links are stored entirely separately from the note data. Open a TBX with links in a code editor like BBEdit and look for the <links> element. It will contain a series of <link> elements, 1 per tag.

Thus links are essentially first class objects, even if not obviously so. A mis-presumption likely arises as the app applies/renders any Text/Web links to the $Text area and, in (map view) any Basic or Text links to the view area.

Please forgive my apparent pedantry here: that is not my intent. But, mistaken assumtions can derail well intentioned ideas about possible new uses.

In Tinderbox links are discrete and (uni-)directional. However, they can be traversed/computed across either way or traversed visually in Hyperbolic view. The latter essentially shows those notes in the whole TBX that can be reached from the current note by traversing any type of internal link in any direction (disjoint , unlinked notes are thus omitted). Although not formalised to the extent, say, of Roan, it is possible for basic or text links to link to anchor text. It is little done/seen as Tinderbox design concept is many small notes rather than notes with long screeds of text that inherently require closer addressing to find the needle in the (textual) haystack of the target note’s text. Unstated assumptions both note size and linking can derail our thinking.

A structural limitation for internal links is they fun between two objects. If note BBB has an alias BBB and note AAA links to BBB that link cannot go to both BBB and BBB. At least it can’t without an extra switching function where the human user would need to indicate which of the two possible targets was intended. Such an approach would damage the current powerful ability to query/reason across the network.

Notes and aliases share all outbound links (basic/text/web). However an alias may be given discrete outbound basic links—though this is rarely seen. When exporting, the logical endpoint for much analysis, a link to an included note (i.e. where a note forms part of the exported content of another note) is not sustained. In theory it might be done (i.e. if were to be engineered so) but currently this in not the case.

In principle, Hyperbolic view ought to cover much of what is being sought but it:

  • controls layout
  • does not plot notes not reachable via link traversal.

Yet, in map view we may often build rich layouts with some/no links and using deliberate ‘manual’ placement of notes (i.e. a structure really only reflected by building of {x,y} positional data.

For me Tinderbox is both a PKM and a thinking space. Indeed the two blur. I’d add from context that to me the ‘P’ in PKM releases to scale (desktop vs enterprise), sharing (single-user space) and privacy (personal vs. public). Apart from fixing other people’s TBXs :slight_smile: I primarily use Tinderbox for exploring new problems where the structure is as yet unclear, so Tinderbox’s flexibility and support for incremental formalisation are second to none (at least for me). Still, almost 20 years of looking at/trying to understand other people’s TBX documents shows there is remarkably little commonality in the way we individually use the app. If there is a degree of concordance it tends to be conceptual which thus hides often significant difference and creates confusion in discussion: i.e. we’re doing the same thing … differently.

I think a contemporary problem is we tends to view programs in terms of what they let us do. I think that’s the wrong way round. Rather our tools for thought should assist us. Then as in any collaboration we may need to calibrate pragmatically our approach within the constraints of the possible

Too harsh! We use what we need. Few if any need to use every tool in the box. Though we see some complex/niche things here it is generally because they butt up against the known edges of what the toolbox can do. By comparison, doing close/reading annotation can be both rewarding in Tinderbox but yet use only a few of the tools in the box.

1 Like
16

I think you may have misunderstood what I intended or imputed more emphasis to certain aspects of what I was describing. That’s not very important.

I disagree though with the idea that links are first class objects logically speaking (and how they’re stored seems to me irrelevant since it is completely contingent). There is no way to traverse the “linkbase” at present except by traversing the notes first. Up until recently, there was almost no way to get at the attributes of links. And there is no way to extend the attributes of links as one can with notes. Indeed, if links were richer, we might have one to many links.

A linkbase sounds a great idea and if it is already latent under the hood of Tinderbox, let’s get it out and have at it.

17

To clarify further, there definitely is a link base. Here is a random TBX on my system—In BBEdit (with XML syntax colouring)—with all except the link type and links collapsed:

alias-test.tbx 2023-02-20 12-33-20
alias-test.tbx 2023-02-20 12-33-201920×1331 499 KB

The full range of possible metadata in a link is here: link tag. (For storage efficiency, Tinderbox doesn’t store most default settings).

I don’t know which of these you’ve actually used in your Tinderbox analysis:

Have you tried all the above and found them wanting? If so, how? I ask not in combative tone but out of a desire to improve/explain. Clearly, few individual operators answer a complete complex question but rather they must be used in consort to achieve the desired aim.

How are you expecting to interrogate the link base? Put another way, what sort of question are you trying to ask. My hunch is the blockage may be as much approach as it is any functional limitation.

The operators for this were first added in v9.0.0, see here, in December '21. As I recall the feature was added as people asked for it (and indeed not asking for it before then) … and there’s the rub. A lot of possible features aren’t in the toolbox because no one has actually asked the developer, directly, for them. In v8+ there has been a big expansion in the degree to which code can interact with more than attribute values. Doubtless more could be added. But with finite resource it makes sense to effect first those which people have actually asked for with a believable use case (i.e. more than “it would be cool if…”).

Beyond the concept of such affordances, what to you want to add to your links and why? In which PKMs do you currently make such link changes? (Examples help understand the actual need vs conceptual possibility) requirement).

What I enjoy about Tinderbox is it makes me think about my thinking. Indeed, helping with other people’s problems, even more so. Why am I using this approach and not that one? Why did I think this arrangement view would tell me more than that one? Why didn’t this query give me anything useful, against my expectation? Can I structure my view/attributes differently to get more traction on this topic? As so forth…

18

Fascinating discussion. A few very brief notes might be useful.

  1. I myself don’t think that outline view is privileged or primary. I think of Map and Outline as coequal, and Chart really ought to be — but has never caught on.

  2. In very early Tinderbox, Outline View was given a small boost in priority because new documents opened as an outline, in contrast to Storyspace where new documents opened as a map. This all became academic in Tinderbox 6, with the introduction of tabs.

  3. Tinderbox links are not quite first-class objects. The late Rosemary Simpson (Lisp Machines, then Brown) was a tireless advocate for making Tinderbox links first-class entities. Most notably, you can’t link to a Tinderbox link.

  4. The mention of multi-way links takes us back to Aquanet, whose influence on Tinderbox seems to grown every year.

  5. One important aspect of Tinderbox that we take for granted is that each note really is concrete. It’s a thing, which you can find at a particular place. You can pick it up and put it somewhere else. Bolter calls this “architectonic”, and its importance has been obscured because we’re accustomed to it. In a database, the data aren’t palpable in this way: their Platonic ideals that we perceive through reports. I worry that p:{[A(xpos,ypos)],[B,(xpos,ypos)]} might interfere with p’s thingness.

  6. I also worry that lots of people have a hard time with vectors and matrices.

  7. This fun 1983 paper, with an all-star cast (just look at the list of authors!) wrestled with the idea of filtered, reconfigurable views in an amusing way. https://www.ijcai.org/Proceedings/83-1/Papers/034.pdf. I currently think that the core problem of the reconfigurable, customizable diagram view is actually the problem of telling Tinderbox which notes you want to put into the diagram.

19

Sorry if I mis-spoke re views & primacy. Nonetheless the (root) outline it the easiest place to see the structure of overall document and unlike the map is is key to understanding (HTML) export. Just as early Tinderbox files opening into an Outline view gave that more apparent standing amidst other views, the Map has the same effect now. My observation is that users, especially those less comfortable with abstraction, can get confused ‘mapping’ the map onto the outline, compared to going the other way. Arguably, it matters not, until/unless one needs to figure out where things are (which isn’t everyone’s problem). Point taken re links. I do think the concern #6 is valid,.

20

I too would love this. I’m calling this “Diagram View” in the backstage.

Regarding your comments on links, our last meetup went over links “making meaning with links” in some detail. I use links extensively in all my work.

21

A way to preserve the thingness could be to keep only one set of attributes in the note itself (as in current TBX) – the alternative xpos,ypos do not have to be inherent to the note, they can instead be attributes of that new thing we are discussing.

When using the new thing, it pulls in everything from some container and overwrites the attributes for which it has its own version.
An analogy to this behaviour would be a mostly transparent cape, that you can throw over your item, to dress it up. You mostly see the original item, but on a few spots (where the cape is not transparent, but has some print on it), it covers the properties of the thing we dressed up. Any changes that happen to your original item can still be seen through the transparent parts of the cape.
When f.e. you color notes through the cape, you “paint on the cape” not on the original items – i.e. those changes become new/update values for attributes saved in the cape.

This is also similar to the way CSS is based around some idea of separating apperance/styling and content. There you can also cover the styling a page has on its own by injecting some custom CSS that will cover parts of the original styling. We could limit the attributes a “cape”/“diagram view”/“empty shell” (…whatever we want to call it) can have. Color, positions, shapes etc. can be saved in there – but anything that is more content-like in nature is not.

some thoughts on "real content" possibly being encoded in attributes considered "styling"

the line one can draw between what is styling and what is content is kind of tricky – one might have encoded content-like information in an attribute we’d consider styling, for example making all notes that represent objects of a certain class one color. Nothing one can’t get around using Prototypes for such distinctions instead however?

A bit more towards keeping ideas well-defined and seperated:
What I was going for in my original and also this post is different from what @entropydave was describing earlier here:

What he described includes changing the set of notes(or replicants of such) seen on the 2d-canvas. Though this could be worked into my “cape” idea as “well adding another note, or a replicant of one to the canvas is equivalent to painting that addition onto the cape” I did not intend that. I in contrast thought that the set of notes you see on the 2d-canvas is given by the original container – with that given, replicants are not needed.
Maybe this is a useful distinction.

22

Yes, this is an interesting alternative way of thinking about it. One way of conceiving it is that containers could have a modalising context, i.e. that they put the thing into a mode in which its properties are transformed. Within the mode that the container sets, some properties would be different.

If you want an analogy and perhaps a use case, consider three containers: Past, Present, and Future, in each there is the same entity, but some of its properties would be different in each container. These might be spatial (e.g. its home address) or they might be other ones (e.g. its age in years).

Very cool as an idea.

23

This is an interesting point Mark, but it does mean that you are thinking about a (software-based) entity as being a real thing because it has a spatial place. But place is not conceptually a spatial notion, there is also a place in time and a place in a hierarchy (and many other logical notions, e.g. a place in a sequence). If we take real people as an example of a thing, we can imagine that someone has three places, e.g. in the hierarchy of his genealogy; in the hierarchy of the org-chart of the job he has; and in the hierarchy of the Army Reserve in which he serves. None of these is primary I’d submit.

I would argue that the minimum you need for thingness is non-identity, namely that it be possible to distinguish one thing from another, and that seems only to require that two entities do not have all and only the same properties.

But you’ve been wrestling with these issues in Tinderbox for a long time and there is likely some other consideration I’m overlooking.

Thanks for your other comments. By the way, I love Chart View. Feature request: Now that we can select a series of notes in the Outline and edit any of them while they’re all shown, could we please have non-contiguous selection in Chart View plus editing of any one of the notes. I tried that in TB recently and it did not seem to work.

1 Like