Notes, titles and text

[tedhogan]

[Admin: I split this to separate thread not as censure but to give this branch a thread its own. It is an interesting point. ]

I would like to ask a question that came to my mind while reading this thread. Forgive me if this has the potential to side track the conversation. I can move it into a separate thread if wanted.

From my view, notes seem to require a title and a body in Tinderbox. “Blocks” in some other programs are roughly akin to a bullet point in a list or a note with only a title or only a body.

So, I find myself mostly wanting to jot down random notes in map view without bothering to attach a title. Usually, I solve this by just entering a title as the text in the map view and not bothering with the body.

Is there a better way to accomplish this?

I just feel like I may be missing something important here.

Thanks!

[eastgate]

That’s fine.

If you need to refer to a note by name, long names can be a bit of a bore.

$Color(/Archives/Confirm that Hobsbawm actually coined ...)="red"

Sometimes you may want several paragraphs in a note, which is awkward for titles.

But sometimes you aren’t yet worried about automation and don’t need paragraphs. It’s up to you.

[mwra (Mark Anderson)]

@tedhogan

notes seem to require a title and a body in Tinderbox.

Require? No. Here are two notes with with no title or text atop a map adornment with no title:

But wait, how can the app track items like these? It is done via an internal unique ID. Initially hidden, in v5.6.0 (Sep 2010) it was made accessible to the user as $ID.

So, ‘required’ no, but in terms of design intent, notes would have a title ($Name) and may have body text ($Text). In some PKM or outlining systems, the note might be one piece of text (with out without discrete paragraphs), in others the same but with all or part (if long) of the text used as a title.

For instance OPML, if one reads the actual spec, it is apparent it has no notion of ‘text’. But, don’t lots of apps use OPML and exchange text? Yes, Tinderbox (here) amongst them (v2.5.0, Jun 2005). As best I can trace it, the divergence is Omnigroup’s OmniOutliner that added a custom extension _note to the format which many now think is part of the text. Because in OPML what we might consider the title goes in the text attribute, while the text goes in _note (at least for use with apps that know about that custom convention). Even that may enrage some as it only supports plain UTF-8 text, so no highlighting supported.

Linkage is another battleground. A recent crop of PKMs, drawing on wiki-mark-up notation, use [[…]] notation. Add an un-styled note space using inline mark-up (currently Markdown is the poster-child) add soon we have many people whose only concept of making/marking a link is [[…]], oblivious to what’s really happening. Again, Tinderbox is accommodating—see ‘Text link creation via the Ziplinks method’.

Thus it is that the PKM/note-taking/outlining domain is bedevilled by:

• WYSIWII (What You See Is What It Is), i.e. it is what it looks like.
• HIWIWII (How It Works Is What It Is), i.e. things must work in a certain way (q.v. [[…]] links)
• TAWDFMA (ThisApp Works Differently From MyApp), a variation on HIWIWII.

