Surprising behavior when copying and pasting to create a new prototype

I’ve been creating a series of new prototypes by copying and pasting (Cmd-C / Cmd-V) existing ones, and I’ve been thrown by TB behavior - not sure it’s a bug but it’s definitely not what I expect!

As an example, I have a prototype “Compétence”, and 4 notes using this prototype.
I want to create a prototype “Connaissance” and use it on one of the notes.

I copy and paste “Compétence” in my “Prototypes” container. I then rename the new note to “Connaissance”, expecting this new prototype to not be used anywhere. I make other formatting adjustments as well.
When I go back to my “Data” container, all 4 original notes now have “Connaissances” as a prototype.

So when copying and pasting a prototype note, Tinderbox behaves as if the new copy is the actual prototype for the existing notes. Which means I need to remember to edit the original prototype to the new value. This really seems counter-intuitive to me. Am I not seeing something obvious, or is it an unexpected behavior.

To be honest, I’m running TB 7.1 on a 10.13 beta (High Sierra) so this might just be a case of beta shakes on macOS’s part.

I don’t know the underlying architectural issues involved here. But this may be a simple workaround that would do what you’re looking for, and almost certainly would avoid the complications:

  • Create your prototype, “Compétence”
  • Create another note, called “Connaissance”. Use the inspector to specify that this note is also a prototype. And use that inspector to set the prototype for this same note to the original “Compétence.” As shown in image below.
  • This means that the new Connaissance will have all the attributes that you want it to inherit from the original. And anything you want to change with this new prototype can be adjusted, and will of course transfer its values to notes you create based on this one.

So I understand the instinctive use of copy-paste as a way to create more prototypes (or other notes) based on a model you’ve already set up. But using a prototype as the basis for other prototypes can combine the convenience without the spillover effects you’re seeing. Or that’s what I would expect!

Thanks for the thoughtful answer.
My issue is that it introduces an unwanted link between the two notions. It’s probably stupid: just because I use a software inheritance between the two prototypes does not make them functionally linked in my database - but still, it creates cognitive friction that I’d rather reduce by using my weird workaround!

And all of this in the hope of making sense of the French high school math program. The things we do for kids!

I understand that these preferences aren’t always purely logical. My point is that the Copy-and-Paste method (apparently) also creates an unwanted link, but unlike the sequential-prototype approach it’s a link that’s less visible or predictable and harder to control.

Of course the main point is and remains, chacun à son goût, so hope these various avenues help you tune this in the way you would like.

1 Like

I see this behavior too, and I agree it’s unintuitive. It seems to me that copying and pasting a prototype note should not affect the state of the prototype graph. I’d be interested to hear @eastgate’s thoughts on the matter.

I just ran some quick tests that may help.

duplicating a prototype doesn’t have this problem, presumably because the new note gets named my prototype duplicate and so there’s no name collision.

If you absolutely need to copy and paste… Tinderbox appears to search for prototypes in reverse $OutlineOrder. So if you copy and paste and change the second prototype name, it’ll break the existing ones as you found. If you change the first one (higher in $OutlineOrder) then it won’t break anything. If you absolutely have to change the pasted one (maybe because something links to it), then you can move the pasted one above the copied one and change it.

Personally, I would just duplicate :slight_smile:

2 Likes

The prototype–instance relationship in Tinderbox is represented through prototype links, not by a location-dependent search. Links go from prototype to instance. My guess is that prototypes of a note are resolved by following the first (for some definition of “first”) incoming prototype link, and that copying and pasting a prototype inserts links from the newly minted prototype “ahead” of the links from the old one.

That’s exactly right; Tinderbox follows the first prototype link it finds.

The real question here is, why do you want to duplicate an existing prototype? A common reason – to represent a variant or specialization of the prototype – is what James Fallows had in mind. In that case, there is a relationship between the concepts, and that’s usefully reflected in a prototype chain.

Another case might be that you’ve got two unrelated concepts, but you want to reuse some complex or finicky settings from the existing note. In this case, you can Duplicate the prototype and rename it. Then, select the new prototype, open Roadmap, and click the checkbox to Include Prototype Links.. Delete those links, and you’re set. (This is a nuisance, but it’s not something you’re likely to need to do very often!)

If you find yourself wanting to make a considerable number of prototypes, you might want to stop and think. Most Tinderbox projects – even very elaborate projects – work fine with a handful of prototype. If you need more than a dozen, there’s no technical problem that prevents it, but you may be building more formal infrastructure than you really need.

2 Likes

Fair enough, but there’s also the question of avoiding surprising behavior. This behavior has tripped me up a few times, and it’s only in researching this thread that I’ve understood why Tinderbox behaves as it does here.

Would it make sense to simply have Copy not copy outgoing prototype links, just like Duplicate does not? This strikes me as a good option.

I’m finding that the second step isn’t necessary, since Duplicate doesn’t seem to duplicate outgoing prototype links. (It is necessary if you Copy and Paste the prototype.)

1 Like

Excellent question: initially it was only as a way to duplicate formatting, much in the way I’m trained to reuse shapes in Powerpoint once I’ve made them look like I want them. The “Duplicate” function is of course much more meaningful than ⌘C ⌘V, just not in my muscle memory. (and I just realized that ⌘D exists in PPT - but muscle memory is very very strong).

James Fallows’ suggestion was spot on for the specialization of the prototype, and I’ll keep it in mind when such a case comes about. However I still maintain that having the “copied thing” become the “master” is counter-intuitive - I’ll allow that copy/paste to duplicate is probably something I need to change in my own habits.

As for large number of prototypes, your advice is noted. I’ll stop and think …

Thanks to all for your replies and investigations.