As I said before, I am willing to bet your example below, and any example of a project not auto starting being the desired effect is, in fact, a minority. Your statement about being different than a business project actually supports the argument for making this behavior automatic (in addition to it simply being intuitive), as business projects have many stakeholders and project start status is specifically relevant; personal use, not so much. With that said (it doesn't matter so much), and the intuitive default would be that a project has started once work on it has begun, the default should be for this expected behavior. The cramped settings thing is a non-starter since it would only be a relevant setting to a very small group of users, or an even smaller group of situations in which it's counter-intuitiveness would need to be disabled.
You are arguing for an outlier example for an outlier group of users. I don't know why this small group of people and use cases is a hill worth dying on when the vast majority would expect and welcome this. It simply means LESS clicking for the larger group of users. Why is this not the goal of the organization? On Friday, May 4, 2018 at 9:26:59 PM UTC-7, Domas wrote: > > Hi, > well, I think MLO positions itself as a personal task management solution > and not a professional project management software. > In these terms, the "Project" in MLO means quite a different thing than a > usual business project. The most prominent use case is GTD system, which > defines a project as "any task, which requires more than one step". > In this sense, I can easily see how I would want to see the project "Not > started", even if few tasks are already complete. Perhaps I would want to > have few preparation tasks at the beginning of the project. For example, if > my project would be "buy a car", maybe I would want to complete few things > like, "decide do I need a car" or "look for options", but still don't have > a project as "Started". > If the project is just a list of tasks and not a business project with > clear definition, then the "Project status" property becomes just one more > property of this item, which you can set up in any way you want, depending > on your productivity system. > > Of course, I would agree that it would be good to have a possibility to > turn this automatic function on and off. But that would mean one more > setting in a already cramped settings window, and of course, some cost for > its implementation. I assume that the developers decided that it's not > worth it. > > Regards, > Domas > > On Friday, May 4, 2018 at 8:16:56 PM UTC+3, cirrob wrote: >> >> I don't see that. If you have a project, with subtasks, that means those >> subtasks are part of the project. And if you complete a subtask on a >> project, the project has started because work on it has started, ergo the >> default should be to the behavior I described. >> >> But I'll humor you: let's say that there are some use cases where this >> behavior would not be the norm. Fine... but I think we can all agree, >> those would be outliers; the exception, not the rule. So, in an effort to >> accommodate the masses from several more clicks, we should pander to the >> normal use case rather than the exception and make it the default behavior >> as to inconvenience the least amount of users, and for those VERY few users >> who do not need this normal and expected behavior, they can turn it off; >> not the other way around and the majority can turn it on.... in what world >> does that make sense? >> >> Yes, the app is being flexible. But there is a line which has clearly >> been crossed in this one workflow that goes against the normal use and >> expected behavior. >> >> Just ask anyone when a project has begun: Is it when work has begun on >> the project or some other time after that? The answer will almost always >> be, "When work has been done on the project." So why not accommodate the >> majority, and most logical use case, with the option to turn it off for the >> extremely rare instance when this would not be the acceptable and desired >> behavior. >> >> On Monday, April 16, 2018 at 12:57:04 AM UTC-7, Domas wrote: >>> >>> Hi, >>> But there definitely could be cases where this is the required >>> behaviour. >>> So it is set up so that the user can decide himself on project status. >>> I find it reasonable. >> >> -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/mylifeorganized. To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/b6c406dd-f044-4bf3-bb05-9f12fc83b9e3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
