riccqi / pe

1 stars 0 forks source link

Editing of tasks will change their index order in the list #7

Open riccqi opened 2 years ago

riccqi commented 2 years ago

Similar to the problem with mark and unmark, the editTask command also will change the index of the tasks, which makes it confusing for users to view the before and after of the task they were editing.

I would expect the index to not update. This behaviour is also not documented in the user guide.


video:https://raw.githubusercontent.com/riccqi/pe/main/files/afe46374-122d-4703-b5c3-877fc7578111.mov

nus-pe-bot commented 1 year ago

Team's Response

No details provided by team.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Mark and unmark commands have undocumented sorting behaviour

When a user marks or unmarks a task, the task index automatically changes to the top of the task list. This is quite confusing behaviour, as a task previously with index 3 will now be index 1 right after executing a mark command.

This automatic sorting feature is also not explained in the User Guide, so I would have expected the task item to stay at the same index after the mark or unmark command. Users who are not aware of this sorting behaviour might find it disorienting to refer to any tasks because their indexes keep changing with every task that is marked or unmarked.


video:https://raw.githubusercontent.com/nus-cs2103-AY2223S1/pe/master/files/26ff686a-801b-4f7b-b1e9-2353aabe2065.mov


[original: nus-cs2103-AY2223S1/pe-interim#3688] [original labels: type.FeatureFlaw severity.Medium]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Response

  • It is documented

image.png

As shown in the UG, all task is sorted by deadline with the earliest deadline found at the top of the list. This is an expected behavior for our application. Since it is sorted at all times after every command, finding of task is simple as they are group according to the deadline.

However you have a valid point in saying that it might be disorientating but all of our task are still sorted according to the deadline so it will be easy to find. Hence I will propose to change the severity to low since it does not affect the normal operation of our application much as user can continue to use the application normally.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: [replace this with your explanation]


:question: Issue type

Team chose [type.FeatureFlaw] Originally [type.FunctionalityBug]

Reason for disagreement: [replace this with your explanation]


:question: Issue severity

Team chose [severity.Low] Originally [severity.Medium]

Reason for disagreement: > Since it is sorted at all times after every command

This is not stated in the UG, which only states the sorting behaviour in the listTasks section. Doing the sorting after EVERY command (even mark, addTask etc) is not mentioned.

I think this behaviour is very jarring because not only is it not documented properly in the proper sections, it also has caveats that are not mentioned, which made me confused as to how the sorting was being done. For example:

If 3 tasks have the same deadline, and you mark the 3rd task in the list as complete, it jumps up to the top of the list, even though the 3 tasks still have the same deadline. I would have expected the tasks to stay where they are on the list. This is not explained at all in the UG.

I also think it should be a medium, since marking, unmarking, and adding of tasks is a key feature that will be used very often. And this poorly documented and jarring behaviour will definitely affect user experience, hence the medium severity.