The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus 1 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
OmniFocus 1.8 sneaky peeks are now available Thread Tools Search this Thread Display Modes
No doubt, whpalmer, you have a point too.

It all comes down to different tastes and priorities, obviously. For me, simplicity is about having clear and unambiguous conceptual categories. For others, simplicity is about visual presentations. For others still, it boils down to minimizing the number of clicks to access your information.

It seems overall that Curt's suggestion (projects and action groups being actionable and automatically placed in their own "bin") makes both camps happy. If no such "bin" is implemented, at least there should be a "default context" setting for projects and groups in the app's preferences. That way we can create our own bin of sorts by having a special "Projects/Groups" context automatically assigned to parents.
 
Quote:
Originally Posted by whpalmer4 View Post
jdh,

I'll have to think about it some more, but your suggestion sounds good to me at first hearing. I like the ability to use the functionality only some of the time (which is how I use the auto-complete feature), too. I think "parent context" might be a confusing name for some, however, especially when dealing with action groups.
It doesn't have to be called "parent context"—which of course would look appalling and irrelevant on screen. Instead, as I wrote above, it can be a "bin", just like the inbox, perhaps even placed immediately below the inbox on the sidebar, which would be titled "Projects and Action Groups." And that can be hard coded—automatically assigned to projects and groups, or assigned to them by default, with the capability of it being overriden by the user.

Last edited by macula; 2010-02-22 at 11:25 AM..
 
I think you may have missed what I was suggesting... While I agree that there is definitely better nomenclature than Parent Context, my earlier post was suggesting that each Project and Action Group have an extra field to allow the user to specify a specific context (separate from the "Default Context") if they so desire.

While adding a new field may seem more cumbersome, it's one of those things that's useful if you want it, and can easily and safely be ignored if you don't. Nothing extra is needed in context view except to ensure that projects/action groups without a context simply don't appear at all.

I'm personally not in favour of the idea of putting an extra "bin" in context view, since that tends to defeat the purpose of context view IMHO. Having a "bin" with unassigned projects/action groups seems cumbersome regardless of whether they're listed under "No Context" or some other place. I'd rather they appear where they're specifically assigned or not appear at all.
 
I agree that a project's default context for its actions and its context in which I might want to see it in context mode are two wholly different things. Cramming both into the same field makes little sense. I second the idea that, if this new functionality is going to be added, a new field will need to come with it.
 
jdh and Craig,

That sounds fine, thank you. I would only add that there should be a global default setting for the parent's context in the application preferences (with the possibility, obviously, to override that context for each parent individually via the inspector). This arrangement will also satisfy those users who don't want to bother with manually entering a context for each parent, but at the same time don't want the parents to be hidden away.
 
I think jdh's proposal has merit, especially if the context for parents could be set to default to something like "Review" (or whatever the user chose). That default would essentially replace the Parent bin that I suggested.

It's not clear to me which would be more understandable. One difference with jdh's proposal is that it exposes in the UI that there is a distinction between the context of a project and the default context for actions in that project. That gives the user the ability to set the two independently. With the Parent bin proposal the context of a project effectively would always be Parent, though Parent would be called out in the UI as a special context.

For extra credit, suppose that contexts for projects could be automatically set in the preferences. What do you call that setting to distinguish it from the default context field of a project that will be used by new actions?

(I have to say, I'm enjoying the discussion about the best way to resolve this. Thanks for all the interesting opinions. I know the folks from Omni are watching the thread.)
__________________
Cheers,

Curt
 
Quote:
Originally Posted by macula View Post
Here is my somewhat radical suggestion then: Remove the check box altogether and hardcode this behavior whereby a parent will be automatically marked as completed when its children are completed. Then also remove all this "1.8 baggage", most of all the assignment of contexts to parents, which has sparked so much lively debate among both devoted and new users.
IMO that works for groups, but not for projects. I definitely don't want to have to plan all my projects in detail in advance to keep them from being automatically marked "Done" when they're nowhere near it!
 
Quote:
Originally Posted by curt.clifton View Post
For extra credit, suppose that contexts for projects could be automatically set in the preferences. What do you call that setting to distinguish it from the default context field of a project that will be used by new actions?
Review context?
Completion review context?
Check completion context?
Context mode context?

Dunyet context? :-)
 
Quote:
Originally Posted by curt.clifton View Post
I think jdh's proposal has merit, especially if the context for parents could be set to default to something like "Review" (or whatever the user chose). That default would essentially replace the Parent bin that I suggested.
At that point, what's the difference between this Review context and the existing Stalled filter/perspective that's already available in 1.7, other than whether it shows up in planning or context mode?
 
Am I understanding this right, that the only purpose of showing parents within context views is to keep them from stalling by alerting the user that a parent's last unfinished action was just finished? If so, why not just alert the user directly by putting up a dialog when the last available action is checked "done" or deleted? That way contexts are kept uncluttered and conceptually clean.
The dialog could offer to open a window focused on the parent that's at risk of stalling. Click "OK" or hit Enter to go to that window and add more actions, or click "Cancel" or hit Esc to dismiss the dialog and continue doing something else.
Conceptually, defining new tasks for a project belongs in planning mode anyway, where of course it's already available in 1.7 via the Stalled project filter.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
OmniFocus 1.7.5 sneaky peeks underway! Ken Case OmniFocus 1 for Mac 1 2009-10-21 01:34 PM
OmniFocus 1.7 sneaky peeks have begun! Ken Case OmniFocus 1 for Mac 56 2009-08-27 04:37 PM
OmniFocus v1.6 sneaky peeks! Ken Case OmniFocus 1 for Mac 32 2009-02-26 01:12 AM
Sneaky Peeks gone? Smithcraft OmniWeb General 5 2007-10-25 05:10 AM
CPU use in sneaky peeks hardcoreUFO OmniWeb Bug Reports 7 2007-08-31 02:23 PM


All times are GMT -8. The time now is 09:06 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.