As for matching heuristics, I'll admit I haven't tried OF's implementation with thousands of projects. I would think that such project heavy usage would be less typical than the 30-100 range I mentioned. Should the application restrict information to accommodate the few project happy, or remain more open for the majority? Or, should the matching algorithm be tuned to accommodate both.
I quite like LaunchBar's way of assigning defaults. The first time you type some nickname or abbreviation in, you have to select it with the arrow usually (unless it is a spot on match). The second time it may not be selected, but it will moved up to a much higher position in the list. When you manually select it the second time it becomes the default. So you only have to use an abbreviation twice for it to be set. This solution is adaptive instead of prepared (filling in fields), and only requires two attempts to set. For wildly off-character nicknames, there is a system for assigning defaults manually, too.
Remember, if the matching is clumsy in large lists, then matching needs to be improved upon. There are a number of successful models out there for good abbreviation matching against huge data sets. Even a thousand projects should not be a problem. The key is, we don't need to see this list. That is why it is only five lines or so visible at once. The true size of this list should be irrelevant.
Finally, I wasn't meaning to advocate constant usage of on hold projects. If a project is undergoing intense planning, it shouldn't be on hold, with this I agree. With occasional inspiration, here is the catch: If you have thirty or forty on hold projects, and you are an active thinker during the day, chances are you'll have an inspiration for at least a dozen of these. This will be distributed amongst numerous on hold projects, in all likelihood. Therefore, even though no single holding project is being subjected to "constant use," in effect, you are very frequently if not "constantly" interacting with holding projects due to quantity. I think that is where we had a miscommunication. A holding project is not a dead or cancelled project. That is what "Dropped" is for, and I don't think dropped projects should be in The List.
A good example right now for me is my book list. I'm in the process of moving, so *all* of my procurement lists are on hold until I get settled in. However, I still come across a book or two a day that I want to buy or check out from the library. Adding books right now is a royal pain. I don't want them in my next action lists, but I need quick entry access to the list.
I quite like LaunchBar's way of assigning defaults. The first time you type some nickname or abbreviation in, you have to select it with the arrow usually (unless it is a spot on match). The second time it may not be selected, but it will moved up to a much higher position in the list. When you manually select it the second time it becomes the default. So you only have to use an abbreviation twice for it to be set. This solution is adaptive instead of prepared (filling in fields), and only requires two attempts to set. For wildly off-character nicknames, there is a system for assigning defaults manually, too.
Remember, if the matching is clumsy in large lists, then matching needs to be improved upon. There are a number of successful models out there for good abbreviation matching against huge data sets. Even a thousand projects should not be a problem. The key is, we don't need to see this list. That is why it is only five lines or so visible at once. The true size of this list should be irrelevant.
Finally, I wasn't meaning to advocate constant usage of on hold projects. If a project is undergoing intense planning, it shouldn't be on hold, with this I agree. With occasional inspiration, here is the catch: If you have thirty or forty on hold projects, and you are an active thinker during the day, chances are you'll have an inspiration for at least a dozen of these. This will be distributed amongst numerous on hold projects, in all likelihood. Therefore, even though no single holding project is being subjected to "constant use," in effect, you are very frequently if not "constantly" interacting with holding projects due to quantity. I think that is where we had a miscommunication. A holding project is not a dead or cancelled project. That is what "Dropped" is for, and I don't think dropped projects should be in The List.
A good example right now for me is my book list. I'm in the process of moving, so *all* of my procurement lists are on hold until I get settled in. However, I still come across a book or two a day that I want to buy or check out from the library. Adding books right now is a royal pain. I don't want them in my next action lists, but I need quick entry access to the list.
Last edited by AmberV; 2007-06-26 at 09:36 AM..
Linear Mode
