Apologies if this has been answered before, but I was unable to find it in the archives.
Page 50 of the tutorial PDF says to select the PublicationYear from the attribute list. This proceeds to present the entire list of attributes defined in TBX7 (300+), not including user-defined ones.
May I be so bold as to suggest that the list be trimmed to show only attributes that exist within the specified container, since it is a sort function? This would be beneficial from a user experience standpoint since attributes that do not exist donât even appear in the dropdown menu.
âExist within the specified containerâ in what sense? Behind the scenes, every attribute âexistsâ for every note, and it is very possible (and not uncommon) to sort containers by an attribute that is not in that containerâs key attributeâs list or that containerâs prototype.
Checking, this relates to the Sort Inspector and the pop-ups that set $Sort and $SortAlso. Since these were first added, I suspect the System Attributes alone have doubled in number. Perhaps this inspector needs some sort of input box with autocomplete. Iâm not sure a filter as described would work as envisaged as inheritance means more attributes âexistâ in context than perhaps presumed.
I just thought that it might be overwhelming especially for new users such as myself, when presented with such a long list of âpossibleâ attributes. However, the fact that the user is in sort mode means he desires some sort of structure to emerge. Therefore, presenting attributes that are not attached to any particular note(s) will not help with the sorting task at hand. I donât know how how TBX7 works, but a trie-based approach should not make this too difficult. i.e. only return attribute nodes with values greater than 0.
Thanks for taking the time to read this. Just an idea.
Because every attribute can be attached to every note, an approach such as @mwra suggested (search box in the sort inspector) would be a more reasonable approach for all users, IMO.
I donât think this leads to a good outcome. Letâs say we have $Tags in the key attributes for all notes in a container, but only half of those notes has $Tags != ââ. The suggested approach would make it cumbersome for users because they wouldnât be able to use the inspector to initiate a sort of notes based on $Tags.
In a relational database, a SQL query will fail since sort requires a column to exist i.e. you canât return a sorted result set if the column was not specified with SELECT in the first place.
Just ran a test with your scenario and the result (with âreverseâ left unchecked) is that the notes with $Tags are sorted in lexicographic order, followed by notes without the $Tags attribute. And sorting the container of notes where none of the notes have the specified sort attribute just returns the list in order of creation. Which in itself does not make any sense (as explained in the preceding paragraph), lending support for the proposal. i.e. should a user need to scroll through a dropdown menu with hundreds of attributes, of which the vast majority is not used? My proposal is, in plain English: in this container, these notes have these attributes. Put these attributes in a dropdown menu so that they can be sorted. It would be a bonus if they can be sorted numerically instead of lexicographically (I donât know how Tinderbox works internally and this could lead to far-reaching data type considerations so I understand if this part is rejected).
Mark, thanks for the tip. I suppose if the attribute contains mixed types then it would assume the numbers entered are considered strings? Could be a little confounding for new users who donât understand data types and enter a list containing an integer, a float and a string.
