MyInfo Community Forums

Here's some "philosophy", i.e. very important conceptual work for MI. If you follow me here - or do something even better, and if all little quirks are eliminated -, MI will be of overwhelming practical value to professionals, and they would be willing to pay real money for this program. In fact, I am developing here the difference between an "amateurish" "we are here, too" program like dozens of others, and the real, outstanding thing. Programming time should be 1 big week or so, but less than 2, so it's worthwile.

I

As I developed before, MI is "1 Topic a Tree", whereas UltraRecall, for example, is "All in One Tree"; some people have one UR database with 1 GB or more of content, "pouring" subtrees to work on into different tabs: the tree itself (=containing all their stuff) is the supertree at the same time (but needs - and has - a (technically at least) very elaborate hoisting function in order to manage all that. (As stated elsewhere, after pouring those multiple subtrees into those multiple tabs, clutter begins, since their software design isn't at par with their softare encoding quality.)

And nobody would dare pouring all his staff into one single MI file, 1 GB of data or more - and why should he? Since there is this "1 tab 1 topic" system, including global searching (and a very fine separation of finds in those different topics, including discriminational collapsing / expanding for each topic containing finds).

I've had some 30 or 35 files in my unmentionable "basic" outliner, ActionOutline; in MI I've got some 120 for the time being, and soon I'll reach 150 or even 200; many people weren't that happy with MI's denomination of files as "topics", but as soon as you see the philosophy behind MI, naming those trees / files "topics" is the very best name for them indeed.

II

The cloning function in MI is very / too rudimentary. As you (possibly) now, by cloning, the current item is cloned (as in UR for example) with its subtree (in case there is any), and afterwards, the cloned item will be updated whenever the original item changes, and vice versa, the original item is updated with any changes in the clone. All this goes without saying, without that there would not be clones, but only copies, i.e. copied items that would not be updated by changes in the original item, and where changes would not affect the original item.

Where problems arise, is, first, in those dam**d sub-items of clones. Whenever you add or delete (or transfer to another place) any subitem of the original (or of the clone, or make changes to them, the "other party" will not be affected anymore by all this, and this way, clones in MI are of very limited use, or worse, their use could lead to many "errors" by leaving out information when you assume you dispose of information that in fact is not there, or had been updated, eliminated, whatever... but in the original item('s subtree) when you consult the clone, and vice versa.

The same problem arises whenever you do some changes within / to items in the subtree of such an original or of such a clone: Even knowing you are breaking the cloned synchronizity apart - that you are wrecking it -, you cannot but accept that fact, or manually re-do the cloning of the cloned head item, after each such a change occurs. This is awful and error-prone.

This way, the only conceivable use of MI's cloning function would be e.g. a list of customers where the first = main tree is by geography, and where you do a secondary tree, after the first, where you do clones, by ABC analysis, by size, by branch of business, or whatever. But then, there is the fine tagging feature of MI which would do all this much better, and then, even in this sparse possible example, the above-mentioned synch problem would arise as soon as you dared to do sub-items, e.g. for the commands of those customers, or for the contacts with them.

Why these problems? Let's face it, not synching but the cloned item itself, was a lot less work in programming this feature... This is not a critique, it's just a fact. Let's see the second problem with cloning in MI:

III

The second problem is, cloning is only available WITHIN the tree, within the given topic. Of course, when you have a program like UR where, by it's "definition", all your stuff (= all your stuff of a certain kind; of course there could be reasons to put all your strategy in one tree=file, all your customers into another, and all your hobbies into a third, if you want to do so) is in the same monster tree, this limitation of all those programs, "cloning only possible within the tree", does not really hamper you, since your "Action Section" / "ToDo Section" will be in that one monster tree indeed, rather at the beginning of it, on top of your various "stuff sections" containing perhaps more than 1 GB of "reference" data.

The same, in such a system, for those various not Allen's "Getting Things Done" or other project management action triggers, all together instead of dispersed within 100,000 or more items in your monster tree - and which might be considered technically as clones, but are in fact references to that various stuff damped into the whole, but for all those REAL clones, as we might call them, where some reference materials are needed in various sections where they belong. The classical example of this is, where to put car insurance, under "car" or under "insurances"? With a cloning system like that in UR, you'd have "car insurance(s)" under the "car(s)" section AND under the "insurance(s)" section of your very big tree; the same with house insurance; the same with individual insurances of each member of your familiy: Their respective insurances would be dispersed in the tree, as would perhaps the different schools your kids attend, each such a doc under the corresponding child heading, but at the same time, all insurances (and their brokers) would be grouped together under "Insurances", all schools (and teachers' telephone numbers e.g.) would be grouped together under "Education", and for every subject belonging to different headings, you'd find entries under both headings: this is the perfect example of the real advantage of digitization over paper files: the third dimension is available whenever you need it, instead of manually-to-be-sychnronized reference entries (which are very error-prone and awkward to maintain).

IV

Another example, very important this one, since it does not imply a one-and-single "we stuff all our things into our system, and then it will stay without much change afterwards, except for content (=but not for "constructing the system"):

You are a laywer, you have different cases. You are a consultant, you have cases. (You see, I am interested in high-paid professionals who do real work with their working program, and I want it to be MI...) Now, what do you do? You do a heading (=in UR) for your case, say "John Smith vs. the Government". And then, you fill up that case with reference material. Of course, in continental legal systems, your main base would be some codes of law; in many countries, the "Civil Law" comprises some 2,000 or 3,000 articles, often subdivided into paragraphs. So you would need this "Civil Law" in its entirety for all your civil cases, but then, for each case, you would need SPECIAL PARTS of these laws, and you would need specific rulings of other, similar cases, or cases similar in certain aspects to your current one.

This way, you would need to integrate a lot of various stuff into each of your individual cases, some rather general, some perhaps very specific, some at the very first beginning of your case, some rather far behind in the development of your case; some reference material then would not apply and would have to be replaced by some other, and so on; some standard material could be put there by your secretary, for further stuff your own expertise would be in demand for carefully chosing it.

Either way, some reference material would lay dormant for years, just in case of, and other reference material would be put into almost each case, or, as I said, various parts of it, or even "standard parts" of it, "standards" if you want.

A consultant of any kind would do the same, and of course, "reference material" would not only be real reference stuff, but very often parts of other projects that could be re-used: Thus, strictly separating "reference material" from "project material" is only valid for any given project; as soon as a project - or a legal or whatever "case" is completed, almost all of this material could be considered reference material for any new project / case.

V

It goes without saying that a big tree with real cloning (= cloning incl. sub-items), like in UR, seems to be perfect, at first glance, for this real work (=whereas "I do my recipies with XYZ" is not real work), whereas MI does not seem to be suitable for this work... for the time being.

There is a big flaw in the first concept, the "One Big Tree with ToDo's, then Projects, then all that Reference Stuff, and Perfect Cloning Holding It All Together" - your projects are all in that big tree, whereas legal cases should be separated, commercial projects should be separated, pychoanalytic work and everything... should be separated BY CUSTOMER. No lawyer stuffs different cases into one lever file... in UR or other "big trees", electronically, he would be forced to do that.

VI

Whereas in MI, he would have his dozens, his hundreds of individual topics, one for each case / project... but how to collect all these disparate reference materials in a neat and easy way? Or put it another way: The third dimension in electronic paper work has to be file-spanning, must not be within-the-file only, and that's a MUST!

VII

So, first, we need that SUPER TREE. What's a super tree? A tree that is a three-dimensional file system, for all topics, and superimposed on them, to begin with. A tree in which are automatically entered, under its heading "IN" or "NEW" or whatever, all newly created topics, and from which "in basket" you would shuffle all your topics into whatever heading or subheading (!) there in which you want them to be. Thus, you would put your topic cat (or whatever you name it, but it would mean "Car Assurance Thomas") underneath the headings "Cars", "Assurances" and "Thomas", and you'd put your topic "cb1" (= Customers Biz 1, understood you wear several hats) under the heading "Customers" and under the heading "Biz 1".

Whenever you rename or delete a topic - remember, here at step 1 we are strictly on the topic = file level -, it must be updated in this super tree.

This super tree should be accessible at any moment in the task pane, like the filter and the tags list should be accessible there, and in fact, very soon, this content of the task pane would soon become its default content, and it would be in this super tree that you would normally switch from 1 "tab" to another, clicking on the headings in the super tree (and loading the corresponding topic by that if it's not yet loaded anyway).

VIII

So what, up to now? Where's the interest of having this super tree, together with its topics list (with multiple entries of topics)? In this first step, the interest lays in... the HEADINGS!

Since double-clicking on the headings would load all corresponding topics !!!

(Whereas simple clicking on the heading would expand / collapse its topics or subheadings.)

This first-step advantage is tremendous yet since whenever you'd click on Thomas (= one of your children, in our example), you'd see all topics relating to him, doctors, education, assurances taken out for him, his car (which you bought for him, and of which you took the assurance, in a bunch with your others (=thus making it less expensive)), assets (= you've given to him, in order to save future inheritance tax), his wife, his children... and THEIR sub-topics...-

And whenever you want to see all assurances of all the members of your family (= even adult members, but again, one broker, one customer = yourself, in order to get all the bunch as cheap as possible), you click on "a" = "Assurances" in your super tree, and all assurances will be shown (= MI loads perhaps 15 or 20 topics into as many tabs).

The same way, you could have your super tree entry "Assurances", then "Houses" (=incl. the topic "Vacation Home"), then "Parents" (with the corresponding topics), then "Children", with 3 subheadings, 1 for each child, and this would give you the possibility to double-click on "Assurances" to load perhaps 15 topics, to double-click just on "Parents' Assurances" to load 4, to double-click on "Children's Assurances" to load 11 (=15-4) or to load just "Thomas' Assurances" = 3.

I concede that my assurances' example seems a little bit over-constructed, i.e. artificial, nobody would want to separate all his assurances into that many a file.

But imagine any legal stuff, any business management stuff, and it becomes clear that this super tree = topics list (=allowing for multiple, synchronized topic entries on multiple levels, i.e. under multiple headings / sub-headings) is of the utmost interest for serious work: It is like electronically fetching multiple files belonging together in various ways, be those files similar or disparate in kind, altogether with one double-click, instead of manually selecting those files one by one in order to load them, which is time-consuming and, worse, error-prone.

IX

Of course, you could do the same with global tagging, but there is no neat global tagging at this moment. Yes, you can do a global search for "tag:xyz" over ALL files, loaded and unloaded (and this is a very helpful feature), but this is real searching and takes many seconds (if you have many files, i.e. the results are NOT indexed, but for each such search, the tags have to be searched for anew, thru all given files. In my about 120 files, this takes very long; imagine a lawywer with 2,000 files or more: It would be impossible (since, again, there is no tag indexing beforehand, in order to throw out a list of all corresponding topics in a fraction of a second).

And then, after 1 minute or more waiting time, you'd have a search results list, from which you could manually select all items (=items within the topics, not the topics themselves: far from elegant, by the way!), in order to load the corresponding files: For a legal case, that could make 25 or more different files, to be loaded one by one, one after another, manually - that's awkward, that's not doable in everyday business: that's a deal breaker!

And then, I know that it would be possible to implement a function that would index all tags - and indeed, please implement it, it would be extremely helpful anyway! - and another one that would automatically load all topics concerned by a search result - again, please implement that, it could do no harm to anybody! -, but the real advantage that would be brought by a super tree, would be that it would be a super tree, i.e. a "graphical", "contemplateble" representation of "all things in your whole system", a representation that is always present in those "big tree systems", all the more when there is (real or rudimentary) cloning in them, and where the one and only tree represents all your stuff, expanding items showing then what MI handles as "topics" = separate files - this GLOBAL, AGGREGATE representation is nowhere in MI at this time, where thus you have to carry MANUAL LISTS (=manual even when maintening them in an MI item - awkward and error-prone), from which then you have to load your grouped items manually.

XII

In a second step, LINKING should be made possible within the tree, AND there should be a special link form, a link "load with": Every time a given topic is loaded, all those "load with" links should be loaded / opened at the link item.

Now let me tell you first what I do for a macro, for the time being, then, what MI should do for us.

I

I have a dozen or so "main subjects". In those, I pour new things, so they are my "in boxes". I have a special key which gives me a menu of those subjects = topics = files. They have 1-digit names. They are all loaded when MI starts. When I want to go to one of them, I do the F-key, then the name key, let's say "F6 a" or "F12 k", WITHOUT any Enter, so that gives me each of those in a 2-key access which is very important.

II

On top of that, I have the file "a", as a "super inbox" when I am too lazy to change first to the "right" inbox, let's say, to "k". This "super inbox" is accessible by 1-key access (let's say F2 goes to "a").

Let me give you some advice here. I do NOT stuff "general things" of my subjects into those "super subjects", but only as an inbox, to further distribute items onto the concerned subjects, afterwards, so I try to TRIM those "super subjects" / inboxes; for "general things" of my subjects = things that cannot be easily distributed to their "right place", I have, in case of, topics like "tg", "vg" = "topic t general", "topic v general" - and I do comments to my topics, like "ah - topic a except subtopic xxx", "pg - topic p including subtopic xxx", etc. - this way, I have very few "general" stuff for which I do not easily find its "real place".

But then, I ALSO DO THE PROBLEMS HERE. Since I do not really like to have to do a searching for some tag "overall" (I have some 200 files = topics, and they will probably be 300 soon), I do all the CONCEPTUAL WORK IN THOSES IN BOXES, which thus contain, for me, not only the "in" items to be distributed into their "right" files, but especially all the problems, thoughts, etc. where some decision making has to occur.

Putting it the other way, after some 3 months of working with MI, I ELIMINATED all real working stuff in my "details topics", by this relegating them to their REFERENCE FUNCTION, providing details to my decisions, etc., but NOT CONTAINING any "decisional stuff".

This way, my "inboxes" are my real work environment, being supported by any detail topic that applies. (At this moment, this is possible with about 20 characters of the alphabet, but it is to be assumed that one day I will have to have 2-digit "super projects" and 3-digit "details topics"... but it will be a similar system: "Handy topics" at hand, for doing your work, and reference material that does NOT get into your way of decision making, but that does just HELP you with that.

III

My macros do not only go to those inboxes, but to the first item of them. Why? Because in the "text" of the first item, I have up to 3 lines, as lines 1 to 3, let me give an example:

"a" "ak" "al" "am"
"ak" "ap" "az"
"a" "ak" "al" "az"

IV

You'll have guessed it: I have other 3 macros that I trigger then: Load the files in the first / second / third line.

And in fact, when loading those lines into the clipboard, then ^o, then loading them there, then "Enter", you get MI to load those "projects".

V

On any such "main topic", I have up to three "projects", by this, and in order to know what those projects contain, my first items on those main topics look like this:

"a" "ak"
etc up to 3 lines
then a blank line, then:
ONE (bold)
a Tab Comments on the contents of file a
ak Tab Comments on the contents of file ak
etc.
(blank line)
TWO
same as above
(blank line)
THREE
same as above
(blank line)
here: if available, other files not (yet) contained in any above project.

VI

Most of those files are, of course, named with regard to their main topic, i.e. when the main topic is "k" (= k.mio), there might be one or two dozen of "detail topics", all beginning with "k" and which are mostly 2-digit, sometimes 3-digit, or you can even do them, as I stated elsewhere, in the form "k.name1.mio", "k.name2.mio", etc.

But of course, there are OTHER topics in those projects also, which belong, systematically, to OTHER main topics, and here it becomes really interesting.

Thus, my first line of the main topic could be:

"k" "k1" "kl" "k.johnsmith" "jl" "jm" "jz"

Just imagine a legal case, John Smith, where I need some laws, let's say the matrimonial law and some special laws.

Whenever I work upon my case "John Smith", my macro will thus load me every topic I need for this case.

VII

When it's already loaded, no problem. But there's another problem: When I close my case, what should I do? In a perfect world - in a perfect program - all topics would be closed that are not used by any other loaded project... Oh my, I know this is difficult. So let us just say this: MI should be able to close any topic THAT HAD NOT BEEN LOADED WHEN MI WAS LOADED. Thus, when you start MI, the topics loaded then would be considered "standard topics" not to be closed but manually (or when closing MI), whereas there would be a command "close any other topic NOT loaded with MI when started".

This way, you would load your real standard topics with MI, and thus, a penal law lawyer would load the penal law with MI... whereas he would load special laws with his specific projects, and all the worse if thus MI would close a special topic with closing one project, reloading perhaps the same special topic with another project loaded immediately afterwards; all this is much better than to load multiple projects one after the other, and then having 40 or 50 files loaded (as it happens often to me at this time with my macros), since RE-LOADING even the initially loaded topics would cost me 1 minute or so!

VIII

But you will have noticed that my way to do projects is not only ugly, but has a deep fault in it: All my comments are left without any synching!

When I have the main topic "k" before my eyes, I can easily change my comments on topic "kl" there, for instance. But that same topic "kl" could be in 20 other projects, first line of "l", second line of "m", third line of "o", again second line of "v": whatever!

Thus, sustaining any status comment of any topic is a real pain in the a**, and the same applies to any RENAMING of any topic!

IX

And then, I have about 200 topics at this moment, and about 20 or so main topics, but it goes without saying that my system ONLY functions for such a size / number of things.

Imagine a lawyer having hundreds of cases. He would need to have dozens of intermediate choice items (= like my main topics) where those cases are listed, and from which his macros could trigger / load them, as projects, with their adjacent topics.

Of course, he could have lists of cases, and then he could do something like my current project strategy, not from main topics, but he could load the case = 1 topic, and THEN the first item of the case could be such a "load adjacent to this case" list, where he'd trigger the same (first line) macro I trigger now at my main topics - but again, I do this in order for having a chance to maintain at least SOME coherence in my topics comments, limiting the number of places where I must search for them, so imagine HUNDREDS of places where to search for them?!

X

Oh yes, and there is a detail applying to macros, or applying to any MI implementation of this functionality: You should do some prototypes, i.e. if you have legal cases, do not do a project "John Smith", then collect all the applying legal reference materials to this project, but do a project "divorce cases", rename it "John Smith" when such a case presents itself to you, and it will contain all STANDARD reference materials for SUCH cases, and THEN only, collect SPECIAL reference materials applying to John Smith's case!

XI

So what should MI do offer us, in order to get all this done correctly?

At this time, there is the function "Organize Topics" (= in the file menu) - it's almost worthless as it is.

But in this function, there could be a "Super Tree", i.e. you just do a file manager (= topics, not items, we are speaking of the macro, not the micro level here) for us, where dozens of CLONES (= again, of topics, not items) are shown in a tree, and where any file can be put as subtree of any other file, or, if that's too difficult, where any files that are NOT in the first or second level of the tree, can be put anywhere, in multiple instances, into the third level of the tree.

Then, we would click onto some second-level file, and it would be loaded with any "sub-files", i.e. any files that are put "under" it.

Copying (= with sub-files) must be possible, thus "standard projects" would be possible: Thus, a case "divorce with children" would become a case "John Smith", with the 5 standard legal materials coming with "divorce with children", and then, with the mouse (= drag and drop) or by ^c ^v, we would affect 3 or 4 other special legal materials to that case "John Smith".

I am speaking here of 3 levels (= where the reference materials = sub topics would be on the third level) because of my above-mentioned fear that some lawyers would have hundreds of cases in one year, so thousands in many years: on just 2 levels this would give endless case lists, whereas 3 levels would give us GROUPS (= level 1) of lists (= level 2), where (= on level 2) a click would load all files (= level 3) listed "UNDER" the topic on level 2.

And, of course, all those entries would need a commentary function, after a tab, or in brackets, or whatever, that is to say, it would be necessary to implement some functionality into those "items" (= which are file names and their commentaries) in order to load the file "ak" without some "file ak your commentary xxx not found"!

Why this is "necessary"? Because I need short file names, 1-, 2-, 3-digit names in order to have 30 or more topics as tabs on a 15,4" screen without horizontal scrolling, and other professional users would like to do the same, and then you need such commentaries but that are NOT displayed in the file names (= no "coding" within the file name which makes the file name way too long).

And this implies that - but only in this special function, this "super tree", not troughout your system, i.e. 200 or 2,000 files = topics - those file names, when renamed, should be renamed everywhere, and the same with short comments (let's say up to 32 characters, that would do... 64 would be better...) - whenever I change a comment in that super tree, I would like that comment to be updated wherever that file name is in that super tree (and that might be, in the case of a lawyer, 500 or 1,000 times).

XII

All this will not give us a solution to the problem that on the micro level, "projecting" is not supported, i.e. cloning items does not imply any "children" add-ons further on - like in UR where the cloning functionality is absolutely wonderful, just do a ^c, then a ^v, and you have a clone, and any future "children" will appear anywhere such a clone is inserted. So why do I NOT go to UR? Because all this wonderful functionality is bound to work within ONE database, ONE file (which is updated after each minor change, so try and do some ^x ^v between two items... try to do THOUSANDS of such minor shuffles - yep, let UR drive you crazy, let it drive you NUTS!) - whereas I have 200 as yet...

So what, why not using ONE database, and optimizing the update time after each minor change? Well, have a look at professional databases. They ALL are distributed into several... many. Just have a look into the architecture of myspace or what it's called again; have a look into the architecture of databases serving not individual users but 500, 5,000 users within any business: "ONE database, ALL served"? Nope!

Thus, these problems have to be addressed within MI's architecture, within the philosophy "a file a subject, and then interacting between them", and NOT within the philosophy "since we only do, for the time being, one-user-systems, one file for all your stuff will do when this one file is optimized" - it's a philosophy without development potential.

So you know at last why I do NOT have the intention to jump unto the UR wagon (buying a faster hard disk first, in order to support all those innumerable data base updatings forcing me to wait for the program, instead of shuffling my data around ad libitum) - I'd like to work with a program that evolves into something really good, conception-wise, not with a program that will never break its inherent boundaries.

( By the way, I spent one day trying out file managers, etc., offering "virtual directories / folders", etc., trying to use one of those on top of MI in order to get my project functionality (and without the comments of course) - well, there isn't ANY ONE left... there has been one that did it in some way, but the developer is "broken", and for some file manager, there seems to be a third-party add-on which does it but which I did not know how to install. So, everybody, spare your time, do not look out for something that doesn't exist. But Petko, you see how extraordinary such a functionality within MI would be: it would be hors pair, without any competition: It would just be needed to be presented in a way people immediately saw its usefulness, and they would need to buy MI in order to have it... at least for their MI files... and so their files would necessarily be MI files... so you see what I am doing here: Not pouring "features" into MI that are present elsewhere, but precisely, INTRODUCING USP's THAT INVOKE SALES... besides me making happy.)

That's all for today, good night.

I

I would like to precise an important point of my yesterday evening's development:

1.

The "items" = entries on FIRST level of the super tree (which would be displayed in the search / action pane of course) would NOT be considered "items" in that way that MI would control if they are names (= always without the ".mio" part = the suffix of course) in your file system.

That is to say that those first level entries might or might not be identical to such files but that in any case, they would just be considered CATEGORY ENTRIES. Click on them would expand them, not trigger any loading of files.

2.

The entries on SECOND level of the super tree might or might not be identical with actual .mio files, as those on first level (always without the suffix if that is the case), and any click on them would, as above, expand those "categories", be they just a category or a category and a file at the same time.

But a DOUBLE click on those SECOND level entries would be interesting since IF those entries are present in MI's file system as a file name, this file would indeed be loaded, together with all third-level files "under" it, and if there isn't any such "main" file, the "double click" (= mouse double click or special keyboard command, please! and left / right arrows would collapse / expand like in the normal tree) on such an entry just would load its sub-entries (= third-level entries which would HAVE to be real files (in their first, their not-comment, part)).

3.

Thus, on third level, MI would ONLY allow real, existing files, or even, would ask, "this file doesn't yet exist - would you like to create it?" or something like that.

This way, on first level, you would have the possibility to create categories, independently if they are homonyms of files you have; on second level, you would do precisely the opposite: you would put in a "main file" "TOGETHER WITH" (= on third level, that is) its subordinated "detail files", OR you would just create some category that's NOT a main file but for loading those (third-level) files IN that category. (And distinguishing them on the user level would be easy, we've just had to put a "_" before the name, or anything else, in order to remind ourselves that it's just a category, not a "main file" loaded together with its sub-files.)

4.

Really important in this is that we would be able to use, on second level, the SAME file names again and again, with DIFFERENT sub-files; perhaps with some special "comment" for distinguishing. Let's take an example:

Legal cases would be naturally different, "John Smith" would be unique, it would be a main file, and it would load "its sub-files" = all those files placed underneath here (and perhaps placed underneath multiple other main files) - no problem.

But other "projects" would indeed set up a problem: "xxx" would sometimes contain "abc" and "abb" and "xyz", at others, "abc" and "jkl", and additional "comments" would not only drive the developer crazy but let in chaos for us users also!

Therefore, the solution to all the above would be:

On second level, entries MUST be unique, BUT MI would control this way: IF en entry there corresponds to a real file, that file is loaded together with its "sub-files".

If it does NOT correspond to a real file, you HAVE to use some special character before it, and why not a simple point? Thus, "abc" would be a file, and ".abc" would just be a category (= which loads its third-level files, and there, on its third level, you could put, in first place if you want it to be there, your "main file" of that category).

Those "." entries (why just a point in front? It's not as ugly as some other real "special" characters, and it takes a minimum of screen real estate, a "_" in this respect would not be smart!) would ALSO need to be "unique" - and MI would give a message if / as long as they are not -, BUT, since they do NOT correspond to real file names, you could easily do entries like ".abc1", ".abc 21", ".abc xyz", or whatever!

As said before, on third level, only real file names would be allowed, but, to the contrary of first and second level, HERE, and here only, those entries would be allowed multiple times, one file under dozens of headings if needed.

Voilà for a start.

II

Just a little remark on UR. As said elsewhere, its hoisting capability is tremendous, you can pour a part of your monster file into a new tab (but as said elsewhere, the monster file is the problem). So, you would naturally expect UR people to do something really elegant: to preserve the current state of the original tree!

Because, that way, you could hold, in your first tab, a "super tree" that is rather collapsed, and then, you would see all those details in other tabs; you could even pour sub-parts of that super tree into other tabs, which then would only show the second level of great parts of your whole tree, pouring those details into more "details tabs", your super tree, and intermediate trees would thus remain as collapsed as possible, giving in this way a perfect general overwiev instead of showing chaos.

But nope. As soon as you pour a sub-tree into any new tab, your original tree is expanded with it, and thus, chaos is everywhere.

As you see, I am NOT asking for some more feature where "the competition has it already", but again, I am asking for something really new, a USP which will make MI outstanding from the competition.

I

( This first paragraph copied from "Miscellaneous" : ) We need a third dimension, on macro level and on micro level. On macro level, that should be rather easy to implement, on micro level, it's almost impossible; in fact, ALL information management systems struggle with this problem. Since on the macro level, it's easy, I would like to develop the solution (where I do with macros at this time, which is not beautiful but is working at least). ADDENDUM : COPIED TO "THIRD DIMENSION"

II

I would like to add five important point regarding all synching of this master level tree:

a )

Of course, synching would not only be necessary when deleting and when renaming a topic, but also when CREATING a new topic. Which is to say, whenever you create a new topic, it would be automatically be referenced in a sort of "inbox" / "New Topics" heading in that super tree / topics = file management section of MI. This way, no new topic would ever be "lost", = "without a (= at least one) parent", no "orphan topics".

b )

In the same range of thoughts, on every deletion of a topic, MI would need to synch the super tree, deleting the occurrence of this topic everywhere in this virtual file system.

c )

Category entries (= first or second level entries) in the master tree could very well be renamed but never deleted except when there are "empty", i.e. when no (more) files are categorized "under" them (= in the third level beneath them). Thus, no "orphanED topics" either!

d )

MI could never hinder users from creating new MI files by copying them under a new name within the file system, e.g. with that very fine file manager we all (?) know, FreeCommander, or by the Windows Explorer or by whatever means. BUT MI would URGE its users to NEVER DO SO, explaining the reasing: In doing this, users would create orphan topics, or, when renaming topics by this, they would create orphaned topics (= the renamed topic in its renamed form) AND "inexistent topics" (= the renamed topic under its former name, always referenced in the super tree but not any more accessible under that name). As soon as users understand they'd create chaos in MI's file system by doing so, they would only use that super tree for renaming, deleting, creating... and shuffling around (cf. e) their MI topics.

e )

The same would apply to shuffling around MI topics, from one sub directory to another one. I think MI's file system should allow for sub directories since we intend professional use (I hope), and thus, there will be lawyers and other users (= not I; I could perfectly do with just one MI directory) who'll have thousands of cases and thus thousands of MI files - storing all of them in just one directory, without sub directory, could cause problems for them.

This way, sub directories should be allowed for technical reasons, but NOT MULTIPLE directories. Thus, in the super tree, all topics would be stored without their path, but the super tree itself would "know" where to find them (= complete internal storage vs. neat display).

And then, the MI files directory in a WHOLE could be renamed, or transferred to any other storage medium, even by means of the Windows Explorer or whatever. Thus, the internal links in the MI file system would ALL be relative links, whereas the name (and storage place = complete path) of the MI directory CONTAINING all those sub directories would always be, as it is today, to be determind in the MI options / presets (and could be changed there "manually" after possible renaming transferring of this directory).

III

For an intermediate solution, I am currently considering / trying out the alternative of programming AHK or AI scripts in order to do a much better macro as the one described above (= with HotKeyboard that one and thus too primitive and not shareable - at least HotKeyboard would not be shareable, and bying it would not be a good idea it seems).

I could then SHARE such a script since both AHK - Autohotkey - and AI - AutoIt - are FREE, and thus, every MI user could freely install them (= one of them) without additional cost.

Unfortunately, up to yesterday, I hadn't been aware of those programs; both seem to be as good as the most expensive commercial macro programs out there, whereas HotKeyboard by comparison is not third-, but fourth-rate.

Of course, there seems to be NO real comparison between the two programs, only such things as "a is better than b, blabla, because I like it more", or even "AHK version 2010 is better than AI version 2005" (not, that's not my joke, people seriously dare tell such crap), and that way, I'll have to compare their respective functionality thorougly before doing serious "programming" - or let's call it scripting - with them. (But I'll do it.)