I, like you suggested, had to invent some dummy locations for @pc, @phone etc. @work/home/cabin are physical locations and placed correctly.

I can't really tell if there are any advantages in this. I was surprised to learn that lots of people use tags for contexts. In some way it's easier not to have all tag info in the same field, but it's difficult to draw a sharp line between tags and location. Before, in the old days (before tagContains) it was easier to find tasks without a context. I require all my tasks to have a context but not necessarily a tag.

Thanks Rajjan. The one DISadvantage I just thought of was that if your contexts are locations, they don't show up in your tag cloud. That is the primary way I get to my context-based lists at this point. I don't have saved smartlists for each of them mainly because I can easily get to them via the tag cloud and in order to save the space on my already very wide set of list tabs!

Actually locations do show up in the tag cloud.

In many ways they behave as tags, maybe I should move from location-based contexts to tag-based? However, testing javascript entry of tasks, I find that locations are handled better than tags, with a listbox for selection.

Ah! That does make things easier, since theoretically you should only assign one context for each task. I suppose if you wanted the added flexibility and somehow figured a departure from strict GTD that allowed you more than one context per task, it would be better to put them into tags, but maybe I'll transfer them to locations now and see how that works...

Ok, I switched my context tags to locations and thought I'd give some additional impressions.

First of all, the locations do indeed get displayed in the tag cloud. Although for some reason my tag cloud deviders now overshoot the square box they used to be contained in. Also, only the locations for which there is a task assigned get displayed in the tag cloud. This is the same way as tags work, but what I'd done is created a fake task to contain all my contexts. I guess it's not a big deal. Theoretically I could create a fake task for each location, but I guess the main reason I did this was so that I'd be reminded what the various contexts were whether or not I actually had any tasks assigned with a given location, but with location you have that drop down list, so you don't need that reminder...

There's another advantage you didn't mention - you can capitalize the contexts and that capitalization will show up, which make them a little eaiser to read that the all-lowercase tags.

The one definite disadvantage, although probably a minor one, is that there is no option to get locations to show up next to a given task, which as of a few days ago you can now do with tags. This was a nice bonus because you could be looking at a list of tasks categorized by something else - say a project, and just with a quick glance could see which ones out of these were @phone. In other words, it was a nice way you could do a kind of secondary "sort" or "categorizing" or whatever.

It is nice to not have to crowd the tag list up with contexts and to have a dedicated spot for them...

I think that's it. I'm not sure, I'll have to think more about whether the one disadvantage is enough to counteract the advantages.

Personally, I have stuck to using physical locations in the location slot. The main benefit here is that I love the mapping feature! If I'm heading out the door to a certain part of town, I can quickly see geographically which other tasks are "on the way".

To keep things separate in the tag cloud, I use a "@" prefix for all locations, and "+" for all tags. Lists and "project" tags get no prefix.

I would *LOVE* to see different colors for tags/locations in the task cloud and on the list view. It would be nice to see locations on the list view too (different color please!).

Well, after just a couple of days I decided the one big disadvantage overshadowed the few small advantages so switched back to using tags for context.

Erik, I had thought about using location, but generally the only place where that really is useful is in my @errands tasks, and even then it's not THAT useful, but I'm trying it out. One question for you: perhaps you are not in a congested suburban area like me (Northern VA), but I find that for many of my errands, I have multiple locations that I can do something. Specifically certain types of shopping like food shopping, or getting light bulbs, or what not, there are many places I could get these things, and even if I stick to one specific store (Giant/Wholefoods/etc.), there are still multiple branches within a very short distance - some being closer to where I work, some closer to where I live, etc. So there's no real telling which one I would use. Any idea how to deal with such an issue?

I gave up on having multiple locations for errands for that very reason. Most errands can be done at several places - it became hard to choose after a while. Now I only have one @town, works well.

Also, I have a link on my mobile phone directly to the smart list which filters out all errands, rather convenient to be able to check that if I happen to be downtown with some time to spare.

You can find this mobile version list on http://m.rememberthemilk.com/lists/.

Raijjan, I'm experimenting now with actually having locations in addition to my general @errands context tag.

I did notice some odd/interesting things during this process:

1) locations don't show up in the cloud tag unless they start with '@'. Maybe there are other characters this holds true for as well, but for normal letters they don't.

2) When changing over all my context tags to locations, my tag cloud changed in an odd way - my divider tags suddenly appeared shorter so that I had to decrease their length. Then when I went back, the dividers are now too long. It's almost as if the location names, when inserted into the tag cloud, include additional spacing, or some extra (possibly invisible) characters?

Oops, I take back 1) above. I just didn't see it. Maybe I do need a new prefix though, to seperate out actual locations...