Useful tip, Mark. I might steal that idea!
I rather like VisibleAttributes. I think we could use that moving forward, while also supporting reference to KeyAttributes as equivalent.
2 Likes
Sounds good!
1 Like
If change is possible, think this is better than the current $KeyAttributes, given the above, but it does carry the sense of other attributes therefore being invisible. I think that is problematic for learners given the known sense for many that you can only edit a visible attribute. That’s not true, of course, but false assumptions can bed in deeply, so there is a danger or reinforcing a mis-presumption.
With that in mind, I’d suggest a rename/mapping going to $DisplayedAttributes (DA for short, ). The ‘-ed’ suffix is deliberate as this isn’t about controlling the display (UI) but what is displayed within it.
That said, I’m open to anything to make it easier for folk to not get stuck on being able to use attributes efficiently. (FWIW, neither VA nor DA contraction poses a problem, as these would get used in time if a change is adopted).
I think @mwra is right. Much as I rather like $VisibleAttributes, I think it carries within it the seeds of further incomprehension (and more time spent on user support). $DisplayedAttributes is pretty much cut down to the essential “attribute” of the attribute. It is displayed (in what might be thought the “default” view of the program), whereas other attributes are normally not on display, unless you open an inspector.
1 Like
$ExposedAttributes is an idea I just had. The problem with “visible” is that it could be taken to mean only attributes like color or font or any quality that you can SEE when you look at the note itself on the screen… “Exposed”captures the distinction we’re looking for a bit better…
I’ll confess I find neither DisplayedAttributes or ExposedAttributes any more obvious than KeyAttributes, both suggestions give me the connotation of something visible. My first thought would be that this is something I can see, perhaps in Map View. One option is to make it more abstract such as FavoriteAttributes, which suggests it is user-specific and perhaps not integral to the data structure. The other option is to be more precise, like TextPaneEditorAttributes.
The connotation issue cuts all ways, as TextPaneEditorAttributes might be attributes to do with configuring the Text pane. I accept some might think of DisplayedAttributes as those being used to ornament the current view, repeating the problem we are trying to solve in the first place. But, by comparison, FavoriteAttributes as a description does step outside such inference as to display/function.
So, I think ‘Favorite Attributes’ (and $FavoriteAttributes) is the best of the suggestions thus far for a possible rename/replacement for current Key Attributes which does only muddy the waters in a different way. The inference is attributes chosen because…they were important to the user, which is essentially what Key Attributes are.
Having thought about this for a few days now, I’m not sure a change is going to gain anything. Whichever way you go, people are going to assume a meaning. I’m not sure the name of KA is a major issue. I still think it’s about people learning artisanal software and realising it takes effort and mental application.
Renaming the attribute is likely to break the majority of Tinderbox docs that people have. People will need to update all their code. This will produce a massive amount tech help requests when someone’s TBX doc was working and now isn’t. Someone will need some info from an old TBX file and find the info isn’t displaying like it should. Personally, I do not relish needing to go through all my TBX files and updating code. Then you have the issue of people running different versions of TB. Some with KA and some with the new attribute name. Again, people will look for tech support as to why things aren’t working.
In the end you need to evaluate whether the real gain (as opposed the perceived gain) is really worth it. Going down this road is going to produce a ton of extra work.
1 Like
We already have a mechanism for this, Under the hood, a RenamedAndDeprecatedAttribute is like a BasicAttribute, but it has two names: the new name, and a deprecated, obsolete name. Either can be used interchangeably, but things like menus and autocomplete recommend the new name.
1 Like
I agree, my preference is for $FavoriteAttributes as a synonym for KA.
I have a tech background so picking up the meaning of $KeyAttributes was not that hard, but the first few times I saw it I was put in mind of Primary/Key Fields/Attributes in relational database design. So I did expect that they had more import than in fact they do.
The only thing re $FavoriteAttribute is that “favorite” tends to connote a kind of short list, permanently set aside so as to be more quickly available - vide favorites in Contacts etc… Using prototypes you can effectively recreate a kind of favorites of attributes or combination of attributes, but in the more civilian (ie not professional per se) computer world the word may only create more misunderstanding. Thus my thought re $ExposedAttributes. This terminology would signal to one population that it is a category they are NOT familiar with, thus leading them to investigate and learn what the feature actually is, while “exposed” would, I’d think, make intuitive sense to those more deeply embedded in the coding, “power user” etc community…
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