Interesting! I agree that complex priority systems are more effort than they help, and I also very rarely have a concept of "higher" priority. My use for the defer buttons is to make low-priority stuff go away. You're right, I could leave it on my front page, but if I know it's not going to happen today what's the cost of hitting +1? Our tags system is very limited at this point, and too impotent to make it into my workflow as it stands. If that were better, maybe I wouldn't use the defer buttons as much. On the other hand, it seems to me that the defer buttons are to tags what having nothing is to having a priority system: reduced complexity with minimal cost. Instead of trying to tag and categorize and fit everything into projects, I just hit +1 for anything I'm not doing today, and +7 for stuff that's not critical this week when I'm really busy.

GTD is a house of cards? I agree that it can be very easy to fall out of highly productive mode into an unproductive mess, but is that GTD's fault or natural tendencies? Not having a stinking pile of "todos" is my big take-away from David's book. Trusting my own intuition is also important. Using physical folders isn't. I believe Tracks should enforce good habits, but should it force One True Way? Where to draw the line is a tricky question, and one definitely worth discussing as we add more and more features.

On Oct 8, 2008, at 6:07 PM, Dieter Plaetinck wrote:

@Eric&Joseph: Well, in the gtd book David mentions several times that trying to get/store priorities in your gtd system is a waste of effort. Suppose that you're somewhere and you have free time and you want to pick a next action to do. In that case you should be able to filter all your next actions by selecting the context you're in and optionally by specifying tags/projects too. David mentions specifically several times in his book that you should then just look at the list and trust your own judgment in picking the task that is "the right task to do". Note that in the whole process, the concept of priorities is never entered into the system specifically, unlike many traditional approaches. You look at the list and you decide. No need to enter priorities first and then pick the one with the highest prio or whatever. If you follow gtd you just _know_ you've made the right choice

Sure, the list can get long and resorting to some priorities system will give you a way to not have to look to all of your next actions. (You can scan the high prio ones and don't look at the low prio ones). But why would that be a better system? Most of the 'high prio' things are only high prio because they need to happen before a specific date. in that case they belong in the tickler. Others are "high prio" because they are in a project that you want to/must finish. Well then.. put them in the project and focus on the project if you want to do the project. The other 'high prio' things are just things 'you would prefer to do as soon as possible', does that make the other next actions not work looking at? Any of them can become more important due to circumstances, so imho you should have the full list available. (In fact, the principle of 'constantly changing priorities' is one of the reasons gtd is designed the way it is designed) I think you can get away of using a priorities system by making good use of projects and tags. (even though a priorities system may look like something useful on first sight)
Unless I'm missing something here.  Feel free to correct me.


@Joseph: 'deferring to someday/maybe'? Sorry but that's really not gtd. 'Someday/Maybe' is about things you don't plan to do. (they are not actions!) You might do them sometime in the future, so you just dump them there and review the list every once in a while so you don't forget about them. You could convert them into next actions someday. If you feel like you need to do something like this, it seems to me like you made a mistake of putting this as a 'next action' in your next actions list, because apparently you have "next actions" that just are not next actions, but things you might do someday. If you have next actions that you just "don't want to think about for a couple of days", they probably belong in one or more projects/ tags, and then just don't look at those projects/tags if you don't want to do them. (this is where the "you can trust your own choice" part comes in)


Bottomline is: GTD can work great, but it's a concept as a whole. if you mis-implement one or more patterns the whole thing collapses down in an unproductive mess. The tricky part is that some of those "bad patterns" might make sense if done as only task management system, or as part of some other task management system, but _not_ in gtd.


Bottomline 2: We need a better way to filter the 'next actions' list, by enabling/disabling the view of one or more projects,contexts,tags and see the updated view in realtime.

Dieter


Joseph Method wrote:

I like/use them. There are things that I don't want to think about for
a couple of days. I actually wanted (or thought I wanted) a defer to
someday option, but I liked the +5 once I started using it. But it
also seems reasonable to defer to someday/maybe; it's not deferring
then, it's re-prioritizing.

On Tue, Oct 7, 2008 at 6:35 PM, Eric Allen <[EMAIL PROTECTED]> wrote:

It is definitely just moving actions to the tickler. I didn't realize how un-GTD my approach was until you brought it up. I guess my workflow has some optimization opportunity! That being the case, are the defer buttons a good
idea or should I revert them?
On Oct 5, 2008, at 1:23 PM, Dieter Plaetinck wrote:

Ok, I just realised your 're-deferring' approach is probably moving actions
to the tickler. (and not to someday/maybe, phew ;-)
But still my points remain. One should not re-defer because he doesn't want to do the action right now, one should only defer to the tickler if he is 100% sure he only needs/wants to do the action at that specific time. (or
later)
Otherwise you're moving actions around too much.
Dieter

