What personal GTD / To-Do services lack

I think many will agree that the main problem with most personal GTD / To-Do services is their inconvenience. In pursuit of the maximum functionality that would suit everyone, the developers are hanging many functions. But, starting from a certain moment, each new function does not lead to simplification of work, but to complication, since the loss of time for actions begins to exceed the benefits of using services.

About a year ago, I tried several services, and then settled on Workflowy. Three months later, I almost abandoned Workflowy and considered returning to paper recording. The reason was commonplace: realizing that this service, from the point of view of implementation, is closest to simple paper recording, I could not organize the system in such a way that there would be no problem of complication. And then I came across what many beginners probably came across: it is incredibly difficult to find a description of an adequate experience in using services. It is experience; success stories with details.

The problem of the absence of "experience stories" is dedicated to the post under the habrakat. If I get an invite, in the next post I will describe the experience of using Workflowy, why I wanted to leave, and what I’ve come to now.

Imagine buying a Swiss knife and don’t know how to use it. With it, you need to periodically open canned food, cut bread, open bottles of citro and fight off wild hedgehogs. Suppose that the tasks are not so linear, various options are possible for their convenience, they cannot be solved by simple exhaustive search, and there is no unique solution for each of the problems. Here is an analogy with a beginner starting to learn GTD and asking the basic question: “How exactly, with the help of this miracle tool, can I solve my problems and organize myself?”

It would seem that help is everywhere: both developers and users are ready to provide it. It’s annoying that in most cases their efforts are not aimed at beginners.

What the knife developer usually writes about:
  • "Hurrah! We are releasing a new model of knife. It’s twice as good as the previous model, and we also fixed the bug with the opening of the second longest blade. ”
  • “We added a plug to the case. How to get it, see the video. "


What users usually write about:
  • “There are seven different knives, here is their description and screenshots.” A little better: “I tried seven knives. The case of the fifth knife is blue, and the sixth does not open in rainy weather. ” Even better : “The second knife showed itself perfectly when opening the Citro. “This is most important to me, so I settled on it.”
  • “Ever since I bought this knife, I have twice advanced at work. I love you developers! ”
  • “The knife of the First knife factory integrates perfectly into the backpack from the First backpack factory”


Does this solve the beginner's questions? Does not solve. Even if he knows how to open a knife, he still does not understand how to cut bread. In the meantime, he will be bitten by wild hedgehogs several times. 5 user stories describing their approaches to cutting bread will be much more informative. Let 3 out of 5 stories be crooked, the fourth will be about cutting boards, and the fifth method will not please the user himself. Acquaintance with this experience in any case reduces the time spent on development. And developers get a unique monitoring tool, how they use the functions they invented.

I am by no means against the help that users and developers are now creating. On the contrary, it is mostly useful; but, unfortunately, it is often simply not enough to get comfortable with GTD.

Another important point for me. I believe that there are similar descriptions of experience on the net. But at the same time, they are drowning in the issuance of the first pages of search engines filled with "ordinary" articles by developers and users. There is probably no better solution than to collect such stories centrally directly on the developer's site.

PS In the text, GTD is used as a designation of a class of programs. This is not entirely correct, but, in my opinion, is consistent with common practice.

PPS I always advocate not to chew, but to give, as Zhvanetsky said, an extract. Whoever needs it will come home and dilute (he will look for additional information). The post is not about writing detailed instructions. On the contrary, it is normal for a person to indicate only the direction and limit himself to the basic principles.

Also popular now: