MyInfo Community Forums

I

Thankfully, there are the options to "show state icons in tree" and "show doc icons in tree", so I was able to DISABLE those signets. What I miss though is the possibility to also disable the tree LINES. This option would be very nice (again, we are trying to do a neat screen, to do a functional AND A BEAUTIFUL program). BTW, UR has that option, thus have a look at the tree there with the option to "NO": it's very bautiful indeed to not have to see those unnecessary lines with your entries.

II

When searching for such an option, I understood that currently, the tree options are split up into two parts:

a )

Options - Display:
- Show Tree Grid
( - Show Topic Tabs )

b )

Properties & Security - Appearance:
- Show State Icons in Tree
- Show Doc Icons in Tree
- Multiline Doc Titles
- Use Horizontal Panes

Of course, a) are global options, and b) are individual options (= like the one which columns are to be displayed) for each topic = tree.

Thus, I am wondering if the option "Show Tree Grid" is rightly categorized under a) = global options, or if it could be categorized under b) (= and thus being made optional separately for each file). (Personally, I am not affected since I optioned for NO and have thus got rid of it, but for dogmatic reasons, that option should be under b - in fact, if "multiline doc titles" and "horizontal panes" can be chosen individually for each topic, it scarcely would be understandable that "show tree grid" only would be a global option for all topics altogether.

( COPIED FROM "MISCELLANEOUS" : )

Whenever you insert an item (or a group of items) into the tree, the tree MOVES, it scrolls, that is, but unfortunately to the BAD direction: Instead of giving you more sight of it where you want to see it after that inserting, it HIDES that new part from you... and other quirks in scrolling away from your sight. Is it a known issue that will be attended soon, or do I have to develop? In fact, I have already written some details about the various problems raised here, so could publish the details in case of need.

I SHIFTED THIS POST ( = Parts I and II ) HERE, FROM "MISCELLANEOUS" :

I

TREE SCROLLING PROBLEMS

(...) ( ADDENDUM : SHIFTED TO "TREE" )

When you shuffle around items, within the same topic or into other topics, you encounter a recurring, twofold problem whenever there are more items than there can be displayed at the same time in the window, that is, when there is the scroll bar displayed.

1 ) When you PASTE an item - or a group of items - into the UPPER third or so of the tree, instead of not moving the tree and just inserting the new items into it, the tree is scrolled upward, so as the first new item will be the first item displayed, with all items above this first new item being hidden above the window. You then must scroll manually in order to display them again. This is as ugly, as it is unpractical. (I am not speaking of very long inserts when such a "freeing" of screen space for seing them all would perhaps be ok, but I'm speaking of inserting little groups of some 3, 4 items, and it even misbehaves when you insert 1 item only.)

2 ) When you PASTE a group of items into the LAST third of your tree, THEN you would probably like to have your tree scrolled upward automatically, so as to have your new items displayed in front of you. But here the tree is not scrolled automatically, but stays as it is, and thus it is possible that almost all of your newly inserted items will be invisible if you do not then scroll the tree manually. This is almost as ugly and unpractical as number 1. But there is a third problem:

3 ) Whenever you EXPAND an item, similar problems occur: Instead of not scrolling at all at least, or better, scrolling in the right direction, the MI tree scrolls in the wrong direction, so as to HIDE precisely those sub-items from you you've just expanded: This is simply awkward!

I did not try to analyze these problems further, but am willing to do precisely that if you, Petko, could please tell me / us the current behaviour in numbers (= which behaviour is triggered when you insert what (= packages of x to y new lines, a) by pasting, b) by expanding (= if there is different behaviour)). Then, having the precise (intended) behaviour before my eyes, I would do some testing, in length, in order to identify BETTER numbers for this top and base borders overflow of the tree list in its frame. (Since the tree is with columns, I suppose you programmed it itself and that's it's not a third party component; thus, introducing better scrolling automatisms would be easily doable.)

II

SIMILAR PROBLEMS WITH THE EDITOR

(...) ADDENDUM : ALSO SHIFTED TO "TREE"

1 ) When you do a SEARCH, you then must click on the item in the search pane (= in length discussed elsewhere in this forum) in order to display the item in which there is a find .

