51
General Software Discussion / Re: RightNote Revisited / Review (in lieu of a RN forum)
« on: June 05, 2014, 02:40 PM »
Greetings, donleone.
"by namely THERE automatically pulling out & showing together, not just the selected tag, but with it also automatically all the tags that are found WITH your tag, either as a tag unto the left, or as a tag unto the right - in all the items across your entire database.
(and in that sense "related tags", since these are found occurring WITH your selected tag together,
and even just in one single item used together, is enough to make them show up as "related" in that top right corner pane)"
I think this is a tremendously and-powerful, and-helpful feature, and I'm also very interested of the current developments of Surfulater since the developer will abolish traditional tree building altogether, replacing it by smart tag trees; of course, this is a quite different concept from RN's "related tags" (in a way, it's related to amazon's "customers also bought...""), but it's obvious that these two developers, at this moment, are those who are deep into conceptual work re on the tagging front, and I greatly appreciate this.
I make big reservations about (current/traditional!) tagging, and I explained my stance in depth here:
http://www.outliners...revgen-on-bits-again ("prevgen" = mocking of "nextgen" of course),
and if you allow for a very brief summary of what I think about tree structures vs. tagging, it's,
1) with traditional tagging, you will miss both "context in several indendation level shapes" and "context in order/formatting", meaning it makes a big difference if you just get "relevant" items as a list, or if you will have pre-arranged those items (or do this arrangement/grouping work now, that you will work on your items, gathered in disorder beforehand), will have created micro-relationships, micro-hierarchies, by creating "indentations", groupings (= by sub-parenting and putting items as siblings together, and also by creating "divider lines"
- I developed on this here (in point 2): http://www.outliners...messages/viewm/19697 ), in aforementioned "prevgen" thread, and especially here:
http://www.outliners...messages/viewm/19768
where I wrongly assumed there was no sw like RN which did already have multiple trees in one db, as we see now, from your explanations, but in which I exposed my ideas of "live trees" into which subsets of the whole set of material would be put together, creating a new concept of truly independent items, just gathered and ordered in various trees, whilst even RN's multi-tree concept which we know now, clings to the traditional idea of items "belonging" to some specific tree, and then PERHAPS being cloned to another one, or rather, in RN, creating tagging as an expediant, an overlayed structure, in order to replace that missing inter-trees cloning (this is not a criticism, it's just some second concept, overlayed onto the primary concept, the tree structure, in order to give it "complete" functionality, in some way, but not within the bounds of the original mainfraime, which is the tree concept, in outliners -
and even by sheer order within those micro-lists, and then, and THAT's why I so much insist upon tree formatting, by weighting, not only by putting some important item up one level, but also by bolding it, for instance.
All this "contextual info" (which, as explained, is NOT only about "what items are tagged identically or similarly", but both about relative order, and relative importance/weight within that items cluster) is missing from traditional tagging.
2. As explained in one of those linked threads, I do not see this prob in the context of items which are traditionally worked upon without "matter context", i.e. for "subjects", tree systems (but with advanced cloning as I have developed over there, and here, these last weeks/days) are best, whilst for customers, real estate objects, supplies, applications and such, (advanced) tagging (and yes, as in RN, which seems to be more than promising from what you say) should be the tool of choice: Here, you consider distinct records, even when comparing them with other distinct records; it's quite different from "compound files" where you work, over hours, days, or even months, within a frame of "disparate but interrelated case/matter info", and try to create new info from it, or in a some words:
textbook writing is conceptually different from application appraisal, and for the former, you'd need the perfect outliner, whilst for the latter task, some tagging system (that's why I so much touted almost-defunct askSam over there) would be best.
In the light of these considerations, tagging concepts are of the highest interest, but let's bear in mind my reservations either should be given the right "answers", so as to overcome tagging's shortcomings, or then, the tree concept should be further developed, along the lines I have explained in depth, and to which I even made a significant contribution here and today since my today's add-on is one possible answer to the relevant question how to realize "live variants" (i.e. cloned structures that then partially and in a controlled, monitored way come to a life of their own - well, at the end of the day, it's nothing less than the introduction of the "object model" into outlining, together with controlled inheritance) on the technical level.
I'm not trying to devaluate RN's tagging mastership, I'm just saying that my concept is trying to remain within the confines of the tree paradigm, whilst tagging in outliners (and of which RN's seems to be the very sophisticated) are melt into outlining, instead of striving to lead the tree concept itself, into perfection (which is possible, as my writings clearly show); of course, we're discussing conceptual coherence, conceptual purity here; wherever a perfectly "working" hybrid solution to that age-old "items in multiple contexts" arises, it will be more than welcome; "working" also meaning "minimizing complexity in the user experience, while allowing for as much technical complexity as is needed" (- now compare with Evernote...).
It is obvious that RN's "this tag comes with these other tags, which in their turn come with those other tags yet" feature tries to enable this "multiple contexts problem", but I'm not sure yet that it succeeds at it in an ideal way, just browse all threads over there, on "RightNote", and you'll see that most users praising RN do not praise it for this feature, so there's grounds for suspicion they did not yet grasp this elaborate feature, both in its way of functioning and its possible positive implications for their work: In a word, its realization is not easy enough yet in order to be really useful.
"(and for this initial creation of ALL your "categorization possibilities" aka. all possible "contexts" or "keywords",
i especially recommend using Microsoft Excel" - no, really, I INSIST on the fact that I don't want to devaluate/attack RN (anymore; in fact I created this thread in order to dismiss that former attitude of mine), but we must agree that any tagging program should have some integrated "tagging taxonomy maintenance" gui, and that the hint to fall back on some spreadsheet tool, in parallel, will neither convince prospects, nor will it be followed by that many current users; this being said, RN is under continuous development (even for non-EN-integration-related features I hope!), and I'm just saying relying upon external tools cannot be the definite answer to the need of tagging taxonomy; let's see what the developer will bring about re this part of his program!
Btw, you (duly) speak of "classification", and that's exactly my point (developed in the above links) in emphasizing perfect tree M over tagging, for such "compound work" like forging strategies, finding new insight, writing books: tagging is perfect for (even multiple!) classification, but not for bringing perfect order into and perfect relevance onto your material (both raw, input, and created, possible output): traditional tagging creates unordered, unweighted lists, and for "compound work", that's not enough.
I read your description of RN's tagging with delight, and when I read further (and remembering your former UR experience), I discover you're joyfully describing an almost-ideal realization of exactly that tagging feature numerous people had been begging for, for years, for many years, over there in the UR forum, the developer just lending them his hardest possible ear, and you know what?
I'm sure this thread, and all the good things you have to say about RN and its tagging feature (which appeals, as i'm perfectly aware of, to lots of people, all of them negating my fundamental criticism of tagging), will motivate LOTS of prospects to buy RN, both this forum and the title "review" (which I chose on purpose) getting lots of coverage by google, and it's a very good thing UR, with its blatant unwillingness to take even minimal advice from their (formerly) loyal customers, gets some more heavyweight competition.
(And of course, my theory being that so many outliner users long for good tagging since day in day out they feel, and suffer the shortcomings of today's tree realizations, with them not feeling the need for tags anymore within some tree(s)-wise perfected outliner...)
I also get your point in criticising (even UR's otherwise brilliant) cloning, and you're entirely right in claiming quicker, handier target selection, btw from BOTH sides: "Put this item as clone THERE", and "Put THAT item right here as a clone": Both ways of cloning should be "immediate", "instantaneous", at least when subject or target belong to some history (!), to some "favorites", and especially to some "ToDo's", and not speaking of the fact that currently, only the first variant is possible, not the second one also, which means there's some unnecessary switching forth and back involved, too.
But you see here what I said in the links above: Much of our current criticism, of one, or the other paradigm, just addresses current realisations of those competing concepts, and not necessarily ideal realisations of them. As for real life, when I asked for additional panes in UR, the developer told us that UR even had many a pane as it was and is, and almost too many of them to his liking:
Unfortunately, we're speaking of developers with not enough conceptual imagination (and that's why I wrote the Maple review, in order to acknowledge the things they do really well over there!), and of course, some "pane M" is to be recommanded in all those cases, and it's evident that in the very moment you're choosing your subject-for-cloning, you will NOT need the tree pane for the entire tree, but for "intelligent proposals" being made there, and the moment you will have made your choice there, that very pane should show your (proposed) target position(s): It's certainly not about multiplication of panes, but of multiplication of possible USES of the those panes you've got anyway (and as said re Maple: Why waste screen real estate for a search hit list (or worse, hide, or even delete it whenever the user choses some hit from there), when you can perfectly toggle it with the tree?).
"And specifically because the search allows you to narrow down into & bring together "many similar items"" - again, my argument that those search results will bring "unordered" lists (i.e. ordered by tree position or alphabetically, but not in your "man-made context order", in any case. Btw, that's my argument against the "just search" paradigm, where search is perfected to a point that the developers say you don't need any tree structure anymore (e.g. original askSam (which then added some live tree structure though), and advocates of the combo of desktop search engines like X1, and then just myriads of single files (instead of outlines): All these concepts make you lose ordering/weighting within the clusters they deliver ("relevance sorting" weighting frequencies or even combos of search terms, but cannot order in some "manual-processing-relevant" sequence, just outliners (with clones, and may they show trees or cascading lists, so-called Miller Columns) can do that).
"a giant high quality relational database" - well, you ain't wrong altogether, but let's say that SQLite's big advantage resides in its "incroporability", i.e. it will become part of your application on the pc of your customer, whilst a real high-quality db like PostgreSQL, which offers many more possibilities to the "interface developer", will appear as some distinct body on your customer's hdd; you can appreciate the difference when comparing UR or RN with TheBrain (which does not use PostgreSQL, but another db spreading its data over the place.
Thus, whenever I miss some functionality in some SQLite-based outliner, I ask myself, is it due to SQLite, or could the interface developer have done better?! ( Ok, it's the latter alternative in almost every case... ;-) )
"and to thus remove this manual step here out too" - again, I'm just "putting into perspective", I'm not denigrating RN: the application of a common command to a bunch of search results is thanks to the db, and also available in UR, for some such commands, but of course, it's a VERY good thing that RN's developer has made them available; I said this before, re UR: The interface hides a lot of db functionality from the user, and even erects barriers between what the db theoretically could use for the user, and what will finally get thru to him; I also said, over there, don't be too much impressed by the presumed brilliance of the interface when simply it translates db functionality for you, instead of barring it out from you... but I acknowlege that such a remark might appear a little bit nasty. ;-)
"to be tagged / contextualized / categorized" - It all reverts to the truth that (current) tagging doesn't allow for "fine-tuning" of your material within those "micro-compounds", within those lists of 15, 20, 60 items you will have to work on/with concurrently. I know (and infer from your kind explanations, which are truly "over-constructive" in the best sense I can imagine this term to have, that it will even be very easy to do so in RN) that from then, by "micro-tagging", you could create sub-groups, and sub-groups again, but this would be quite artificial, since you would have to fractionize again and again, by "taxonomie-going-bonkers" (or to be more precise, from a certain level downwards, it's not sensible anymore to give "titles" to sub-groups (since within themselves, they become both too disparate and mixed-up content-wise: atomization-by-content just being sensible down to SOME level), hence tagging those would become "unnatural"), AND, even with multiple, artificially-created sub-groups (where I would simply do manually-sorted lists, with separator lines, cf. in the above links), you would not get to YOUR order, within those sub-groups:
You'll get some ranking, multiple tables of 12 within your reception hall, but you won't get seating: those 12 persons on those tables will not sit together well, or just by rare chance.
This being said, I certainly would not like to put off any RN prospect coming here from google, from buying RN, by my observations on the limits of tagging in general: That RN is among the heavy-weights in outlining, and perhaps even within the top group of three (consider MyInfo and Zoot, too, before buying!), has undeniably been PROVEN by the very kind efforts of donleone, here and today!
2 EDITS:
- There is a difference in atomizing external content, and self-created content. If you're really good, and if your subject lends to it, you can atomize your own FINAL writings to a very fine degree. (But for them, order would be of even more importance than for external material, so you can do with an outliner, without tagging, but not just with tagging... and even MS Word heavily outlines, e.g. by its paragraph formatting hierarchy.) Whilst for imported content, further atomization is only sensible up to a point, below which you have to live with "mixed content": Writings ain't butterflies or beetles in boxes, hence outlining more natural than tagging=categorising; the multiplicity of categorization in tagging just mitigating this conceptual limitation.
- My RN copy is the free one, i.e. has reverted to the free version a long time ago, and during the presumed 4 weeks it was "Prof.", I didn't "get into" the intricacies of this application, and much of my "not getting from given explanation to the program's features" may just be due to those features in my version not being available anymore. That's the risk of most trials: If you don't profit from your short trial period, for further trialling, you'll have to buy. That's why rare exceptions, like Scapple and Beyond Compare, to name just two in quite different sw categories, and which count your 30 or so trial days not consecutively, without mercy, but just when you open the applic, are so much better suited to be trialled in depth. ;-)
"by namely THERE automatically pulling out & showing together, not just the selected tag, but with it also automatically all the tags that are found WITH your tag, either as a tag unto the left, or as a tag unto the right - in all the items across your entire database.
(and in that sense "related tags", since these are found occurring WITH your selected tag together,
and even just in one single item used together, is enough to make them show up as "related" in that top right corner pane)"
I think this is a tremendously and-powerful, and-helpful feature, and I'm also very interested of the current developments of Surfulater since the developer will abolish traditional tree building altogether, replacing it by smart tag trees; of course, this is a quite different concept from RN's "related tags" (in a way, it's related to amazon's "customers also bought...""), but it's obvious that these two developers, at this moment, are those who are deep into conceptual work re on the tagging front, and I greatly appreciate this.
I make big reservations about (current/traditional!) tagging, and I explained my stance in depth here:
http://www.outliners...revgen-on-bits-again ("prevgen" = mocking of "nextgen" of course),
and if you allow for a very brief summary of what I think about tree structures vs. tagging, it's,
1) with traditional tagging, you will miss both "context in several indendation level shapes" and "context in order/formatting", meaning it makes a big difference if you just get "relevant" items as a list, or if you will have pre-arranged those items (or do this arrangement/grouping work now, that you will work on your items, gathered in disorder beforehand), will have created micro-relationships, micro-hierarchies, by creating "indentations", groupings (= by sub-parenting and putting items as siblings together, and also by creating "divider lines"
- I developed on this here (in point 2): http://www.outliners...messages/viewm/19697 ), in aforementioned "prevgen" thread, and especially here:
http://www.outliners...messages/viewm/19768
where I wrongly assumed there was no sw like RN which did already have multiple trees in one db, as we see now, from your explanations, but in which I exposed my ideas of "live trees" into which subsets of the whole set of material would be put together, creating a new concept of truly independent items, just gathered and ordered in various trees, whilst even RN's multi-tree concept which we know now, clings to the traditional idea of items "belonging" to some specific tree, and then PERHAPS being cloned to another one, or rather, in RN, creating tagging as an expediant, an overlayed structure, in order to replace that missing inter-trees cloning (this is not a criticism, it's just some second concept, overlayed onto the primary concept, the tree structure, in order to give it "complete" functionality, in some way, but not within the bounds of the original mainfraime, which is the tree concept, in outliners -
and even by sheer order within those micro-lists, and then, and THAT's why I so much insist upon tree formatting, by weighting, not only by putting some important item up one level, but also by bolding it, for instance.
All this "contextual info" (which, as explained, is NOT only about "what items are tagged identically or similarly", but both about relative order, and relative importance/weight within that items cluster) is missing from traditional tagging.
2. As explained in one of those linked threads, I do not see this prob in the context of items which are traditionally worked upon without "matter context", i.e. for "subjects", tree systems (but with advanced cloning as I have developed over there, and here, these last weeks/days) are best, whilst for customers, real estate objects, supplies, applications and such, (advanced) tagging (and yes, as in RN, which seems to be more than promising from what you say) should be the tool of choice: Here, you consider distinct records, even when comparing them with other distinct records; it's quite different from "compound files" where you work, over hours, days, or even months, within a frame of "disparate but interrelated case/matter info", and try to create new info from it, or in a some words:
textbook writing is conceptually different from application appraisal, and for the former, you'd need the perfect outliner, whilst for the latter task, some tagging system (that's why I so much touted almost-defunct askSam over there) would be best.
In the light of these considerations, tagging concepts are of the highest interest, but let's bear in mind my reservations either should be given the right "answers", so as to overcome tagging's shortcomings, or then, the tree concept should be further developed, along the lines I have explained in depth, and to which I even made a significant contribution here and today since my today's add-on is one possible answer to the relevant question how to realize "live variants" (i.e. cloned structures that then partially and in a controlled, monitored way come to a life of their own - well, at the end of the day, it's nothing less than the introduction of the "object model" into outlining, together with controlled inheritance) on the technical level.
I'm not trying to devaluate RN's tagging mastership, I'm just saying that my concept is trying to remain within the confines of the tree paradigm, whilst tagging in outliners (and of which RN's seems to be the very sophisticated) are melt into outlining, instead of striving to lead the tree concept itself, into perfection (which is possible, as my writings clearly show); of course, we're discussing conceptual coherence, conceptual purity here; wherever a perfectly "working" hybrid solution to that age-old "items in multiple contexts" arises, it will be more than welcome; "working" also meaning "minimizing complexity in the user experience, while allowing for as much technical complexity as is needed" (- now compare with Evernote...).
It is obvious that RN's "this tag comes with these other tags, which in their turn come with those other tags yet" feature tries to enable this "multiple contexts problem", but I'm not sure yet that it succeeds at it in an ideal way, just browse all threads over there, on "RightNote", and you'll see that most users praising RN do not praise it for this feature, so there's grounds for suspicion they did not yet grasp this elaborate feature, both in its way of functioning and its possible positive implications for their work: In a word, its realization is not easy enough yet in order to be really useful.
"(and for this initial creation of ALL your "categorization possibilities" aka. all possible "contexts" or "keywords",
i especially recommend using Microsoft Excel" - no, really, I INSIST on the fact that I don't want to devaluate/attack RN (anymore; in fact I created this thread in order to dismiss that former attitude of mine), but we must agree that any tagging program should have some integrated "tagging taxonomy maintenance" gui, and that the hint to fall back on some spreadsheet tool, in parallel, will neither convince prospects, nor will it be followed by that many current users; this being said, RN is under continuous development (even for non-EN-integration-related features I hope!), and I'm just saying relying upon external tools cannot be the definite answer to the need of tagging taxonomy; let's see what the developer will bring about re this part of his program!
Btw, you (duly) speak of "classification", and that's exactly my point (developed in the above links) in emphasizing perfect tree M over tagging, for such "compound work" like forging strategies, finding new insight, writing books: tagging is perfect for (even multiple!) classification, but not for bringing perfect order into and perfect relevance onto your material (both raw, input, and created, possible output): traditional tagging creates unordered, unweighted lists, and for "compound work", that's not enough.
I read your description of RN's tagging with delight, and when I read further (and remembering your former UR experience), I discover you're joyfully describing an almost-ideal realization of exactly that tagging feature numerous people had been begging for, for years, for many years, over there in the UR forum, the developer just lending them his hardest possible ear, and you know what?
I'm sure this thread, and all the good things you have to say about RN and its tagging feature (which appeals, as i'm perfectly aware of, to lots of people, all of them negating my fundamental criticism of tagging), will motivate LOTS of prospects to buy RN, both this forum and the title "review" (which I chose on purpose) getting lots of coverage by google, and it's a very good thing UR, with its blatant unwillingness to take even minimal advice from their (formerly) loyal customers, gets some more heavyweight competition.
(And of course, my theory being that so many outliner users long for good tagging since day in day out they feel, and suffer the shortcomings of today's tree realizations, with them not feeling the need for tags anymore within some tree(s)-wise perfected outliner...)
I also get your point in criticising (even UR's otherwise brilliant) cloning, and you're entirely right in claiming quicker, handier target selection, btw from BOTH sides: "Put this item as clone THERE", and "Put THAT item right here as a clone": Both ways of cloning should be "immediate", "instantaneous", at least when subject or target belong to some history (!), to some "favorites", and especially to some "ToDo's", and not speaking of the fact that currently, only the first variant is possible, not the second one also, which means there's some unnecessary switching forth and back involved, too.
But you see here what I said in the links above: Much of our current criticism, of one, or the other paradigm, just addresses current realisations of those competing concepts, and not necessarily ideal realisations of them. As for real life, when I asked for additional panes in UR, the developer told us that UR even had many a pane as it was and is, and almost too many of them to his liking:
Unfortunately, we're speaking of developers with not enough conceptual imagination (and that's why I wrote the Maple review, in order to acknowledge the things they do really well over there!), and of course, some "pane M" is to be recommanded in all those cases, and it's evident that in the very moment you're choosing your subject-for-cloning, you will NOT need the tree pane for the entire tree, but for "intelligent proposals" being made there, and the moment you will have made your choice there, that very pane should show your (proposed) target position(s): It's certainly not about multiplication of panes, but of multiplication of possible USES of the those panes you've got anyway (and as said re Maple: Why waste screen real estate for a search hit list (or worse, hide, or even delete it whenever the user choses some hit from there), when you can perfectly toggle it with the tree?).
"And specifically because the search allows you to narrow down into & bring together "many similar items"" - again, my argument that those search results will bring "unordered" lists (i.e. ordered by tree position or alphabetically, but not in your "man-made context order", in any case. Btw, that's my argument against the "just search" paradigm, where search is perfected to a point that the developers say you don't need any tree structure anymore (e.g. original askSam (which then added some live tree structure though), and advocates of the combo of desktop search engines like X1, and then just myriads of single files (instead of outlines): All these concepts make you lose ordering/weighting within the clusters they deliver ("relevance sorting" weighting frequencies or even combos of search terms, but cannot order in some "manual-processing-relevant" sequence, just outliners (with clones, and may they show trees or cascading lists, so-called Miller Columns) can do that).
"a giant high quality relational database" - well, you ain't wrong altogether, but let's say that SQLite's big advantage resides in its "incroporability", i.e. it will become part of your application on the pc of your customer, whilst a real high-quality db like PostgreSQL, which offers many more possibilities to the "interface developer", will appear as some distinct body on your customer's hdd; you can appreciate the difference when comparing UR or RN with TheBrain (which does not use PostgreSQL, but another db spreading its data over the place.
Thus, whenever I miss some functionality in some SQLite-based outliner, I ask myself, is it due to SQLite, or could the interface developer have done better?! ( Ok, it's the latter alternative in almost every case... ;-) )
"and to thus remove this manual step here out too" - again, I'm just "putting into perspective", I'm not denigrating RN: the application of a common command to a bunch of search results is thanks to the db, and also available in UR, for some such commands, but of course, it's a VERY good thing that RN's developer has made them available; I said this before, re UR: The interface hides a lot of db functionality from the user, and even erects barriers between what the db theoretically could use for the user, and what will finally get thru to him; I also said, over there, don't be too much impressed by the presumed brilliance of the interface when simply it translates db functionality for you, instead of barring it out from you... but I acknowlege that such a remark might appear a little bit nasty. ;-)
"to be tagged / contextualized / categorized" - It all reverts to the truth that (current) tagging doesn't allow for "fine-tuning" of your material within those "micro-compounds", within those lists of 15, 20, 60 items you will have to work on/with concurrently. I know (and infer from your kind explanations, which are truly "over-constructive" in the best sense I can imagine this term to have, that it will even be very easy to do so in RN) that from then, by "micro-tagging", you could create sub-groups, and sub-groups again, but this would be quite artificial, since you would have to fractionize again and again, by "taxonomie-going-bonkers" (or to be more precise, from a certain level downwards, it's not sensible anymore to give "titles" to sub-groups (since within themselves, they become both too disparate and mixed-up content-wise: atomization-by-content just being sensible down to SOME level), hence tagging those would become "unnatural"), AND, even with multiple, artificially-created sub-groups (where I would simply do manually-sorted lists, with separator lines, cf. in the above links), you would not get to YOUR order, within those sub-groups:
You'll get some ranking, multiple tables of 12 within your reception hall, but you won't get seating: those 12 persons on those tables will not sit together well, or just by rare chance.
This being said, I certainly would not like to put off any RN prospect coming here from google, from buying RN, by my observations on the limits of tagging in general: That RN is among the heavy-weights in outlining, and perhaps even within the top group of three (consider MyInfo and Zoot, too, before buying!), has undeniably been PROVEN by the very kind efforts of donleone, here and today!
2 EDITS:
- There is a difference in atomizing external content, and self-created content. If you're really good, and if your subject lends to it, you can atomize your own FINAL writings to a very fine degree. (But for them, order would be of even more importance than for external material, so you can do with an outliner, without tagging, but not just with tagging... and even MS Word heavily outlines, e.g. by its paragraph formatting hierarchy.) Whilst for imported content, further atomization is only sensible up to a point, below which you have to live with "mixed content": Writings ain't butterflies or beetles in boxes, hence outlining more natural than tagging=categorising; the multiplicity of categorization in tagging just mitigating this conceptual limitation.
- My RN copy is the free one, i.e. has reverted to the free version a long time ago, and during the presumed 4 weeks it was "Prof.", I didn't "get into" the intricacies of this application, and much of my "not getting from given explanation to the program's features" may just be due to those features in my version not being available anymore. That's the risk of most trials: If you don't profit from your short trial period, for further trialling, you'll have to buy. That's why rare exceptions, like Scapple and Beyond Compare, to name just two in quite different sw categories, and which count your 30 or so trial days not consecutively, without mercy, but just when you open the applic, are so much better suited to be trialled in depth. ;-)