WYSIWII address the tendency of many (most?) of us to work backwards from an idealised ill-defined but sharp-edged mental view of how things should be. IOW, getting to re-paint the room countless times until it ‘looks right’; easy, no understanding/thought involved! HIWIWII speaks to the constant issue of paradigm mismatch: “ThisApp doesn’t do task X in the same way as OtherApp. Everything should work like OtherApp (unstated part—I use OtherApp a lot and know it far better”. IOW don’t make me think.

I googled ‘Block Reference’. If using ‘normal’ Web behaviour, there is no answer as page #1 of results is all about CAD apps. If we roll our eyes and go to page #2 there is a link to " How to Use the Block Reference Menu in Roam Research" which starts “Everything is a block in Roam Research” before failing to explain what an addressable block is and rapidly dumping the reader into easy-to-understand constructs like:

I’m sure it works (I don’t use Roam) but sadly I’m none the wiser other than that it appears to mainly work of literal string matches. Probably (hopefully) there is something like an aTbRef for Roam (and other PKM) that explains all the assumed-self-evident detail. The example above explains why such resources are of value. Now I come to think of it Tinderbox does have block referencing, it’s just not much used or particularly easy to do. Tinderbox does have transclusion, and very richly so, in its export code. Recall, the app’s debut was in 2001 and back then personal web-based apps weren’t really a thing for the ordinary person. Originally such rich views were exported. The march of time and the “don’t make me think” approach of many has pushed the evolution of the Tinderbox preview (originally added in v6.0.0 (Apr 2015) to ‘test’ HTML pages without exporting) in a zero-config Markdown-based preview.

Here, I feel for the app developers. The behaviours above in many (most?) cases rest on real thought and research going back decades. We as users tend to over-emphasise in the User Expereince (UX) part before looking deeper. Many users jump around serially between apps, berating the UX of the last—often for not being ‘new’ or ‘intuitive’ enough in some unexplained way—before rushing to the newest shiniest entrant to the field. There’s a paper for someone looking at the underlying design of PKMs & note-taking apps rather than the visual froth of the UI. I suspect there are fewer ‘new’ ideas around than we are led to believe

In closing I think this sums it up rather well, in relation to non-trivial use of PKMs:

“Do not try and bend the spoon, that’s impossible. Instead, only try to realize the truth… there is no spoon. Then you’ll see that it is not the spoon that bends, it is only yourself.”

[mwra (Mark Anderson)]

@tedhogan

So, I find myself mostly wanting to jot down random notes in map view without bothering to attach a title. Usually, I solve this by just entering a title as the text in the map view and not bothering with the body.

‘…a title as the text…’, but that is a title, i.e. the note’s $Name when see from the app’s perspective.

Is the issue here one of using vernacular from some other app? Regardless, the title—the contents of $Name

@tedhogan

Is there a better way to accomplish this?

Stepping back to design paradigms, up until Tinderbox v4.0.0 (Aug 2007) map icons only ever showed the note title. Since then $Text could be shown in a map icon, and more recently is shown by default as part of the icon—if there is enough space. But I don’t think the core map design is predicated in showing lots of mini essays on screen.

Indeed, screen size is an issue. Whilst there will be those with a 49-inch monitor and a Mac with an M1Mac chip, most common seems to be people working of a 13" laptop screen. Why doss this matter? The more info in each icon, the less will fit (at readable size) visibly on-screen at a time. So a question users often forget to ask themselves before choosing a title vs text/text-length style is"What will fit". Unwittingly choosing a style that has to scrolling or zooming all the time is an unforced user choice error.

Looking a different way, could a title have multiple sentences or paragraphs? Why, Yes, it can:

But notice that the title/edit box in the text pane has a limit to how much of such a multi-paragraph title it can show and doesn’t indicate there is more, unseen—likely because it doesn’t expect to need to do so).

You can still show text with a long title, but of course you need to make the note icon bigger:

…which takes us back to the point about screen space being a relevant factor in choices here.

As regards a title hint, e.g. trailing ellipsis or such, for a clipped title in a map view, the short answer is, no. That’s no a flat ‘NO!’, but rather I recall it being discussed in the community as some depth a while back and the take-away was that there are plenty of other affordances already available: $MapNameSize lets you adjust a notes title size in the name, there are other expansion options for note size. I guess someone could make a feature request (emailed in not here as this is just a user forum) for a trailing ellipsis. Plus, correctly guessing things like the title’s bounding box (the tile has to fit with shape/badge/body text) and the result looking right to the eye is already a long running challenge (not obvious to us users).

A final thought. Maybe we’re looking for certainty where there is no one right choice leading to the false assumption of repeated questions which taking the hint in the answer :

Monty Python's Life of Brian 1979 Alright I am the Messiah

In truth, I know no better than the next person, other that there are choices and choice is a good thing!

[rcramer (Ralph Cramer)]

Very interesting discussion!
I am always a little bit struggling in the outline view, because I’m taking notes during the meeting with a long text in $Name and was experiencing some troubles with special characters and the length of the text afterwards, e.g. in agents.

But the discussion was giving me the idea to use an agent to split up the noted text from $Name into $Text and to use a key phrase in the beginning of the $Name as unique title. And putting it together again in $DisplayName afterwards. Because I want to see whole noted text in outline.

Still not sure if it will work, because I have to put a key phrase in the beginning in all notes and often the key phrase is not “visible” during the discussion in the meeting.

Maybe there is a better approach from your experiences?

Thanks for the interesting discussion!
Ralph

[mwra (Mark Anderson)]

A good issue to raise. Apologies for a light (admin) edit of your post as $DisplayName is the attribute to which I think you refer. $DisplayName is the string resulting from evaluation of $DisplayExpression, even if the latter just holds a fixed string, such a the desired full title ($Name) of the note.

I’ve used just such a techniqwue in some of my doctoral research. There notes were the titles of discrete conversations on Wikipedia pages (i.e. heading from within an archive page). For provenance and export purposes I needed the note title to be the heading as seen at source (on Wikipedia). But many title were very long and ocontained problematic characters for use within Tinderbox.

