Why did I stop taking meeting notes with Obsidian?

Q & A - getting started with Tinderbox
1

This article is a [great read](

Why did I stop taking meeting notes with Obsidian? | by Romell Avendaño | Oct, 2023 | Medium). The author’s key insights from his use of Obsidian.

The reproduction of useless notes

  • Notes without information, much of the automation led to incomplete notes,
  • Loss of focus, he was not “present” when taking his notes so they did not reflect is experience, the tool was monopolizing his attention.
  • An Outlook clone, data already somewhere else
  • The past has already happened, actionable items had already been addressed, no need for a note.
  • The vanity of the BigBang, the graph view became useless, blowing things up, did not do harm

For me, the big difference here is the difference between a vault and a thinking tool, like Tinderbox–something that lets you not just enter data, but do it with limited structure, view it from different lenses, transmute/transclude/include/transform data, and export it to any output (structure and appearance) you want.

2

Rather silly essay. The writer doesn’t have an Obsidian problem, they have a focus issue.

3 Likes
3

As I see it, the author focused (or still does) on what to do to his notes, not focused on what the notes do to him. And to me the article is more interesting as an illustration of this broader failure mode, rather than in the way it was intended to be interesting.

Also, my ego was sky-high because, given the volume of meetings I had per week when I generated the graph view, it looked cool. However, after a while, one day, while reviewing my Vault (which I was proud of) […]

People mentioning graph views in f.e. Roam or Obsidian are like a code-smell for this phenomenon to me at this point – I’ve never seen someone actually documenting how they got something useful out of these graphs, yet people obsess about structure of their entire body of notes to make it look pretty. Note how this article also is an example of neither giving any info about the actual usecase, nor about what advantage any of the notes actually are intended to bring.

So what the author did:

  • set up automation to make his notes “neater”
  • realized he does not need the information (clear sign: did not even bother entering it, because intuitively, he already knew)
  • got discomfort from his notes not being “neat” (again, still focused on “neat”, not seeing them as a pure means to an end, i.e. being fine with a mess, if it does not hurt you)
  • deleted all his meeting notes, to relieve the discomfort

I’m not saying you always need to know the purpose a note will have in the end in mind before creating it. After all, that’s impossible as we don’t know the future. I think creating notes just for time-capsule purposes and just-in-case is perfectly fine – as long as it does not draw your attention away from your main task in a way that detriments what you are trying to accomplish too much. And that seems to have been the case for the author. The reported loss of focus could be attributed to caring too much about his fancy tool and neat notes as well.

PS: I find thinking about what the notes do to future you as opposed to what should I do to my notes to be a lot more useful and have not seen it spelled out anywhere else, so I thought this might ring with some people here.

1 Like
5

Notes cover a wide range of use and meaning. It might be the master plan or a sketch if that plan, a just a part of the plan or simply a proxy to remind us work on the master plan. Yet, all are notes. It is the addition of process and/(software) tools where unintended balkanisation of perspective occurs. This breadth of field in note-taking is why it is often difficult to answer the seemingly innocent forum question “How do I…?”.

Someone steeped in GTD and someone who takes fleeting notes as proxy anchors via which to revisit ideas are definitely not the same sort of note-taker (though one person might be each in separate parts of their work/life). Confusing the nature of the note-taking of a questioner in the forum and the ensuing friction is a common trope in the forum. People are trying to help, but the questioner gave insufficient context to enable those assisting to calibrate their help.

We also tend to confuse the note-taker with their note-taking process. We like X’s successful use of notes, we adopt their tools/process, without the same success. We forgot to adopt their PoV and if we don’t then we need to temper our expectation of magical outcomes.

I also regularly see exploratory/analytical note-taking getting mixed with list-making and noting for retrieval/learning. Both are valid, but definitely not the same. Happy are those who can live with that seeming dichotomy, even in a single note-taking tool. Those who assume insight is only the output of process are more likely to suffer disappointment.

I’d also observe the those with the most notes are not necessarily the best-informed or most efficient. The process can become a subtle form of avoiding the real work, q.v.

Right back to my note-taking. Indeed, should I make an note about this? Perhaps some insight may thus emerge… :slight_smile:

5 Likes
6

Are there any of the new note-taking apps that are interesting to this group or are they insufficient?

Im considering ending my roam subscription because In three years Ive really not needed its true advantage which is its filtering technology. Its nice to have, but my workflow doesn’t need that level of power just yet, but graph view is nice to have…

