On Hold projects not populating auto-complete
 

Currently, when a project is placed on hold, it no longer comes up as an available project when you are adding new tasks in Quick Entry or the Inbox.

How does everyone feel about this?

I have a big problem with it, because quite often projects on hold are simply still in the process of being developed. I'm not ready yet to take them on, so I don't want them showing up everywhere, but I'm still getting ideas in the back of my head for how to do them. This is precisely the type of situation that Quick Entry is good for: When you are doing something and have an idea for something else that you want to make a quick note of. As the system currently stands, you have to do a lot of jumping through hoops to get this "quick idea" into the appropriate location. You can just leave it blank and hope you remember want the task was for when it comes time to process the inbox, or you have to bring down filters, set to All Projects, locate the holding project, and then manually drag the task into the holding project.

I'm sure the argument for not including them is good. You want a clean project list everywhere, and putting things on hold is part of keeping things clean. My response to that would be: Isn't that what auto-complete is for, to make long lists of things quickly accessible with a few keystrokes? To, in essence, reduce massive lists to smaller user comprehensible lists? This is how programs like QuickSilver and LaunchBar work. I have hundreds of thousands of searchable items in there, but I'm always able to reduce that number to One in a matter of seconds.

So yes, what are your opinions? I've already sent mine to the OF team, and they stated that it is a concept under debate amongst themselves. But since then they have only made the project list culling more tight, by also hiding projects beneath inactive folders.

The way I see things going for me is that On Hold is going to become less and less useful for me. I'm going to have to live with a much greater amount of clutter in the [i]visible[/i] areas of the GUI, to keep the [i]invisible[/i] areas populated. Because the simple fact is this: I'm always thinking of everything in some part of my mind. Inspiration shouldn't be hampered by whether or not I am actively working on a project yet. Just because something is on hold doesn't mean it should be difficult to evolve its preparation for the time when it is not on hold.

Well articulated, Amber!

I would also like to have inactive folders and on-hold projects show up in the project entry column. This "improvement" seemed like a regression to me.

I do like the fact that children of inactive folders are hidden in Active Project view. This makes it very easy to hide/show my Pending projects, which are all under inactive folders named Pending (themselves under folders for each of my life roles). But during quick-entry, I want access to every project that isn't already completed.

Here's a crazy idea for consideration: What if project searches included just active projects when the search text was in lower case, but included every incomplete project when the search text was in upper case? A preference could toggle the upper/lower case behavior.

Hmm. That's not a bad idea; better than the one I discarded and did not write up above (population of menus dictated by filter state--not cool because you still have to mess with filter toggling). Users of QuickSilver who are used to using caps to automatically switch to actions would probably take to this method quickly.

I'm with Amber. It's called [COLOR="Blue"]Quick Entry[/COLOR], so if I want to add to something I know is in OF, no matter what the state, then by gosh, I should be able to put it where I want without having to get there by using Robinson's Bridge. Otherwise, it's not really a Quick Entry, is it?

I'm totally with Amber

What about if on hold projects matched at a lower priority than active projects ? That way when there were a lot of possible completions (i.e. one or two letters typed) they would sink to the bottom of the results. They would be less visible and less in your way but still accessible by either scrolling down further or providing enough text to make the match less ambiguous. Perhaps the name could be shaded a little lighter as well in the results list to indicate their on-hold status.

I prefer that to case sensitive searching.

I wouldn't that like because then you reduce consistency. The reason why the whole abbreviation matching thing works so well is that your brain picks up on these things exceptionally quickly. You only need to type in an abbreviation for something a few times before you'll remember it very well. When the software is being adaptive on the other hand and adjusting to how your memory takes to these things, it is a very powerful combination. If you start messing with what matches and what does not match, it will slow down your recall. It seems like a small thing, but if you are used to typing 'mhea' for 'Mental Health', and decided to put that on hold for a while and suddenly 'mhea' starts matching 'Miles Heath Contract', it would mess with your brain. And the moment I have to start reaching for more characters to type in, or worse, the arrow keys to select a highly demoted project--the process becomes cumbersome when multiplied by constant usage.

Personally, I don't think there is any need to artificially restrict access to holding projects. As I said above, I can zip through thousands of possible matches in seconds using LaunchBar. I hardly think 30 projects is going to be that encumbered by the addition of another 20 or 40 holding projects. It isn't as though we are talking about adding 100,000 new items to the list.

I'd prefer to see on-hold projects appearing in the completion menu at all times, mixed with active projects, and not ending up lower down the list as a kind of punishment for being on hold. But perhaps they could be in italics? Or in grey?

Well I guess I just figured that if the project was on hold then your need to add items would be of the occasional inspiration sort not constant usage as you suggest. Seems odd to me but to each their own.

I understand your thinking that filtering through a few dozen more projects (although some people on here report having thousands) shouldn't be a technological hurdle but I'm assuming that the developers made this change for a reason perhaps on input from other users who found it too cluttered. I admit that I sometimes find the matching list less than precise. Maybe I need to have more differentiation in my naming. Anyway, you certainly have the right to lobby for putting it back the way it was but providing they decide not to do so what else might solve the problem for you?

I wonder if there might be a way in the project inspector to add a nickname or keyword field, sort of like how you can for bookmarks in Camino or Firefox, so that you could create your own absolutely matching shortcuts such as the mhea in your example above then you could make it something memorable that wouldn't even have to match the exact name very well at all but would be guaranteed to always be the first match. I think Quicksilver has a feature like this too. Maybe this sort of match could override the current behavior as long as it was exact. Just a thought.

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 [i]see[/i] 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 [i]are[/i] 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 sent my own feedback in before I saw this thread:
-----
I asked for a way to create a custom filter for projects, so I can mix 'em up any way I like.