My solution, IIRC (without opening some enormous TBXs), was thus:

• For any note with a troublesome title, I would put the original verbatim source title in a user string $FullTitle.
• All notes had the Display Expression if($FullTitle){$FullTitle}

Why not set $FullTilte for every note. Well, there were c.4,500 such notes and duplicating unneeded data seemed like point less bloat.

The result is like so:

Thus we see that the $Name of the first note (selected) is ‘Arkle’ but it is displayed as ‘Arkle Farkle’ as that is the value of its $FullTitle. All notes have the same Display Expression. See, that note ‘Nudnik’ has no $FullTitle so the displayed title is $Name (because the Display Expression evaluates to nothing):

Perhaps a clearer Display Expression, leaving nothing to be inferred, would be:

if($FullTitle){ $FullTitle }else{ $Name }

Anyway, here is the test doc from above: FullTitle-demo.tbx (79.6 KB)

[mwra (Mark Anderson)]

Another approach.

Type all your words into one note’s text. At a pause or finish. Review each ‘note’ i.e. paragraph. If the title needs shortening, add a short sentence at the beginning of each paragraph. Now Explode the note on the default per-paragraph break, using the ‘first sentence’ for the title and not omitting text (i.e. the ‘full’ source title is in text). Now you have a list of notes with usable titles.

Another overlooked feature is ‘Split Note’ (Note menu or shortcut).This does require the cursor focus to be in the text pane and in $Text. When invoked it splits the note at the cursor point with all after it becoming a new note that uses the first sentence of the new text as its title ($Name).

I don’t believe there is a title split method (though @eastgate may correct me here).

[tedhogan]

Thank you for all of your contributions to this thread. There is some excellent advice here that spurs thought!

I think the crux of this might be the perceived difficulty or ease of getting information into the system. The importance of that will change with use case. For instance, deliberate research would most likely place a lesser value on this ease of input than would capturing random bits of information as a knowledge worker goes about their day. One case may be a more deliberate and careful effort while the other may be a mad rush to capture potentially valuable information as a secondary effort while focusing on other primary tasks, to revisit and further develop later.

As mentioned in these forums before, allowing too much ease of input can result in systems that are very difficult to retrieve meaningful information from. An equally valid thought is that too much difficulty in inputting can result in a system that is not used. I think both cases have been observed among different types of apps in this nebulous space. I would rather avoid comparisons of apps or approaches themselves as those discussions often devolve into mere partisanship and the essence of collaborative ideation on possible ways to work is lost.

I think the idea might be to be able to input without any thought (no concerns about where it goes, what it represents, anything - similar to a TODO inbox I suppose) and then be able to go back later and further develop.

Some use cases I am thinking about while writing this:

• meeting notes
• highlights from texts
• random thoughts
• ideas

What I have seen on these forums is not that Tinderbox cannot do things, but that the complexity of the tool may serve to obfuscate what is available. Perhaps this could be more of a UX disconnect?

One thing I can say for certain is that Tinderbox has far more capability and complexity than any of the so-called knowledge management or note taking or second brain or whatever marketing term apps do. The only thing lacking in comparison would be mobile capability.

Thanks for your thoughts.

[mwra (Mark Anderson)]

FWIW, I’m a pragmatist. There’s what I want or can imagine. then there’s what’s available or I can afford to have built, or even afford at all.

An under-observed fact is how highly we value our own time versus those —human or automated process—which which we interact. All to often this leads to very poor assessments of the utility/cost of choices.

Speed of input is one such. Even that is nuanced. The perception of speed/ease will differ between the fluid fast touch-typist and a person with only one hand or having to use text-or-speech. “But” we cry “others’ problems are not mine, the ‘system’ should ‘just’ adapt”. Indeed it does though often not to our liking if the optimisation is not in our favour. This is why an element of pragmatism is an exercise in enlightened self-interest.

my italics:

@tedhogan

I think the idea might be to be able to input without any thought

Well in that case we are either just tipping stuff in a bucket or assuming the system is highly attuned to our, and only our foibles. The solecism of “But surely everyone does…” applies here to.

@tedhogan

Perhaps this could be more of a UX disconnect?

Some would argue everything is UX—and UX is everything.

My point here isn’t to disparage the points made (i.e. not just argue for arguments sake) but to unpick the real actionable use case. For instance, I tried typing notes live in conferences but I’m (a) a dyspraxic two-finger typist and more importantly (b) my human brain has a sense of nuance that it’s unreasonable for code to guess (even if built only for me). I could get angry about that, but others would just laugh at my hubris.

