I dunno. We already have DisplayName. Why not DisplayAttributes? I worry that VisibleAttributes would lead some to infer that the others are invisible in some fashion until made visible by being added to the Visible list.
In place of my customary habit of overthinking things, I think this time perhaps we’re all overthinking this one. But welcome to my world.
I see nothing whatsoever wrong or misleading with “key attributes” – seems to me it’s much superior to other suggestions. True, they are visible, but their being visible mirrors the fact that they are of special importance, hence “key.” Key Attributes tend to be those that need to be modified to accomplish some purpose that the user has in mind. To say “visible” or “displayed” would obscure that fact.
As for the previous discussion here about prototypes, I would remark that what makes Tinderbox different from other apps that organize and analyze data (including Devonthink, which obviously is a very useful app) is that one can start entering information in different notes without thinking of what attributes one might want to create and modify, and without going to much effort to organize the notes. As one continues to add material, it may become obvious that a certain attribute needs to be associated with some notes – and the user creates a prototype with that attribute as a key one, and then perhaps puts all the relevant notes into a container that associates them with the prototype (Action $Prototype=x), Then, sometime later, if another attribute needs to be created and made key, it can be added to the prototype and immediately it is there for all the notes that have that prototype. Tinderbox can be programmed on the fly, in other words, and that is what makes it so useful – and unique.
It is quite clear, however, that others have been misled by the present name, and the consequence has been that it has take some effort to clarify concepts. We need to be able to put ourselves in other people’s shoes, and not just look at something from our own viewpoint. Good communication is a co-operative process, and demands some effort from both sides, but if the originator of the discourse does not try to avoid ambiguity, it certainly makes misunderstanding possible. I think it has become clear that the term “Key Attributes” is ambiguous, and open to a variety of interpretations.
That may be the way that you use them, but it might not be the way that others use them, or how they conceptualise them. Once again, I would say that we need to guard against the assumption that our own practice and viewpoint is typical. It has become clear that a number of people thought that Key Attributes were the only attributes that a Note had, and that you had to make something a Key Attribute in order to be able to use it with a Note. I have lost track of which threads touch on this matter, but it has come up more than once in recent months, hence the consideration being given to a less ambiguous and misleading name.
2 Likes
I’m not sure why anyone would make an attribute visible (“key”) unless it was specially important to them. The problem is, perhaps, that Tinderbox is so malleable and can be used in so many ways that there is no one term that would encompass the intended uses of key attributes. Perhaps “Note attribute” would work – that would seem to me to be better than “visible attribute.” Or “Visible note attribute” might be better, especially given the fact that one note might have a key attribute that another note does not. In this respect, “key attribute” is misleading, as it only applies to certain notes, not all of them, while the name implies that the attribute is “key” for everything.
I think as this thread highlights changing, “Key” in KA to another name will just give you another set of problems. I’m coming more to the conclusion, “If it ain’t broke, don’t fix it”.
My advice would be to leave it alone. It’s survived thus far, it’ll do another 20 years. Set a review date for 2040. 
Responding to this thread and others touching on misperceptions about Key Attributes and inheritance I’ve added new content to aTbRef, see this post.
One metaphor from everyday life that might be useful here is the administrative form – a tax return or driver’s license application or passport form. Everyone knows that such forms contain boxes that you don’t fill in. There is a box for “middle name” but you don’t have one. There is a box for corrective lenses but you have 20/20 vision. There is a box for your US Zip code but you live in Togo. A note is like a form, with scores of boxes that you can fill in but also boxes that you don’t. And unlike a form imposed by bureaucrats, this a form you can add your own boxes to!
Might that metaphor help?
The other thing that I believe would be enlightening for users is, I think, kind of counter to Tinderbox’s aesthetic. As almost all of us have noticed, Tbx offers very few guardrails and warnings when we are about to make a consequential error. And while such protections can be cumbersome, they are also highly educational in early phases. Suppose a warning popped up saying “In changing this prototype you are about the change the value of $Text in 18 notes. Are you sure you want to do this?” That would convey quite memorably the difference between = and == .
As you say, the situation for most users is not “read documentation, then use.” It’s “use, then read documentation when you stumble.” So lessons imparted during use tend to sink in. Different people have different ideas of where useful guidance crosses over into intrusive hand-holding, though, so I am not quite sure what practical suggestions I can make here.
David