Quote:
|
Originally Posted by Paul
I do agree that Get the phone number is the next action, but for me it's a waste of time to write it down in the project list, since getting the number is almost as quick as planning to get the number.
|
Agreed on that. Especially if you use LaunchBar or Quicksilver. LaunchBar you can select the name, and hit a keystroke to paste the name & number into your system. Quicksilver is a couple more keystrokes but it is still quick. Not to mention, most of my calls are made by looking them up from my cell phone.
The only time I'll need to look up a number is a place I've never been and need to look it up on the internet.
Quote:
|
Originally Posted by Paul
Ethan's kGTD answer to your wanting not to see all your waiting-fors is to put start dates on them. Then they are not actionable and don't show in the context list until the start date. I think that's a simple, practical approach.
|
Now back to the "problem" of waiting for.
If you have 20 waiting for items, and one of them comes in... let's say a call from vendor B. How do you find it quickly?
If you go to your waiting for list, you can't see it. The item isn't set to appear for another week.
You could search for it in the outline, but what if you have multiple projects from that one vendor?
Quote:
|
Originally Posted by Paul
And of course your example was just an example. My answer was just an example of the principle as I see it: if there's a dependency, it's just a sequence. If you really need to document those to get them out of your head, you can add a "Start install-cool-software" task at the end of your install-Server-OS project. If your dependencies are really more complicated than that, you would need project management software that maps the graph of dependencies -- lists simply won't cut it in that case.
|
This is one thing I run into often, When does a project become it's own separate project. When one project depends on another part of another project to be completed first, do I move the entire project into the first project? It becomes extremely unwieldy and the projects quickly loose their boundaries.
I'm not sure why you are offering me solutions that I have already tried in this post. I'm not asking for help here, I'm trying to brainstorm on something I see as a weak point in GTD type software.
My hope is the OmniFocus software will develop software that will be a clear cut system. Not one that is extremely flexible for anyone to put their own system into. All the other GTD type software out there does that already, offering their users 'suggestions' for 'workarounds' to make the software work for them.
OmniFocus needs to be one thing... not try to be everything to everyone. But in being one thing, they need to think about all the issues that come up when working with a GTD system.
For example...
what if a piece of software had a way to have repeating appointments, but didn't think about all the different ways to repeat an appointment and only provided a user with... repeat daily, weekly, monthly.
Users would write in saying... I want something to repeat on Monday, Wed Fri.
And the software company would say, well... you can't do that with our software, here is the workaround. Create three repeating appointments that repeat every week.
My point is... the software company should have thought of that and created a way to repeat an appointment every week on whatever days they wanted.
kGTD is an inventive piece of software... especially because it used applescripts to tap into the outline. But it's far from unique in what it did. There are at least 5 other applications out there that have been doing the same thing for longer than kGTD.
But for some reason, all these applications fall short. Why is it the essence of GTD seems to fall through the cracks? GTD was designed on pieces of paper and started as lists of items on paper in different folders labeled with contexts. I don't want to go back to that. The essence of GTD is a good one.
But the computer can offer so much more. Why is it people are so afraid of moving forward? I guess one fear is the tool will become unwieldy and complex. It's one of my fears as well. But I still have the hope that the software can be developed elegantly, meeting the needs of the user without becoming burdensome.
And why is it, so many of these software companies that are so close to a GTD system, do not embrace the GTD system? I still haven't found one that embraces it. It's like they are afraid of people thinking they are a GTD application. And yet people are using GTD in their software.
If an application is too simple you become like basecamp, and it takes more work for a user to enter items into the software and be reminded what the item was for. Thus taxing the user.
If an application is too complex the user is entering too many fields or forced to use the mouse for every data entry. Thus taxing the user.
The purpose of GTD is to think, plan, and then do... crank on items. Not have to look at a list of 100 items and think... okay, what does this relate to? What do I have to do next with this item. Should this item be in this context?
Simple is good, but we do not strive for simplicity. Because simplicity is as much work as complex... we strive for
Elegance...
pleasingly ingenious and simple : the grand unified theory is compact and elegant in mathematical terms.