A factor here is the view used. In the mind’s eye, we not only type fast and flawlessly, within the speed of the speaker’s ideas, but also triage the view into a beautiful map. So much (over-)valued time saved. In reality very few can go that and then because they also know the appear well. The wrong inference is the that the app design is sub-par.

I think using outline or chart view—basically not map view_ reduces the cognitive load massively. In map view you’re working through the cognitive over load of “Why did it wrap?” “Why is some of the title not displayed?” “Is this the right badge?”, long before we get to “why is my note not pretty like all the examples I’ve seen?”.

One idea—possible feature request?) is a ‘split title’ feature. But, app expertise would suggest its better to capture a short note title, Return to close title entry, Opt+Tab to add some $Text if needs be. Opt+Tab back to the view, hit Return to start a new note.

Ask not, what can the app do for me? Ask, what can I do working with the app?

[tedhogan]

I think the actionable use case is dumping random information from the mind into a digital bucket to be refined later. This is a different use case than constructing deliberate notes from the outset. Perhaps it could be viewed as the most basic of starting points in incremental formalization, one that requires no thought and only the absolute bare minimum of structure?

I agree with the idea that outline view reduces the cognitive load compared to map view. I think that would facilitate quicker input.

My hope for this discussion is to find out other approaches that do work in Tinderbox as it is. An additional hope would be to also engender some thought as to possibilities of how it could work differently.

I have no interest in debating one piece of software against another or the possible motivations of people as the former is unhelpful and the latter usually unknowable.

[mwra (Mark Anderson)]

@tedhogan

dumping random information from the mind into a digital bucket

Ah, the Holy Grail. My experience of that pilgrimage is that I get… a bucket of data.

@tedhogan

Perhaps it could be viewed as the most basic of starting points in incremental formalization

Interesting, but I think that happens after input not during. Efficient input isn’t new, here’s Doug Engelbart rocking a chorded input in the late 60s:

BUT, you needed to invest in technique. As long as my backside points downwards and no matter how much I try I won’t master this.
Thus I’d argue, pragmatically, efficiency is in the eye of the beholder.

If that sounds like push back, it isn’t from that place. I think for input it is—for some (many?)—maybe outside Tinderbox. What‽ That sounds like heresy, but Id argue felicity of capture within your chosen (or enforced) style is what matter. Finding typing hard? Try otter.ai^† or similar. I think sometimes we treat software to competitively where me ‘beating’ the machine (software) gives a warmth outweighing the efficiency of outcome.

I truly don’t think there is a one-size-fits-all answer. I’ve learned (over longer than I’d have liked) to look at app’s strengths rather than tangential weaknesses.

HTH

†. Honesty compels me to note online app mean “unknown server in unknown juris-my-diction” but other options are available. Curmudgeonly as I may be about ‘AI’, it is getting better and i’m all for using it where it helps. Not everyone has ten functional fingers/thumbs so I’m always open to technical assists).

[rcramer (Ralph Cramer)]

Dear Mark, thanks for your support! I would like to test solution #1. What am I missing is an idea for automation. I tried using a prototype with action / rule setting FullTitle to $Name. But after changing $Name to a short text, FullTitle was changed, too.

Using OnAdd is not helpful, because I am not using on big container but many different ones.

Looking forward to your suggestion.

Ralph

[Maximus (Max)]

Returning to this very interesting discussion, I would like to clear some technical moments:
is there a fast way (using only keyboard) to move from $Title to $Text?
Mr Anderson write

@mwra

Opt+Tab to add some $Text if needs be

but that shortcut results moving from $Title to $Subtitle.

And a general question to all:
How do you add notes in Tbx when you’re in “Zettelkasten mode” (i.e. you just jot down your thoughts with minimum correction?
Do you use $Subtitle or $Text to distinguish some information from $Title?

[mwra (Mark Anderson)]

@Maximus

but that shortcut results moving from $Title to $Subtitle.

I can’t replicate this.

Return starts a new note. Return completes entry and leaves focus in the view pane. Opt+Tab moves focus to the $Text area in the text pane; or use Return to start an new note.

Is the a set of steps to reproduce your problem?

[Maximus (Max)]

Thank you, Mark! It works. (I beg you pardon for the delay in reply).
I can suggest one additional step to what Mark wrote: after typing a text in $Text area press Opt+Tab again to return focus to the map. You can then continue creating new notes.