Quote:
Originally Posted by gshenaut
When red-flagging was implemented in OF in the early days, I'll bet there was a discussion among developers about whether to add multi-colored flags. Evidently, a decision was made to just have the single red one. Yet, if multi-colored flags (red orange yellow green blue purple gray) had been chosen, mimicking Apple Mail, and sort-by-flag sorted them as Mail does, with red as highest and gray as lowest flag value, I would have a further, multi-part bet: no one would now be asking to have that capability removed; many would just be using the highest priority red flag and none of the others, just as now; many others would use flag color to allow priority-tagging their tasks; and this entire discussion about whether or not to f*king *allow* people to prioritize tasks would not exist.
|
First, blatantly masked base language does not give power to your statment.
Further and in response to your assertions, I speculate flaging was a solution to the choosing priority actions from a condensed context list. I do not believe as an application born to assist in implementing the GTD method would have considered the use of multi-colored flags. However, in both of our cases we are unaware of the facts contributed to this decision. I do, however, disagree with your assertions of the importance of flag color prioritization especially within an application designed to assist users to implement the GTD method.
You posit your opinion on flagging and priority identification as a basic fuction for your workflow.
Quote:
Originally Posted by gshenaut
My world exists for the most part without specific time/date deadlines, yet there are clear priorities and overall, higher priority things have to get done before lower priority things. Just using the existing flagging mechanism is very good; without it, OF would be nearly useless for me. Adding the completely standard (in Mail) system of seven flag colors corresponding to priorities would make it even more useful.
|
It is a distinct difference that David Allen saw GTD as separate from traditional time management philosophies because it did not use a pre-determined priority system. The reliability of a priority based system breaks down upon adding new "important" tasks to the users immediate environment. (e.g. Priority one is now priority two). This is fine with a few actions, but as has been mentioned here of action numbers estimated in the 100's or 1000's, this does not equate to practical with making such adjustments across a vast number of actions. The use of the GTD system allows for priorities, but only once context, duration, and energy level have been determined and at that point only. If any of the variables change (e.g. context) then so does the priority and the old priority identification should be replaced by the current. The point is the context system makes for a more flexible system to identify priority at the moment.
I for one do not agree that tagging and multi-color flagging bring value to a GTD application. Others have opposing opinions and that is fine. Time management should be something that works for the individual. Even with this statement, if GTD or OmniFocus does not work for your specific workflow - why use it? I would rather you support an application which offers non-GTD features than asssert many users of a GTD application want non-GTD features. I for one do not want tagging or flagging taking up development resources for the Omni Group team, especially ones that go against the heart of David Allen's GTD method.
Linear Mode
