ThinkingRock Forum

I don't see the difference, some people are already using contexts for their agendas with people like @Wife.

I still stand by my assertion that if you go multiple contexts we should do hierarchical contexts, otherwise it would be rather repetitive to have to enter all the contexts something could be done in.. but having your contexts set up right you choose one and it's done for you.

my idea was to use tags similar to the categories in outlook, you could assign several different tags to one task. if multiple contexts are allowed in TR that would be probably much the same as tags/categories.
but many users might still prefer to keep the current context approach, the tagging would be just an additional option for users who want to have more fine grained sort&view of their tasks.

actually, if contexts are nested then it should also be possible for a context to be sub-context of more than one other context.

_________________
Andrey

After the reading of David Allen's GTD, I've been looking for some GTD tools this week. I found several, and TR was amongst them. Its Overview page was quite inviting. The other screenshots, on the other hand, were a bit intimidating. Nevertheless I gave it a try, and yes, TR 2.0 epsilon is impressive. I really appreciate the balance between completeness and simplicity, and I hope TR will never aspire to being as omnipotent as emacs.

Having said so, I do miss some features right from the first start. Slightly disappointing that I can't rearrange Contexts and Topics in their setup tables by moving rows to another location. But what's worse, I haven't found a convenient way to implement agendas ('Agenda Jan', 'Agenda Paul', 'Agenda Committee Meeting' and so on) as Contexts. There are a lot of them, and some would be temporary (i.e. the contractor building my new shed). Storing all these agendas in the Contexts table would produce a huge listbox of Contexts.

A full multi-level Contexts model (and ditto Topics model) is not a very attractive strategy, in my opinion. It's overkill and it would complicate things too much. But may I suggest these two additional Context attributes: a boolean Suspended field and a Group Name. They could relax the limitations of the present flat data model in a substantial way.

If the Suspended attribute of a Context is set, that Context can't be assigned anymore, because it will be filtered out of any listbox (except for an item that already has the Context concerned). The Context can be reactivated by clearing Suspended.

A Group Name is just a preferably self-explaining (but that's up to the user) string that identifies a Contexts group. That's all. There is no setup table for groups, and it's impossible to create a group of groups. Contexts with a non-empty Group Name will be suppressed in the listbox, only their Group Names will be presented (every Group Name once, of course). When the user selects a Group Name, a second listbox with its group members pops up.

That will keep the Context listboxes handy-sized. The enabling of these two attributes could be configuration options. A disabled attribute means: it isn't visible in the setup table (but its value is preserved in the database) and it is ignored by the UI (no filtering or two-stage selecting in the corresponding listboxes).

Same mechanism for the Topics (but I don't think I'll ever need the grouping).

I'm looking forward for any comment on these ideas. And maybe there's a workaround for my agendas problem?