What is the current procedure for treating User Attributes that were set up in a Source project, but not in the Destination project that the Note is pasted into?
I was under the impression that they get truncated; but upon copying over a handful of legacy notes to a new project, I observed these ‘orphaned’ Attribute names show up in the DisplayedAttributes pane - no individual values assigned, but the Attributes themselves are displayed. They do not show up in the Attributes Inspector, as is expected.
So what I’m wondering is - in what manner/method are User Attributes displayed in the Destination project? Do they get ‘saved’ somewhere? And could I deploy this behavior as a safe ‘hack’ to identify those User Attributes I may need to create in the Destination project?
The value of $DisplayedAttributes is a list of strings, and so it’s copied from the original project. If $DisplayedAttributes contains an element that’s no an attribute, the element is grayed out and the value is disabled.
If you want to use those attributes, enter the Displayed Attributes configuration pop-up (top-right of text pane) and click out of it. Tinderbox will now ask you if you want to create those ‘new’ attributes. Tick the desired items and set a data type and click outside. The attributes are now created, although things like suggested values, default, description would still need manual attention in the Document Inspector.
If you want the values for the above attributes, simply delete the note(s) and re-paste them. As the previously missing attributes are now defined, the pasted notes will retain their values for those attributes.
OK great! The latter part is what I’d begun to do while transporting some Notes around; wasn’t sure if it was kosher. Good to have confirmation. $DisplayedAttributes is remarkably versatile!
Anyone else having this issue. Resizing such windows as I can resize does not change the display of these two pop-ups, ie, resizing doesn’t solve the problem.
Well, that’s odd. Never seen that effect and can’t reproduce it here. No, by accident, I think I found the cause. When you click outside the first pop-up, where do you click? I ask as the only way I can replicate this is if, instead of clicking off the initial pop-over, I click on the pop-over calling button.
I think I see what happens. When you click the open Displayed Attributes pop-over button with the pop-over already open, the current pop-over closes triggering the secondary pop-over. But the click also re-triggers the original pop-over to re-open.
So please try this. Open the pop-over with the undefined Displayed Attributes names. Now click anywhere outside the pop-over except the button used to call the pop-over:
Incidentally, the second pop-up still works, albeit some of it is obscured.
I’m intrigued by your attribute naming. You seem to use at least 3 different styles:
normal Tinderbox style: ‘Address’, ‘FullName’
normal but with lowercase first character: ‘candidateNatGeoWeb’
all lowercase ‘blogmaybe’
Unless these have definite purpose, I’d strongly suggest using one consistent naming style. Otherwise it is increasing the likelihood of an unnoticed typo causing a head-scratching code failure to have to trace. If the different styles are due to import from some other source, there is noting to stop you renaming (user) attributes to use a consistent style. For examples ‘blogmaybe’ → ‘BlogMaybe’, to whatever style to choose. If you have code already using the different styles that will need manual editing as an attribute re-name doesn’t alter action/template code already in the document. I only mention this as at one point I did similar to above but found that once I used a single consistent attribute name style inside Tinderbox, I have fewer strange (normally typo related errors). Remember that attribute names are case-sensitive.
If the above explanation on where to click to closeems complex, image the button to open the Displayed Attributes pop-over is labelled “START”. We could then say: to close the pop-up click anywhere except on a button labelled ‘START’.
OR
(having checked). If, having set up your chosen Displayed Attributes including new attributes, you can press the Escape key (⎋) and the pop-up will close and still open the secondary pop-up. You can now either add the new attributes or click Escape again without making an any changes to leave Displayed Attributes as they were. I’ll admit I find this a bit counter-intuitive as I’d assume the first button press would close the first pop-over without calling the second pop-over as I think of Escape as akin to ‘Cancel’. But, whatever. If it helps, give it a try!
Hi, Mark,
Thanks very much! I had gotten the impression that clicking elsewhere did nothing, and that therefore I HAD to click on the pop-over calling button.
Obviously that was a mistake. I appreciate you taking the time to straighten that out.
As for the name consistency, yeah, that is good advice. These attributes were created in two different Tinderbox files that once served somewhat different purposes.
I have mixed feelings about the fact that you are right. On the one hand, yes, it is wise to do things in a way that poses the fewest problems. On the other, it is a sort of cognitive tax whenever software demands that we think as its creators do, and not as we do. But that’s a philosophical can of worms not worth opening in this context.
Thanks again for your thoughtful answer. Your work is much appreciated!
To be fair, I don’t think it is a case of the software ‘demanding’ anything here. It is simply enlightened self interest — avoiding confusing oneself. I’m a clumsy dyspraxic typists: what I think I’m typing isn’t always accurately reflected on the page. That despite several layers of helper systems (spellcheckers, etc.) in the app, OS, etc. I thus embrace simple rubrics like a single style of capitalisation, as it helps me to spot my errors.
I suspect some of the naming constraints (see here) arose form an early app design aim to allow people to write actions with very permissive syntax and let the app ‘just’ parse out the sense. As action code’s reach and complexity grew I suspect that laudable aim became unsustainable.
I strive to maintain a consistent naming system - to the extent that I keep a separate list of my commonly used User Attributes outside of Tinderbox; it takes only a few seconds to verify spelling and/or any name changes (my list includes “current name” as well as “previous names”).
This practice is priceless for someone like me - last week I moved over 500 notes between various files while re-structuring some of my projects.
On a side note - I also maintain a few Stamps across projects; for example:
Stamp 1 - “Minimal DisplayedAttributes” [$DisplayedAttributes=“Created;Comment;URL;”]
Stamp 2 - “AllUser DisplayedAttributes” [self-explanatory]
Stamp 3 - “TheWorks DisplayedAttributes”
And also! It can be fun to add $DisplayedAttributes to the list of DisplayedAttributes
That makes sense, Mark. And on further thought I agree that this isn’t a very good example of what I was talking about. And in fact I am talking about 2 different things. The first is the way Tinderbox declines to use conventions we’ve all been trained to expect by their standardization in other Mac apps (where is Update? In About or in Prefs? Nope, it’s in Register; where is History? you have to create your own; that sort of thing). The second is the way Tinderbox insists on its way (attributes can’t have spaces, a B is not the same as a b – even in instances where the user doesn’t want case to matter, that sort of thing). I suspect as you say that the latter examples arise for good reasons, having to do with all the things Tinderbox can do.
Anyway, I totally agree with the larger point – consistency is essential working with a lot of data.
Ah, the old chestnut of the association fallacy, here in the form “I use App X a lot. This is not like app X. Everything should be like app X.” This cause is not considering context. As an Englishman, if I go to France, is it patently apparent people are driving on the wrong side of the road; a French person would disagree. Depending on conytext we are both right and both wrong.
A quick canter round my large set of apps shows a lack of consistency. If really exercised about menu choice, please write direct to support as this is a user-to-user forum and we can’t fix this.
Well, lots of apps use Sparkle, a third-party tool for automatic installation of free updates. That model works for games, and for abandoned software. Because we did not adopt it, Tinderbox did not join MORE, Agenda, and so much else in the dustbin.
I’m not sure that History is a standard software affordance. It’s common in Web browsers. We used to have History; Storyspace still does.
Well, on the side of “names can have embedded spaces and case doesn’t matter”, we have
Finder
On the other side:
Just about every programming language, from FORTRAN through Clojure and Swift
Just about every scripting language from sh to EMACS to python and R
There are good reasons for these decisions. Case is easy to handle in English*, but it’s tricky in some other languages, ambiguous in some, and has no referent in others. (A few years back, we opened attributes to permit most Unicode characters not otherwise forbidden, but even there it’s messy: is does “ß” match “ss”. Does Hückel match Hueckel? Is Aarhus equivalent or Århus? Archæology and archaeology? Does “naive” match “naïve” always, or only in The New Yorker? Things get even more complicated in Chinese. Then there are languages with multiple writing systems, like Japanese and Zuni…)
If spaces are allowed in attribute names, you either need to quote attribute names or otherwise delimit them (bash), or your parser needs to work overtime because a space might be a token boundary or it might not. That in itself makes your grammar context-dependent, which can be a big deal in terms of implementation and performance. This could also give rise to the need for new and obscure precedence rules and would greatly complicate error messages.
Elsewhere, we’re now pretty good at idiomatic, localized case-conversion and comparison operators. .icontains() is your friend.
It’s just a notation.
Not always easy. In English, Jack is a good driver, but a jack belongs in the trunk. And, of course, Title Case In English is not La casse de titre en français.
Attributes need to be findable in our inputs. How useful would allowing an attribute name t E x_t really be. The more permissiveness, the more coding to try an understand user intent. For a small developer, that’s more use of a finite programming resource for little gain. Put another way, sometimes choice doesn’t help in the round.
To be clear consistency might imply either/both ‘avoidance of errors’ or ‘becoming habituated and not learning new things’. In noting that I implied the former, I’m as prone as any to the latter but have leaned that consistency in terms of habit generally works against one unless fortunate enough to work in a niche that sees little change. As an erstwhile general consultant, where there are no norms and every day is a school day, I’ve always been slyly envious of those who learn a thing and then just do that over and over again. I should be so lucky.
Writing—and maintaining—aTbRef has become a good prod to me to not stop pedalling on the learning front. Helping out here I’m daily surprised by people arriving with uses of Tinderbox I don’t know or recognise yet which is their norm. I now think of Tinderbox as ‘an Erector Set† for thinking and noting’.
There are lots of apps that do part of what Tinderbox does, but there’s the rub. They may do that part better but ont other things. Thus if the part is all one needs, there may be a better primary tools. The fact that I ‘live’ in Tinderbox (well and BBEdit - another toolset app) suggests there aren’t many wide toolsets around—given that i’m also one from trying out most tools.
† or ‘Meccano’ for those of us on this (East) side of the Pond. Or Lego, if one prefers.
I recall a meetup discussion (around April?) where we agreed that Tinderbox was so flexible and powerful that a little knowledge of and commitment to learning a few ropes as well as building consistent habits yields enormous payback.
As a pattern-recognizing creature, I am a big fan of the visual appearance of text. As a longtime Mac user, I’ve long since been a camel text aficionado. For example - the visual pattern of “UrgentNote” is unique and cognitively distinct, allowing me to identify and process accordingly with minimal latency. What I’m trying to say is that consistency and pattern recognition was biologically necessary for survival and thus baked into our neural circuits, so why not take advantage of it now?
In light of 1) and 2), I feel that some measure of consistency in both the design and usage of our tools - whether Tinderbox or an earth-mover or electron microscope - are only to the benefit of the user. Over time our habits meld with the app and graduate into our own unique toolset; allowing us to experiment, blend, and synthesize new knowledge relating now to the content of our work.
That Tinderbox is such a flexible tool - in effect, allowing the user to drive all over the road and off it and then take off and fly (Chitty Chitty Bang Bang reference) - can perhaps be recognized in the words of Voltaire (or Uncle Ben, depending on whom you ask), that “with great power comes great responsibility.”
I’m plagued by the call of improvisation, re-synthesis (and regularly pouring data from one app to another!). It’s actually perhaps the main reason my brain does not willingly grasp or long retain the rigor and structure of programming. I assemble my own structures, whether in story or music, and live with them, learning to love them eventually; somewhat like Dr. Moreau. It’s a bit of a lonely living, but I’m exploratively compelled and have come to terms with that.
In the ‘not related to anything but nevertheless weirdly apropos’ compartment - one of the side results of growing up in India was the absence of “Pond” variance. I owned both Meccano and Lego sets, and often blended them to create novel structures that wouldn’t have been possible with either individually. Come to think of it, my own process now makes a little more sense to me. Thanks, Obama!
Amen. I used to assume the software (and its hidden designer(s)) had to be wrong, as how can my intuition be wrong. But experience of all of beta testing, volunteer supporting (i.e no under-the-hood privileged access), and writing documentation of others has cured me of that conceit (even if the feeling lingers).
The self-first, self-validating aspect of modern (Western) culture validates person view above all else, and not to our betterment. I’m the child of two parents who left mid-school, on their birthday, to serve in WWII and an others-before-self view was a constant drumbeat in my childhood. If nothing else, it creates the space to assume—before reflexive judgment of others—that it might be the mote in one’s own eye rather that the beam in the others†. An adulting achievement is to take pleasure in learning rather than seeing it simple as leaving less time for watching reality TV/social media.
That word has its own ‘Pond’ variance. The first time I saw ‘legos’ (AmE) I though LegOS was a funky new OS because in BrE ‘lego’ is an invariable noun. But, Lego(s) and Meccano together? Chapeau for colo[u]ring well outside the lines!
† Insert $deity-appropriate parable as necessary. They are all the same metaphor for self-diminishing self-privilege!
In Vancouver, BC, during the late 90’s (dating myself, too :)), I worked in student support at a renowned Arts and Industrial Design School. It was the beginning of the (public) internet, and technologies like color/colour printing, design-based applications (and their emerging paradigms and toolsets), and digital file exchange were nascent-but-rapidly-maturing.
It therefore became my defacto responsibility to learn ALL the commands, shortcuts, and menus of the gamut of design and art apps (Adobe, Corel, Quark, Autodesk, and many now defunct) - mostly only to ward off (privileged?) student meltdowns in our computer labs that housed 150 Macs (and 5 Windows machines!).
Fun times. I developed a bit of a reputation as a walking helpdesk, as well as an appreciation for sussing what the designer/s had in mind regarding feature choices. Mostly, I learned to accept the things I could not change, and to assist students and faculty in overcoming them
only yesterday, clearing out, a came across a stack of those fanfold icon/shortcut cards that used to come with the big Adobe apps, listing all the icons/shortcuts. Still, it was magic. I recall the day back c.'95 when I sat down, installed Streamline and Premiere and in [too may] hours had scanned a stack of hand-drawn images and made some an animation (with much thumbing of the manuals (in the days when you got a paper manual). It truly felt like living in the future.
Learning point: friends don’t let friends make minor UI animations using hand-drawn 12 fps images.
Still, we knew no better and couldn’t afford adult supervision. But knowledge is a game where all can play. I recall the moment when, beta-testing an invite-only DeBabelizer† beta I found all the other player were big-name outfits like Disney. Imposter syndrome? Much.
My first public white paper was back in '99 (though it started awhile before) showeng how to make a cross-OS CD running Acrobat Reader off both Mac and PC partitions—recall at the time Mac & PC didn’t share media (you needed special apps for that). I well remember bemused Adobe staff contacting me after I first posted the paper‡:
them “How did you do this? We didn’t think it was possible”
me “What? But, it said so … on the side of the box”
them “No one reads the side of the box. Seriously, what did you do?”
me “I just tried, as I couldn’t afford to pay someone else.”
them “So are you making money off this?”
me <blush> (bearing in mind we were ‘cash poor’ at the time) “Am I supposed to? I just thought sharing might help other people”
<line goes dead>
Funnily enough before CDs went to the scap heap, every few months I’d receive a jiffy back with unusual stamps, with a CD - "Look what I made using your doc. Memorable were one from the inner sanctum of the Vatican and one that came partly on mule-back from a UN project in the depths of the jungle in the North of Laos. I like karmic closure, having learned so much by the kindness of strangers.
Different times, different values. But the experience stayed with me in 2004 when starting aTbRef. My webserver was paid for, so everything else was my willingness to learn and to write down what I learned. Answering other people’s queries taught me a lot; actually they are less stressful as nothing rides on the outcome apart from there being an answer even if it—occasionally—is “not possible!”. On balance, I think I made the right choice.
†. Yes, figuring out a single 256-colour palette for a whole CD’s worth of images was a real task, once upon a time.
‡. A hat-tip to the many on the Usenet Acrobat list who contributed signifiicant expertise. We stand on the shoulders of giants.
only yesterday, clearing out, a came across a stack of those fanfold icon/shortcut cards that used to come with the big Adobe apps, listing all the icons/shortcuts. Still, it was magic. I recall the day back c.'95 when I sat down, installed Streamline and Premiere and in [too may] hours had scanned a stack of hand-drawn images and made some an animation (with much thumbing of the manuals (in the days when you got a paper manual). It truly felt like living in the future.