Team's Response

No details provided by team.

The 'Original' Bug

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

Screenshots under edit task not sufficient to show edits

Note from the teaching team: This bug was reported during the Part II (Evaluating Documents) stage of the PE. You may reject this bug if it is not related to the quality of documentation.

---

should include before -after comparison, similar problem for other edit features

---

_{[original: nus-cs2103-AY2122S1/pe-interim#5178] [original labels: severity.Low type.DocumentationBug]}

Their Response to the 'Original' Bug

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

The details for the edit task command and other edit commands are already specified in words above the screenshot. The missing screenshot does not affect the functionality of the UG as users can still use the command even without any of the screenshots.

Items for the Tester to Verify

❓ Issue duplicate status

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

• I disagree

Reason for disagreement: The original bug is lacking screenshots and the 'duplicate' one is not specifying which command is being executed in the screenshot. They are 2 different issues, and even for the different features in the UG. They can only be solved independently. As mentioned in the module website, bugs are duplicates if they CANNOT be solved independently.

❓ Issue severity

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

• I disagree

Reason for disagreement: 'Duplicate' bug #12: Ambiguity in which example command is being executed. There is no way for the user to validate that his application is following the expected behaviour since the user is clueless about which command was being executed in the screenshot. This affects the readability of the UG and is not just a cosmetic bug. I still feel that the severity should be Low.

For the original bug, #5178: since this is an edit command, there should be a corresponding before screenshot to show the users the state of the application before edit was executed. This would explicitly highlight to users the expected changes. As compared to only one screenshot, the user would not be able to notice any changes in the screenshot, this makes the insertion of that single screenshot pointless as it does not document any changes.


As mentioned in the module website, the lack of visuals and poor integration of visuals into explanation is a bug.

from pe.