Petko,
I got this idea from opensource projects.
I am willing to donate or to purchase more licenses immediately if you could
prioritize certain functionality in your todo list for MI.
What is your thought on this?
I think there would be some members on this board who would join too.
I realized this is more cost effective for me than hiring another developer to build
a customized scripts that would complement MI (similar to what Fred is doing).
Everybody would win at the end.
support for new features
-
Crystal401
- Posts: 126
- Joined: Fri Jul 13, 2007 11:59 pm
Hi again, Alex,
Sorry, I hadn't been aware you were speaking of this post I had indeed read some days ago, without daring to give my 2 cents then; in the meanwhile I got the courage to give my opinion onto this.
Let's say it's psychologically degrading, but it won't be degrading to have some SPECIFIC answers from Petko - not immediate answers, and then, INTERMEDIATE answers only, after some weeks allowed each time to Petko for each suggestion - in order for us to know us if he seriously considers these suggestions, or if we are developing wishful thinking. I think, real developing help in Petko's direction might be utmost thing we can offer him, and again, describe, Alex, what'd be important to you, and for the pseudo-code, I'll be willing to step in if Petko allows - and if I know he'll encode it then
- so no psychological degradation on its way but real group work, benefitting the fellow user community and everybody out there...
and as I said, as soon as MI is really outstanding, it'll be a PLEASURE for me to do some phone calls, contacting journalists at computer papers, and so on, touting its USP's... by touting their specific usefulness for different professionals' groups, comprehensible examples at hand.
And again, Alex, I've had this idea months ago, then only discarded it, for the reasons developed today. I'm not blaming you, it's just that I've had more time to discard an idea that seemed finally unacceptable to me... after having pondered it for some time
Sorry, I hadn't been aware you were speaking of this post I had indeed read some days ago, without daring to give my 2 cents then; in the meanwhile I got the courage to give my opinion onto this.
Let's say it's psychologically degrading, but it won't be degrading to have some SPECIFIC answers from Petko - not immediate answers, and then, INTERMEDIATE answers only, after some weeks allowed each time to Petko for each suggestion - in order for us to know us if he seriously considers these suggestions, or if we are developing wishful thinking. I think, real developing help in Petko's direction might be utmost thing we can offer him, and again, describe, Alex, what'd be important to you, and for the pseudo-code, I'll be willing to step in if Petko allows - and if I know he'll encode it then
- so no psychological degradation on its way but real group work, benefitting the fellow user community and everybody out there...and as I said, as soon as MI is really outstanding, it'll be a PLEASURE for me to do some phone calls, contacting journalists at computer papers, and so on, touting its USP's... by touting their specific usefulness for different professionals' groups, comprehensible examples at hand.
And again, Alex, I've had this idea months ago, then only discarded it, for the reasons developed today. I'm not blaming you, it's just that I've had more time to discard an idea that seemed finally unacceptable to me... after having pondered it for some time
-
Crystal401
- Posts: 126
- Joined: Fri Jul 13, 2007 11:59 pm
Fred,
Thank you for your feedback.
Let's wait until we hear back from Petko.
Thank you for your feedback.
Let's wait until we hear back from Petko.
We've done some custom work on MyInfo in the past, but was only for small things that could be useful for other MyInfo users, but were by no means priority for us. So, it depends on the request.
On the other hand, there is no need to purchase additional licenses of MyInfo in order to make it better - it is my utmost priority anyway.
On the other hand, there is no need to purchase additional licenses of MyInfo in order to make it better - it is my utmost priority anyway.
-
Crystal401
- Posts: 126
- Joined: Fri Jul 13, 2007 11:59 pm
Petko,
Thanks for the reply.
My top priority for now (mentioned in other thread)
* I have 1000+ docs - 10 of them have tag "A"
* select those 10 documents with tag A in filter view
* Cut these 10 documents
* Goto Tree view
* Paste these 10 documents in specific location all grouped neatly.
Based on your post, something similar was possible with prior versions?
This feature would cut down my time spent on routine process by 1/3....
I really hope this will become feasible.
Thanks,
Thanks for the reply.
My top priority for now (mentioned in other thread)
* I have 1000+ docs - 10 of them have tag "A"
* select those 10 documents with tag A in filter view
* Cut these 10 documents
* Goto Tree view
* Paste these 10 documents in specific location all grouped neatly.
Based on your post, something similar was possible with prior versions?
This feature would cut down my time spent on routine process by 1/3....
I really hope this will become feasible.
Thanks,
Please re-read my "old" posts, on "Tabs, Files, Items, Go Back", where I've been asking for the possibility to further process filter results.
Did I understand well? 10 docs out of 1,000 in filter view, with tag, that is in reality, you have ONE topic, with 1,000 items, of which 10 would be tagged "a", and ONLY THOSE TEN would then be in the filter view, since you filter by tag a, right? So in this list, there only would be these 10 items tagged "a", right? Thus, no selecting a sub-group in the filter view, just selecting the filter group as a whole?!
But of course, in the tree, those 10 items are spread over the whole tree, and they would to be CUT there, wherever they are, at 10 different locations in the tree, right?
And then, they would be pasted somewhere, as a group, right?
If you want to have this for multiple topics, no way at this time, but then, we NEED those filtering things for multiple topics at the same time... But let's consider doing this only for one tree:
The filter view is on. You do the special command. The special function would build up an array (not a list since those items could be parent items of sub-trees, and these possible sub-items would also be cut and pasted) in which it identifies those items that are to be selected for cutting, by their position in the tree / tree array. Then it would automatically go to tree view and invite you, by a non-bound message, "Escape to abort or navigate to the item under which your cut selection will be pasted to, then press Enter." You would react accordingly; since the message is unbound, you could scroll the tree and click on as many intermediate items as you need; then you press Enter, and then, perhaps it would be a good thing to give a message box with a warning, perhaps with OK preselected so that you only would need to press Enter again in order to proceed. If you do, then only the special function would write the selected items, with all their attributes, in a multi-dimensional array, would cut the items on their original position, then would read the built-up array into the tree on the selected position.
This might be 2 days work - But the real problem is, at this time, filtering is only possible for one topic at a time, tags in several topics at once can only be searched for, not be filtered, and there is thus this architectural inconsistency; as I said before, tagging is really extremely helpful when it spans all existing files - Allen's GTD, all your tasks are spread over 100 or more topics, especially the not (!) loaded ones, and thus when they (= the tags) are not stored in the respective topics themselves, but in a reference table always loaded in the working memory, for immediate access. Having a lot of possibilities with the tags of just ONE topic, when tags over several topics can only be searched for, with the hit items not being able to grouped and processed, as filter hits are, is not a viable solution at long term.
Thus I propose this: Within the version 5.xx range, we must address "all those little things"; by 5.5, we could discuss, for one, a project management functionality, but which I'll first share as a script running with MI, and, having 5.5 in our hands, we would start to discuss how to manage a much better tagging functionality, especially in view of the fact that real tagging is number one of UR's development list, so a much better tagging will be necessary, and soon, for maintaining MI's advance over UR in this respect.
Technically, a reference table in which tags will be stored, should be feasable, and as soon as this table exists, MI will finally have REAL GTD functionality; since there are a lot of GTD sites in the web, touting for MI will then be possible there, whereas MI's GTD functionality at this time is practically limited to one topic; the search functionality over several files being fine for searching remote subjects, but not for "do this, do that" tags you use 10 times every day!
Thus, a real enhancement of tagging / filtering, between 5.5 and 6.0, FOR 6.0, would be sort of a common priority, whereas a perfect PM functionality would only be implemented in 6.5, and before this be "script courtesy", with the additional advantage that this would give us the possibility to thoroughly try such a PM feature, without Petko having to restart his work if by in-depth use we come to better ideas to realize this function.
Since Alex' wish for grouping filter results, then pasting those to another location (in the same tree, for the time being, I hope), only affects the given RESULTS of such a filtering, it seems to me Petko could dare to implement such a function even before the real filtering enhancement can be implemented, of course in holding in your mind that those filtered results will eventually come from MORE than one source topic, but technically it's easy, just add one more dimension to the array in which those addresses will be stored - instead of just storing the position number in the tree of one topic, the array must store the name of the topic (= even when totally redundant at this time), and the position number there.
Easy, that one. And anybody who can top me, it'll be a pleasure for me to say, even better, that one: Let's create perfect software together!
Did I understand well? 10 docs out of 1,000 in filter view, with tag, that is in reality, you have ONE topic, with 1,000 items, of which 10 would be tagged "a", and ONLY THOSE TEN would then be in the filter view, since you filter by tag a, right? So in this list, there only would be these 10 items tagged "a", right? Thus, no selecting a sub-group in the filter view, just selecting the filter group as a whole?!
But of course, in the tree, those 10 items are spread over the whole tree, and they would to be CUT there, wherever they are, at 10 different locations in the tree, right?
And then, they would be pasted somewhere, as a group, right?
If you want to have this for multiple topics, no way at this time, but then, we NEED those filtering things for multiple topics at the same time... But let's consider doing this only for one tree:
The filter view is on. You do the special command. The special function would build up an array (not a list since those items could be parent items of sub-trees, and these possible sub-items would also be cut and pasted) in which it identifies those items that are to be selected for cutting, by their position in the tree / tree array. Then it would automatically go to tree view and invite you, by a non-bound message, "Escape to abort or navigate to the item under which your cut selection will be pasted to, then press Enter." You would react accordingly; since the message is unbound, you could scroll the tree and click on as many intermediate items as you need; then you press Enter, and then, perhaps it would be a good thing to give a message box with a warning, perhaps with OK preselected so that you only would need to press Enter again in order to proceed. If you do, then only the special function would write the selected items, with all their attributes, in a multi-dimensional array, would cut the items on their original position, then would read the built-up array into the tree on the selected position.
This might be 2 days work - But the real problem is, at this time, filtering is only possible for one topic at a time, tags in several topics at once can only be searched for, not be filtered, and there is thus this architectural inconsistency; as I said before, tagging is really extremely helpful when it spans all existing files - Allen's GTD, all your tasks are spread over 100 or more topics, especially the not (!) loaded ones, and thus when they (= the tags) are not stored in the respective topics themselves, but in a reference table always loaded in the working memory, for immediate access. Having a lot of possibilities with the tags of just ONE topic, when tags over several topics can only be searched for, with the hit items not being able to grouped and processed, as filter hits are, is not a viable solution at long term.
Thus I propose this: Within the version 5.xx range, we must address "all those little things"; by 5.5, we could discuss, for one, a project management functionality, but which I'll first share as a script running with MI, and, having 5.5 in our hands, we would start to discuss how to manage a much better tagging functionality, especially in view of the fact that real tagging is number one of UR's development list, so a much better tagging will be necessary, and soon, for maintaining MI's advance over UR in this respect.
Technically, a reference table in which tags will be stored, should be feasable, and as soon as this table exists, MI will finally have REAL GTD functionality; since there are a lot of GTD sites in the web, touting for MI will then be possible there, whereas MI's GTD functionality at this time is practically limited to one topic; the search functionality over several files being fine for searching remote subjects, but not for "do this, do that" tags you use 10 times every day!
Thus, a real enhancement of tagging / filtering, between 5.5 and 6.0, FOR 6.0, would be sort of a common priority, whereas a perfect PM functionality would only be implemented in 6.5, and before this be "script courtesy", with the additional advantage that this would give us the possibility to thoroughly try such a PM feature, without Petko having to restart his work if by in-depth use we come to better ideas to realize this function.
Since Alex' wish for grouping filter results, then pasting those to another location (in the same tree, for the time being, I hope), only affects the given RESULTS of such a filtering, it seems to me Petko could dare to implement such a function even before the real filtering enhancement can be implemented, of course in holding in your mind that those filtered results will eventually come from MORE than one source topic, but technically it's easy, just add one more dimension to the array in which those addresses will be stored - instead of just storing the position number in the tree of one topic, the array must store the name of the topic (= even when totally redundant at this time), and the position number there.
Easy, that one. And anybody who can top me, it'll be a pleasure for me to say, even better, that one: Let's create perfect software together!