Failing that, creating a new filter for both Active and On Hold projects, maybe named "Available Projects" or something similar.

...and here, I had the fact that on hold projects didn't show up for QE (or Inbox, or Context for that matter) in my list of bugs to report.

When a project is on hold, it's something I want to do, but I'm not ready to start working on it. This doesn't mean things that involve that project don't pop into my head at random times!

I love OF because I can easily dump things out of my head and into the program, but I've been hung up multiple times mid-dump because I was trying to QE a task into an on hold project and I couldn't get at the project! And I get completely derailed from what I was doing because I won't let it go until I've un-held the project, put the task in it, and held the project again. If I don't do it then, I might forget which project it was supposed to belong to and delete it.

Either option undermines my confidence in OF: I either lose my train of thought to salvage the task, or I risk forgetting to which project that task belonged.

The latter results in emails that run "I know I needed to email you, but I don't remember why, do you know why?"

Well said! Your experience mirrors mine precisely. It is really frustrating and "derailing" as you put it, to have to do the FilterDance whenever I have a quick idea for a holding project. The entire purpose of QE is lost whenever--[i]whenever[/i]--you have to switch to OF from your current working app, or change the UI configuration or focus scope in OF.

Thanks everyone for sharing your opinions. I'm surprised that there was only one respondent who actually prefers the current behaviour. Anyway, I've sent the OF team a link to this thread, so hopefully our voices will be heard on the matter. At the very least, it would be nice to have the [i]option[/i] to have a non-culled auto-completion list.

I am going to have to go with the lone voice of dissent and say that I wouldn't want to see “on hold” projects in auto-complete. As i’ve in said previous posts elsewhere on the forum, in my world "on hold" projects are basically dead to me until my weekend weekly review when i review whether or not it's time to make them "active" and get them going again, or rather leave them be for another week. If I need to add actions to "on hold" projects, I would prefer to take the 2s and put them myself than have to spend extra time typing for all the other actions that go into my active projects because the auto-complete is cluttered with all the held projects.

If there’s a way to avoid auto-completion cluttering and speed up action entry for most of my actions, I’m all for it.

Since "our voices" will be heard, I'd like to change what I wrote above and agree with AmberV. I use LaunchBar (constantly) and the list length is irrelevant and does not slow me down. Best to let the app learn your favorite abbreviations quickly and be done with it.

Personally, I want my on-hold projects to be visible for auto-complete. I have pretty significant ADD, so not having to stop when I have an idea for something is a boon to me. I probably don't have nearly the number of projects that others do. Could this be the kind of thing that could be a preference setting so that it comes down to personal preference?

ok, i definitely need to amend my previous statement.

if OF can do a launchbar or quicksilver type of auto-completion where you can set defaults and it actually learns, then I am all in favor of showing everything. i use quicksilver pretty much all day long so i more than get it, and i'm in. If it can't, i would like the option of hiding my currently irrelevant stuff.

has anyone gotten any clue from the omni crew whether this auto-learning stuff is even on their radar and/or in the works?

It seems to me that at least some "simple" learning would be a [b]vast[/b] productivity boost to people with large project lists. And that really makes sense even outside this debate on whether or not holding projects should be included. Anyone with a lot of projects is going to want at least basic matching heuristics, and if those basic systems exist, it would only make sense to open up the project list a bit wider. It doesn't have to be super complicated. Even just implementing the two-strike-to-set-default method I outlined above would make a difference.

[QUOTE=AmberV]Well said! Your experience mirrors mine precisely. It is really frustrating and "derailing" as you put it, to have to do the FilterDance whenever I have a quick idea for a holding project. The entire purpose of QE is lost whenever--[i]whenever[/i]--you have to switch to OF from your current working app, or change the UI configuration or focus scope in OF.

Thanks everyone for sharing your opinions. I'm surprised that there was only one respondent who actually prefers the current behaviour. Anyway, I've sent the OF team a link to this thread, so hopefully our voices will be heard on the matter. At the very least, it would be nice to have the [i]option[/i] to have a non-culled auto-completion list.[/QUOTE]
Looking back over this thread I suppose the "one respondent" your referring to is me but I never said that I prefer the current behaviour I was merely trying to offer some alternative solutions.

Like I said, I'm assuming the developers made this change for a reason, either based on feedback or for some programmatic reason that may not be readily apparent to us. This is a pre 1.0 product and I'm sure that they are looking for ways to keep the feature set as simple as possible until release hence I was suggesting what I thought were some easy to implement fixes as a compromise. Advanced pattern matching and learning capabilities may just not be feasible for this round of development.

Yes, I was referring to your comment, my apologies if I read it to be more negative than you meant it to be. As for advanced learning, I wouldn't expect that in this round either. To reiterate, I think a simple double-strike default would go a [i]long[/i] way toward helping out, and it shouldn't be that difficult to code. It would even give them the ability to say the auto-complete system is adapative in their press releases.

Just a quick "thank you," to the OF team for implementing this. Since the change has been in effect, it has made my usage of OF [i]much[/i] more happy! I also like how it was done. The lighter grey colour is enough to let you know the intended project is offline at the moment, but access is still as simple as any other project.