search

pzl111 / pe

0 stars 0 forks source link

Command error in UG is cut off #23

Open pzl111 opened 11 months ago

pzl111 commented 11 months ago

image.png

It is inconvenient that the user cannot see the entire error message in the UG, and needs to refer to the app. It goes against the UG constraint of being pdf friendly, it requires using the app to see the entire error message. Furthermore, it affects the reader understanding the error based on the UG alone, and is not simply cosmetic.

nus-se-bot commented 11 months ago

Team's Response

Thank you for the feedback. We have opted to classify this as VeryLow DocumentationBug and as Accepted for the following reason:

While it does affect the readability of the UG, the user can also experiment with the command directly in the application to view the same error message. The error message previewed in the UG is only for the purpose of illustrating what is the potential error. The UG is also available online where the area is scrollable as well. This is why we're proposing a VeryLow severity as this is primarily a cosmetic issue and does not influence the overall usage of our application.

Items for the Tester to Verify

:question: Issue severity

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

Reason for disagreement: The textbook mentions that "very low" severity should be used when it "doesn't affect usage":

image.png

When reading the command error, it is clearly missing information from the cutoff. Suppose the reader sees this, and would not know that it meant "Category". Furthermore, it cuts off at "index num", which would mean the reader firstly has to assume "num" is "number", but also would not know what that index number points to. It could be the overall list, the filtered list. Not knowing which list would mean the user doesn't know which transaction it belongs. Would this affect usage? I take it as so, since they would not know which transaction to refer to. Hence it leads to usage inconveniences, not just a cosmetic issue.