At @dmrogers request, I’m re-posting some thoughts I sent as a DM.
Why originally a private msg? I simply didn’t want to make another long post and which might discourage more folk to contribute to the thread. Anyway, with some very light editing for sense (including changing second-person terms to third person so as to be less direct), …
So, we often describe what Tinderbox does, or does not do, but what we’re pushing on here is the sense to which we are essentially the victims of our past experience, as it shapes our norms’ as to what is expected right.
I think there are two overlapping issues here:
- did our previous note-taking app(s) have a discrete title and body text or not?
- if our note-taker used files, were the filenames the title of the note, in-app or only used under the hood to link files in-OS to content in-app.
This digs into the under-discussed aspect of what do we expect a note’s title (forget the attribute’s name for a moment) to tell us, in-app?
A linked aspect we might also check, is why are we trying Tinderbox? Is it replacing another app and if so, what did the other a not do for us?
I note these as all too often we get new joiner’s moaning that Tinderbox works wrongly as it not like [app they know]. So are they escaping a bad experience or looking for more capability? The answer leads to a different way to help them (e.g. in @dmrogers’s HHGTT).
We also overlook different domains’ perspective. In some of the humanities, argumentation is expected to be a visible part of the structure (this supports…, this opposes …, etc.) but that not a universal. Of course, experience is again a dis-enabler here as it colours our norms. If I expect very visible argumentation structure, then that not being front and centre of a how-to may be perplexing—and vice-versa.
I’m coming to see most of [us] are quite blind to this unintentional parochialism. Even knowing there is difference doesn’t stop us naturally reaching for ‘our’ perspective when explaining things: q.v. all the recent discussion of name prefixes. I think much of any to-and-fro discussion is people getting discomforted by exposure to others norms.
An overlooked factor is the subtle effect of a raft of apps in the last decade using Wiki-style linking where the note title—external file or internal text—is used for linking and as the anchor text. This has its own subtle constraints on naming as what might make a clear note title may look odd auto-inserted as anchor text inline in $Text. Using zip-method linking for typing holds an echo of that approach. There’s no ‘wrong’ in that, merely an echo of constraints imported with a technique acquired we an inflow of users who cut their teeth in such an environment.
I still tend to use drag-drop for link creation. My documents often have duplicate $Name values (for valid content reasons) so I consider naming far more in the context of its effect on export (sharing with others) than for internal use (apart from problematic characters).
Map-centric (-only) use can unwittingly add a constraint that what isn’t displayed is not ‘seen’ so may result in longer titles or more displayed $Text. Some people are definitely more visual literal (info must be visible) whereas others are happy to treat notes and their names as a proxy pointer to greater info ‘hidden’ in text.
Prior experience in other notes taking apps and the subset of Tinderbox views/features use are as likely to affect $Name formulation as any more philosophical choice (nor is there an implicit zero-sum choice).
Bottom line: I’ve observed no single common note-naming approach, nor would expect such in a very open-ended tool. But whether the $Name† is repeated in $Text or not, Tinderbox expects a note to have a title and optionally further body text.
†. Yes, I realise it is possible to have a note with no title‡, but does have a $Name which is "". Howe er the places where that is desirable are too niche to be germane to the wider topic.
‡. All notes have a (unique) ID ($ID) within the document so missing or ambiguous $Name or $Path can be routed around. But again, an edge case.