Forum Posts Feed
Clones? Cross-referencing?
< Next Topic | Back to topic list | Previous Topic >
Posted by 22111
Oct 7, 2013 at 11:57 AM
Two ideas:
Even when the “original” item gets a “clone” icon, as in UR, that item does not indicate “cloned to location a” or “cloned to location b”, which is a problem whenever you clone standard items, several times, to different target locations, so what is missing here, is some function that within a sub-heading, will show the respective cloning target locations in a table or such, but since they might be multiple, it would perhaps be preferable to have a function, not starting from the “origin”, but from your respective target, and which shows, wherever you “are” within your material, “this item/heading has been cloned to the target of interest”, this being some heading/sub-heading of its own. This means, a function would, when triggered upon a certain heading anywhere, then check for and visually indicate any other item/heading, wherever you are navigating, if that particular heading/item has been cloned to that heading and its subtree, where you triggered the command, for example by displaying those specifically-cloned items with a colored background.
And also, there would be an additional function that, within such a setting “selected target for gathering elements”, a simple click/key pressing would clone any other item/heading (together with its sub-items) to that particular target, meaning in this technical situation of your outliner, you would not have to identify the target again and again for such cloning.
Second idea: It seems obvious many problems arise from the fact that outliners today mostly don’t display two items at the same time, and even those that do, will not display but the content pane of that second item, but not its “core” identifiers: no subtrees, and no title-as-target, to which you could “send” things; this latter functionality, though, would be rather easy to implement, in comparison to “full” display of a second item.
If you had two subtrees, side-to-side, one where you are navigation in order to gather things, and the other displaying your target to which you are collecting things, instead of having to switch back and forth for this, all these tasks described would be much less cumbersome. But as said, this could be facilitated by a function “set this item as collecting target”, and then making the outliner indicate visually which items “are already cloned to that target”, and which are not, and this would resolve the above-mentioned problem of not knowing, by a simple “is clone(d)” icon, if some item has been really cloned already to your current target, or to some other location within your big data.
I think this would be one (of certainly several) valid solution to the problems stated above.
In another thread some days ago I said, often, it’s the missing coding capabilities of developers that is responsible for missing functionality, but here we have clearly a case of first having to develop how to realize a function best, and then the actual coding would not be so difficult!
Posted by 22111
Oct 7, 2013 at 12:37 PM
It goes without saying that within your file system (physical as well as on your pc), the problem is similar: You have grouped reference material, be them reference material from the beginning or just old projects from which parts then (should) become reference material for new projects, and again and again, only sub-groups of files (and then, of content within those files) will “apply”, when other content or other files within those sub-groups / sub-folders will not be relevant. The only conceptual difference to what is within your outliner is the possibility, in your outliner, to better fine-grain those different contents, meaning you cut them up into more pieces, in order to make one bit apply and another one not, when in files, there will be more disparate content, in most cases, than in one outliner item (ideally).
Technically, to replicate such “sub-groups of originally connected items” on the file system level, is possible even if you try to do it all within the file system, for example by .lnk files, but perhaps there is a real interest instead of doing it by database links, which means by a document management solution but which should have such “gathering” functionality for fast building up new compounds from spread, “old”/standard data.
For physical files, some makers offer “thin folders”, which at first sight, is a very good idea to better realize such multiple combinations, but then, most things do have some “natural context”, in which it’s very handy to “have it all together” in sort of a “standard combination”, from which you deviate only scarcely, depending on the respective context, and this invalidates this “thin folder paradigm” (I’m not speaking of separate customer files here, of course, but of files to be combined in order to be useful).
So we have a disruption from physical files to pc, but it seems that except for real expensive software, our pc tools don’t make enough advantage of their additional possibilities-over-paper yet.
I once considered cloning a real paradigm shift, and it is, considering paper files, photocopies, and such, but their current technical realization is too cumbersome yet in order to become really helpful for “project work”, which is NOT about “putting fome file into several categories” only, but which is of partial combinations of single items, and of sub-groups of “connected” items, in endless variants, so I hope some ideas above, or additional ideas posted here, could find their way in some outliner or another.
Posted by 22111
Oct 7, 2013 at 01:01 PM
I cannot resist to give this citation:
from http://takingnotenow.blogspot.be/ from “Blumenberg on Luhmann, Part II”:
“Blumenberg had to re-order his cards several times, depending on the purposes he had at a certain time. Luhmann never did. Whether that was an advantage may be doubted because repeated interaction with the material is more like to stimulate revisions and growth over time. While Luhmann’s work often is repetitious and not very elegantly formulated, Blumenberg’s work is much more polished. However, both their texts reveal how they were put together, i.e. that they are accretions of more basic units.”
You must know that Luhmann did his index cards the same way most library archives are stored: chronologically, meaning books/cards 3, 105, 2058 and 19386 belong together, in a certain way, but you would never know without the index, and then, no “natural context”, but gathering one-by-one. For books delivered to a counter, that’s the right system, but I assume if you have 85 such index cards, “held together” just by an index, and spread over thousands of physical cards, you will probably not gather all them but do some triage, hoping you have the content of the remaining 45 sufficiently memorized, taking out 40, and having to restore them all afterwards, one by one, being lots of work in itself, even without those other 85 you judge (from memory) “not so important here”.
The same applies to gathering material to work on/with within your computer: If it’s too cumbersome to “gather it all”, you will probably not do it, by this leaving out important elements. So the computer/software should help you in gathering all important / probably relevant material in every instance, instead of your having to do “real work” for this “secondary activity”.
I know there is “search”, but the more you write with an extended vocabulary, the less you’ll be able to find relevant things, since “manually”, you simply don’t think of all possible variants of terminology, and today’s search tool will not be of big help to find them either.
So this means, Luhmann probable too much relied on his memory since “calling up” his carded knowledge was simply too much effort for him and/or his secretary, and what we get from today’s outliners and from today’s file system (in Windows), is a little the same phenomenon, that we often have to make do with what we immediately get, since digging further is too much effort and thus not justified - better software could be of big help here to include more relevant things, as for Luhmann would have some categorization instead of just using an automatted pagination stamp.
Posted by 22111
Oct 7, 2013 at 01:02 PM
I beg your pardon, citation’s from “Part I”, blog entries being sorted the commercial sorting way, not the administrative sorting way. Sorry.
Posted by 22111
Oct 7, 2013 at 01:27 PM
I beg your pardon also for all those typos above, “remaining 45” not seen, out of the 85 lot, etc.
I would like to add that Luhmann’s pagination stamp wasn’t something “idiotic”, as it might appear today at first sight, since all this referencing would have to be redone, manually, if he tried to constitute groups of cards, meaning if you put card number 2490 out of its context (if there is a context), into a new context 843, all those references to this card “2490” have to be changed to “843”, and you will probably not even know where they are, or you must put the references, “backwards”, onto the card itself, too: “this card has been referenced in the following contexts” - but then, you must do a lot of rewriting at numerous places whenever you re-assign some “group”-card to any other location… and there is the “xerox” problem quickly coming in, because it offers easy solutions to “shifting 1 card around, but having to update 322 index numbers in consequence”.
So my point is not that Luhmann did it wrong, but my point is, this paradigm shift to computers/software (where updating thousands of index entries is done in the fraction of a second) did not offer us enough from what Luhmann et al. could do with physical files: Technology would offer it, but software doesn’t follow.
Btw, the very first version of askSam was promoted as an electronic Zettelkasten version, as was HyperCard (and that’s why HyperCard was abandoned, and AS took many years to get its tree-on-the-fly: Before, it was all about remembering key words (whether in fields, or in body text, for AS), without a real “key word management” offered by the software: just tagging, and this made many users had left AS even before their intro of the tree-on-the-fly, which thus came too late.