[Ward]

I started out in Project view by creating a folder for each client, with 1-3 projects for each. Here are the first three:

• Jim
  • Web dev
• Larry
  • Mac support
  • FileMaker dev
  • Web dev
• Priscilla
  • Mac support
  • FileMaker dev
  • Web dev

And I created two generic contexts:

• office
• client site

This works well in Project view (except when I select the "Projects" line and see a long list of like-named, intermixed projects).

On the other hand, the Context view is not very useful because ...

1. I can't see the clients (aka Folders).
2. The "client site" context is actually "n" separate places with the same generic name.

I realize I could work within the current OmniFocus structure by used client-specific project names and client site contexts. But it would be so much easier/cleaner/nicer to have my Project folders displayed in the Context view.

I can tediously simulate a client-specific Context view with today's OmniFocus, one client at a time:

1. Select a client folder in Project view
2. Click Focus
3. Switch to Context view
4. Switch back to Project view & repeat 1-3

Even that's a bit of a problem because the Context view does not display the focused client-name/folder-name.

P.S. I'll submit this as a formal request if no one shows me the error of my ways.

[acid2]

In my opinion, OmniFocus is behaving correctly here. It sounds like you like to work specifically on one client at a time, which is not necessarily how the GTD methodology works. I mean, context's are just places you can do stuff... my computer, my garden, whatever (I'm sure you understand them, just recapping though!) - and when you work in a context you're just doing everything you can do here, instead of moving between contexts and working on 1 project.

I agree, seeing folder would be helpful in context view... We already have the project name as a column, maybe Omni could make it so it reads "Folder -> Project" ?

Also, if the client site is "n" seperate places, why not make these places? It sounds like you're using the client site context as a group, and OmniFocus supports grouping contexts - so this may help you here.

[Ward]

Originally Posted by acid2

In my opinion, OmniFocus is behaving correctly here. It sounds like you like to work specifically on one client at a time, which is not necessarily how the GTD methodology works. ... - when you work in a context you're just doing everything you can do here, instead of moving between contexts and working on 1 project.

I'll confess to diving into OmniFocus after reading only the first chapter of GTD. (Do I hear a chorus of "RTFM?").

I spend 90% of my work hours in my office. So having that as a single context is confusing. I prefer to think of "office" as client A in the morning, client G in the afternoon, client M all-day Tuesday, ...

Originally Posted by acid2

I agree, seeing folder would be helpful in context view... We already have the project name as a column, maybe Omni could make it so it reads "Folder -> Project" ?

While that would be a slight improvement over the naked project name, I'd really like to see the project folder as a top-level item (à la Project view). This would allow expand/collapse and Focus for contexts. Showing projects could be a user preference, retaining the current flat view for those who like it.

Originally Posted by acid2

if the client site is "n" seperate places, why not make these places? It sounds like you're using the client site context as a group, and OmniFocus supports grouping contexts - so this may help you here.

Excellent! I hadn't found that. I've renamed "client site" to "on-site" and added sub-contexts for each client I visit in person. And I've added a "screen share" group for those I visit over the Internet.

My new context groups provide a Focus-like ability to isolate a single client.

[curt.clifton]

Originally Posted by Ward

While that would be a slight improvement over the naked project name, I'd really like to see the project folder as a top-level item (à la Project view). This would allow expand/collapse and Focus for contexts. Showing projects could be a user preference, retaining the current flat view for those who like it.

Just to be clear: You're just asking for Folder as one of the group-by choices in the Context View filter, right? That seems perfectly sensible to me.

[Ward]

Originally Posted by curt.clifton

You're just asking for Folder as one of the group-by choices in the Context View filter, right? That seems perfectly sensible to me.

Right ... probably. I'll have to get more experience with Filter before deciding whether that's the right place to request/customize default grouping.

[Ward]

Originally Posted by acid2

I agree, seeing folder would be helpful in context view... We already have the project name as a column, maybe Omni could make it so it reads "Folder -> Project" ?

