Search Results
I said it before, in 5.5 there were up to 3 search results underlined = "selected" concurrently when you selected them with the mouse, one after another. You evidently did some work on this, since now in 5.51, I only "succeed" in thus selecting TWO search results, when in fact, there should be only ONE selected search result at any given time, since only ONE item is displayed.
But worse: Since you introduced, THANKFULLY, that new command "Go to next/previous search result", these "selected" search results, selected by mouse click, have no more anything to do with any actually displayed search result: It is now perfectly possible to have two (!) "selected" search results in the search results pane, whilst a THIRD one, NOT selected there in any way, is actually displayed!
And this brings me to another problem (mentioned before, in 5.5): If you select search results by the aforementioned commands ("go to next/prev result"), unfortunately, there are NO selection of these displayed items in the results tree, so you get rather quickly lost in that tree if you rely upon these key commands, instead of clicking the results by mouse, so up to here, there's no real progress made in this.
I assume you are continuing your work here, and the current state of affairs is just an intermediate result, so my observations are in no way intended as puns.
But as said before, you should consider implementing NORMAL commands, up and down arrow, instead of those special commands, since users would like to select = give focus to the search results pane, then browse the hits, by up / down arrows, perhaps go to the text field of a hit (= by tab key, e.g.), then again they would re-select the search result pane, and again, up and down arrows should scroll in that special list.
In fact, and I did in length develop this subject in this thread, elegant user interfaces should, whenever possible, try to apply the SAME standard commands, in the special appropriate way, to their different objects: If this or that object has focus, then the standard command does have a "standard" effect on the content of that object, just adapted to the special character of this special content, but as standardized as possible, in order to make program usage easy, even when program possibilities and features are elaborate as hell!
Thus, doing special commands for browsing in the search results pane is better than not to have any browsing feature there, as before, but is unelegant GUI design: No user needs SPECIAL commands for browsing in the search results, since those special commands would only be helpful if there were situations in which users doing something ELSE would STILL need to browse in that pane, concurrently, and at this moment, I don't see any such situation. Thus, the affectation of the STANDARD list browsing commands, to these functions, as soon as this list has focus, is the only natural way to implement this function.
And this is not preposterous lecturing, it's just the one and only truth, and as such, real help.
EDIT: Oh yes, and PgDn / PgUp could jump to the next/prev topic in that search result list!
And right/left arrows could expand/collapse those topics' search results (sub-lists): This is by no way of academic interest only since you only have those commands, search subtree, search tree, search open trees, search all treas... and not, "search selected trees" (= by multi-selecting in any file list e.g.). Thus, you thankfully provided the manual possibility to collapse (and re-expand) those subtrees, for search results in automatically-included but unwanted topics, and thus, being able to dismiss them by key pressing would be more than handy, here and there.
And finally, my graphical considerations here apply to the search results pane also, and especially, since you thankfully could get rid of the tree pane's tabs, could you do the same with the tabs beneath the attributes / search results pane? (Again as an option of course.)
Two Hints
As said before, EditTags, EditComment and Rename/Edit (F2) should work even when focus is NOT in the tree, just as the now very fine (and thankfully even with search term history) "find files" command now works from everywhere (as said before, I do it by a macro first focusing the tree, but as said before, the program itself should work in an elegant way, without users having to fall back on macros just for doing NORMAL things - for the special things of each user, it's another question...).
BTW, my advice / wish to get rid of the grey vertical thick line between tree and text applies as well to the search results pane / task pane: no problem there either, since the search results are in blue, so with a WHITE thick "line" / vertical ribbon instead, their color alone will perfectly mark them as separate, special... just try it, it'll be modern and beautiful! And for the double arrow appearing on those lines and indicating / used for resizing the different panes, people using modern software will immediately understand that those arrows will appear there, on white background, as well as they would appear on vieux jeu grey thick lines, so resizing frames will function as ever.
EDIT: When loading (existing) topics, that flashing of filter view is thankfully gone, but the flashing of an empty tree/text/item view persists, together with a half-baken ruler above an empty text field, even when the ruler (for this topic and for all topics) should not be displayed (and will not be displayed anymore once the loading processus is finished). Thus, as said, please, introduce something like "syslockscreen = true/and then false" or anything comparable into the loading procedure, in order to have topics displayed in a neat way, from the beginning on!
EDIT2: Thank you very much for the command "TextEditor" which I just discovered and which I had asked for to exist in the way like "Tree", etc., i.e. "GoToThatSpecialAndPrecisePaneFromAnywhere". Thus, in my macros, I don't have to go to Tree first and then do the toggle to go to the text pane. Cute!
EDIT3: I've used this (with the old command) for a long time now, but never spoke about it, so here as a hint, for new users and the help file:
First, put the very fine new "toggle tree / text" command on the key just to the left of the Enter key, on German keyboards it's the number sign, on Swiss-French keyboards it's the dollar sign. So sacrify this sign (or put it onto a key combination, by a macro program), and put, in MI, the ttt (tree-text-toggle) on this key.
This will be a tremendous help in everyday use, since this way, you'll toggle, with your right hand near the arrow keys, between tree and text.
And furthermore, whenever you create a new item, don't do "Enter" after naming it, but just press the ttt, and you're in the text pane (as you were with the old command also), and you can start typing.
Existing users should have found out this for themselves? And if not, some "thank you fred" would be welcome.
EDIT4: The "Confirm Delete" message after the delete command for deleting an item cannot yet be exited with pressing Escape. As said before, such "normal behavior" is expected from users, so it's awkward to try it as in any other program, just to see that in MI it does not work. Should be easy.
BTW, my advice / wish to get rid of the grey vertical thick line between tree and text applies as well to the search results pane / task pane: no problem there either, since the search results are in blue, so with a WHITE thick "line" / vertical ribbon instead, their color alone will perfectly mark them as separate, special... just try it, it'll be modern and beautiful! And for the double arrow appearing on those lines and indicating / used for resizing the different panes, people using modern software will immediately understand that those arrows will appear there, on white background, as well as they would appear on vieux jeu grey thick lines, so resizing frames will function as ever.
EDIT: When loading (existing) topics, that flashing of filter view is thankfully gone, but the flashing of an empty tree/text/item view persists, together with a half-baken ruler above an empty text field, even when the ruler (for this topic and for all topics) should not be displayed (and will not be displayed anymore once the loading processus is finished). Thus, as said, please, introduce something like "syslockscreen = true/and then false" or anything comparable into the loading procedure, in order to have topics displayed in a neat way, from the beginning on!
EDIT2: Thank you very much for the command "TextEditor" which I just discovered and which I had asked for to exist in the way like "Tree", etc., i.e. "GoToThatSpecialAndPrecisePaneFromAnywhere". Thus, in my macros, I don't have to go to Tree first and then do the toggle to go to the text pane. Cute!
EDIT3: I've used this (with the old command) for a long time now, but never spoke about it, so here as a hint, for new users and the help file:
First, put the very fine new "toggle tree / text" command on the key just to the left of the Enter key, on German keyboards it's the number sign, on Swiss-French keyboards it's the dollar sign. So sacrify this sign (or put it onto a key combination, by a macro program), and put, in MI, the ttt (tree-text-toggle) on this key.
This will be a tremendous help in everyday use, since this way, you'll toggle, with your right hand near the arrow keys, between tree and text.
And furthermore, whenever you create a new item, don't do "Enter" after naming it, but just press the ttt, and you're in the text pane (as you were with the old command also), and you can start typing.
Existing users should have found out this for themselves? And if not, some "thank you fred" would be welcome.
EDIT4: The "Confirm Delete" message after the delete command for deleting an item cannot yet be exited with pressing Escape. As said before, such "normal behavior" is expected from users, so it's awkward to try it as in any other program, just to see that in MI it does not work. Should be easy.
THE CUT & PASTE BUG
You said you eliminated the but, well, not entirely!
In fact, I did several cut and paste things, without any problem; they all were single items.
Now, I cut and pasted a block of FOUR items; some of them had sub-items. This time, nothing was lost, so real progress has been made, but as soon as the paste was done (and the four items showed up in the target tree), I got that nasty error message again wanting to be sent by the net: "Error occurred - List index out of bounds (-1)". So please look again at it, and this proves I was right some days ago when I said those university professors, etc. say all's right when in fact it should be easy for them to share in my debugging work here, instead of leaving me all alone to do it for all of us. But may be as it is, I'm not in the mood to get angry at them again.
EDIT 2: Other packages are cut and pasted just fine if those items do NOT have any sub-items, so it's the sub-items that trigger the bug.
But please, Petko, I do tremendous work here, so be nice and follow my advice to radically modernize the look of MI, trust me, please, I'm not going to try to have you realize something unappealing to the masses, on the contrary. Have it my way, and people will come and buy, promised.
EDIT: Commercial consideration: All these little things in 5.5, and then, immediately afterward, let's start the 6 betas, everytime with a time limit which will prevent people from "having" a 6, definitely, without paying for it. This way, we'll be free to implement all the things for v. 6 as soon as they are available, one after another, AND TO DISCUSS THEM thoroughly IN THEIR MAKING, instead of "having nothing" for too many months, and then be in a hurry preventing us from doing the details the right way. This way, every "5.5 Professional Final" user will get those 6 betas "before time", but so what? He'll have to buy one day, in order to use those v. 6 features he'll be accustomed to by then, indefinitely!
And of course, Daly should upgrade to Prof., in order to not be left out of this stream! (Upgrade is 45 dollars it seems, so it's 5 dollars more than the price difference, but that seems to be fair: compare with wasps' monthly income!)
Let me say to fellow users that since I make extensive (mis-) use of the web link, in order to link to other topics (which, for the time being where this linking is not yet possible to given items in those other topics, requests cutting up your topics into a lot of rather tiny topics, but if I can do this with 100,000 topics, you can do this with possibly less topics?), MI has become really useful for me. I very much hope that Petko and his fellow programmer will be able to deliver a linking to other topics' items for 6, and then, with another, much better look than today's, it'll be a real useful and appealing program for everyone, so there's real future in it. Project management will then be easy, with rather little (and which is more, easy) more features needed for this. Thus, upgrading is worthwile, and I'll give my hints how to best use it in elaborate real-day tasks. I try out a lot of things with macros at this time, and I'll share my findings, awaiting their implementation in MI itself.
EDIT 3: I can now assert that the reason for the bug (= at least one of the reasons, and perhaps the only one) is this phenomenon: You paste a block of several items into a new location, fine... but if the item BEFORE THE LAST ONE of this block has sub-items, this bug occurs every time (and I did not see it occur on other occasions anymore). Thus, if your block has 6 items, and the 5th item has sub-items, the bug occurs, e.g. This is perfectly replicable, so I hope your encoder will identify his error.
You said you eliminated the but, well, not entirely!
In fact, I did several cut and paste things, without any problem; they all were single items.
Now, I cut and pasted a block of FOUR items; some of them had sub-items. This time, nothing was lost, so real progress has been made, but as soon as the paste was done (and the four items showed up in the target tree), I got that nasty error message again wanting to be sent by the net: "Error occurred - List index out of bounds (-1)". So please look again at it, and this proves I was right some days ago when I said those university professors, etc. say all's right when in fact it should be easy for them to share in my debugging work here, instead of leaving me all alone to do it for all of us. But may be as it is, I'm not in the mood to get angry at them again.
EDIT 2: Other packages are cut and pasted just fine if those items do NOT have any sub-items, so it's the sub-items that trigger the bug.
But please, Petko, I do tremendous work here, so be nice and follow my advice to radically modernize the look of MI, trust me, please, I'm not going to try to have you realize something unappealing to the masses, on the contrary. Have it my way, and people will come and buy, promised.
EDIT: Commercial consideration: All these little things in 5.5, and then, immediately afterward, let's start the 6 betas, everytime with a time limit which will prevent people from "having" a 6, definitely, without paying for it. This way, we'll be free to implement all the things for v. 6 as soon as they are available, one after another, AND TO DISCUSS THEM thoroughly IN THEIR MAKING, instead of "having nothing" for too many months, and then be in a hurry preventing us from doing the details the right way. This way, every "5.5 Professional Final" user will get those 6 betas "before time", but so what? He'll have to buy one day, in order to use those v. 6 features he'll be accustomed to by then, indefinitely!
And of course, Daly should upgrade to Prof., in order to not be left out of this stream! (Upgrade is 45 dollars it seems, so it's 5 dollars more than the price difference, but that seems to be fair: compare with wasps' monthly income!)
Let me say to fellow users that since I make extensive (mis-) use of the web link, in order to link to other topics (which, for the time being where this linking is not yet possible to given items in those other topics, requests cutting up your topics into a lot of rather tiny topics, but if I can do this with 100,000 topics, you can do this with possibly less topics?), MI has become really useful for me. I very much hope that Petko and his fellow programmer will be able to deliver a linking to other topics' items for 6, and then, with another, much better look than today's, it'll be a real useful and appealing program for everyone, so there's real future in it. Project management will then be easy, with rather little (and which is more, easy) more features needed for this. Thus, upgrading is worthwile, and I'll give my hints how to best use it in elaborate real-day tasks. I try out a lot of things with macros at this time, and I'll share my findings, awaiting their implementation in MI itself.
EDIT 3: I can now assert that the reason for the bug (= at least one of the reasons, and perhaps the only one) is this phenomenon: You paste a block of several items into a new location, fine... but if the item BEFORE THE LAST ONE of this block has sub-items, this bug occurs every time (and I did not see it occur on other occasions anymore). Thus, if your block has 6 items, and the 5th item has sub-items, the bug occurs, e.g. This is perfectly replicable, so I hope your encoder will identify his error.
Last edited by Fred on Tue Jan 18, 2011 10:40 pm, edited 4 times in total.
Second Text Window
As we all know by now, our observations (Felix' and mine) have not yet been addressed; I'm not ranting since you're certainly working on it, I just included it here in order to gather "all things undone yet" in one thread.
As we all know by now, our observations (Felix' and mine) have not yet been addressed; I'm not ranting since you're certainly working on it, I just included it here in order to gather "all things undone yet" in one thread.
Go First Doc/ Go Last Doc (= in tree)
a ) The commands were necessary and have thankfully been implemented. Unfortunately, they work errateously. Sometimes, they work fine, sometimes GoLast goes to the last item not in the tree, but its last first-level item, and often both commands select all items between the current item and the first / last one = dozens of them, incl. the pane "there are xxx items selected".
Since you did assign those commands by default onto shift-alt-home and shift-alt-end, I suppose that the shift component in these assignments does do some bad work in these bugs, but that would not yet explain everything of this erratic behavior.
I'll try now with other key bindings, without any "shift" part in them, but anyway, a lot of users would certainly (like to) stay with your default key bindings, so even with some "shift" part in it, it should function correctly.
b ) Tried with control-alt-g and control-alt-h. Did work fine first, several times. Then same problem as above, selecting several items (and not only all items between current item and first item, but just 2 items in-between where in fact there would have been many more). Is indeed a bug in the commands, and has nothing to do with a possible "shift" part of a key binding.
EDIT: I have a macro "Go to Tree", 4 times PageUp (since the "Go First Item" command does not work correctly yet), Collapse All. Works fine, except for the fact that then, the first item is selected (good so), but not displayed; instead, I get that ubiquitous message, "There is 1 document selected."
Well, if there is 1 document selected, I would like to have it displayed, the above-mentioned message not being of any interest but if there are 2 or more documents selected, and let's face it, if we hadn't above-average navigational requirements, we'd all use MS Word or whatever, not an outliner. Thus, smoothly (and correctly, to begin with) working navigation commands are the CORE functionality of an outliner.
BTW, my first item is (as anywhere in my about 250 topics), one of those in-length-described "Web resource" item = link in the tree, and if my first tree item is (= I just tried out for this reason) a normal text item, its text is displayed. But be it "Web resource" or normal text item, the item should be displayed (= the item itself, without triggering the link, that is), like it is when I navigate manually to the first item (= "Web resource" item).
In the above-mentioned macro, the command that displays the message screen ("There is 1 document selected.") instead of the item, is the "Collapse All" command, BTW
a ) The commands were necessary and have thankfully been implemented. Unfortunately, they work errateously. Sometimes, they work fine, sometimes GoLast goes to the last item not in the tree, but its last first-level item, and often both commands select all items between the current item and the first / last one = dozens of them, incl. the pane "there are xxx items selected".
Since you did assign those commands by default onto shift-alt-home and shift-alt-end, I suppose that the shift component in these assignments does do some bad work in these bugs, but that would not yet explain everything of this erratic behavior.
I'll try now with other key bindings, without any "shift" part in them, but anyway, a lot of users would certainly (like to) stay with your default key bindings, so even with some "shift" part in it, it should function correctly.
b ) Tried with control-alt-g and control-alt-h. Did work fine first, several times. Then same problem as above, selecting several items (and not only all items between current item and first item, but just 2 items in-between where in fact there would have been many more). Is indeed a bug in the commands, and has nothing to do with a possible "shift" part of a key binding.
EDIT: I have a macro "Go to Tree", 4 times PageUp (since the "Go First Item" command does not work correctly yet), Collapse All. Works fine, except for the fact that then, the first item is selected (good so), but not displayed; instead, I get that ubiquitous message, "There is 1 document selected."
Well, if there is 1 document selected, I would like to have it displayed, the above-mentioned message not being of any interest but if there are 2 or more documents selected, and let's face it, if we hadn't above-average navigational requirements, we'd all use MS Word or whatever, not an outliner. Thus, smoothly (and correctly, to begin with) working navigation commands are the CORE functionality of an outliner.
BTW, my first item is (as anywhere in my about 250 topics), one of those in-length-described "Web resource" item = link in the tree, and if my first tree item is (= I just tried out for this reason) a normal text item, its text is displayed. But be it "Web resource" or normal text item, the item should be displayed (= the item itself, without triggering the link, that is), like it is when I navigate manually to the first item (= "Web resource" item).
In the above-mentioned macro, the command that displays the message screen ("There is 1 document selected.") instead of the item, is the "Collapse All" command, BTW
Last edited by Fred on Mon Jan 17, 2011 1:31 pm, edited 1 time in total.
New Items
I've got a new item that is formatted, in the tree, regular but black, instead of grey, and that should not be so since it's empty! There are no add-ons / files / pdf's / etc., I opened the attributes pane to see if there is hidden content, but no; of course, I did, in this new item, several times delete and backspace and control-a for select all and then delete, to no effect. "Text Size" attribute is about 11,000! Then I got interested in other items, having just very little text (no rtf), and for some 30 characters, they appear to have about 13,000 or 15,000 (= characters?????)!
Thus, two things:
a ) There appears to be a bug somewhere now in 5.51 since never ever in 5.0 I had such a black instead of grey formatted (= in the tree), definitely empty item, and with no add-ons.
b ) Why items with just some 20 or 40 normal characters in them, like these here (= no Chinese or whatever) appear to have about 15,000 characters if you believe the "Text Size" attribute in the attributes pane? That's so weird that it would be interesting to have some information upon this.
BTW, other empty items are indeed be indicated with a "Text Size: 0" attribute...
And finally, I entered 13 characters (jkljkljkljljl) into such a "normal" empty item's text field, went to another item, went back to the 13-characters field: Text Size according to the attributes pane: 10,929... whereas the false empty item above would have, according to MI, 10,901 characters or whatever, in its text field. Please comment.
In order to get it possibly right, I entered text into the weird item above (= item in the tree is black instead of grey, whilst being empty), went to another item, went back: always black (= now rightly so since some characters in it). I then deleted those new characters, the text pane of the item being empty anew...
Well, you've guessed it: Newly emptied item remains black in tree, instead of being formatted in grey...
There's definitely a new bug in 5.51 in this matter.
And finally again, saving the file doesn't change anything. So I closed the file and reopened it. Behavior unchanged, empty item blacked, not greyed, text size 10,901...
I shifted it to another place in the file: unchanged.
So I cut and pasted it: unchanged for the formatting: black, not grey. But text size according to attributes pane is 0 now. So why the black color instead of grey?
Put some character into it: text size about 11,000 again. Deleted those characters: Item's color in the tree is black, not grey. By palette, put another color to the item, worked. Put the item's color back to black: it's black, not grey, whilst empty.
I've got a new item that is formatted, in the tree, regular but black, instead of grey, and that should not be so since it's empty! There are no add-ons / files / pdf's / etc., I opened the attributes pane to see if there is hidden content, but no; of course, I did, in this new item, several times delete and backspace and control-a for select all and then delete, to no effect. "Text Size" attribute is about 11,000! Then I got interested in other items, having just very little text (no rtf), and for some 30 characters, they appear to have about 13,000 or 15,000 (= characters?????)!
Thus, two things:
a ) There appears to be a bug somewhere now in 5.51 since never ever in 5.0 I had such a black instead of grey formatted (= in the tree), definitely empty item, and with no add-ons.
b ) Why items with just some 20 or 40 normal characters in them, like these here (= no Chinese or whatever) appear to have about 15,000 characters if you believe the "Text Size" attribute in the attributes pane? That's so weird that it would be interesting to have some information upon this.
BTW, other empty items are indeed be indicated with a "Text Size: 0" attribute...
And finally, I entered 13 characters (jkljkljkljljl) into such a "normal" empty item's text field, went to another item, went back to the 13-characters field: Text Size according to the attributes pane: 10,929... whereas the false empty item above would have, according to MI, 10,901 characters or whatever, in its text field. Please comment.
In order to get it possibly right, I entered text into the weird item above (= item in the tree is black instead of grey, whilst being empty), went to another item, went back: always black (= now rightly so since some characters in it). I then deleted those new characters, the text pane of the item being empty anew...
Well, you've guessed it: Newly emptied item remains black in tree, instead of being formatted in grey...
There's definitely a new bug in 5.51 in this matter.
And finally again, saving the file doesn't change anything. So I closed the file and reopened it. Behavior unchanged, empty item blacked, not greyed, text size 10,901...
I shifted it to another place in the file: unchanged.
So I cut and pasted it: unchanged for the formatting: black, not grey. But text size according to attributes pane is 0 now. So why the black color instead of grey?
Put some character into it: text size about 11,000 again. Deleted those characters: Item's color in the tree is black, not grey. By palette, put another color to the item, worked. Put the item's color back to black: it's black, not grey, whilst empty.
Hyperlinks
I hope some adjustements as described here can be done for 5.5 final or in real early versions of pre-6, in some weeks from now; I'm saying this, knowing that from a technical point of view, all this will be really quite easy. That's not the case for point f) below, I know this perfectly well: Thus, I hope that point f can be done in v. 6, let's say in 6 or 8 or 10 months from now. (Remember, UR does it even now, even if they do it in an incredibly user-unfriendly way.)
a ) As we all know by now, "Insert Hyperlink" does not work but in the text pane; for me it's of no use, then.
As I've explained in length, there's the command INSERT WEB DOC; this is that mythical thing that can be triggered when being in the tree, and you can do a link to any other file or program with it, in the form
file://c:\mi\xyz.mio
Of course, the dialog form is called "Web Document", and the rest is according to that, so for aesthetical reasons, that should be changed... only for this SECOND use, for links to files and programs, whereas for its original use, it should be left as it is (see below). Thus, this "compound" command should be divided into two different commands, with two different key assignments.
b ) Then, there's the command EDIT HYPERLINK. This command works in the text, AND in the tree. You must understand that in spite of its name, "EditHyperlink" does not just EDIT hyperlinks, but also CREATES them, but does not create a new item for this, as in a), but creates a new hyperlink, from any EXISTING item in the tree, the rest being then the same. Thus, as in a), this command should be divided into two different commands, assigneable to two different key bindings, in order to trigger, for purely aesthetical reasons, those TWO different dialogs as in a), one for web documents, and one for links to files / programs.
Thus, we need two additional commands, since the commands a) and b) must have one "sibling" each for files instead of web documents. Since all the real programming has been done yet, this will be realizable in a handshake.
c ) If you have created a hyperlink, either by a) or by b), you then can again use the command in b) for any real EDITING of those hyperlinks, be it a web doc or a file. I often use this command in this respect for doing NEW hyperlinks. E.g., if I have a yet linked file xu, and want to link to a file xt, I copy and paste the link to xu, then do "EditHyperlink" in order to replace the u with the t in the link, and in order to set up an appropriate text for the text line appearing in the tree.
d ) And then there's the command OPEN HYPERLINK. There's nothing special here, it just works as a double click on any hyperlink in the tree (or even as a single click on a hyperlink in the text if you allowed for such action in the options): Be the hyperlink a web doc or a file, it shows up by this command, like you would make it show up with the mouse. I'm very thankful for this command, since it allows me to browse my main topics (a, b, c...) with the keyboard arrows, and whenever I want to trigger the loading of (or the switching to an already loaded) topic listed there (say ac in main topic a, or lu in main topic l), I don't need to shift my hand to my mouse in order to double-click with it, but I simply press a single key, and the wanted file shows. It's this perfect easy character of triggering such links that made me use them extensively in my MI files; for some 250 files now I got some 350 such hyperlinks now, and I'm getting more and more of them, I do all my cross-referencing with them.
Here's another hint: When even in ActionOutline, you can do the same (!!!), there's a big difference: There, the link, in the same form as in MI, is at the same time the text of the item in the tree; thus, if you have files like xy.mio (or there, xy.ao), you cannot have any more indication with respect to its content / subject there, since in AO, a link in the form as above and then with, let's say, "(see for xyz)" would not work.
It's all different in MI: Here, the link in itself must be as pure as in AO, but the link is hidden under the text of the item in your tree, as we all know, and by this characteristic, you are able to do your many links to a given file, anywhere in many other files, and you are NOT bound, when you copy a link, to copying also the textline appearing in the tree.
This way, I do links in the form as above, but I do the according textlines as "xy - for doing this!", "ab - see that!"
And I do my project management / GTD system by this trick of again and again referencing to the same files, but doing different indications, regarding the exact purpose of my referencing, in the tree textlines of those referenced files.
It goes without saying that being able to reference to a given item in a given file would be MUCH better, but waiting for this, my trick will do for me (if waiting time for the better solution will not go on for years).
Since filtering of tags isn't possible but WITHIN a given file, and searching for tags (= possible even over several / all files) is not really handy (and if you don't confine yourself to a handful of strictly standardized tags overall, you'll risk never find some of them again...), I think that cross-referencing between files with my system is preferable to tagging, but you'll do as you prefer for your purposes.
EDIT: For my about 250 topics so far, it's been a big task but it's worth it: For every topic, in line 1 of the tree, I do a link to the topic itself, formatted in bold. I know this link is useless in that given topic, but whenever I want to REFER to this topic, I now have the link to it ready, and I just need then to copy this first tree line of my topic, then paste it into any other topic I want it to be referenced.
And more to this, every topic is referenced to in its main topic, in "regular" formatting; thus, any ac, ad, ae, etc. will be referenced in main topic a. Furthermore, whenever I do some referencing OUTSIDE such a main topic, or even, under a second heading, within that main topic, I format it in italics; thus, every ab, ac, ad, etc. will be referenced in "regular" formatting just ONCE in topic a, but perhaps, under a special heading, in the same topic a, in italics, and whenever I do cross-referencing in ab to xy, or in oz to nx, or whatever, I always format those hyperlinks there in italics; you'll have understood that this is a reminder of my long-gone system, described above, of (just one) "natural parent" and (possibly multiple) "adoptive parents".
This "adoptive parents" referencing system is very useful when I go into the depths of THREE-character-named files, also: e.g., I have the main file c for computer, etc.; then I have several intermediate files, like ck (for keyboard, macro programs, mice, scripting programs, etc.) or cg (for graphics), and "beneath" the file ck, I've got ckc for Cherry, ckh for Hot Keyboard, cka for AutoIt, ckd for Dragon Naturally Speaking, etc.
But, in order to maintain some order in my denominations / file names even after renaming, etc., in the current absence of a synching component within MI (see above), I do NOT have any 2-chars file as my "natural parent" for a 3-chars file, but ALL files are referenced by their "natural parents", the main files, the 1-char files, under various sub-headings there, but so, it goes without saying that if I have 5 or 6 "children" cka, ckb, ckc, etc. referenced to under the relevant heading (= a link to ck.mio in itself) in their main file's tree (= in a.mio), it's important to have those cka, ckb... files again in their "intermediate / adoptive parent" ck.mio! Thus, in this ck.mio tree, all those cka, ckb... files are again referenced to, in italics here...
It goes without saying that as soon as we'll have a real reference system built WITHIN MI (= a synching component tracing any topic's deletion, renaming, shifting, cutting up into several topics), my current system will be streamlined, but for the time being, my current system is the only one I'm able to conceive, allowing for NOT creating any orphaned links, within the system we've got.
If anybody can do better than I, please tell us; if not, you'd indeed be well-advised to adopt my system, awaiting something better in the future.
(I'm experimentin with an asterix (or other special sign, but it should be searchable; an asterix is not) in all those concerned item's entries in the main topics' trees, meaning "this topic is referenced to somewhere in the depths of my system", meaning in fact that just a search for topics among "open topics" (remember, my main topics are loaded at every given time), then necessitating a search among "all topics" for these ones = for any cross-referencing between second- or third-level topics in my system... you see that in the end, a real cross-referencing management component = file / array loaded with any MI start will be unavoidable for smooth working with it; at this time and with all my tricks, any readjusting work has to be done manually and thus is strenuous and, worse, error-prone...)
EDIT 2: A real-life example; all these are hyperlinks:
In topic c:
ck - Keyboard, etc. : [this heading and the following subs (=indented) are regular:]
cka - AutoIt
ckc - Cherry
ckd - Dictating Software
ckh - Hot Keyboard
ckp - Phrase Express, etc.
ckw - WinTask
In topic ck:
ck - Keyboard, etc. : [this one = first line in tree and bold]
cka - AutoIt [this one and the following in italics]
ckc - Cherry
ckd - Dictating Software
ckh - Hot Keyboard
ckp - Phrase Express, etc.
ckw - WinTask
Remember, up to now I must maintain all this manually. (My indentation efforts here are vain, neither tabs nor leading spaces show up here, hence the multiple edits.)
EDIT 3: Oh yes, and my real-life example shows that in these second-level topics, I do NOT see to clean them up from any specific content (as I do in my main topics). Thus, whilst topic c doesn't contain but a strict minimum of content (and a max of links indeed), in topic ck there are many (= non-hyperlink, bold) headings, like "Keyboards" (with sub-items for several forms / manufacturers of them), "Macro Programs" (ditto), etc. - with the exception of those subjects, of course, for which I've created special topics, so AutoIt is absent in my list of scripting languages in my topic ck, while AutoHotKey has its own (bold) heading in ck, "AHK"; in that same topic ck, there's another heading, "Remap Scan Codes", and so on...
(I'm not a genius (Robert Carr is), but all my information management insight is based upon the principles of the German Civil Law (BGB) of 1900 if I might say...)
EDIT 4: And if ever I'd to replace AI by AHK, I'd replace the file cka (= AI) with a topic cka (= AHK), AI becoming just a heading in the ck file... and in my topic a (= Agenda), I have a (bold, not-hyperlink) heading "My Comp" beneath which (= indented, those), I store hyperlinks to all the frequently-accessed comp topics, like cim (=comp info management MI) or ckc (= my macro keypad), cka... I think you should have got my system by now...
EDIT 5: And since most users will not adopt such a minimal system, here's another hint: Try something like a.aname.mio, b.anothername.mio, or something like that; that is, do SOME grouping at least, by, e.g. one-char prefixes dot, or in any other such way facilitating management of dividing up files. When I say hoisting isn't but a real poor ersatz for any such a system, trust me. There are people out there who'd CRAVE for getting such good advice as my fellow users get here, but google and yahoo are my friends, checking for my advice (and other things) regularly, so paternity's assured.
EDIT 6: I forgot when writing edit 5, now I remember: From the views of Petko's beta announcement, we could assume that fellow users' count should be around 500 or even more, up to 800 perhaps. That's better than I had thought, but then, 790 profiteers and some 10 active (= that's meant as an euphemism, folks!) contributors? What a shame, no? Anyway, I'm very pleased we don't just count in some dozens here, allowing for Petko's financing, which is a very important point of view indeed.
e ) Then we must see that the created item for those hyperlinks (see a and b) is well adjusted to their original target, web docs; for cross-referencing MI files this very special layout isn't really adjusted, and especially, it's ugly in the sense that you'd expect some normal text page, not that big grey field with the inscription "Click to open the link", especially since clicking there would indeed open the link, but unnecessarily so, since the item's line in the tree is the link: double-click there to open the link, or even better, refer to my point d) above, much more elegant even. Thus, even from anywhere in the text field, you just have to press a single button (if you assigned that command in d) to a single button like me, that is), and you're done: nothing could be more easy and elegant than this!
And thus, again as in a) and b), those SIBLING commands mentioned there should then trigger the display of a NORMAL page / item in the case of a hyperlink to a file or program, and the current special item in the case of a web doc; if for any technical reason (I don't see at this moment yet) it's not possible to display a really normal item for such a hyperlink, ANOTHER special item should be created, but with a layout very near the layout of normal items; it would even be possible to do a CHAMOIS background for the text pane, for example.
f ) And for v. 6, all this hyperlinking in the tree should be possible to ITEMS of other topics as well, and from that point on, I really think MI will be a state-of-the-art program where just details must then be amended (supposed that cloning will be simplified and that people will be able to set up projects = loading of file clusters without recurring to macros / scripts - but it'll be simple, technically, promised: I know how to do it in a rather easy way). (Of course, there will be the problem of synching after renaming, displacing, etc., but let's discuss all this when preparing that.)
I hope some adjustements as described here can be done for 5.5 final or in real early versions of pre-6, in some weeks from now; I'm saying this, knowing that from a technical point of view, all this will be really quite easy. That's not the case for point f) below, I know this perfectly well: Thus, I hope that point f can be done in v. 6, let's say in 6 or 8 or 10 months from now. (Remember, UR does it even now, even if they do it in an incredibly user-unfriendly way.)
a ) As we all know by now, "Insert Hyperlink" does not work but in the text pane; for me it's of no use, then.
As I've explained in length, there's the command INSERT WEB DOC; this is that mythical thing that can be triggered when being in the tree, and you can do a link to any other file or program with it, in the form
file://c:\mi\xyz.mio
Of course, the dialog form is called "Web Document", and the rest is according to that, so for aesthetical reasons, that should be changed... only for this SECOND use, for links to files and programs, whereas for its original use, it should be left as it is (see below). Thus, this "compound" command should be divided into two different commands, with two different key assignments.
b ) Then, there's the command EDIT HYPERLINK. This command works in the text, AND in the tree. You must understand that in spite of its name, "EditHyperlink" does not just EDIT hyperlinks, but also CREATES them, but does not create a new item for this, as in a), but creates a new hyperlink, from any EXISTING item in the tree, the rest being then the same. Thus, as in a), this command should be divided into two different commands, assigneable to two different key bindings, in order to trigger, for purely aesthetical reasons, those TWO different dialogs as in a), one for web documents, and one for links to files / programs.
Thus, we need two additional commands, since the commands a) and b) must have one "sibling" each for files instead of web documents. Since all the real programming has been done yet, this will be realizable in a handshake.
c ) If you have created a hyperlink, either by a) or by b), you then can again use the command in b) for any real EDITING of those hyperlinks, be it a web doc or a file. I often use this command in this respect for doing NEW hyperlinks. E.g., if I have a yet linked file xu, and want to link to a file xt, I copy and paste the link to xu, then do "EditHyperlink" in order to replace the u with the t in the link, and in order to set up an appropriate text for the text line appearing in the tree.
d ) And then there's the command OPEN HYPERLINK. There's nothing special here, it just works as a double click on any hyperlink in the tree (or even as a single click on a hyperlink in the text if you allowed for such action in the options): Be the hyperlink a web doc or a file, it shows up by this command, like you would make it show up with the mouse. I'm very thankful for this command, since it allows me to browse my main topics (a, b, c...) with the keyboard arrows, and whenever I want to trigger the loading of (or the switching to an already loaded) topic listed there (say ac in main topic a, or lu in main topic l), I don't need to shift my hand to my mouse in order to double-click with it, but I simply press a single key, and the wanted file shows. It's this perfect easy character of triggering such links that made me use them extensively in my MI files; for some 250 files now I got some 350 such hyperlinks now, and I'm getting more and more of them, I do all my cross-referencing with them.
Here's another hint: When even in ActionOutline, you can do the same (!!!), there's a big difference: There, the link, in the same form as in MI, is at the same time the text of the item in the tree; thus, if you have files like xy.mio (or there, xy.ao), you cannot have any more indication with respect to its content / subject there, since in AO, a link in the form as above and then with, let's say, "(see for xyz)" would not work.
It's all different in MI: Here, the link in itself must be as pure as in AO, but the link is hidden under the text of the item in your tree, as we all know, and by this characteristic, you are able to do your many links to a given file, anywhere in many other files, and you are NOT bound, when you copy a link, to copying also the textline appearing in the tree.
This way, I do links in the form as above, but I do the according textlines as "xy - for doing this!", "ab - see that!"
And I do my project management / GTD system by this trick of again and again referencing to the same files, but doing different indications, regarding the exact purpose of my referencing, in the tree textlines of those referenced files.
It goes without saying that being able to reference to a given item in a given file would be MUCH better, but waiting for this, my trick will do for me (if waiting time for the better solution will not go on for years).
Since filtering of tags isn't possible but WITHIN a given file, and searching for tags (= possible even over several / all files) is not really handy (and if you don't confine yourself to a handful of strictly standardized tags overall, you'll risk never find some of them again...), I think that cross-referencing between files with my system is preferable to tagging, but you'll do as you prefer for your purposes.
EDIT: For my about 250 topics so far, it's been a big task but it's worth it: For every topic, in line 1 of the tree, I do a link to the topic itself, formatted in bold. I know this link is useless in that given topic, but whenever I want to REFER to this topic, I now have the link to it ready, and I just need then to copy this first tree line of my topic, then paste it into any other topic I want it to be referenced.
And more to this, every topic is referenced to in its main topic, in "regular" formatting; thus, any ac, ad, ae, etc. will be referenced in main topic a. Furthermore, whenever I do some referencing OUTSIDE such a main topic, or even, under a second heading, within that main topic, I format it in italics; thus, every ab, ac, ad, etc. will be referenced in "regular" formatting just ONCE in topic a, but perhaps, under a special heading, in the same topic a, in italics, and whenever I do cross-referencing in ab to xy, or in oz to nx, or whatever, I always format those hyperlinks there in italics; you'll have understood that this is a reminder of my long-gone system, described above, of (just one) "natural parent" and (possibly multiple) "adoptive parents".
This "adoptive parents" referencing system is very useful when I go into the depths of THREE-character-named files, also: e.g., I have the main file c for computer, etc.; then I have several intermediate files, like ck (for keyboard, macro programs, mice, scripting programs, etc.) or cg (for graphics), and "beneath" the file ck, I've got ckc for Cherry, ckh for Hot Keyboard, cka for AutoIt, ckd for Dragon Naturally Speaking, etc.
But, in order to maintain some order in my denominations / file names even after renaming, etc., in the current absence of a synching component within MI (see above), I do NOT have any 2-chars file as my "natural parent" for a 3-chars file, but ALL files are referenced by their "natural parents", the main files, the 1-char files, under various sub-headings there, but so, it goes without saying that if I have 5 or 6 "children" cka, ckb, ckc, etc. referenced to under the relevant heading (= a link to ck.mio in itself) in their main file's tree (= in a.mio), it's important to have those cka, ckb... files again in their "intermediate / adoptive parent" ck.mio! Thus, in this ck.mio tree, all those cka, ckb... files are again referenced to, in italics here...
It goes without saying that as soon as we'll have a real reference system built WITHIN MI (= a synching component tracing any topic's deletion, renaming, shifting, cutting up into several topics), my current system will be streamlined, but for the time being, my current system is the only one I'm able to conceive, allowing for NOT creating any orphaned links, within the system we've got.
If anybody can do better than I, please tell us; if not, you'd indeed be well-advised to adopt my system, awaiting something better in the future.
(I'm experimentin with an asterix (or other special sign, but it should be searchable; an asterix is not) in all those concerned item's entries in the main topics' trees, meaning "this topic is referenced to somewhere in the depths of my system", meaning in fact that just a search for topics among "open topics" (remember, my main topics are loaded at every given time), then necessitating a search among "all topics" for these ones = for any cross-referencing between second- or third-level topics in my system... you see that in the end, a real cross-referencing management component = file / array loaded with any MI start will be unavoidable for smooth working with it; at this time and with all my tricks, any readjusting work has to be done manually and thus is strenuous and, worse, error-prone...)
EDIT 2: A real-life example; all these are hyperlinks:
In topic c:
ck - Keyboard, etc. : [this heading and the following subs (=indented) are regular:]
cka - AutoIt
ckc - Cherry
ckd - Dictating Software
ckh - Hot Keyboard
ckp - Phrase Express, etc.
ckw - WinTask
In topic ck:
ck - Keyboard, etc. : [this one = first line in tree and bold]
cka - AutoIt [this one and the following in italics]
ckc - Cherry
ckd - Dictating Software
ckh - Hot Keyboard
ckp - Phrase Express, etc.
ckw - WinTask
Remember, up to now I must maintain all this manually. (My indentation efforts here are vain, neither tabs nor leading spaces show up here, hence the multiple edits.)
EDIT 3: Oh yes, and my real-life example shows that in these second-level topics, I do NOT see to clean them up from any specific content (as I do in my main topics). Thus, whilst topic c doesn't contain but a strict minimum of content (and a max of links indeed), in topic ck there are many (= non-hyperlink, bold) headings, like "Keyboards" (with sub-items for several forms / manufacturers of them), "Macro Programs" (ditto), etc. - with the exception of those subjects, of course, for which I've created special topics, so AutoIt is absent in my list of scripting languages in my topic ck, while AutoHotKey has its own (bold) heading in ck, "AHK"; in that same topic ck, there's another heading, "Remap Scan Codes", and so on...
(I'm not a genius (Robert Carr is), but all my information management insight is based upon the principles of the German Civil Law (BGB) of 1900 if I might say...)
EDIT 4: And if ever I'd to replace AI by AHK, I'd replace the file cka (= AI) with a topic cka (= AHK), AI becoming just a heading in the ck file... and in my topic a (= Agenda), I have a (bold, not-hyperlink) heading "My Comp" beneath which (= indented, those), I store hyperlinks to all the frequently-accessed comp topics, like cim (=comp info management MI) or ckc (= my macro keypad), cka... I think you should have got my system by now...
EDIT 5: And since most users will not adopt such a minimal system, here's another hint: Try something like a.aname.mio, b.anothername.mio, or something like that; that is, do SOME grouping at least, by, e.g. one-char prefixes dot, or in any other such way facilitating management of dividing up files. When I say hoisting isn't but a real poor ersatz for any such a system, trust me. There are people out there who'd CRAVE for getting such good advice as my fellow users get here, but google and yahoo are my friends, checking for my advice (and other things) regularly, so paternity's assured.
EDIT 6: I forgot when writing edit 5, now I remember: From the views of Petko's beta announcement, we could assume that fellow users' count should be around 500 or even more, up to 800 perhaps. That's better than I had thought, but then, 790 profiteers and some 10 active (= that's meant as an euphemism, folks!) contributors? What a shame, no? Anyway, I'm very pleased we don't just count in some dozens here, allowing for Petko's financing, which is a very important point of view indeed.
e ) Then we must see that the created item for those hyperlinks (see a and b) is well adjusted to their original target, web docs; for cross-referencing MI files this very special layout isn't really adjusted, and especially, it's ugly in the sense that you'd expect some normal text page, not that big grey field with the inscription "Click to open the link", especially since clicking there would indeed open the link, but unnecessarily so, since the item's line in the tree is the link: double-click there to open the link, or even better, refer to my point d) above, much more elegant even. Thus, even from anywhere in the text field, you just have to press a single button (if you assigned that command in d) to a single button like me, that is), and you're done: nothing could be more easy and elegant than this!
And thus, again as in a) and b), those SIBLING commands mentioned there should then trigger the display of a NORMAL page / item in the case of a hyperlink to a file or program, and the current special item in the case of a web doc; if for any technical reason (I don't see at this moment yet) it's not possible to display a really normal item for such a hyperlink, ANOTHER special item should be created, but with a layout very near the layout of normal items; it would even be possible to do a CHAMOIS background for the text pane, for example.
f ) And for v. 6, all this hyperlinking in the tree should be possible to ITEMS of other topics as well, and from that point on, I really think MI will be a state-of-the-art program where just details must then be amended (supposed that cloning will be simplified and that people will be able to set up projects = loading of file clusters without recurring to macros / scripts - but it'll be simple, technically, promised: I know how to do it in a rather easy way). (Of course, there will be the problem of synching after renaming, displacing, etc., but let's discuss all this when preparing that.)
Last edited by Fred on Fri Jan 07, 2011 1:07 pm, edited 8 times in total.
History
The history commands, backward and forward, have not yet been amended. As said before, they go back to too many items, for one to those items you just had touched in order to expand them (= no time frame observed, 3 seconds would be good), and the other problem, the commands go back multiple times to items you had touched and even considered for some time, but too often: When you have a list of say the last two dozen items, it should be assured that any "doubles" are eliminated from this list. Worse: I even have the impression, and often, that the "go back in the history" command jumps back and forth to ever the same items even when I had not jumped around as fervently!
Anyway, groping in the dark isn't that effective, and thus I would really be happy with a list (in a frame, being dockable at the bottom of the search results list) showing the last 20 items visited or so. Ideally, there would be heavy synching, for checking out deleted / renamed / shifted items (and I had done all this back in time), but I understand that these will probably be tasks you're more willing to do when commercial success will have given you the right motivation to do it well. For the time being, all I'd insist on would be a routine eliminating "doubles", so that for any item visited twice or more within the last two dozen visits or so, only the most recent visit would be shown.
I would heavily rely on such a list (where users would need to choose by mouse if you didn't want to implement more commands), as any professional user would, so it's really important; perhaps it could be done in a very early stage of pre-v. 6, let's say within 2 or 3 months from now?
(UR has such a function, but not in a frame / pane but by menu only (as are the topics in the Window menu in MI) - that's so awkward that it's certainly not an acceptable way to do it since nobody would want to have to flash a menu list down his screen, every some seconds: You'd like to have this list before your eyes, on a quiet screen!)
The history commands, backward and forward, have not yet been amended. As said before, they go back to too many items, for one to those items you just had touched in order to expand them (= no time frame observed, 3 seconds would be good), and the other problem, the commands go back multiple times to items you had touched and even considered for some time, but too often: When you have a list of say the last two dozen items, it should be assured that any "doubles" are eliminated from this list. Worse: I even have the impression, and often, that the "go back in the history" command jumps back and forth to ever the same items even when I had not jumped around as fervently!
Anyway, groping in the dark isn't that effective, and thus I would really be happy with a list (in a frame, being dockable at the bottom of the search results list) showing the last 20 items visited or so. Ideally, there would be heavy synching, for checking out deleted / renamed / shifted items (and I had done all this back in time), but I understand that these will probably be tasks you're more willing to do when commercial success will have given you the right motivation to do it well. For the time being, all I'd insist on would be a routine eliminating "doubles", so that for any item visited twice or more within the last two dozen visits or so, only the most recent visit would be shown.
I would heavily rely on such a list (where users would need to choose by mouse if you didn't want to implement more commands), as any professional user would, so it's really important; perhaps it could be done in a very early stage of pre-v. 6, let's say within 2 or 3 months from now?
(UR has such a function, but not in a frame / pane but by menu only (as are the topics in the Window menu in MI) - that's so awkward that it's certainly not an acceptable way to do it since nobody would want to have to flash a menu list down his screen, every some seconds: You'd like to have this list before your eyes, on a quiet screen!)
Last edited by Fred on Fri Jan 07, 2011 10:28 am, edited 2 times in total.
Topics
As we all know by now, I use very short topic titles, but we also know that most users won't ever adopt such a system. Thus, they have terrible problems with their tabs since no screen is large enough to hold dozens of topic titles in one row, and so they will necessarily rely upon MI's Window menu where there's the list of loaded files, but my observations with respect to History by menu apply.
We need some "project management" functionality soon, where people would automatically load a bunch of topics belonging together, as I do at this moment by macro, and it's necessary to facilitate the USE of such a function in order for people needing those functions being tempted by really using them in MI; it's no good to just offer something not really good here since would-be power users would then say, well, it's there, but not in a way I like it, it's not really practical, so I look elsewhere...
Thus, people should not be forced to flash down a long list from a menu every time (= every 20 seconds, sometimes) they need to go to another topic within their current project, but they should be able to freely jump forth and back between many topics at their very ease; thus they need a list, in a frame, dockable to other frames on the right side of their screen, at bottom, on top, or even, when their project contains dozens of topics, as a long list WITHIN the search results frame, replacing that list by toggle.
As we all understand, I do NOT need such a frame as desperately since I'm able to show 40 or more different topics, as tabs, even on a 15,4" screen, but people giving their topics "normal" names are not in that enviable waiting position for better times; they need something better as soon as possible.
Thus, as we want MI to become really successful with professional users, such a frame should be included in v. 6, let's say, in 6, 8 or 10 months from now, and together with a better way to CONSTITUTE such projects / various topics lists; it'll be really important, and the current Window menu list couldn't be but a substitute for the waiting time. As said above, THINKING is contemplating lists, not triggering falling-down lists from menus obstructing your text (so that you instinctively want to get rid of them as soon as possible, by this making impossible any contemplation).
As we all know by now, I use very short topic titles, but we also know that most users won't ever adopt such a system. Thus, they have terrible problems with their tabs since no screen is large enough to hold dozens of topic titles in one row, and so they will necessarily rely upon MI's Window menu where there's the list of loaded files, but my observations with respect to History by menu apply.
We need some "project management" functionality soon, where people would automatically load a bunch of topics belonging together, as I do at this moment by macro, and it's necessary to facilitate the USE of such a function in order for people needing those functions being tempted by really using them in MI; it's no good to just offer something not really good here since would-be power users would then say, well, it's there, but not in a way I like it, it's not really practical, so I look elsewhere...
Thus, people should not be forced to flash down a long list from a menu every time (= every 20 seconds, sometimes) they need to go to another topic within their current project, but they should be able to freely jump forth and back between many topics at their very ease; thus they need a list, in a frame, dockable to other frames on the right side of their screen, at bottom, on top, or even, when their project contains dozens of topics, as a long list WITHIN the search results frame, replacing that list by toggle.
As we all understand, I do NOT need such a frame as desperately since I'm able to show 40 or more different topics, as tabs, even on a 15,4" screen, but people giving their topics "normal" names are not in that enviable waiting position for better times; they need something better as soon as possible.
Thus, as we want MI to become really successful with professional users, such a frame should be included in v. 6, let's say, in 6, 8 or 10 months from now, and together with a better way to CONSTITUTE such projects / various topics lists; it'll be really important, and the current Window menu list couldn't be but a substitute for the waiting time. As said above, THINKING is contemplating lists, not triggering falling-down lists from menus obstructing your text (so that you instinctively want to get rid of them as soon as possible, by this making impossible any contemplation).
Menus
I happened to see this months before, in 5.0, then I did not find it again, and all seemed to be right, and now I know why. Now in 5.51 it's definitely there again, and this time I caught why I hadn't been able to identify the problem:
We have 10 menus - but only when the text field has focus; if the tree has focus, there ain't but 9 menus, the tenth one being the problem: The favorites menu is accessible by Alt-a, and the table menu also is accessible by Alt-a...
In fact, here are the menu alt-combinations in alphabetical order:
a(2 times), e, f, h, i, o, t, v, w
Thus, the table menu should be made accessible by Alt-b.
EDIT: And please tell us here whenever there are new beta versions to download (since there is no notification by email for this); no need for me to work with / rant on "old" versions!
EDIT 2: I'll do real marketing efforts for MI as soon as it appears to be acceptable to me, and I seem to have clarified a little bit, in this thread thus far, from which point on this might be the case; in other words, I'll NOT be demanding the "impossible" from MI before declaring it being "good enough quality" for me: promised.
I happened to see this months before, in 5.0, then I did not find it again, and all seemed to be right, and now I know why. Now in 5.51 it's definitely there again, and this time I caught why I hadn't been able to identify the problem:
We have 10 menus - but only when the text field has focus; if the tree has focus, there ain't but 9 menus, the tenth one being the problem: The favorites menu is accessible by Alt-a, and the table menu also is accessible by Alt-a...
In fact, here are the menu alt-combinations in alphabetical order:
a(2 times), e, f, h, i, o, t, v, w
Thus, the table menu should be made accessible by Alt-b.
EDIT: And please tell us here whenever there are new beta versions to download (since there is no notification by email for this); no need for me to work with / rant on "old" versions!
EDIT 2: I'll do real marketing efforts for MI as soon as it appears to be acceptable to me, and I seem to have clarified a little bit, in this thread thus far, from which point on this might be the case; in other words, I'll NOT be demanding the "impossible" from MI before declaring it being "good enough quality" for me: promised.
Insert Date and Time
There has been no change from 5.0 to 5.51 yet. In fact, InsertDate is easy, it inserts the date in a totally acceptable format; InsertTime is easy as well, it inserts the time without the seconds, in the format 10:53, which is perfectly fine; but InsertDateAndTime is the same mess it was in the past:
Instead of really inserting something, a given standard format you've chosen before, it opens a dialog each time, for "chosing", when in fact you'd want to insert it a real thing, like the two other commands, without questioning you what / in what format you want to insert.
Worse, the wanted format is not even in that list, and seems not being able to be preset if I'm not erroneous: My "default" format = first in the list = available by just pressing "Enter", is
07.01.2011 10:55:31
when in fact I would like to have it without the seconds (as in the command "insert time", but there seems to be no way to preset such a format in accordance with the two other formats, up to now the seconds seem to be mandatory in this format; in fact, it's the ONLY format MI presents for chosing from when the command "insert date and time" is indeed to insert date AND time, as the name of the command would indicate: that's really weird!
Thus, the command "Insert Date and Time" is something of a hybrid, thus far: instead of inserting date and time in the format the user wants, it just is a thing of presetting a bunch of different formats, time, date, and just one format for both of them.
This command must hence be divided up into TWO different formats (both accessible by key bindings): one for presetting formats, and one for inserting date AND time, without displaying any dialog, and in the format you'd chosen in the other, the presetting command.
This is indeed one of those "strict minimum" issues in MI that should have been addressed years ago, but our happy-earning university professors might have been other, better-paid, things to do than helping in debugging MI. No pun intended, just another reminder that I'm doing good work here, even if some people deny that.
There has been no change from 5.0 to 5.51 yet. In fact, InsertDate is easy, it inserts the date in a totally acceptable format; InsertTime is easy as well, it inserts the time without the seconds, in the format 10:53, which is perfectly fine; but InsertDateAndTime is the same mess it was in the past:
Instead of really inserting something, a given standard format you've chosen before, it opens a dialog each time, for "chosing", when in fact you'd want to insert it a real thing, like the two other commands, without questioning you what / in what format you want to insert.
Worse, the wanted format is not even in that list, and seems not being able to be preset if I'm not erroneous: My "default" format = first in the list = available by just pressing "Enter", is
07.01.2011 10:55:31
when in fact I would like to have it without the seconds (as in the command "insert time", but there seems to be no way to preset such a format in accordance with the two other formats, up to now the seconds seem to be mandatory in this format; in fact, it's the ONLY format MI presents for chosing from when the command "insert date and time" is indeed to insert date AND time, as the name of the command would indicate: that's really weird!
Thus, the command "Insert Date and Time" is something of a hybrid, thus far: instead of inserting date and time in the format the user wants, it just is a thing of presetting a bunch of different formats, time, date, and just one format for both of them.
This command must hence be divided up into TWO different formats (both accessible by key bindings): one for presetting formats, and one for inserting date AND time, without displaying any dialog, and in the format you'd chosen in the other, the presetting command.
This is indeed one of those "strict minimum" issues in MI that should have been addressed years ago, but our happy-earning university professors might have been other, better-paid, things to do than helping in debugging MI. No pun intended, just another reminder that I'm doing good work here, even if some people deny that.
Expanding / Folding Bug
Focus is in Tree. With mouse, I collapse an item. Works fine.
Focus is in Text Pane. With mouse, I try to collapse an item in the tree. Get an error message (not asking for net transmission this time): "Error reading text data!".
Tried anew, same error message. Thus, set focus to tree first, then click on the symbol for collapsing, and no problem.
As said before, some attention should be drawn to making commands working correctly from anywhere in MI, not just from within the given object they are to work in. (As said before, with arrow commands and some other "intelligent" commands, it should be the other way round, they should work THE SAME WAY, depending on the focus pane, like prev/next in tree, up/down in text, prev/next in search results, and some other: This is intelligently fetching the info: Where is the focus, and then, depending on this, doing the SAME / a similar behavior, with certain adjustments.
But when such "parallels" are not in question, but a quite normal command is expected to work always in the same way, whatever the target object might be, it should NOT be necessary to select the target object first, in order for the command correctly, the crashing of MI whenever trying to do a save / general save but when the focus was in the search line, being a spectacular illustration of why this "works only from target object's focus" is undesirable.
BTW, yesterday, UR / UR Prof. was on sale (19 dollars, Prof. 39 dollars; I doubly knew in time, from mail by them and from outlinersoftware). Hope MI's coming enhancements will prove I was right NOT to buy. Next sale for UR will probably be in January 2012, since up to now they always did one yearly sale at that time... but that's not a reason to make us wait for substantial enhancements up to December, 2011.
Focus is in Tree. With mouse, I collapse an item. Works fine.
Focus is in Text Pane. With mouse, I try to collapse an item in the tree. Get an error message (not asking for net transmission this time): "Error reading text data!".
Tried anew, same error message. Thus, set focus to tree first, then click on the symbol for collapsing, and no problem.
As said before, some attention should be drawn to making commands working correctly from anywhere in MI, not just from within the given object they are to work in. (As said before, with arrow commands and some other "intelligent" commands, it should be the other way round, they should work THE SAME WAY, depending on the focus pane, like prev/next in tree, up/down in text, prev/next in search results, and some other: This is intelligently fetching the info: Where is the focus, and then, depending on this, doing the SAME / a similar behavior, with certain adjustments.
But when such "parallels" are not in question, but a quite normal command is expected to work always in the same way, whatever the target object might be, it should NOT be necessary to select the target object first, in order for the command correctly, the crashing of MI whenever trying to do a save / general save but when the focus was in the search line, being a spectacular illustration of why this "works only from target object's focus" is undesirable.
BTW, yesterday, UR / UR Prof. was on sale (19 dollars, Prof. 39 dollars; I doubly knew in time, from mail by them and from outlinersoftware). Hope MI's coming enhancements will prove I was right NOT to buy. Next sale for UR will probably be in January 2012, since up to now they always did one yearly sale at that time... but that's not a reason to make us wait for substantial enhancements up to December, 2011.
Is a better / neater / more adjustable browser import function possible?
Since I detailed my information input workflow earlier in these thread / forum, I'd like to add that now I've implemented another macro working in my browser, so that there are TWO macros there, for this reason:
- one key adds any new item to my general input box in MI, OR (now) to the last chosen input box in MI, e.g. h, n or g
- another key lets me choose the input box, by ONE other key pressing,e.g. h, n or g; at the same time, it sets the default to that given input box
- you could of course set up THREE such commands:
- one key inserts into the general inbox
- another key inserts into the chosen inbox (chosen by this one:)
- a third key inserts into any one-key inbox (and sets your above-mentioned choice to it)
In any case, the selected text in the browser window is put as plain text into a new MI item (and the macro asks for its name), then the address of the web page is put above that text (and an empty line).
I have other macros for my browser in order to add selected text to the last created / last selected such item (allowing for selective selection in my browser, since I can thus easily add more snippets to the current item), and for importing pictures / screen images (made by FastStone Capture 5.3 = the last free version, to be found in the web even today by about 5-8 minutes' searching; I would not have given this hint had FastStone answered my kind request to amend their viewer (just by streamlining its perverse graphic appearance, you mind); from a company where the a**ho** facture is 100 p.c., buying is not recommended though) in case information cannot be easily copied.
All those import commands are triggered by mouse clicks (since I use the mouse for selecting in the browser): e.g., mouse key xyz triggers Shift-Alt-z (= designated in the mouse software), and then, the command Shift-Alt-z triggers this command in this application, that command in that other applic, etc.
For the reasons given in this forum by me, MI's browser importing function is not useful for me, since, in order to avoid any information clutter, I insist on having the importing process as a first information filtering step in my workflow, instead of just collecting 100,000 or so web pages - but indeed, the going forth and back (Selecting in the browser, mouse command triggers display of MI and naming dialog for the new item, then Return triggers creation of that item and pasting of the copied text, then the screen goes back to my browser, where the macro copies the address line; then the screen goes back to MI to insert the address, and again screen back to the browser for further reading / copying...) isn't handy at all.
I'm considering an additional clipboard manager in order to make my macro copy BOTH the selected text and the address in ONE step, not going forth and back two times to MI for doing the necessary pastings, especially since all this va-et-vient takes a lot of time, the macro mandatorily allowing for the necessary copying time even for rather substantial pieces of text taking some seconds to be successfully stored into the clipboard.
Or then, MI could implement an additional feature like the current "import from browser" feature, indeed importing content and address in one row, but according to the above-mentioned buylines - NOBODY needs a whole web page, and those who do - notaries as evidence for legal affairs -, need quite other softwares in order to make their web site copies testifyable before the court (BTW that's why I consider programs as Surfulater rather useless: their strengths reside in issues we simply don't need, whereas their weaknesses abound).
In the meanwhile, let me say, that with the new, flawless commands "Toggle Tree-Text" and "Go Text Pane", my macros take time but work finally flawlessly, which is a great step ahead indeed.
Other MI users' tricks to import web pages' contents must be 1,000 times better than mine, since they jealously guard them for themselves. Chapeau !
EDIT:
So my web import macro (1 = new item) was:
- copy (= selected text in browser)
- go to MI
- ask for new item's name (and Enter)
- create new item
- paste selectedtext as plain text into text field
- go back to browser
- copy address line
- go back to MI
- paste address line and a blank line in text field, above previously pasted text
- go to end of text, in order for MI to be macro 2- (= possible further snippets) -ready
- go back to browser, for further reading and possible pasting
As said before, this had to come to an end, for the double reason of all this jumping before my eyes, and for my waiting time before and after every Alt-Tab. So I searched the web for 5 hours in order to find a (free or commercial, but preferably light-weight) clipboard enhancer that could easily be integrated into macros; this criterion excluded about 85 or 90 p.c. of available clipboard enhancers, since making fiddle a macro-driven mouse in convoluted "menus" showing snippets was indeed not what I'd had preferred.
And indeed, there are some macro-friendly clipboard enhancers, and thus, my macro now is this:
- copy selected text in browser (automatically in clipboard 1)
- activate clipboard 2 (= in a tenth of a second, without any screen clutter)
- copy address line in browser (= into clipboard 2)
- go to MI
- ask for the new item's title (and Enter)
- create the new item (as sibling or as child of the current item there, depending on my macro-triggering command)
- paste the address line into text field (= automatically from clipboard 2), and insert a blank line after it
- activate clipboard 1 (= no problems, as above)
- paste selected text from browser after the above-mentioned blank line, and go to end of text (see above)
- go back to browser (where for containing further snippets, clipboard 1 stays already activated)
So, by just reading the text without taking care of understanding, casual readers could indeed think that I've just replaced a macro with another, so what? But just imagine, from the steps described, the difference in screen activity and execution time, between my ancient macro and my new one: It's another world, opened up by having 2 clipboards instead of 1...
Of course, the programming "problem" when implementing such a macro into MI is, you FIRST select your text / text snippet (= from 1 to dozens of millions characters...), and THEN only, the address line can be stored by MI, since, if MI does it make the other way round, you would have to trigger the macro first, and then only you'd be allowed to select your text (be it after a control-a or just some words): another big interference with your work-flow. Thus, MI could not just store the address in the clipboard first, then store it, from there, to a variable, then empty the clipboard for your storing the selected text there, but it would need to catch the address line without relying upon the Windows clipboard for this, preserving its content for pouring it, some steps later only, into the (not yet existing text field) - of course, the selected text could indeed be stored in a variable... but a variable containing dozens of millions of characters? And then, many users wouldn't have their clippings / web texts stored as plain text only, so formatting should be preserved, by option...
As for the clipboard enhancer, it's the old problem of the web, and it's like FastStone Capture: With that, I can capture a rectangle within a fraction of a second, for free, but in most of those recommendations, you get again and again some convoluted, big, overpriced softwares... that take, on the same computer, for the same rectangle to be captured, not just some fractions of a second more... but up to 5 or 8 seconds, 50 times the time of the freeware thus: It's scandalous. And that's why for every such a comparative review, and stay it at the utmost surface, expect 5 hours minimum... or have something really not suited. I remember that in the Eighties / early Nineties, real in-depth comparative software / utilities reviews appeared regularly in the "trade" publications (= for the masses) - today, even in the real trade publications, you rarely see one of those: It's the old problem of the press being a whore... of politicians, of well-connected industrialists, of would-be costumers even if their product is sh**...
But then, I adore saying that if Steve tomorrow sold Jobs-certified liquified dog sh** in bottles for 99 dollars apiece, he'd be out of stock in a day; people would happily pay for ingurgitating it!
Since I detailed my information input workflow earlier in these thread / forum, I'd like to add that now I've implemented another macro working in my browser, so that there are TWO macros there, for this reason:
- one key adds any new item to my general input box in MI, OR (now) to the last chosen input box in MI, e.g. h, n or g
- another key lets me choose the input box, by ONE other key pressing,e.g. h, n or g; at the same time, it sets the default to that given input box
- you could of course set up THREE such commands:
- one key inserts into the general inbox
- another key inserts into the chosen inbox (chosen by this one:)
- a third key inserts into any one-key inbox (and sets your above-mentioned choice to it)
In any case, the selected text in the browser window is put as plain text into a new MI item (and the macro asks for its name), then the address of the web page is put above that text (and an empty line).
I have other macros for my browser in order to add selected text to the last created / last selected such item (allowing for selective selection in my browser, since I can thus easily add more snippets to the current item), and for importing pictures / screen images (made by FastStone Capture 5.3 = the last free version, to be found in the web even today by about 5-8 minutes' searching; I would not have given this hint had FastStone answered my kind request to amend their viewer (just by streamlining its perverse graphic appearance, you mind); from a company where the a**ho** facture is 100 p.c., buying is not recommended though) in case information cannot be easily copied.
All those import commands are triggered by mouse clicks (since I use the mouse for selecting in the browser): e.g., mouse key xyz triggers Shift-Alt-z (= designated in the mouse software), and then, the command Shift-Alt-z triggers this command in this application, that command in that other applic, etc.
For the reasons given in this forum by me, MI's browser importing function is not useful for me, since, in order to avoid any information clutter, I insist on having the importing process as a first information filtering step in my workflow, instead of just collecting 100,000 or so web pages - but indeed, the going forth and back (Selecting in the browser, mouse command triggers display of MI and naming dialog for the new item, then Return triggers creation of that item and pasting of the copied text, then the screen goes back to my browser, where the macro copies the address line; then the screen goes back to MI to insert the address, and again screen back to the browser for further reading / copying...) isn't handy at all.
I'm considering an additional clipboard manager in order to make my macro copy BOTH the selected text and the address in ONE step, not going forth and back two times to MI for doing the necessary pastings, especially since all this va-et-vient takes a lot of time, the macro mandatorily allowing for the necessary copying time even for rather substantial pieces of text taking some seconds to be successfully stored into the clipboard.
Or then, MI could implement an additional feature like the current "import from browser" feature, indeed importing content and address in one row, but according to the above-mentioned buylines - NOBODY needs a whole web page, and those who do - notaries as evidence for legal affairs -, need quite other softwares in order to make their web site copies testifyable before the court (BTW that's why I consider programs as Surfulater rather useless: their strengths reside in issues we simply don't need, whereas their weaknesses abound).
In the meanwhile, let me say, that with the new, flawless commands "Toggle Tree-Text" and "Go Text Pane", my macros take time but work finally flawlessly, which is a great step ahead indeed.
Other MI users' tricks to import web pages' contents must be 1,000 times better than mine, since they jealously guard them for themselves. Chapeau !
EDIT:
So my web import macro (1 = new item) was:
- copy (= selected text in browser)
- go to MI
- ask for new item's name (and Enter)
- create new item
- paste selectedtext as plain text into text field
- go back to browser
- copy address line
- go back to MI
- paste address line and a blank line in text field, above previously pasted text
- go to end of text, in order for MI to be macro 2- (= possible further snippets) -ready
- go back to browser, for further reading and possible pasting
As said before, this had to come to an end, for the double reason of all this jumping before my eyes, and for my waiting time before and after every Alt-Tab. So I searched the web for 5 hours in order to find a (free or commercial, but preferably light-weight) clipboard enhancer that could easily be integrated into macros; this criterion excluded about 85 or 90 p.c. of available clipboard enhancers, since making fiddle a macro-driven mouse in convoluted "menus" showing snippets was indeed not what I'd had preferred.
And indeed, there are some macro-friendly clipboard enhancers, and thus, my macro now is this:
- copy selected text in browser (automatically in clipboard 1)
- activate clipboard 2 (= in a tenth of a second, without any screen clutter)
- copy address line in browser (= into clipboard 2)
- go to MI
- ask for the new item's title (and Enter)
- create the new item (as sibling or as child of the current item there, depending on my macro-triggering command)
- paste the address line into text field (= automatically from clipboard 2), and insert a blank line after it
- activate clipboard 1 (= no problems, as above)
- paste selected text from browser after the above-mentioned blank line, and go to end of text (see above)
- go back to browser (where for containing further snippets, clipboard 1 stays already activated)
So, by just reading the text without taking care of understanding, casual readers could indeed think that I've just replaced a macro with another, so what? But just imagine, from the steps described, the difference in screen activity and execution time, between my ancient macro and my new one: It's another world, opened up by having 2 clipboards instead of 1...
Of course, the programming "problem" when implementing such a macro into MI is, you FIRST select your text / text snippet (= from 1 to dozens of millions characters...), and THEN only, the address line can be stored by MI, since, if MI does it make the other way round, you would have to trigger the macro first, and then only you'd be allowed to select your text (be it after a control-a or just some words): another big interference with your work-flow. Thus, MI could not just store the address in the clipboard first, then store it, from there, to a variable, then empty the clipboard for your storing the selected text there, but it would need to catch the address line without relying upon the Windows clipboard for this, preserving its content for pouring it, some steps later only, into the (not yet existing text field) - of course, the selected text could indeed be stored in a variable... but a variable containing dozens of millions of characters? And then, many users wouldn't have their clippings / web texts stored as plain text only, so formatting should be preserved, by option...
As for the clipboard enhancer, it's the old problem of the web, and it's like FastStone Capture: With that, I can capture a rectangle within a fraction of a second, for free, but in most of those recommendations, you get again and again some convoluted, big, overpriced softwares... that take, on the same computer, for the same rectangle to be captured, not just some fractions of a second more... but up to 5 or 8 seconds, 50 times the time of the freeware thus: It's scandalous. And that's why for every such a comparative review, and stay it at the utmost surface, expect 5 hours minimum... or have something really not suited. I remember that in the Eighties / early Nineties, real in-depth comparative software / utilities reviews appeared regularly in the "trade" publications (= for the masses) - today, even in the real trade publications, you rarely see one of those: It's the old problem of the press being a whore... of politicians, of well-connected industrialists, of would-be costumers even if their product is sh**...
But then, I adore saying that if Steve tomorrow sold Jobs-certified liquified dog sh** in bottles for 99 dollars apiece, he'd be out of stock in a day; people would happily pay for ingurgitating it!
Last edited by Fred on Thu Jan 13, 2011 11:39 pm, edited 1 time in total.
Newest Bug: No Jumping to Items in Tree Anymore
I don't know how it's called - as UR people so appropriately say, English does not seem to be my native language. But however it might be called, we discussed earlier MI's a little bit weird (if real intelligent) way to jump to items in the tree by just pressing a character key (if tree has focus), and I said, please offer us the NORMAL way also, by option, if really you stick to your intelligent but weird way of doing this up to now.
I understand that you cling to good ideas, but your way of offering this function is NOT prone to make happy 2/3 of users I would presume, since in all other programs it's not implemented this way, and it's a function that most users rely heavily on. The problem with your way of doing things there is illustrated in this example:
User does not know, in a long tree, the exact title of the item he wants to jump to (begins with c but he doesn't know it); he remembers the title of an intermediate item, though (= intermediate heading, e.g.; begins with b, and he knows it).
Thus, he would, in the tree, press key b, in order to first go to the intermediate heading. From that position, he'll see the target item and now knows it begins with c. In every other program he now would press c (perhaps several times, if there are other items beginning with c in-between). Not in MI: Here he must use the mouse (!) in order to click it, or many arrow key pressings, since the pressing of c would mandatorily try to jump to an item beginning not with c, but by bc, and even if there isn't any, MI will not understand that the user just is wanting to go to a c, not to an inexistent bc debuting item.
So I would really like to behave MI the normal way, by option, and if the bug I hinted to is due to work on implementing the second, normal way of doing this, very well indeed!
But for the time being, there is no such jumping to tree items anymore, be it your way, be it the way most users would prefer...
Again: Please let us be informed of any new intermediate beta release; I'm currently using the one that is FALSELY identified in the Help-About menu field as 5.50 but that you announced as 5.51 end of December or early January, I don't remember. Hence, it would be a good idea to update the intermediate number in that help-about field so that everybody knows anytime which is the version he's currently working with.
I don't know how it's called - as UR people so appropriately say, English does not seem to be my native language. But however it might be called, we discussed earlier MI's a little bit weird (if real intelligent) way to jump to items in the tree by just pressing a character key (if tree has focus), and I said, please offer us the NORMAL way also, by option, if really you stick to your intelligent but weird way of doing this up to now.
I understand that you cling to good ideas, but your way of offering this function is NOT prone to make happy 2/3 of users I would presume, since in all other programs it's not implemented this way, and it's a function that most users rely heavily on. The problem with your way of doing things there is illustrated in this example:
User does not know, in a long tree, the exact title of the item he wants to jump to (begins with c but he doesn't know it); he remembers the title of an intermediate item, though (= intermediate heading, e.g.; begins with b, and he knows it).
Thus, he would, in the tree, press key b, in order to first go to the intermediate heading. From that position, he'll see the target item and now knows it begins with c. In every other program he now would press c (perhaps several times, if there are other items beginning with c in-between). Not in MI: Here he must use the mouse (!) in order to click it, or many arrow key pressings, since the pressing of c would mandatorily try to jump to an item beginning not with c, but by bc, and even if there isn't any, MI will not understand that the user just is wanting to go to a c, not to an inexistent bc debuting item.
So I would really like to behave MI the normal way, by option, and if the bug I hinted to is due to work on implementing the second, normal way of doing this, very well indeed!
But for the time being, there is no such jumping to tree items anymore, be it your way, be it the way most users would prefer...
Again: Please let us be informed of any new intermediate beta release; I'm currently using the one that is FALSELY identified in the Help-About menu field as 5.50 but that you announced as 5.51 end of December or early January, I don't remember. Hence, it would be a good idea to update the intermediate number in that help-about field so that everybody knows anytime which is the version he's currently working with.
And TOGGLES for Item / Tab History, Please
Sometimes I'm not precise enough, even if always trying. So again, very short, it would be nice to have the item history (not also topic history) as a pane, since if not, you get lost, staggering in the dark. But much more importantly, and for BOTH the tab and the topic history, we need a TOGGLE, additionally, not only forward and backward each.
There might be SOME users that use only the forward and backward command notwithstanding possible choice, but they should be rare. Most users would indeed SOMETIMES (= perhaps in 20 p.c. of cases) use the corresponding history, and everytime they must reach out for some item / topic (=tab) that is two or more items away in the history.
But in about 80 p.c. of cases, you just TOGGLE between TWO items / topics, i.e. even when you use the history here and there - and you do, but then, for the items at least, a history PANE would be so much more handy! -, between these "real" history uses, you jump back and forth, back and forth, again and again, between just TWO of those items / topics: the LAST TWO entries, in fact, of / in the corresponding history.
Why then, for toggling between two items / topics, a toggle appears to be so much important (for 90 p.c. or more of users)? Because, if you have to use the history commands instead, for every jump, your mind must first decide "where am I: in a or in b?", and then your mind must do the transition "backward (or forward), and what's now the corresponding key (combination) I'm supposed to press for this?": This INTERFERES greatly with your / everyman's workflow in almost any such situation; just DOING a toggle when you just WANT to toggle, without having to think about the right key to press, is the most smooth way of doing it indeed (I often press the false key, and then I have the "pleasure" to press the right key two times afterwards, in order to get to the right item/tab: That makes 3 keys and several seconds' fuddle, hence 20 seconds interruption of my thinking, instead of ONE key, half a second, and NO interruption of my mental working.
From a technical point of view, it's very easy since, if programmed correctly, it's just activating the LAST item in the corresponding history array (and then adding the current item as last one, the activated item becoming the item last minus one in the array, the rest of the array being left unchanged; thus, the toggle is just a very minor programming add-on to the history function which is already there; let's say I could add it in 30 minutes, so a professional programmer could do it in ten.
Thus, please be nice - since we have a common objective, I hope: facilitating editing work to MI customers (and possible customers = "prospects") - and give as those two additional commands, TOGGLES for "go to last viewed item/topic(tab)".
EDIT (ATTENTION EDIT 2!): As said long before (= regarding 5.07), the items history was and is unreliable; when I go backward and forward, I'm sometimes put onto items that I had visited long ago, whereas those I expect to be in the list (= and I expect thus to attain, thus searching for them in the dark) seem to be lost from the list.
Now that I use the topics history, backward and forward, it's the same phenomenon I encounter: Those commands sometimes bring me to topics I had visited a long time ago, but NOT to those, recently visited, I intend to go. This unreliable and unpredictable behavior of the four existing commands is so awkward, it makes them almost unusable, which is all the more unhandy since up to now, there ain't toggles (for toggling between the current and the last visited ones) yet; thus, in 5.51, I have to use the mouse to click on tabs and items as before, and I cannot say to which point I'm fed up with that. If you did a displayable list for each item history and tab history, we then could all see this chaos for ourselves, and better describe it, or at least click with the mouse in a tiny list to get to visited items / tabs, in order to have to click permanently all over the screen. Please note that these history issues are of the utmost importance since they interfere with our workflow as nothing else does at this moment.
Besides, ALL bugs described by me are real, I would never invent a bug just for making you search for it. Thus, if you don't encounter the bugs I describe, be assured they are very well there, but they don't appear every time, and if they ain't addressed, they'll make it into 5.5 Final. E.g., the bug in the cut-and-paste function for several items, some of which have sub-items, most of the time, it's not there, but then again, it appears again, and I don't know why, perhaps when items with sub-items are in a certain order, or are at certain positions, or whatever. If I was the programmer, I'd debug it; being a customer, I'm not going to spend hours on such unpredictable bugs... but the programmer should; in fact, it was him who introduced them in the first place.
EDIT 2: Sorry, my fault. The additional Cherry macro program fell back to ancient key bindings, between closing down the comp and turning it on again, without letting me know (= in its caption it does not indicate the current key bindings set = the name of the set), and even if MI's history functions ain't what they should be, they ain't what I thought they were. Thus, I'll have to try them out anew, but the chaos I spoke of, was indeed caused by pressing the wrong keys. Sorry again.
Sometimes I'm not precise enough, even if always trying. So again, very short, it would be nice to have the item history (not also topic history) as a pane, since if not, you get lost, staggering in the dark. But much more importantly, and for BOTH the tab and the topic history, we need a TOGGLE, additionally, not only forward and backward each.
There might be SOME users that use only the forward and backward command notwithstanding possible choice, but they should be rare. Most users would indeed SOMETIMES (= perhaps in 20 p.c. of cases) use the corresponding history, and everytime they must reach out for some item / topic (=tab) that is two or more items away in the history.
But in about 80 p.c. of cases, you just TOGGLE between TWO items / topics, i.e. even when you use the history here and there - and you do, but then, for the items at least, a history PANE would be so much more handy! -, between these "real" history uses, you jump back and forth, back and forth, again and again, between just TWO of those items / topics: the LAST TWO entries, in fact, of / in the corresponding history.
Why then, for toggling between two items / topics, a toggle appears to be so much important (for 90 p.c. or more of users)? Because, if you have to use the history commands instead, for every jump, your mind must first decide "where am I: in a or in b?", and then your mind must do the transition "backward (or forward), and what's now the corresponding key (combination) I'm supposed to press for this?": This INTERFERES greatly with your / everyman's workflow in almost any such situation; just DOING a toggle when you just WANT to toggle, without having to think about the right key to press, is the most smooth way of doing it indeed (I often press the false key, and then I have the "pleasure" to press the right key two times afterwards, in order to get to the right item/tab: That makes 3 keys and several seconds' fuddle, hence 20 seconds interruption of my thinking, instead of ONE key, half a second, and NO interruption of my mental working.
From a technical point of view, it's very easy since, if programmed correctly, it's just activating the LAST item in the corresponding history array (and then adding the current item as last one, the activated item becoming the item last minus one in the array, the rest of the array being left unchanged; thus, the toggle is just a very minor programming add-on to the history function which is already there; let's say I could add it in 30 minutes, so a professional programmer could do it in ten.
Thus, please be nice - since we have a common objective, I hope: facilitating editing work to MI customers (and possible customers = "prospects") - and give as those two additional commands, TOGGLES for "go to last viewed item/topic(tab)".
EDIT (ATTENTION EDIT 2!): As said long before (= regarding 5.07), the items history was and is unreliable; when I go backward and forward, I'm sometimes put onto items that I had visited long ago, whereas those I expect to be in the list (= and I expect thus to attain, thus searching for them in the dark) seem to be lost from the list.
Now that I use the topics history, backward and forward, it's the same phenomenon I encounter: Those commands sometimes bring me to topics I had visited a long time ago, but NOT to those, recently visited, I intend to go. This unreliable and unpredictable behavior of the four existing commands is so awkward, it makes them almost unusable, which is all the more unhandy since up to now, there ain't toggles (for toggling between the current and the last visited ones) yet; thus, in 5.51, I have to use the mouse to click on tabs and items as before, and I cannot say to which point I'm fed up with that. If you did a displayable list for each item history and tab history, we then could all see this chaos for ourselves, and better describe it, or at least click with the mouse in a tiny list to get to visited items / tabs, in order to have to click permanently all over the screen. Please note that these history issues are of the utmost importance since they interfere with our workflow as nothing else does at this moment.
Besides, ALL bugs described by me are real, I would never invent a bug just for making you search for it. Thus, if you don't encounter the bugs I describe, be assured they are very well there, but they don't appear every time, and if they ain't addressed, they'll make it into 5.5 Final. E.g., the bug in the cut-and-paste function for several items, some of which have sub-items, most of the time, it's not there, but then again, it appears again, and I don't know why, perhaps when items with sub-items are in a certain order, or are at certain positions, or whatever. If I was the programmer, I'd debug it; being a customer, I'm not going to spend hours on such unpredictable bugs... but the programmer should; in fact, it was him who introduced them in the first place.
EDIT 2: Sorry, my fault. The additional Cherry macro program fell back to ancient key bindings, between closing down the comp and turning it on again, without letting me know (= in its caption it does not indicate the current key bindings set = the name of the set), and even if MI's history functions ain't what they should be, they ain't what I thought they were. Thus, I'll have to try them out anew, but the chaos I spoke of, was indeed caused by pressing the wrong keys. Sorry again.