Forum Posts Feed
one idea, one fact - taking note blog post
< Next Topic | Back to topic list | Previous Topic >
Posted by jimspoon
Oct 21, 2013 at 05:06 PM
from mk’s “taking note” blog -
————
One Idea, One Fact—Again
From the Notational Velocity Website: “To make good use of NV, try to maintain one detail/fact/item per note. Notational Velocity’s strength, note-filtering, is diminished when only a few notes contain most of the content in the database.”
This does not just hold for Notational Velocity. It holds for any slip box or note-taking application. I don’t think that this can be repeated enough. So, ...
This advice holds for outline headings and hierarchical note-taking application (or even paragraphs).
——-
The more we atomize our notes, the more flexibility we have in arranging them.
This is why I don’t want to put my notes into some RTF pane, I want my notes to be “in the tree”. Stated otherwise, the tree shouldn’t hold just titles, but the notes themselves. Even relatively short notes (paragraphs) lend themselves to being put into an outline structure. One sentence per item? To me they’re easier to read that way, and the structure of major and minor points, conclusions and premises, etc. is explicit.
I would reserve the “lengthy material” pane for content that needs to be kept together for some reason - for example, a captured web page, a PDF file, some reference material - you would naturally want to be able to see it in the form in which you obtained it. Even then it could be useful to make small sections of it into separate items - with a link back to the original so that you could see it in its original context.
sorry to beat the dead horse - I hope that the authors of the note organizers will take heed some day!
Posted by 22111
Oct 21, 2013 at 09:21 PM
Jim, I fully understand now what you are trying to do, and I often have tried to do the same, only to put my subtree then as indented text into one text pane if there was not enough “meat” for my entries. You also advocate multiplication of entries; if a “regular user” has 10,000 items, you would have 200,000 items instead.
So from my practical experience, yours is not yet the very best solution, all the less so since most things DO have some “natural” or “main” context, and whenever I try to realize such context not by paragraphs, but by siblings/children in the tree, it’s the “meat” consideration that then stops me: HOW to cut up the idea between tree item/“title” and (short) “content” (in the text pane)? Or in other words:
If you try to place too much content into the “title”, it gets unreadable, all the more so since most outliners do NOT permit line breaks within titles (only some do (or did in the past), forgot which ones), and even if you have got some of those outliners, most “titles” will take more than one line, which means that you will have not that many such “subjects” displayed in your tree without scrolling.
Also: If you try to place the info into the “title”, it can become quite long, so you are tempted to place some of the info into the text pane (which normally in your system will remain empty), and from my experience again, the “remaining” info to be placed into the text pane often does not psychologically “justify” the “indendation” done by placing it “under” the title instead of “within” the title, but then, just in the title, it’s too long, so the separation isn’t done for logical reasons, but just for “emptying” a little bit that overloaded tree, and this again will create an unwanted imbalance between such subjects that are ONLY in the tree, and those others, where 1 or 2 sentences are within the text pane, too: Again, because there is no logical decision for them getting additional space, “under” the entry, but only practical considerations, and this interferes with the logical concept you have of it all.
So I end up with titles and very short (but systematic) texts in the respective text panes, and this again will show those disadvantages of 2-pane outliners some of our fellow users have often mentioned here, and which cannot be denied.
This being said, there IS a REAL need for further atomization, not the slightest doubt about it, and as I have mentioned, in legal texts, books of 800 pages are often divided up into some 3,000 paragaphes, called “Randnummern”, “Rn”, and here there is free cross-referencing between them. But you READ those books on paper, mostly, or if you read them in electronic products from their publishers, those bits, ON THE READING SIDE, are NOT divided into 3,000 different bits, but into chapters, and then some 8 or 20 such bits in one chapter, which means, within the tree they offer, you will NOT find those bits, but the chapters only, when in fact the “Rn” bits are paragraphs again, within the “text pane” of the reading thing.
This (and we are of extreme examples here) seems to indicate that for CREATION of text, such atomization is helpful, but not on the “receptive/reception side”.
That’s why so many users here are begging for inline outlining: Since within their “natural” context (for alternative contexts, cf. what I’ve written re Outliner “Viewers? eBook Creators?”), it seems to be reasonable to have direct visual access to the context, too, without navigating the tree, in which you would navigate for the “next step”, though, but not for the next atomized bit.
Then, we are speaking very atomized bits here, since in the mentioned post I speak about bits of “up to one page length”, which also could mean a single (a little bit longer) paragraph, or 2, or 5, depending on the “mini-” subject.
But so, we have to accept that there are “bits”, single paragphs, or even single sentences, and then, such “mini-subjects”, self-contained aggregations of bits already.
Again, I don’t have a good solution to this (and I tried them all, spatial representations and such), but I think that for practical purposes, developers should indeed put inline outlining into their 2-pane outliners (the coding is quite difficult…), and also should allow for cross-referencing such inline items.
In this context, it’s only fair to mention MyInfo again, since there it’s possible to cross-reference paragraphs, within the whole file, and I sometimes think that I didn’t dig far enough into the possibilities this MI feature permits for your writing - I had been too much disappointed by missing things in MI, but that was at a time I hadn’t grasped already there is really no further real development in competitors like UR and such, so perhaps this is a valid reason to look again at MI. Or the other way round:
_____Which outliners currently permit cross-referencing not only to items, but to paragraphs, beyond MI?_____
(It goes without saying that better functionality that currently is available in most outliners, for gathering text bits, is highly wanted; we discussed this in a CT thread because CT permits this, as seemingly the only outliner/PIM currently.)
Posted by Dr Andus
Oct 21, 2013 at 09:43 PM
jimspoon wrote:
>This is why I don’t want to put my notes into some RTF pane, I want my
>notes to be “in the tree”. Stated otherwise, the tree shouldn’t hold
>just titles, but the notes themselves. Even relatively short notes
>(paragraphs) lend themselves to being put into an outline structure.
>One sentence per item?
Interesting topic. Doesn’t WorkFlowy does this already? It’s a single giant outline with inline note capability.
>I would reserve the “lengthy material” pane for content that needs to be
>kept together for some reason - for example, a captured web page, a PDF
>file, some reference material - you would naturally want to be able to
>see it in the form in which you obtained it. Even then it could be
>useful to make small sections of it into separate items - with a link
>back to the original so that you could see it in its original context.
In fact MK was kind enough to write an AutoHotkey script for me that does exactly that with CT (create a new note with the selected text and include a link back to the original):
http://drandus.wordpress.com/2013/01/10/academic-writing-workflow-with-connectedtext-freeplane-and-outline-4d/
However, I have to say I didn’t end up using that feature in the end all that much (even though it’s very clever). In fact I’m doing wikis “all wrong,” because I’m keeping my notes in long documents in CT. Why?
For one, it just feels tidier to have a smaller number of documents than a huge number of them.
Secondly, I find it time-consuming to create new documents (give them titles, categories, templates, icons etc.)
But the main reason is that CT’s powerful search capabilities obviate the need for breaking long documents up. There are searches for the entire database, incremental searches within a note, and some other searches I don’t even understand how to use :)
But my point is, if you have a good search engine, you don’t need to waste your time breaking things up and annotating things, when you find anything every time anyway… My 2 cents…
Posted by Dr Andus
Oct 21, 2013 at 09:55 PM
Dr Andus wrote:
>But my point is, if you have a good search engine, you don’t need to
>waste your time breaking things up and annotating things, when you find
>anything every time anyway…
Well, I’m not against annotation as such, that’s part of the analysis, so it’s very valuable. What I meant to say is that I do the annotations within the long document, rather than breaking them into smaller notes and annotating them that way.
But this might just be a limitation of the tool: if there is another tool that can break things up more quickly and give titles automatically (made from the first line or from a selected piece of text), while also linking them to the original which remains intact, then I might change my mind…
Posted by Dr Andus
Oct 21, 2013 at 11:09 PM
But when it comes to writing, I definitely agree with the one idea = one note = one paragraph. That’s exactly how I’ve been using O4D for reverse outlining: write one paragraph in one outline item, then give it a title to express the main idea of the paragraph, and start a new outline item for the next paragraph (or split the note). And that’s also how I use Gingko: one card for each paragraph, then give it a Markdown heading (a title and a place in the hierarchy).