7

They’re all interesting.

Tell us about the filtering technology of Roam?

9

I looked for an official explanation but couldn’t find one.
This is AI generated (for your convenience)

Query Syntax and Functionality

  1. Basic Query Structure: A query in Roam Research is initiated using the /query command, followed by specifying the criteria within curly braces {}. The basic syntax allows for searching keywords, page titles, or specific tags.
  2. Variables in Queries: You can specify variables (e.g., [[Page Name]]) to search for references or links to particular pages. This is useful for pulling up all mentions or linked references to a given topic.

Boolean Logic Operations

Roam Research’s query language incorporates Boolean logic to enhance the specificity and flexibility of searches. The primary Boolean operators used are:

  1. AND: This operator is used to return results that match all of the specified conditions. For instance, querying for blocks that mention both “Page A” AND “Page B” will only return blocks that reference both pages.
  2. OR: The OR operator broadens the search to include results that match any one of the specified conditions. Using “Page A” OR “Page B” in a query will return blocks that mention either “Page A”, “Page B”, or both.
  3. NOT: This operator is used to exclude results that match the specified condition. A query structured as “Page A” NOT “Page B” will return blocks that mention “Page A” but do not mention “Page B”.

Advanced Query Functions

  • Nested Queries: Roam Research allows for nesting queries within each other using parentheses to create complex logical structures. This can combine different Boolean operations in a single query to refine the search further.
  • Date and Tag Filtering: Queries can be tailored to include or exclude specific dates or tags. This is particularly useful for organizing tasks, events, or notes associated with particular time frames or categories.
  • Wildcards and Partial Matches: While not a traditional Boolean operation, Roam supports using wildcards for broader searches, allowing users to find blocks that contain partial matches to the query terms.

Practical Applications

The query feature in Roam Research is invaluable for a range of applications, including:

  • Daily Reviews: Pulling in tasks, notes, or priorities based on dates.
  • Research: Combining terms related to a research topic to see all relevant notes and sources.
  • Idea Synthesis: Finding connections between disparate ideas or notes that may not have been explicitly linked.

Conclusion

Roam Research’s query language is a dynamic tool for navigating and extracting value from your digital garden of notes. By leveraging Boolean logic, along with Roam’s flexible query syntax, users can perform intricate searches and automate the organization of their notes, tasks, and research findings. This functionality underscores Roam’s utility as a tool not just for note-taking, but for thought processing and knowledge management.

10

OK: is there something in this AI summary that was absent in Tinderbox since 2001?

3 Likes
11

I’ll attempt a human summary for you. I’ve used Roam from early beta in fall 2019 until mid 2023 – newer features I would not know about.

Filtering and querying are based on [[page-references]] or #Tags which are inside a block. There is attributes too, but I doubt they were ever used much for querying. Nothing exciting so far. But: the UI is great and you can filter the list of references to a page too, not just the main body of the page.

image
image2132×586 92.2 KB

Based on the content of the page you are looking at, you get buttons, to set/remove filters with a single click. If there is many, you can start typing in the search box to narrow down what is presented as a button.

You get the same functionality for references to a page, which are shown on the bottom of each page. A button to search within the content these referencing blocks is included too:

image
image2052×938 115 KB

12

Assuming ‘references’ means links, in Tinderbox the list of a notes in/outbound links is found in the Roadmap dialog. Tinderbox does not use on-the-fly wiki-linking that I think Roam may use. Links in Tinderbox are directional but can be traversed or queried in either direction.

The most striking thing, when trialing Roam, is the feel of an IDE. So , for a programmer whose using thinks like VSCode or Sublime to code and Slack, Discord, etc. for realtime chat Roam would look right. Conversely, if not from that background it can seem hard to read - lots of text, minimal/no UI. There’s no right/wrong in that but I think this makes comparison difficult because it is not just feature parity but how one interacts with the features. The latter is very subjective so hard to assess for anyone but oneself.

The chick and egg of any note-taking/sense-making tool is the the balance of who is in charge. Do we start with the information (notes/data) and tease out the structure or do we assume the app does this. Computer-in-the-loop vs. Human-in-the-loop. I see Tinderbox in the first of those categories, I’ve insufficient use of Roam to place it in such continuum.

More control means more user choice, which some of us see as failure if we presume the app should magically do that for us. But again, this isn’t a binary judgement. It’s a continuum reflecting the diversity of individual humans.

