Though I already have a brief explanation in the documentation why Tasks Pro™ and Tasks don’t have categories, I still get e-mails from people asking about categories. In the future, I will point those people to this post. 🙂
First, a brief definition: categories are containers that you put things into. They are used to organize and group things together (and apart from each other as well). With categories, there is already an expected behavior because many systems use them.
Categories are a primary organization method, so is the task hierarchy. Making them work together isn’t so simple. The hierarchy is the primary interface, it is the core of the system and won’t be changed. With this as a base, the question is “how do categories work with the hierarchy”?
Most people ask for a drop down at the top that will allow them to change categories, with another drop down on the task edit screen to allow them to select a category for each task. Seems simple right?
Consider this situation:
- Task A (Category 1)
- Task B (Category 1)
- Task C (Category 2)
- Task D (Category 1)
- Task E (Category 1)
- Task F (Category 3)
How would this collection of tasks be displayed in the hierarchy plus category model? Let’s say the user clicks on the Home screen and chooses ‘Category 1’ from the category list:
- Task A is displayed.
- Task B is displayed under Task A.
- Task C is not displayed because it is not in Category 1.
- Task D – well, here we have a problem. We want to show Task D because it is in Category 1, but the parent task (Task C) isn’t visible.
- Task E is displayed.
- Task F is not displayed.
Now let’s say the user selects Category 2 from the category list:
- Task A is not displayed.
- Task B is not displayed.
- Task C now has the same problem that Task D had previously; the right category but a parent that isn’t shown.
- Task E is not displayed.
- Task F is not displayed.
The problem is that the categories and the hierarchy are both primary organizational elements; they can easily conflict and one has to win. In the case of Tasks, the hierarchy will always win because it is designed to be a hierarchical system. This leads to inconsistent behavior regarding the categories. Inconsistent behavior is bad; it is confusing to users. It makes it harder for the user to easily grasp the concepts and rules that the software is using.
Some people have suggested a behavior where Task C would be promoted to the top level when Category 2 was selected. This type of behavior is very complex and not easily understood by just using the software. Complex behavior is bad for the same reason inconsistent behavior is bad, it makes the software hard to use.
If we put aside the complexities and problems the hierarchy and categories present when used in concert with each other, I’m still unsure what benefit you’d gain from categories. Again, the desired usage of a category (selecting the category from a list and showing those tasks) is already accomplished by the hierarchy. Set up your top level tasks as the “categories” you want, then use the “Jump to…” menu to move between them. If you want to see a list view of tasks in that “category”, do a search with the ID of the top level task in the “Search Under” field (you can even bookmark these search results to access them quickly if you want).
One great benefit of the hierarchy is that you can automatically create “sub-categories” at will just by the organization of your tasks in the hierarchy. If you decide that a certain sub-category is better suited for a difference category (say you want to move the “Backup Computer” tree from “Home Office” to a “Weekly Maintenance”), all you have to do it choose the new parent for that task and the entire tree is moved. You need to spend any time maintaining categories. You don’t need to go into the admin interface and choose to remove a sub-category from one category and add it to another (and move all the tasks); or add another top level category before you go to create the task for it.
Hierarchical organization and categorical organization are both methodologies for organizing your data. I’ve chosen hierarchical organization as the primary method that Tasks uses. Like all decisions, this opens up certain possibilities and closes off others. If you don’t want a system that uses hierarchical organization as the primary organizational method, Tasks Pro™ and Tasks probably aren’t the best systems for you. There is no point in fighting the nature of the system; especially when there are many task management systems you can choose from that use categorical organization.
Note: Labels and keywords are very different than categories. Labels and keywords do not have the containing properties that a category does.
This post is part of the project: Tasks Pro™. View the project timeline for more context on this post.
I was confused at first as well [as you probably remember ;)], but I found that my problems with the hierarchy system that wanted me to start with categories always, always, always stemmed from ill definition of the actual hierarchy and the task at hand.
Okay, so I shouldn’t post comments after putting in a twelve-hour workday.
I often found myself wanting a category for a task, but a category just isn’t worth it. If you have a task that you think needs a category and a hierarchy, the chances are that you have a task that is actually many tasks rolled into one.
Every category I would want to create is a label or a keyword. So where do labels and keywords come in relation to TP development?
And since I would primarily want labels and keywords to report on them, I bet you’ll say part of the reporting rollout. 🙂
It’s very important to me to keep the system streamlined and quick to use to enter information. The more fields and such that need to be entered, the slower it is to use a system.
That said, reporting will be bringing a number of major changes; including new data that should be useful in the reports.
Categories, or some field like that would make your application more friendly to those of us who are using David Allen’s “Getting things done” method of productivity. GTD is very much task driven, and even calls for the development of projects (tasks with subtasks). The point of difference is that GTD places all tasks into “context”. This means that each task is assigned a particular focal point, typically using focal points such as @work, @home, @phone, @anywhere. The (at)work, etc, lets you complete a given task at a particular location, maximizing your use of time across many “contexts” that you find yourself in throughout the day.
I’ve been testing the demo of your application, and find it to be very useful, and extremely simple. Adding a field to allow for these contexts, or categories, would be very useful for the growing number of GTD users.
Well, you can see the problems explained above with categories. If you have a solution to those problems, I’d love to hear it.
A not-so-elegant solution would be to create top level tasks for each “category”.
Labels may well appear in a future release.
I can’t really offer any new approach, and generally agree with your comments on the category concept as you state it. I think that Labels may well take care of this issue, as all we (the GTD community) would be looking for is a place where the context could be standardized. A field labeled as “Subtitle” right next to the title would do just fine.
A workaround is to place the context inside the note, and then search by context (ex: @home, @work). While this works, the ability to quick sort on a field would be extremely useful.
This page has been linkdumped
Sascha Carlin thought this page could be useful, so he sent it to his linkdump.
This is interesting. It is something I’ve been thinking a lot about, especially since I’ve starting using more non-hierarchical systems such as: gmail, del.icio.us, and flickr, all of which use “tags” or “labels” instead of categories. The main advantage is that a single item can be stored in multiple places by assigning multiple tags. It is also nice for collaborative work because it is easy for different people to assign the same tag to items. My use of Tasks rarely divides things up into many subtasks. I basically use the hierarchy as a means of labeling/categorizing things. All “work” related tasks are sub-tasks of “work”, etc. So I think that I would actually prefer something that worked along these lines, rather than in a strict hierarchy. But I understand that tasks is already the way it is and that it would be difficult to implement both systems together. This also came up in the discussion forums for HogBay Notebook which is an OS X note collection/outlining app. I’m used to working with Tasks as it is, but I do think it is interesting to notice that non-hierarchical systems are gaining increased popularity. When the web first came out I used Yahoo all the time, now I can’t even remember the last time I used Yahoo to search for something!
Yahoo search has actually become quite relevant these days. 🙂
Perhaps a resolution, then is to utilize a ‘dead’ task approach. A great example is vBulletin. You can add a forum but make it so that it’s ‘dead’… no one can add comments, reply, etc. BUT you can have ‘live’ forums underneath it where people can post.
Your main tasks could be your categories, with subtasks organized underneath them. The programmatic changes would be that you do not have to assign someone to it, set a due date, etc.
Just a thought!
Doug
PS: Nice product… but I need categories!
This is what many people use a Sticky task for.
Yes, I should have made it clear that I am using “sticky” tasks for this purpose.
Isn’t the reason that Yahoo search results are more relevant because they’ve moved away from a solely hierarchical paradigm?
For me, a category is a primary organization…. the hierarchy design is also primary, but what’s underneath the top of the hierarchy is secondary organization. In other words, why not make categories only apply to top-level tasks?
That would allow me to group tasks into “pools” (or categories”), for example, there would be a group of work tasks and a group of family tasks.
Of course, this ignores your example (specifically that Task C can have category 2). To me, your example doesn’t make much sense in the real world. Why would a sub-task be of a different category than its parent?
I don’t think limiting the category feature to top-level tasks would be considered a limitation or a confusing factor in the system.
Based on what you’ve written, you’d be surprised at many of the requests I get. Quite often people request the ability to have tasks in different categories within the same branch of the hierarchy.
However the biggest problem with your suggestion is what to do when tasks get moved around. A sub-task can become a top level task and vice-versa – what happens to categories attached to those tasks?
I believe a feature I plan to implement in the future may meet some of these needs.
You emphasize the distinction between “categories” and “labels”. While he uses the “category” feature in Microsoft Outlook, what David Allen means is your “label”. You need exactly one additional field, call it “label” if you like, and the ability to filter (rather than search) on the “label” field. Thanks.
I agree with Bob – what seems to be needed is a field called Label and a function to fiter based on Label.
Just to add some new eggs to the batter.
We are using (to some early success) tasks pro for organizing our software development projects (among other things). The heirarchical nature of tasks pro fits well:
We have a sticky task for each project (say joesPlugin). The following structure is present in each project (all sticky tasks):
joesPlugin
– bugs
– features
– 1.0
— bugs
— features
– 2.0
— bugs
— features
When some new bug is discovered or feature is invented it goes into the global feature/bug task (as a sub-task). When we figure out in which version the feature/bug will be dealt with we move it to the appropriate task.
All is good and right in the world.
Until I want a list of *every* bug in *every* project. Then I’m stuck.
I’m assuming that what you describe as ‘labels’ and ‘reporting’ will allow me to do such things. I just though I’d describe our system for you to give you our perspective.
I agree with M. King : categories and hierarchy can’t live together, because of level conflicts.
I’m just testing Task-Jr and had a look at the comparison chart too… and I’m sure that most people would be satisfied with a “first level category” only, eg :
– imagine you have “Office”, “Writings”, “Music”… in the left column, each of them “linked” to a different table (same structure) of the database. You would be able this way to have these different “categories” (with a different background for example) and the feeling that you work in one category at a time (not the case when you only have that hierarchy look).
I think this would be a rather easy solution to develop (keeping the actual basis), and it would fulfill the requests of many people 🙂
You may say it’s silly, because these categories could just be upper tasks.
But the idea is that it should feel like working on different files (I used OmniOutliner with 1 file named Music, 1 file named Writings…), each one having a dedicated page, so that it’s clear and not mixed with the others.
Maybe a homepage could show categories only.
What’s more, “Writings” do not need to have a priority level : it’s just a title.
😉 Bye
All you need to do is click on each top level task and you get the view you want.