[iNik]

Option 1: Have on context, "Computer", and be done with it.

Option 2: Consider when mode switches are significant.

Perhaps have a context for certain servers that require regular maintenance. So when I remote into "application server 1", I have a list of things it needs (e.g. virus update, clean up temp files, add blah blah blah to security list, open new file share, etc.) that I can just run right through. Since a lot of this stuff isn't terribly time-sensitive, it's okay if it stacks up a bit.

What about time-based contexts? You could have an "After hours" context for everything that needs to be done outside of regular working hours (system updates/reboots, backups, etc.) Meantime, your "manager" tasks could be broken up as during the workday (when your directs are available) and after workday (bureaucracy, paper shuffling, etc.)

As you point out, certain applications have some overhead or individually represent a mode switch. Certainly "Design" might represent Photoshop, Indesign, etc., but can be grouped together since those apps (and that mode of thought) all work together. Then a "Development" context contains those items that require detailed attention of a certain type and are best tackled when you can turn off the phone and email and concentrate for a few hours straight.

In the end, contexts are there so that you can focus on what's at hand and "crank widgets" by going from step to step and get things done without dithering over what to do.

With this sort of meta-categorization, you might find perspectives very useful so that you can zero in on a "Next actions at my office with my Mac" perspective, containing many contexts, and then pick one of those contexts to switch into by finding an important task within it.

(I have exactly such a context that I use each time I need to find something else to do -- i.e. when I stop cranking widgets)

Make sense?