Prototype inheritance with manual attribute handling

Q & A - getting started with Tinderbox
21

Disagreements should be healthy! I would imagine meaning also depends where in the world you are located, what field you work in, and what age you are.

The Mac dictionary definitions do not invalidate how it is currently used in TB. The computing definition is really specific to databases in terms of Primary and Foreign keys and not computing in general and the adjective, "of crucial importance" is very applicable. In a note in a TBX file the KA are of crucial importance for me in that note. Saying the attribute is “crucial” or “key” does not say other attributes do not exist, only that these particular attributes are crucial to me for this note.

I’m not sure in our globalised context changing the name for KA will be universally beneficial. The english language has many subsets with quite different understanding of words.

22

Agreed!

I taught English language and literature in Italy for the best part of ten years, and I am now sixty-eight, and I am very much aware of how much English has changed during its long history, and over my lifetime. Having studied or worked in the fields of history of art, English, history, psychology, and counselling, I am often aware of how terminology gets hijacked for special use (as well as specialist language being taken over in common usage – see Serge Moscovici and Social Representations Theory). And in psychology I have leanings towards Social Constructionism, so I am alive to the importance of context, and how our meanings are socially constructed.

The crucial (sic!) thing for me in this context, however, is the question of how we might make it easier for people to adapt to this piece of software, which frequently seems to leave people feeling disorientated or puzzled (I include myself among them).

I do not have any evidence, only a hunch, but it would not surprise me to learn that the people who have least difficulty adapting to Tinderbox are those who have deeper than average knowledge of “computing” – be it scripting, programming, or something of that sort. People who may, perhaps, have some inkling that what goes on may be hidden below the surface, and not all exposed to the view. I recently suggested on these forums that many computer programs are like Ikea cabinets whereas Tinderbox allows you to take a stack of timber and make almost anything you want, but you really have to have some knowledge of carpentry to be able to come out with a decent cabinet or table at the end of the process.

The question, then, becomes one of how to bridge the gap for those who are used to Ikea cabinets, but might benefit from learning a little carpentry. From discussions I have had with @mwra, I believe that this is what he would like to do. I believe that changing the name of Key Attributes would help in this, though that is only an opinion based on a hunch about the meanings that people are likely to bring with them from ordinary, everyday usage of English. Granted, non-native speakers, of whom I have quite a lot of experience, may bring very different assumptions with them. (I had quite a discussion in another forum regarding the meaning of “buffer”, which presented quite different initial ideas to non-native computer programmers, and native-speaking non-programmers!) And there anecdotal stories of meetings taking place in English in which the non-native speakers all understand what is going on, and the only ones who can’t understand are the native English-speakers! But I think it is difficult to get away from the base idea that a key is something that unlocks things – that makes things possible.

Anyway, communication is an art not a science – and I have probably completely derailed this thread. But I hope with the intention of moving towards making life easier for puzzled users of Tinderbox. The people who “inhabit” this community seem to be thoughtful and prepared to look at things in various ways in a spirit of enquiry, so I hope my ramblings here will be tolerated.

Cheers!
Martin.

1 Like
23

Perhaps removing the word “Key” entirely from KA?

24

Noting my status as a fellow user, none of us can change this in the app. Plus, there is 19+ years of accumulated references to Key Attributes. My pragmatic suggestion would be to revisit primary references (Help, Help menu PDFs, aTbRef) and annotate relevant passages first referring to Key Attributes and emphasise they are simply user-chose displayed attribute rather than them having any enhanced functional status. I suspect, this is do-able but might benefit from the user community flagging up references to Key Attributes that would benefit from in situ clarification or links to the same (the latter easier to do in Help and aTbRef, as opposed to the PDFs).

We’re a renaming possible, I’d suggest 'Displayed Attributes (DAs) as the term. I think ‘displayed’ speaks most clearly—given discussion above—as to the role. Indeed, here we often write of ‘displaying an attribute as a Key Attribute’ (or words to that effect).