Dieter Plaetinck wrote:

Eric Allen wrote:

Yeah, we are definitely starting to suffer from clutter in the
interface. I personally like packing as much as possible in, but I
suspect I'm in the minority. I'd like to avoid too much
customizability in the interface because then we become just another
SAP or something with wayy too many features.

Right now my biggest cognitive cost on the interface is evaluating
which tasks I can actually execute right now. That's my primary
motivation for the defer buttons: get stuff off the screen so I can
focus on what I can actually do.

This is imho not efficient - and not the way gtd recommends it, iirc. Too see what actions you can do at a given moment, you should be able to filter your list of next actions by specifying (a combination of) one or
more contexts / projects / tags.
That's it.
(The tracks interface currently doesn't really allow this right now though.
For more information see the 'menu reorganizing' mails. )
It has been a while since I read the book, but iirc all your next actions are essentially deferred, because you couldn't do them right away when you
thought of them or when you processed your inbox. (2-minute rule)
So if you're re-deferring tasks frequently just to get them out of your sight (and you need to do this again when they show up again, or you need to look them up again when you changed context), are you as effective as you
could be?
How do you 're-defer' a next-action anyway? Because in essence all
next-actions are already deferred.  Aren't you talking about the
'Someday/Maybe' bucket?  (That's conceptually very different then
deferring. It's about placing things you don't plan to do. You might do them sometime in the future, so you just review the list every once in a while so you don't forget about them but they are not in your way either)

Dieter


 Next on my list is task dependencies,
so you can have only the top task from a project showing, for example. I wonder if using alternating colors on the tasks or something else to
separate them visually would help.

On Oct 4, 2008, at 1:52 PM, Luis Villa wrote:



On Sat, Oct 4, 2008 at 1:33 PM, Eric Allen <[EMAIL PROTECTED]>
wrote:


Yeah, I pushed that to trunk before I came up with good
documentation. Those
are defer buttons that will push the show_from date out by 1 and 7
days
respectively. Would "Defer x days" be a descriptive enough alt text?


Yup, that would definitely be an improvement. Ideally if the UI has
that information it shouldn't need to be documented at all (no one
reads the docs anyway ;)

Note that generally I think each task line is really cluttered right
now- at this point every line in the table now has *9* pieces of
information associated with it:

[delete]
[edit]
[star]
[complete]
[overdue?]
[title]
[project]
[defer 1 day]
[defer 7 days]

Multiply that by a lot of tasks and that's a whole lot of information
in every screen. Having your eyes scan that much information every
time makes it harder to find the really important information- 'what
do I need to do next.'

I'm afraid I don't have any great suggestions on how to simplify right now- maybe put the less frequently used star/delete/defer buttons into
the edit box? But I'd definitely strongly recommend considering the
cognitive cost of all this clutter before adding anything more.

Thanks again to everyone- trunk looks great, and I'm looking forward
to playing with calendar and the email code-
Luis



On Oct 4, 2008, at 1:14 PM, Luis Villa wrote:



Like I said in the other question, I just upgraded to latest master.
There are now [+1][+7] buttons next to every action, but they've got
no alt text so I have no idea what they do :) They also don't seem
to
work consistently- I clicked it on one overdue action and it sent it
to the tickler, and clicked on another and (AFAICT) it changed the
due
date instead.

Can someone explain? :)

Luis
_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss




_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss




_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss







_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss

Reply via email to