1 Like
13

Typing in a tiny text box about something that should be a blog post.

I have very strong opinions about meetings.

If a meeting is intended as anything other than a way for someone in the hierarchy to reinforce their position in the hierarchy, then there should be a support infrastructure.

  1. The agenda
  2. The read-ahead (And I pity the fool who didn’t read the read-ahead.)
  3. A facilitator/technographer. Someone not in the hierarchy who guides the group through the agenda and who…
  4. Records the minutes
  5. At the conclusion of the meeting the minutes are forwarded electronically to all participants and otherwise posted where other interested parties can read them.

Outliners can play a vital role in the work of the technographer, as the agenda is presented in outline form and gradually transformed into the minutes.

There’s a bunch of stuff missing in this description, and I’ve probably forgotten an equal amount. But an agenda projected before the participants in a document that becomes the finished product becomes a collaborative effort, not an exercise in everything else that usually goes on in a meeting.

This is all old hat, going back over 25 years to Bernie De Koven who knew and worked with Dave Winer. I worked with Bernie, paid him to come to our command and train us how to do this.

Otherwise, in my experience and opinion, all meetings are an enormous waste of time or grossly inefficient.

1 Like
14

Will Tinderbox import a my knowledge graph backup file from Roam?

Here is a Roam Dev explaining their 3 export options:

However, if worst comes to worst, and Roam dies, then this is specifically why we have backups. Let me elaborate on the types we offer and when you would use which:

  1. Markdown export: These are the most interoperable (you can even open them with any text editor in your computer). However, they are lossy - because, for example, markdown does not support block references.
  2. JSON export: These are probably the best bet for interoperability in case Roam ever dies. A lot of other apps in the TFT space already support our JSON format for import, and I assume more will if Roam ever dies. The JSON schema is completely open and well documented just for this reason (link to the schema here)
  3. EDN export: This is technically the completely lossless export format. This is the format we recommend users store backups in in case they need to later restore to a new graph. Although it wouldn’t be as simple as the JSON export, if Roam dies, someone could make a reader for this and this would contain all the information in the graph.
15

Will Connor send a little support for developing JSON or EDN support for Roam?

16

In places here, when not explicitly referring to an app, I’ll call the app ‘A’ the app you’re using currently, and the app you might next use app ‘B’. We can guess the actual names but using proxy titles removes the freight of past experience of bleeding subjectively into objective assessment of the task.

EDN, would I be correct (I had to look this one up) it to be this Extensible Data Notation (c.2013)? Only noting this here as the term is far less common than the likes of JSON.

Are those the only options? IOW, it’s the app’s baked in export or nothing? Otherwise, if export to Tinderbox is your goal, you might want to roll your own export for better fidelity of transferring your perspective of the underlying graph.

In principle, yes. But success is highly subjective and the nuances that judgment rests upon may not be well captured. Here A and B share a lot of features although they are manifested in

Whilst Tinderbox will allow linking to anchor text within a note’s $Text, it has no method for auto-generating a reference to ‘block’ N of the $Text.

Indeed, what is the canonical definition of a ‘block’. People refer to ‘addressable blocks’, but that defines what is addressable, not conceptually what a ‘block’ is. If a ‘block’ is that which is addressable, that’s something of an ouroboros as it really only helps defines the mechanistic side of things, not how the user makes manifest their knowledge as notes.

So if app A is conceptually block-based and app B is not, when B consumes A’s data-encoded graph, it is optimistic to assume full fidelity of the experience of A, because the ‘picture’ (the UI experience) in A doesn’t match B. Neither app is wrong, just different. Of course as human users of A and B we find this … inconvenient; we want it to ‘just work’.

So as A and B have no direct per-validated transfer, both must bend. A’s export needs to be mindful of B’s design. A ‘graph’ sounds like complete capture. Form experience moving data around over the years, I’d argue that in such ‘undocumented’ use, it is rarely a full capture. That said, part of the seeming loss of fidelity depends on the user being willing to shift their perspective from the design of ‘A’ to that of ‘B’. A common thread here of people adopting a new tool is “why doesn’t B just behave like A?” because at this point the questioners norm is A. But usually it is an unreasonable request if the design of A and b are properly taken into account.

Markdown, if understood as an incomplete pre-markup of HTML, as such it has links are embedded in a note (block?). Tinderbox adheres to the more powerful, pre-Web, hypertext notion of a linkbase. Links using textual anchors at source (and sink) use the chat.