In the 10 days since my last post, my list of clients, projects and actions has grown to the point that I'm perplexed by my Context view.

To recap, I have a dozen active clients, each asking for help with FileMaker, Web development, and/or their Macs. In the Project view, each client is a folder, with like-named projects in each folder (e.g., FMP, Web, Mac).

Since nearly all of my work is in my "office" context, the action list in Context view is quite long. And since I can't see client/folder in Context view, I'm constantly asking myself, "What client (folder) does this project belong to?"

When I'm completely stumped, I can select an action and choose View > Show in Project View.

I'm getting ready to add the client name to each project name so that I can see the client in the Context view.

If there were an optional Folder column in the Context view, I'd be in OmniFocus heaven.

[Weasel]

Originally Posted by Ward

In the 10 days since my last post, my list of clients, projects and actions has grown to the point that I'm perplexed by my Context view.

To recap, I have a dozen active clients, each asking for help with FileMaker, Web development, and/or their Macs. In the Project view, each client is a folder, with like-named projects in each folder (e.g., FMP, Web, Mac).

Since nearly all of my work is in my "office" context, the action list in Context view is quite long. And since I can't see client/folder in Context view, I'm constantly asking myself, "What client (folder) does this project belong to?"

When I'm completely stumped, I can select an action and choose View > Show in Project View.

I'm getting ready to add the client name to each project name so that I can see the client in the Context view.

If there were an optional Folder column in the Context view, I'd be in OmniFocus heaven.

I have an almost identical problem. I have 90% of my actions at home (working from home), and 10 % 'DownTown'. I had named most of my tasks with elaborate names in LB so I could see what they actually are.

For me the addition of a grouping by 'Folder' or Project would be very helpful. Also the possibility of either customising the column that now shows the parent task or adding another column showing the project name would do the trick.

[Ward]

Earlier I wrote ...

Originally Posted by Ward

I'm getting ready to add the client name to each project name so that I can see the client in the Context view.

Well, I actually I wound up adding an abbreviated client prefix to a bunch of action groups (instead of projects).

Imagine my dismay to read this in the July 6 Message of the Day:

• The project column in Context view now shows an action's containing project rather than its containing group.

I'm not sure what I'm going to do now. As I've mentioned earlier, I do same work for most of my clients, which I've set up as FileMaker, Web & Mac projects. So now my Context view has numerous like-named-but-different projects.

I really hope the Context view eventually includes the ability to select ...

• Elements of the project hierarchy to display, e.g., folder, project, group, action, ..., leaf-action
• Display format, i.e., individual columns -or- path (e.g., "folder > project > action")

"Leaf-action" (lowest level action) seems essential. The other levels of the hierarchy could be optional, depending on the user's Project view scheme. In my case, I suspect that "folder > leaf-action" would be sufficient.

[submitted as formal feedback]

[BwanaZulia]

It sounds like you are putting too many things into the "Home" context.

A good rule is when a context gets to have 20-40 things break it up into another context.

For example. Let's say I have 20 things on my list for "Computer" but I start to get a lot of jobs doing graphic work so I create another context for "Photoshop" and offload all that work to that context. Later, as I do more Print and Web work, I create another called "ImageReady" and throw a bunch in there.

The same goes form "Email" and "Internet" as well as "Google" or "OmniGraffle" (yes I have one for OG).

The theory behind the context remains the same. It is a place or state at which you can do tasks and only those tasks which helps simplify the choosing of tasks when you are in that context.

BZ

[Ward]

Originally Posted by BwanaZulia

It sounds like you are putting too many things into the "Home" context.

A good rule is when a context gets to have 20-40 things break it up into another context. ...

Good point. I just split my "office" context into "office - clients" and "office - development".

I'm still left with situations where I have an ambiguous action description. Case in point: I have two "recommend Mac mini" actions in my "office - clients" context. The description was fine when I entered it in two different client projects in Project view. But I can't tell them apart in my Context view.