Open jellywaiyan opened 9 months ago
Our application already has the functionality to address the scenario you described.
You are able to create a done task and track it. Just use the addTask command then use the markTask command to mark it as done.
Like Google Tasks, our application defaults newly added tasks to an 'undone' status, streamlining the task creation process. This design choice keeps the process intuitive and straightforward, catering to a broad range of users.
While we understand that having an optional status field might seem like a more direct solution, However, adding an extra optional field in addTask will overcomplicate the command in adding a task and reduce the user experience.
We believe that the current method, which involves adding a task and then marking it as done, strikes the right balance between functionality and simplicity. It allows users to manage their tasks effectively without the need for additional fields that could complicate the process.
Team chose [response.NotInScope
]
Reason for disagreement: Thanks for the response! While your product does address the scenario, I still don't see the need to exclude it as an optional parameter, as the command is already very short and simple (with only 1 optional parameter which is the tag, and 2 parameters which are just the title and note). I would argue that having this optional field as an option is faster and more efficient than adding the task, then having to find it on the task list, and then marking it as done. (eg (addTask)at T/Example task n/example note t/example tag s/done). It can be further made efficient with short forms, which would be consistent with your current implementations, and you can do s/d if done.
(A realistic example would be having >5 or >10 tasks, where the next task added cannot be seen in the task list unless you scroll down or do findTask, which wastes time and is not CLI friendly)
I would say that it's not a must for this optional parameter to be included, however, your reasoning for excluding it is arguable (saying that it is easier to do it in 2 steps rather than 1).
As for the overcomplication of the command, I would say that it would still be very easy to understand for users if the optional parameter was included (since they also have to take note of a command to mark it which changes the status from undone to done). addPerson in your app has 5 parameters, so I do feel that having this optional parameter for addTask would not reduce user experience.
There may be times where we would want to track tasks which have been done, but not over yet (eg assignments due in a few days which we have completed but still want to track) Having an optional status field would save the hassle of adding the task then marking in in my opinion.