Then, when the text (or other content) in the editor pane is not contained in one window but requires scrolling, you scroll manually with the mouse down the scrollbar up to your (wanted) hit is about in the middle of the screen.

Then you click there with the mouse, in order to edit your text. And then, as we all know, instead of not being moved (= and thus staying at the middle or even at the beginning of your screen, depending on your manual scrolling before that), it is automatically shifted to be the last line at the bottom of your screen!

Again, instead of "helping" you in doing your work, MI does HINDER you, forcing you to do a new manual scrolling in order to reset the "found term line" onto a handy position of your screen.

2 ) I don't need to say that this awkward behaviour of the editor is similar when you PASTE something into the editor: Instead of leaving your text alone or scrolling it into the right direction, it scrolls it into the wrong direction, so for your "seeing nothing" or almost.

Same as above: If you can deliver the numbers for the behaviour, I could do tests in order to identify better numbers for various cases (=after searching it's easy, it's just one line, but after pasting it would be worthwhile to differenciate depending on the POSITION (= of the cursor before pasting) and the SIZE (= in number of lines) of the pasted text - if the editor can be worked on that is.

Fred wrote:I

Thankfully, there are the options to "show state icons in tree" and "show doc icons in tree", so I was able to DISABLE those signets. What I miss though is the possibility to also disable the tree LINES. This option would be very nice (again, we are trying to do a neat screen, to do a functional AND A BEAUTIFUL program). BTW, UR has that option, thus have a look at the tree there with the option to "NO": it's very bautiful indeed to not have to see those unnecessary lines with your entries.

It will be available in the next version.

Fred wrote:II
..

Thus, I am wondering if the option "Show Tree Grid" is rightly categorized under a) = global options, or if it could be categorized under b) (= and thus being made optional separately for each file). (Personally, I am not affected since I optioned for NO and have thus got rid of it, but for dogmatic reasons, that option should be under b - in fact, if "multiline doc titles" and "horizontal panes" can be chosen individually for each topic, it scarcely would be understandable that "show tree grid" only would be a global option for all topics altogether.

This is so by design. The reasoning behind it is because 'Show Tree Grid' is generally an user preference, while "Multiline docs" and "Horizontal panes" are more of a topic-specific settings (for example, if you want the topic to look like outline, you have to enable both these options).

Hi Petko,

Thank you for answering.

ad I : Fine, will be really beautiful! Thanks a lot!

ad II : Having considered what you say, I think now you're perfectly right.

Petko,

Please verify: Your tree single-key access to items does NOT function as in any other program I know, but in a way that makes it impossible to navigate smoothly in the tree. Worse, my macro explained in length cannot work, I simply assumed that MI was working quite normally, but it doesn't. This is an issue to be addressed urgently.

When you have a category (or any other) entry beginning with "A", pressing the "a" key when in the tree above that item, that "A..." item is selected. So far so good (and normal behavior).

Then, you would like to go to a subcategory item beneath (=not indented, but just beneath, on the same (first) level) the "A..." item, let's say "1 ..." (= a digit) or "B..." (=normal a...z character).

In any other program I know, you'd press "a", and then, you'd press "1" (or "b"), and you'd be at your target item.

Not in MI, up to know, as I had to discover. The "A" goes to the "A..." item, as said before, and then, any other key pressing a...z or 1...0 does... NOTHING: focus / selection is STUCK with that item!

You first have to press an arrow key to "free" this bind (or, to not loose your position, a down arrow and then an up arrow, that makes FOUR keys instead of just TWO!!!), and THEN ONLY, you can press your second character key, "b" or whatever; alternatively, you could press the first character key, "a" (or whatever), then Escape, then your seconde character key ("b" or whatever).

THIS IS AWFUL, especially since the Escape key's position on almost all keyboards isn't quite handy (the space bar does nothing but would be awful too but less so).

So please, would it be possible to review this part of MI in order to make that arrow / Escape key pressing(s) between items choices UNnecessary? It's really very urgent, as it is, it gets incredibly in your way.

(I did'nt find out up to this day since now I need it for the explained macro, whereas up to now I always used arrow keys or the mouse to navigate.)

Fred wrote:I SHIFTED THIS POST ( = Parts I and II ) HERE, FROM "MISCELLANEOUS" :

I

TREE SCROLLING PROBLEMS

...

Fred, I investigated all three tree scrolling problems and I am glad to inform you that all of them will be fixed in the next release.

Fred wrote:Please verify: Your tree single-key access to items does NOT function as in any other program I know, but in a way that makes it impossible to navigate smoothly in the tree. Worse, my macro explained in length cannot work, I simply assumed that MI was working quite normally, but it doesn't. This is an issue to be addressed urgently.

I confirm that MyInfo does not work like other programs when using characters keys in the tree. It has a feature called "Incremental search", so when you type a character, it finds the next document beginning with this character, when you type second one, it searches for the next document beginning with this string and so on. It should not get stuck, if there is document beginning with the text you type. Is this the case for you?

Hi Petko,

I

I'm glad you see the problem. In fact, instead of "coming your way", the tree is "fleeing you" up to now. If after your adjusting this behavious, other minor adjustments seem to be useful, I'll say so, but in fact, an intermediary step to this is highly useful in itself, since currently, the tree acts like being really nasty.

I am aware the total of my little things get up to a mountain, and that I'm literally dissecting MI at this moment, but then, as said before, these are a bunch of little things that my fellow users should have complained about years ago, and this way, there is some sort of a "renovation accumulation" or "renovation tailback".

But we're speaking here of little things, a mountain of little things, but of little things all the same, and the architecture of MI is worthwile my efforts, and worthwile yours, and I'm glad we agree of this.

II

My fault: I did not see that it was a - very intelligent indeed! - design feature. After reading you, I tried, and in fact, I immediately understood. It's a question of communicating it to (potential) users (since so many potential users today use this feature abundantly... and therefore need to be informed immediately, to not fall into the trap I fell, taking for amateurishness what's in fact genius), and of taking advantage of it; I immediately got its high interest in normal use, BRAVO! (Not the slightest condescension intented, in fact I'm more than impressed, SPLENDID idea of yours!)

Of course, for my macro, it's counter-productive, but then, I might change my macro!

Cf. "Project Management with MI"

We're on a good way; MI soon will be outstanding.

"Re: Tree Navigation, "Natural Hoisting"..."

( I renamed the thread, and by "Natural Hoisting", I understand really intelligent topics distribution, but I'll explain in depth... - No, I didn't, I only renamed the subject when I thought having renamed the thread. No matter. )

So, let's discuss tree navigation, etc., it's an important subject in outlining.

I

Up to now, I always avoided navigating in trees by character key pressings, because of the unpredictability of the results, and the possible plethoria of forced-upon-you intermediate beacons.

Let's have a tree:

a...
ta...
b...
vt...
tu...
tb...
(with dozens of other entries everywhere in reality, but which are of no interest for explaining)

Now, if we have a normal tree behavior like in other programs, if we are at the beginning of the tree (= if not, it's often a good idea to go there first, by "Home", in order to have at least SOME predictability in the results), and if we want to go to tb..., we do a "t", will bring us to ta..., then we verify "are we there already?", no, so we press a second "t"; this brings us to "tu...". Again we verify, "are we there?" No! So again, we press a "t", and... THERE WE ARE! Our THIRD necessary verification brings us to our target item...

Thus, you easily understand we I, notwithstanding my hating the mouse, I do it with the mouse, or by arrow keys: There, often lengthy pressings in one direction, then (sinve "beyond target"), in the other direction again, but at least, this avoids me those recurrent verifications, "is it the right item, or isn't it yet?" which I hate more than both alternatives.

II

Of course, in order to simplify your navigation, you can collapse a max of items (see below), but in many instances, this is not a good solution: You have a "right" to have many items / categories / subcategories open, and then, have some good navigational features at your fingertips all the less, if I dare say!

III

Thus, in the "0" tree / "0 topic" doing a navigational master tree (as a draft for an inbuilt topics navigation function realized within MI itself, hopefully), I avoided, at all cost, to have categories beginning with the same character, in order to make them 1-click-accessible, and hence my 1-2-3-digit system for those sub-categories there giving instant access to those (I wrongly thought) when at the corresponding category.

Whereas in fact, MI gives us the possibility to do rather smooth navigation in the tree: In our above-mentioned example, our first "t" pressing would lead us to "ta...", but since we KNOW the name (= more or less = it's beginning at least) of our target item (= since if we didn't, we wouldn't want it to access by pressing those character keys in the first place), in MI we wouldn't stupidly press only the first character's key, then naïvely verify, "are we there?", but we'd press the first 2 or 3 keys to begin the item's name, and voilà, we're there!

(In my short-tree tiny example, the difference might look minor, but then, try in a real tree with 100 (displayed) items, and the difference is a real one!)

IV

Of course, there is always a need to differenciate a little bit important headings from each other (and from unimportant ones or from simple items on levels further down), but then, I am very well aware that MI's incremental name matching is superior by far for most uses.

Especiall when you do that "natural hoisting" I proned elsewhere, i.e. hold your topics simple, often give sub-topics their own tree! (see below)

V

In our "0 tree", the MI feature means, no need any more for just doing about 20 or so categories, but you can do more than those, why not a category A, and another one, AR, at the bottom of your screen, eg, category A being accessible by a key pressing, category AR being accessible by just two key pressings (but without any need to verify, between those pressings, where you are in your tree) - at least when you avoid giving names beginning with "Ar" to any subcategory...

Thus, in our example, "ar" would not be given to a subcategory, since we'd need it for a category name, but ANY OTHER key combinations would be great to access any subcategory on-the-fly, no need, as said before, for 1-2-3 numbering, but MI gives us the possibility to do it in a mnemonic way:

Let's have an example with family names, just for showing the principle: You'd have the category "A". Then, you'd have the sub-categories "aBlythe", "aCarolus", "aSmith", "aCurio", "aNeville", and so on.

Now, when you want to access your "aSmith" item in the "A" category, you'd type "as", and you're there, like in any traditional tree functionality; typing "ac" would give "aCarolus", typing "acu" would give "aCurio"...

You see, you'd rather avoid doing several subcategories beginning with the same "real" character (= here, the "C"), in order to simplify things, but there is, indeed, a very big other advantage to this over the mnemonic speed advantage: character encoding will give you many more subitems, if needed, than those digits 1...0, 20 or more instead of just 10, and there's a third advantage to this in most practical cases: This speed access will function FROM BOTH SIDES, you could be beneath the item to be so accessed, it'll work as fine as being above it: Try this will other outliners' traditional approach!

( I want to explain here not especially a "0 topic", but topic building in general, just taking the "0 tree" as an example, but you got this. )

VI

Now for separating topics into "natural" topics.

Do what you want with your non-important topics, stuff them with hundreds of items if that pleases you, make sub-categories at your will...

But just do this with topics you seldom address!

I, for example, have a category "c" for "Computer", another one, "n" for "Net" and "Programming", and there, there are topics like "anonymity", "domains", "examples" (=beautiful ones), "hosting", "spiders", "blog softwares", etc., and so on...

Let's have a look at some example "projects" of my category "Computer", since there is a "project" "Hardware" but EXCEPT "Keyboard", and there's a project "Software", but EXCEPT all those softwares or software categories which have their own projects. Let's see a little bit:

item Softwares = all not in other topics
item Graphics = but without FreeHand and Illustrator (both: Adobe; both: a single topic)
then, a project "Graphics" which loads item Graphics and items FreeHand and Illustrator (and some more, for font creation, etc.)
but most of the time, I use FreeHand, so I load the FreeHand topic only, not my project "Graphics", and thus, I have my FreeHand hints handy in using the program, why the he** should I have some topic "Graphics" to be loaded, from which I then would do hoisting in order to not be bothered with all this other graphics stuff I almost never acceed, just here and there to put some new infos there, for comparison reasons, for my wanting to have infos on a broad range of other softwares, etc., to "outweight" my "real stuff"?

The same with my "Illustrator" topic, I just load it when doing work in Illustrator, or when shuffling around things in my "Graphics" project, but just loading the "FreeHand" topic, most of the time, is "natural hoisting" for me, it's my way of working... and then, I did such a program "all in one file" myself, so be SURE my NEW way of working is the right one since it's denial of what I myself once realized as a program by myself!

VII

Let's have my project "Keyboard". It contains hardware, AND software, since all those additional numeric and other keypads have their own software with them in order to assign their keys; cutting up into "hardware" and "software" categories would be artificial and counterproductive (and as I said, we NEED this "cloning" feature for topics, in such a master tree; this way, some of your projects could be put in the categories "software" AND "hardware" if you have such categories: Such as freely cloning as there is cloning on the topic level, your topic "FreeHand" being in your project "load daily" (= if you're a graphist) and in your project "graphics" to be loaded once a month when you like to refresh your overview of all that's on the graphical market).

Then, my topic "Keyboards, etc." there contains all sort of things there, under Headings "Full Keyboards", "Additional Keyboards" (= with their macro languages), "Macro Languages" (but without HotKeyboard and now without AutoIt) - It's all my stuff I've got gathered, with my notes on them (and thus, whenever I'd want to buy another macro program, my notes are not up-to-date, but I'm aware of this, and my note, "doesn't allow for assigning normal character keys for any such program" won't perhaps inform me of current status, but will give me the hint where to look first when doing a 10 min. try).

When trying AHK and AI (discussed in this forum), I did a new topic for them combined. Then, I decided to stuck with AI, so I renamed my topic to "ni" (= Net and Programming - AutoIt), did thorough rearranging of those a hundred or so AI items... and stuffed my AHK thing into my "ci" topic (= Computer - Keyboard), under "Macro Programs" (where there are some 30 of them, all with 0 to 100 (=for AHK) subitems.

VIII

As you might have understood, I haven't good any character left in my "C" categories, so have to stuff natural "C" items in my "N" category, which has thus become some sort of an extension of my "C" category for currently used stuff - I NEVER said I'm perfect... indeed, my system of "1- and 2-digit file names only" is coming to its implicit boundaries; if I could decide myself to also have 3-digit topics, I wouldn't have this problem to have to install this artificial category in order to have anew my 20-or-so 2-digit topic names, the "natural" name for my AutoIt topic wouldn't be "ni" but rather "cki" = Computer - Keyboard - autoIt. Your also see that "na" for it is not possible, since "a" is taken everywhere for general things...

This problem is the disadvantage of every mnemonic = alphabetical systematics (attention, an alphabetical systematic is NOT abc = alphabetical order, since an abc turns things APART that'd belong together!), and that's why large corporations don't use them but use numerics only, you know those "1.1.4.2.4.1.6.2" systems that can be constructed with endless lists of digits... but that cannot be memorized but by freaks...

Whereas, if I from now on daily load my "ni" file, I KNOW it's autoIt (= with this tiny mnenomics-for-the-poor bit; the same, for the time being, for "nh" for HotKeyboard hints and details), and I have it always at my finger tips, whereas all those other additional keybards and macro programs I never use, are at hand, for comparing or any other wants of mine, by just loading my "ck" project.

But then, you're right, for reason of neat systematics, my "n" category should indeed be a sub-category under "c", for net things only, and thus, there should be a topic "ckh" and another "cka", for HotKeyboard and for AutoIt (= "a" being freely available on this third level where there isn't such an ubiquitous necessity for reserving it for general purposes as is on the second level), and to he** with my "2-digits-only-please!" claim which simply isn't practical enough... I'm learning, as we all are learning each day... and I'm sharing my insights...

IX

So, this is what I call "natural hoisting": When you need things regularly, SEPARATE them, grant them their own housing!

And feel free to stuff hundreds of things you rarely look into, IF and to the EXTENT ONLY that they belong together; but the real secret is, feel free to separate those thing that indeed belong into such a group, but of which you need easy access: THAT's the intermediary result of my "research" here - and that's be easy to realize as soon as you adopt, as I have done, that "project" concept...

X

... and then, this "project concept" is NECESSARY ANYWAY since it OVERCOMES the inherent limitation of the tree system: Many, many subjects might very well have their "natural" place in this world, as your car assurance has its "premier" place in your "assurances cabinet" indeed; but then, it has its "second" place in your "car cabinet", and whatever you do, you MUST store it into (at least) those TWO places (= and for that, as soon as you have intellectual concepts, their storage needs ain't twofold, ofte they're tenfold!), and thus,

OR you end up with such monster trees as can be done in stable outliners as MI or UR, but where even heavy hoisting does not really limit clutter everywhere, besides becoming a monster file of more than 2 GB stuff will interfere with many operating system boundaries, so expect crashes or

OR you overcome the tree system by another tree, a master tree, and there, indeed, elaborate (and easy) cloning is a necessity;

OR you rely on tagging, again in such a monster tree, and that doesn't resolve any problem, or tagging different files, but not enough either, except when you do TAG TREES...

As said before, a dichotomy between trees / outlines and tagging cannot be resolved but by not accepting it, you HAVE o combine those concepts in order to succeed (and that's what MySpace and FaceBook do, for their monster data amounts, thus I'm not really giving something new here, I'm simply trying to find ways to apply their intelligence unto mid-size applications... just imagine, at this time, all these outliners here around are single-user systems, which is NOT where the mass market is: As soon as we get some real intelligent architecture, easy to be implemented (= "doable" for an info management system developer), the "little corporations market", i.e. all those tiny enterprises suddenly come into reachable range of marketing efforts...

But that simply cannot be done with UR's philosophy of monster trees; technically, yes, but then, management efforts get in your way. People need to share information, be it 3 people, 5, 10, 500...

Oh yes, for the big companies, there's specialized software out there, out of reach for the tiny enterprises, and not really - for what I have "seen" (= for what I did get some info about) adapted to your writing / "compositon" needs; more or less, these monster systems are for "document management", for storing and sharing (and even "work-flowing") "already-done" documents, and so, legions of their users are constantly shuffling around between their MS Word writing and their exporting needs into the monster system - an intuitive workspace is quite another thing.

Perhaps - speaking of MI 10 - we succeed in creating such a thing; let's address, 1 by 1, the necessary intermediate steps.

XI

Oh yes, I forgot: My wanting COMMENTS is NECESSARY for file / information sharing, thus it'll NEED to be done one day... but then, it's easy, from a technical point of view, since my topics-managing super tree idea implies heavy use of arrays to maintain (since MI, not the user as in my macro, would need to synch after all renaming, shifting, newly-creating, deleting!), and having comments (= let's say max 64 characters long) would only need another dimension of those arrays, multi-dimensional anywhay: Shifting around a xxx[3][2][23] only, or an xxx[3][2][23][1] and an xxx[3][2][23][2] together each time, that makes no real difference, and would be another BIG step into the right direction from which we could optimize again and again.

I've got my topic ci = "Information Managers", with about 80 headings (and subheadings for those like UR, CT, and even PB, and I load it once a month perhaps)... but then, I've got my topic cm, MyInfo, loaded with every other topic I ever load.

As usual, this discussion is way over my head: I'm a heavy user of MyInfo and other note-taking apps but have no experience in programming.

But here's what I'd like to see in the MyInfo tree:

The tree as it exists seems pretty straightforward and easy to use, but I am also accustomed to using the list of tags in the left column of Evernote. I think it would be wonderful, in the left column of MyInfo, to be able to either switch back and forth between tree and tags or have both of them in parallel columns. Petko, haven't you implied sometime in the past on this forum that you might consider moving the tags to a position at the left of the screen?

Another notion I've often fantasized about is the possibility of having two or more trees in the same file. Here's why it appeals to me: For a couple of years I've been accumulating great piles of notes (in the thousands, no doubt) for a book I hope to write. As I go along, I can't envision exactly the shape of the final book, because my plan of organization keeps changing as I find new material. Hence my tree at the moment represents just a very tentative scheme of organization built around some broad themes. What I need is a second tree in which I organize my notes (OK, documents) in exactly the order I want to see them when I finally begin to write.

There is, of course, another way of doing this, though it feels slightly clumsy. I can create a new topic, build a detailed outline in it, and insert links to the documents in the original topic. But that sounds rather labor-intensive to me.

Fred,
Thank you for all of your insight.
I learned quite a bit, and will be incorporating some new features in my workflow.

Suggestion:
What you think of entering all your suggestions into myinfo.uservoice.com ?
In this way, you can also see how other users are agreeing/disagreeing with you.

I will definitely support:
* more advanced cloning (all subdocuments)
even at the highest level - when I cut and paste a cloned document, it becomes
a standard document.... not good for my purpose.
* filter/tag displaying item in tree order (and NOT alphabetical order)

Regards,

Hi Crystal,

I

I misunderstood something, thus I must edit again, after having reread!

II

I'm not so sure I'm thoroughly read (any more) by that much fellow users, but then, I try to imagine how such a program could be made attractive to new users who at this time might not yet use such a program.

I don't know uservoice.com yet, I'll have a look.

III

You say, regarding cloning, "not good for my purpose" - ? But then, is it worthwile? What I'm targeting at: Cloning, WITH synched sub-documents, is a tremendous feature from the moment on it's allowed BETWEEN files!

Because then, and then only, it would be possible to have reference material in their respective files = topics, AND to use those materials, bit by bit, in multiple files where those reference materials are needed: Have a lawyer with his laws, fine, but then, for his cases he especially needs only SOME provisions, relevant for those cases, and it would be a tremendous thing if he was able to clone just such pieces of information from several laws topics into the concerned cases topics.

Why? Because he would like to COMMENT these law bit, by his own personal notes perhaps, but also and more so, by adjoining to them extracts from judgements, extracts from new commentaries (= law commentary books, maybe in electronic form, extracts by data bases from the web or scanned pages, etc.), and those pieces would not concern but one of those cases but all (not-yet-closed) cases where those special provisions are needed = integrated by this cloning.

Thus, be it with sub-documents or, if not possible otherwise, in integrating new information into the document itself... the decisive factor would be, allow cloning BETWEEN topics!

And I know very well that at this moment, nobody at my knowledge allows that, not UR, not CT, not PB, not dozens of lesser "competitors"...

I made a hint to this problem in saying, "Third Dimension on the Macro Level" and "Doesn't yet resolves the problem of third dimension on the micro level"... - but then, I thought, one step after the other?!

IV

The tree of MI allows for more than the help file and the GUI / command denominations tell (Again, a communication problem: MI is much better even that it claims to be!):

The help file says, you can do hyperlink in the editor. When in the tree, at any given item, the right-click mouse menu shows the command "Edit Hyperlink" - the same command can be assigned to a key / key combination.

Well, when you trigger this command, there is a dialogue that seems to only allow URL links... which is wrong!

In fact, take any tree item, or make a new tree item, let's say name it "ab" for your MI (or any other) file "ab" / "ab.mio". Then do the "Edit Hyperlink" command. Then enter e.g. "file://c:\mi\ab.mio" (= without the "") into the second field of this dialogue (= has focus by default). Then do "Enter" (= all this can be facilitated by a macro).

Voilà, now you have a hyperlink to your file in the tree, and a DOUBLE click opens it in its original / assigned (= by Windows) application, whereas, e.g. for a ".txt" file, a normal (= not double) click on the item opens a special edit screen, for notes, and with a "Click to open the link": When you click there, the .txt file opens there, not editable (but viewable).

I am currently trying to manage my numerous programming scripts = text files with this system, don't know yet if it's really practical BUT indeed it offers me a third dimension for those files, since I can put these hyperlinks, to the SAME text files, beneath DIFFERENT MI headings... (Or in several topics = reuse not just of code snippings in several projects, but even of made-up scripts.)

V

These links are, of course, not updated, so whenever e.g. I rename such a text file, all the links will be broken or are to be maintained manually; when do do all this linking in just ONE file, the search function should help with this... but it shows, as every linking procedure, the underlying problem: Indeed, links should be maintained by the program, in a database table, to, in and from which they should then automatically updated in a system.

Again, NO "competitor" does such a thing to my knowledge, so there's indeed way to excel!

So, again, we're overwhelming Petko with loads of possible work - must be frightening!

Fred,
1.
myinfo.uservoice.com
- You can see what Petko is working on right now.

2.
cloning with subdocuments
To make myself clear- YES, I agree with all of your points about syncing/cloning.
However, implementation wise, maybe it seems more realistic to ask for
this subdocument cloning and syncing for "within topic" first.

Hi again,

Again my fault, you're very right, after pasting, all cloning character is gone! In fact, a cloned document does not BECOME a "normal" document, it just SEEMS to be one, since there isn't any special sign on it, as there is in UR, e.g. In fact, after cloning, you can change the original doc or the cloned one, as you like, but after copying, cutting, pasting (= even in the SAME topic, since between-topic doing is again much more "impossible" if I dare say), the ITEM, not some of it's content, chaos begins! And that's why, in MI, I DON'T USE ANY CLONING!

I tried, but I simply cannot find a real use for it, it's use being too "shortcome-ed" by its limitations! (And knowing it in UR, it's a world apart...)

But let's speak frankly: There would be tremenous work in it, perhaps without even getting to UR's fine feature, and so, I am trying to find new features in order to establish USP's for MI which could be developed in a rather simple way (= not months of coding for each feature), AND make a big difference in its usability = benefit for users / potential buyers.

In other words, cloning is the weakest MI feature in comparison with UR's cloning feature, so I try to give ideas for matters where MI could excel more easily!

And then again, neither UR nor CT nor PB HAVE such INTER-FILE cloning / synching / referencing / etc. in any way to my knowledge (and I say "to my knowledge" to avoid trials in case I overlooked something, I did serious research, without finding anything there).

In MI at least, TAGGING is possible to be SEARCHED inter-file-wise (but searching a tag in my 200 NOT-loaded files takes several minutes, so there's definitely no index for this!!! Petko, please, this would be a beginning for tag enhancement!), but inter-file searching will be implemented in UR, then (= it's on their roadmap, as is real tagging)... but then, MI does NOT yet allow for TAGGING CONSOLIDATION inter-file-wise, hence my lengthy discussion of this elsewhere; your other thread today picks some problems out of this context up, and indeed, there it must begin.

ALL things "INTER-FILE-WISE" MUST be optimized if a program wants to compete, with file fractionizing, with such a "big tanker" as UR is, i.e. MI will lose if it tries to compete where UR is that strong, and again, cloning is its strongest point; so we must find other USP's...

and we must bear this point in mind!

But then, doing some reference tables (to be loaded into memory whenever MI is loaded there) in order to update them every time you do a (simple) cloning or other referencing between several files = topics, technically, is EASY, thus could easily be done, and WOULD be something the great competitors DON'T have!

A word upon PB, PersonalBrain (I spoke in length about it on June 22 at bitsdujour.com):

Their graphics philosophy is very well indeed for this top level, topics in the sense of those great categories and projects: There, indeed, 3-dimensional graphic representation is best.

And so, and since they do a free version that functions in a crippled but not time-limited way, I tried PB in view of perhaps using it as a "GUI", a graphical user interface, for MI, to manage precisely those projects, etc., I have explained here, and which at this time, cannot be managed but by manual sideways, in an awkward way, if you use MI. Thus, I didn't want to replace MI, but I thought, since PB is free, why should we all not use it as an accessory to MI?

Well, there ARE people out there who love PB, and I can tell why: For storage of pdf's, there doesn't seem to be any better out there! And there are scientifics whose incoming materials virtually ain't but pdf's; in the AS forum, somebody has left some time ago, stating he's got 10,000 and more pdf's, and PB allows him to manage them, i.e. to SEARCH their CONTENTS in PB!

But then, for me, pdf's ain't but SOME sources, and then I store them without needing them to be searchable; that would be very well indeed, but I don't depend on this, since most of my docs are formatted text docs, neither original web pages nor pdf's.

So, PB is a very specific application for some people who really need it's USP, and thus, MI would not be too well advised to try to have this, since they have it in a perfect way. (see above)

But for general use, there's a design "fault" (= as I see it) in PB: No need whatsoever to organize ALL your stuff in such a graphic way - which is indeed perfect for designing such a third dimension on top of all your stuff, at the "immediate-access level", but which is not suited (= as I see it) to organize the details, where lists, chunks, information clusters are the best way to organize things.

(But those people had one big, big, big idea, and so, they try to organize the - our! - whole world to suit this big idea! What do they say? If all you've got is a hammer, you don't see any more but nails everywhere!" - right?)

And for organizing MI topics into projects by PB, well:

- First, there's no synching either.

- And then, second, PB triggers only one any file at a time, i.e. when you try to organize projects with it, you must click on every single hyperlink in PB, and thus, if your MI project contains 8 topics, you'll switch 8 times between PB and MI, each time clicking on another PB node in order to launch another MI file; I know ways to make you crazy that are more fun!

This is because PB doesn't allow for loading several files at a time (and notwithstand the synch problem then which this way doesn't need to bother us): a hyperlink "x" "y" "z" brings the message "File doesn't exist".

Thus, MI itself must allow for doing inter-topics work without the need of third-party programs, be they free or not.