I am fed up with Things due to their lack of security with Things Sync. I used Things as a simple To Do list manager. I want to switch to OmniFocus, but the complexity is daunting, and I am not sure how to map my simple system into OmniFocus.
Today: Tasks I need to get done today.
Next: Tasks I want to get done today or very near term. I move tasks from Next to Today as appropriate.
Scheduled: Tasks I want to defer until later, but want to see a pop-up reminder. The task automatically appears in Today on the set date. Sometimes I move tasks from Today to Next. More often I reschedule them for a much later date if I don’t have time to deal with them now.
Someday: Tasks I want to remember, but never seem to have the time to do and get tired of seeing them pop up automatically as in Scheduled. Long term stuff.
Areas (Things tasks are grouped and displayed in this order):
Work (my business), Phone Calls and Emails, Errands, Chores, Other, Elderly Parent Care, Home Repairs, Computer, Vehicles, Long Term.
Most tasks are one-offs. A few tasks are periodic - every six months (e.g., change batteries in smoke detectors).
I am not ready for the full-on GTD regimen. I want to find an easy way to map my system into OmniFocus. I read the OmniFocus for Mac eBook and have no problem understanding each of the components of the OmniFocus software - projects, project types, contexts, perspectives, etc.
Where I am struggling is how to take what I have in Things and apply them to OmniFocus. Are my “Areas” equivalent to Contexts in OmniFocus? If so, what projects do I need? Should they be parallel or action lists? Are they Projects? If so, which Contexts do I need? etc. etc. etc.
Any advice, experience, or suggestions to get started would be most appreciated. Thank you.
No. Areas (or Areas of Responsibility - AoRs) are mapped as the folders in the left pane. Within each AoR, you then put the associated projects or project folders for that AoR. Here is an example of my folder structure.
Tasks are actions that you can do in one step. Projects are collections of tasks that are required as a group. The tasks within the project can be done in series or parallel. Alternatively, the project could just be a “checklist” (single action list). For example, the @Admin > … projects above are single action lists that hold “quick and dirty” todo actions over the entire AoR. YOU decide whether the project contains parallel, series, or single action lists.
Welcome to Omnifocus! I also used Things earlier, but left because of its limitations (especially that it doesn’t offer hierarchic projects). I think you will like Omnifocus. It’s very flexible, so you can adapt it for your needs and liking. You don’t have to make it complex, and you certainly don’t have to fit in into some GTD scheme if you don’t want to. I am sure many other users are willing to share their experiences with you, here are just some small thoughts that might be worth to consider:
Avoid scheduling tasks that don’t have actual due dates, it will easily degenerate to a rescheduling struggle (to me, it was a relief to stop doing that). Use the Review feature in Omnifocus instead. Set the review for your projects to appropriate periods, and stop worrying about forgetting tasks.
There is no Today perspective in Omnifocus, but you may create one (if you have the Pro version). It’s not really what contexts are intended for, but I have a context ”Today”, and a perspective that shows tasks with that context. If you use contexts for other purposes, you could use a home-made tag instead, for example #today, and have a perspective that searches for that text. You could also use the built-in Flagged perspective as your Today perspective.
For Today/Next/Scheduled, you may find the Forecast and Flagged perspectives useful, especially if you chose to not buy the OmniFocus Pro upgrade. Forecast can essentially be your ‘Next’ and ‘Scheduled’ views, whilst Flagged will be ‘Today’.
First, the forecast view, by default, just shows actions that are due today (or the day/date range you select). It can be configured, though, to show your calendar events and even those items deferred until today. (See the “eye” menu/view options to turn these on.)
Then, for the items you intend to do today, you can flag them and use the Flagged view as your working/Today view.
The only caution is that any item that was deferred until, say, today, won’t show in the Forecast view tomorrow. Therefore you should defer those that you don’t intend to/cannot complete today.
If you have OmniFocus Pro you could create custom perspectives if you need more control over what you’re seeing. Scripting is also available in OF Pro, which could, for example, automate flagging actions that are deferred until today.
As suggested, set up your folders (Areas of Responsibilities) and projects.
Then learn how to use and create custom perspectives. This needs the Pro upgrade.
The review workflow is probably the best thing to curate and manage your various projects. The review perspective is probably the feature that I think sets OmniFocus apart from the various other apps out there.
For your one-off tasks, you can create a Single Action List for each folder. For example, I have different folders for Home, Work, Family, Parent Teacher Association, etc.
Then I create a single action list for each folder:
When I have a one-off task, I’ll assign that one-off task to the single action list:
Home Action: Change the light bulb in the bathroom
Office Action: Call Jack re: Spring Gala
There are several resources available for sale that are all wonderfully written. They are all well worth the price.
The great thing about the variety of apps is that you can ramp up or down based on your current situation. If your life is simple, stick with Things. When life becomes more complicated, ramp up to OmniFocus. If life gets simpler once again, go back to Things.
But now that I’ve become savvy enough in OmniFocus, I can’t go back to Things.
Hey everyone - thank you for your great hints and suggestions. I think I am moving in the right direction. I created Projects (Single Action Lists) that correspond to my “areas” - Work, Phone Calls and Emails, Errands, etc.
I plan to use Flags to identify “Today” tasks from the “Next” tasks (keep visible, do it soon). I can use the Flagged Perspective to see only Today’s tasks if I wish.
Now I am looking for a way to do the following two “features”:
(“Scheduled”) Create tasks that are hidden from view until a set date (say, 1 February). On that date, they become visible (appear in the “Next” list). They stay visible until I change them. (Flag for Today, complete the task, or put it back in Scheduled by assigning a new future date.)
(“Someday”) Create tasks that are hidden and stay hidden, but can be reviewed. These would be moved to Next (visible now) or Scheduled (hidden until a certain date) as appropriate.
Thanks again for your help. I really appreciate it.
I think the existing Forecast view has the "Scheduled” features you are looking for. If you have the Pro version, you may also create a perspective that both shows task that are due and tasks that are flagged.
For ”Someday”, you may simply create a project with that name. If you set the status for the project to On hold, it might be close to what you are looking for.
I’d comment that Work is broad enough to be a folder that contains projects, while phone calls and emails and errands are more akin to contexts than projects.
I use flags to identify active versus not active on tasks that have no due date. The Forecast view shows tasks that are due. I create a perspective to show due + flagged. That captures actions due today and actions that are (still) active independent of due date.
Use defer dates for this.
Use a “someday” context for this. Activate / Hide it as needed.
OK. But if OF is thinking that folders equates to AOR, why aren’t they in the ios version. When I create a task, instant adds are projects and contexts. Shouldn’t Folders be there for exactly the same reason, so I can assign a new task to an AOR in the one go, without having to add it to a project?
This is why I think the request has been out there for tags - to meet the AOR need.
What I am doing now is crude, but works. It kinda, sorta, acts like Things.
I have projects for: Business; Phone Calls Emails and Errands; Chores; Children; Elder Care; Home Repairs; Computer; Vehicles; Other; and Long Term. They retain that order, which is what I was used to in Things.
I add actions to the appropriate project and rearrange them as necessary within each project so that they are in the order I want to do them. I flag them if they are really critical, and give them defer and due dates as appropriate (rare).
To get that “Things” view, I click on Contexts. What I get is a condensed To Do list in project and action order, a la Things.
I understand that it is abuse of the powerful, capable OmniFocus program that could change my life, but you gotta start somewhere.
Tasks always go under to Projects, never by themselves in to Folders.
So, I guess you could create Projects as your AoRs. This makes no sense though.
Honestly, I am a bit confused by your thought process. Why do you see think an Area of Responsibility should encompass just Tasks by themselves? Or, better still, why do you think that Tasks should ever be allowed to be atomic units that can, if desired, be entirely free of any association with a Project? This type of approach is overly unstructured.
Are you familiar with the option to create a Single Action List Project at the top level of each AoR Folder?
Thanks for your response. The picture you’ve included linked to the other post which began with Mark asking the same question.
But you’re right. SALs can do it. (Why didn’t I get this before?)
I see what you’re doing with @Admin, so I’m going to try a similar thing with zGen, to put all my general SALs together. Plus zGen is easy to type on the iphone, making assigning it to that SAL quicker. But again, feedback welcome if you think I’m still missing it.
Contexts are tricky, aren’t they: I began by making hierarchical text lists of everything that seemed likely… places, what’s actually required to get something done, types of resource.
Then I took an inordinate length of time transcribing everything exported to a PDF from my previous software (actually 2Do, to which I had moved from Things itself) into OF 2.
It was that very activity which revealed to me how to use Contexts - empirically. Probably half of those which I though I’d need, I didn’t; and a quarter of those that I now have are ones which I couldn’t have foreseen until I started working with actual Items.
SALs make sense - for me - when you want to create subgroups in/under/from the few (I found, again empirically, the fewer the better) Projects into which my actual Items naturally fell.
For example, I have a Computer Software Project. Inside/under that comes a SAL to capture all the investigation I have had to undertake really to get to grips with OF 2. Since by and large it hasn’t mattered what order I learn OF’s functionality in, a SAL is ideal. My Context in this case is Software - Productivity.
When I’m satisfied that the only remaining features of OF that I haven’t learnt can be put on hold until I have time to go back to them and implement them (Styling, perhaps, since it seems likely that a future release will implement Styles more fully, and so differently from now), the remnants of that SAL will go into a Software - Productivity, Waiting Context.
1 - build Contexts empirically - as a result of the totality of my actual tasks… they’ll tell you if you don’t need them :-)
2 - simplicity: only use them if they really serve a purpose… categorizing tasks and projects for the sake of it is a waste of time and effort
3 - everybody’s circumstances are different… someone who works from home or who is retired/unemployed may not need ‘work’ and ‘home’ Contexts
4 - they’re used to indicate something (e.g. What I need to do this, What status it has, Why I’m doing it etc ) so be consistent
A good test for whether a Context should exist and be in use, I have found, is this: are all the items and only those items in one Context also the only ones - and all the ones - that are otherwise in a Project; and likely always to be so? If, Yes, then the Context may well be unnecessary!
And thanks to everyone in these forums, and from links posted here, for views which - after aggregated - make real sense for me.