A discrete but as important issue is clearer understanding of inheritance. To my surprise, aTbRef doesn’t tackle this explicitly (probably as I normally point people to my Clarify doc in the subject). But, I now see (note to self) it ought to be more explicitly described in aTbRef (the never-ending to-do list…). I’ve found this thread really informative, thanks to @svsmailus’ replies as to how inheritance can be ‘mis-intuited’. The latter isn’t snark, a sad fact of our intuition is rarely that of others, even though we know :roll_eyes: it should be. “Why can’t everyone else think like me?” It’s so obvious and much simpler. :slight_smile: Of course, reality is otherwise. a good example is opening a 640x480px desktop in a VM on a VK monitor. Without (software) scaling it looked like a postage stamp. The 15-20 display attributes :wink: I regularly use in current project would have been hilariously aspirational back then. the world changes and, even if through gritted teeth, so must we. (I generally work with a minimum of 2-3 screens and only use a smartphone as a telephone, yet i feel not old!).

Still, my takeaway is what perhaps seems self-evident is less so. Lest that seem snark at the app’s design, for those of use who’ve been using computers since 2001 when the app came out, a lot has changed since.

25

I’m sure somewhere I read that it was possible to get one prototype to build on another prototype to give you more nuanced prototypes. Is there a way to get this to work?

My assumption is that if I create prototype A and add $StartDate and create prototype B and Add $DueDate, setting prototype B’s prototype to prototype A won’t add $Startdate as a KA because as soon as I added $DueDate to prototype B I broke the inheritance?

Why am I asking this? I was thinking of setting some general prototype’s such as Task and then more nuanced prototypes such as TasksDelegated that add $Person attribute, but retain the rest of the attributes from the Task prototype.

26

I tried it and got this:

Screenshot 2020-07-29 14.30.53
Screenshot 2020-07-29 14.30.531800×1204 175 KB

So it seems you can cascade prototypes.

27

That’s exactly what I was after. After trying this out on another note it worked. I must have messed up the local inheritance of the note I was testing!

Many thanks!

1 Like
28

To confirm. Prototypes can inherit from other prototypes. Going back to an earlier theme of getting the ‘right’ Key Attributes one approach you could use is a ‘base’ prototype with the KAs used for all types then set the inheriting prototypes to use an edict (you don’t want this running all the item:

$KeyAttributes = $KeyAttributes(prototype)+"SomeAttr;OtherAttr";

…where the added string is a list of the additional KAs to use in that prototype’s KAs (no $ prefix here!).

Another approach I’ve used when making heavy use of KAs is to make several prototype whose only purpose is to define a set of KAs. If the main prototype for a group has no local $KeyAttributes it will inherit this from its own prototype. Thus, buy changing the prototype’s prototype the KAs altered.

This isn’t a day one thing to try, but as you get to know your data and emerging structure better it can be useful.

My inityal use case was I was making notes about papers elsewhere and in the discovery phase i wanted a lot of addressable metadata about each: putting it in attributes was more useful than putting it in general $Text. At a later analysis phase I wanted to to capture emergent analytic information (again wanting it de-interleaved from $Text). I also wanted some attributes from the earlier phase, e.g. 3-4 source data URLs pertinent to the note.

I could have simply have changed the reference notes’ prototype at (what I thought was) the end of the initial data collection phase. But being able to swap the different sets of KAs, e.g. when i needed to re-explore a source note, just by changing the prototype’s prototype (which then update >1k notes) it was a real force multiplier.

29

Useful tip, Mark. I might steal that idea!

30

I rather like VisibleAttributes. I think we could use that moving forward, while also supporting reference to KeyAttributes as equivalent.

2 Likes
31

Sounds good!

1 Like
32

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).

33

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
34

$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…

35

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.

36

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.

37

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
38

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
39

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.

40

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…