Unclear about Roam is the relationship of a note (document?) vs. a block. Is a note a set of blocks? Do blocks nest? this is why the lack of clarity about the meaning of a block is unhelpful in terms of moving data between A and B, between systems with different design assumption.

As regards formats, which format is only part of the deal. As important is the object structure of the data in the form. So JSON has rules about encoding data, but makes little constraint beyond that. So, might JSON-LD be better for capturing the source ‘graph’. I suspect for that would need to write a custom export (from A) and parser to generate a file in B’s native format. But, it might give you the fidelity you seek.

17

Thanks for the in-depth support. To answer your questions:
Export options: Yes the three options listed are the only ones available.

Rome lexicon: A note in rome is a page, it is represented in [[brackets]] every line of text Ian the note is separated with a ⏎ exists as an individual “block” making all entries atomic. Further they do nest which is a core feature for Roams query.

18

Thanks that’s useful.

So this is mixed-mark-up style where the bracket indicate a link that, unless stored somewhere, is calculated on-the-fly.

So a ‘line’ of text is the same as the wider notion of a paragraph, a single string between line-feed characters† (or that and the beginning/end of the overall string). So, a paragraph is a block. But, notably, a block can nest a block. Unclear to me is whether a Roam page can be nested.

Clearly, though, two differing design paradigms. Note, again, no zero-sum ‘right’ here. We have:

  • App A. A note contains link-addressable paragraph blocks. Blocks are (infinitely nestable and addressable). Links are calculated on the fly using inline markup. (Presumably a literal [[ inline string would require escaping).
  • App B. A note is an atomic object. Notes can be nested. An attribute of a note is its ‘text’. Links are not calculated but created and stored in a link base. There is support for zeitgeist-y notions like [[ ]] indication of links. Even so, when detected, these are turned into actual link upon detection. Text is not nested, but notes maybe. The app has the notion of note-to-note, note-to-notetext, notetext-to-note and notetext-to-notetext links (all stored in a linkbase outside the note (but within the document).

Worthy of observation is that App B is a server based web app. App B is a Mac (only) desktop app with tight macOS integration as well as integration with other (Mac-based) knowledge tools (DEVONthink, Bookends, etc.); it is also a single-user app, note designed for multi-user use or use-via-any-access. The latter should stop going from A to B but is a point to bear in mind. A (webserver-stored) database for A, a local XML file for B.

For app B to represent app A’s data, given the different design, each block would ideally be exported as if a discrete page (note), I think B’s linking would allow for this though how the lower-level nested items would be named in not clear. As long as page/block names are unique in the corpus, [[ ]] links could—I think—be detected and on first such be (re-)created as text links.

TL;DR a simple one-shot lift from Roam to Tinderbox seems a stretch, but due to design paradigm differences

Consulting the devs of another block-based system, they cite Engelbart’s article on Open Hypertext Systems (OHS) (see). Interesting as whilst NLS/Augment had paragraph links (later, ‘purple numbers’) the article dates from the early 1900s. so, formally after the birth of the Web but before is was at scale. OHS was partly resolving the fact that , then, most hypertext systems were standalone and with differing architectures (see now—see above :slight_smile: ).

However, and @eastgate may correct me here (as we can’t ask Doug), I think hindsight blinds us slightly. Looking at (output of) NLS journal files it is essentially one long text file. So, I assume, outlines were possible as blocks [sic] somehow knew their nesting structure (given the time this might be as simple as being tabs at paragraph start‡).

If nothing else this shows how deep the design paradigm can go. Interestingly, we’re reminded of OHs, another idea essentially kicked into the long grass by the popularity of the web. We tend to view hypertext through the lens of the Web, IMO unfortunately so—without prejudice implied.

And interesting topic to finish the week. :slight_smile:

†. In other words, the character : \n, Unicode : U+000A, ASCII : 10, hex : 0x0a.

‡. Ironically, such simple outline notions crop up in this thread, though I’d contest any notion of outline ‘norms’.

19

Yes, NLS was certainly an outliner — indeed, the first outliner.

As I recall, an outline was represented by a note referencing ID’s of other notes, and the viewspec kept track of whether particular notes were expanded or collapsed.

I think that we could likely import Roam to Tinderbox if we wanted to. There would be some impedance mismatch, no doubt, but I think it could be done without unreasonable effort, especially with some cooperation from the Roam side.

1 Like