If there’s anything in your inbox, then there will be a grey border down the left of the Inbox tab. Similarly if there are due items in Forecast there is a red border and an Orange one on Review if there are items due for review.
Never noticed that. Very subtle.
Maybe a tad too subtle.
I too have a similar perspective to filter out Today’s action list, and there is no real necessity for sorting as perspectives take care of that. It is more of an visual and organisational thing. I am a little OCD and prefer to have my lists in some kind of date order (just as in 2Do and Appigo’s Todo).
Wow! That is true … just tested it. It is way too subtle as I saw the red and orange borders, just not this grey one. Maybe it needs to be more obvious. Thanks for the tip!
Wow, claw73 has listed the exact same high priority wish items that I have (except for sorting new tasks by due/deferred). I’d add that there should be some effort to make the views consistent/sensible (e.g., when grouping by project, why list project instead of context for each task?).
Thanks for starting this conversation - looking forward to hearing what items are on people’s wish lists.
Here are mine:
- In Forecast view, deferred items with today’s due date are suppressed in the deferred section [I definitely support this one - thanks for mentioning it claw73]
- Enable users to pin the Forecast calendar to any perspective so you can quickly assign tasks to days (either as ‘due’ or ‘deferred’ items)
- Explore improvements to the Forecast view to make it more useful for day/week planning. Currently the view is helpful to see what items are coming due on your calendar, but its not particularly helpful to work from as a ‘Today’ perspective unless you use due or deferred dates to pin tasks to days. For example, consider the addition of another parameter (in addition to due and deferred dates) that would enable people to assign tasks to days for the purposes of planning a work day/week, without needing to define these as ‘due’ (since you plan to work on them on those days, but they aren’t actually due). ‘Deferred’ can be used for this purpose, but then you have problems in other perspectives if you are using deferred for its intended purpose
I think this is a great topic, but I need to post the obligatory reminder that making a request on the forums is not guaranteed to communicate the request to Omni staff and get it in the development database. We spend as much time here as we’re able, but especially once the support tickets really start rolling in, that time is likely to be more limited than it was earlier in the test.
tldr: if you want to be sure that Omni staff see your feature request, email it to us via the help menu in the app.
Particularly once these forums replace the vBulletin ones we used previously - which is happening later this week - I expect a wave of new community members to sign up; they’ll need a certain amount of coaching on this point. It would be greatly appreciated if more experienced members of the community gently pointed the new folks in the right direction. Thanks. :-)
I actually peter this bar versus a badge counter to make the interface cleaner. However, a toggle option for a counter would be nice if people want that instead.
@Brian I completely understand, but I would also encourage Wish Lists like this thread amongst the community as sort of an advertisement for feature requests to get more of those individual emails rolling in.
Sometimes, I may email a feature request and have no idea if people are thinking along the same lines, so I’ll post on the forums to advertise the feature request to see if more people agree, so he/she will send in an individual request.
4 Likes
I quite agree - the bar does the job now that I am aware of it, so a counter is not that necessary. It does however need to be more obvious so that it jumps out - what about a nice bright blue or green?
Brian, thanks for pointing this out. You will be getting an email from me with this list and more!
Go look at this thread and try out this clever, little bookmarklet that @derekr cooked up: Add it to your browser’s toolbar or favourite bar, select some text (usually your request in the forum thread) and then click on the javascript to shoot off a CC: to OmniFocus.
Oh, I absolutely agree! If my post came across as trying to shut the thread down, I apologize. Threads like this are great - I just feel bad for the folks who only post their idea here. We make efforts to capture ideas wherever they get posted, but email is still by far the most reliable way of communicating those ideas to us. That’s all I meant to say. :-)
2 Likes
We need a dedicated OmniRequest voting chart! I won’t email this one. :)
1 Like
Context and Project as ‘Tags’ not ‘Folders’ (namely letting an action pertain to both more than one context and more than one action)
If this has been posted else where I apologize for the repeat but I’m sad to see this functionality is not in the final build of OF2.
As it is, only a single context and only a single project can be assigned to an action. (Or we might say an action can only be assigned to a single project and context). Either way this is limiting. For example: let’s say I’m building a guesthouse which exists as a folder in Omnifocus projects because there are myriad small projects that go into this. Two of these projects are “hang drywall” and “install countertops.” Both of them require a proper level which I don’t own. ‘Buy level’ therefore belongs in the sequential-type project list of both of these. I could put ‘Buy Level’ twice in each of them, but what if I do the projects months apart and forget I own a level and buy it twice. This seems silly that I would forget, but Omnifocus is supposed to make it so I don’t have to remember such things.
If I could assign "buy level’ to both projects while still dragging it around within those projects I would be golden. If I’m working on the drywall first and buy the level it gets automagically checked off in my countertops project without my need to even enter that project. But what if I delete ‘buy level’ from my drywall project as my contractor has brought one with him? Then Omnifocus should ask me: “Do you wish to also eliminate this action from the following other projects, or simply decouple and delete it from this one?”
Secondly, contexts. What is the context for buying a level? The hardware store, obviously, but what if I’ve got a Home Depot context and a Lowe’s context. Again, I could add buy level to both of those contexts but then if I forget I might buy it twice, and even if I remember, then I have useless extraneous junk-actions in my system. I should be able to assign all of the possible contexts to this item. If I happen to be at Home Depot and buy the level, it also disappears from my Lowe’s context as well. This is very simple database functionality. I realize this way of Tagging things goes beyond the GTD specs that David Allen lays out, but projects and contexts as tags just makes inherent sense. An action should be available in multiple contexts, especially things for purchase. It should also be available to multiple projects. There are many many projects that share requisite actions.
-Robert
One approach would be to group both of these contexts underneath a “Hardware Store” parent context. When you do your morning review and start planning out your trip to the hardware store, you’ll know which one(s) you’re going to go to, and can move it into the more specific context if you so choose.
Personally, I don’t find hyper-specific contexts all that useful, especially for shopping list type tasks. I create all my grocery list items in a Groceries project whose default context is Grocery Store. I re-assign tasks to specialty contexts if I know I can only get them there (for example, Liquor Store or my local fancy-schmancy grocer). I have a perspective called Grocery Run that only shows Flagged tasks that are assigned to the Grocery Store parent context. That perspective is starred on my iPhone so I can quickly pull it up when I get to the store.
1 Like
Good point. And, you are right to point out also that moving these things around is one of the many reasons for the habit of daily/weekly reviews. But I prefer my ‘nightly sweeps’ to be focused on selecting the tasks for the coming day, not redefining their contexts based on guessing where I’ll be much less scheduling errands. I have OmniFocus precisely so that I don’t need to worry about such things. I could be general, but something that is only at the fancy-schmancy grocery (organic fudge and a dozen other items that go with it) are distracting available actions that aren’t really and truly available while I’m at Safeway. I stand in the aisle at Safeway with my @grocery context up on my iPhone going wait, is this really here or at another store? This seems trivial for you and I, but I have friends who are chefs and sometimes have grocery lists as long as their arms. I can’t advocate OmniFocus for them if contexts require such daily maintenance.
I appreciate your use case though and it’s lead me to nest some of my contexts. As it stands it seems the best thing to do is to have Groceries : Fancy Schmancy. Then when I’m at Fancy Schmancy I’ll be sure to get everything on that list but if I’m not pressed for time, I’ll hop up to it’s parent context (groceries) and see if there’s anything else I can get while there. Thanks for the suggestion. I’m also stealing your iPhone context. Good one.
I do still hold that the OF database should be structured to allow for flat taggging rather forcing an action to choose a single context, nested or not. And some actions remain incoherent to nest. Maybe red wine can be on the Grocery parent context, but can it also be on the People : Phil context who mentioned he has an extra case I can have? Forced hierarchy takes the simple and makes it complicated.
1 Like
Feature Request - Next Occurrence in Defer/Due
I emailed this request.
Today is May 28th. If I type “11” in the due field, I wish OF2 would know that I mean the next occurrence of 11 which is June 11th versus choosing an overdue May 11th.
2 Likes
More granular control of Notifications : Highlight Perspectives
It’s nice to be able to Flag unavailable (deferred) tasks. This is especially powerful for recurring projects that – once started-- should be seen through to their completion. But Highlight Perspectives will show up as highlighted regardless of whether the there are available tasks or not. If these highlighted tasks are recurring this effectively breaks Highlight Perspectives functionality.
Example:
In the example you can see that my Laundry project, once completed, will become available again five days later. I may start it then or I may not, but if I check Start Laundry then I want Hang Laundry and Fold Laundry to automatically show up in my flagged list.
This works great already, but since these tasks always exist to be done, even deferred into the future, my Flags perspective always glows orange which makes the notification pointless.
A radio button of Available / Remaining next to Preferences : Notification : Highlight Perspectives : Flagged could fix this.
