nus-pe-bot
commented
2 years ago Team's Response
Thanks for sharing your thoughts on this! We feel that there will be users like you who'd feel overwhelmed by all the information but there will also be users who'd possibly complain about the lack of details about all our commands if we were to remove such information. As such, its best to have the information there to make it explicitly clear than to not have it at all. Moreover, a detailed UG will help you avoid errors in your commands and accomodate easier troubleshooting as you'll know what went wrong and what commands are acceptable along with their parameters.
As such, we're rejecting this. Thanks for sharing though!
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I believe this is still a bug as it places the burden on the user to have to watch out for all these invalid cases that the app is unable to handle by himself. Especially if these invalid inputs are not rejected properly by the app itself (e.g. a previous bug that I posted saying how the program still accepts an input with duplicate dates by taking the first one). This means that the burden of avoiding these invalid inputs fall very heavily on the user if the app is not sufficiently defensive against these (such as the order of the separators and typing multiple identical separators may cause parsing of incorrect input). I believe that it is the responsibility of the developers to ensure the app rejects such incorrect inputs rather than telling the user to avoid them himself just because the app may parse things wrongly. Hence, while it is reasonable to some degree to inform users of the limitations of the app (such as the parameters it is using), I believe that the current list is too much.
:question: Issue severity
Team chose [severity.VeryLow]
Originally [severity.High]
- [x] I disagree
Reason for disagreement: Maybe more of medium severity, as having all these limitations written in the UG (and having the user be careful of following them) can pose quite significant inconvenience to the user of having to watch out for all these things all the time, all the more especially if the behaviour of the app is inconsistent with these invalid cases (e.g. typing multiple separators may sometimes cause incorrect parsing of input).
While I see why your team would want to include this section into the UG, I feel that it is too overwhelming especially for a first time user reading this UG to understand all the limitations and many restrictions in their text-based input. The user would probably figure out some of these errors along the way as he uses the product through error messages.
The UG as a whole was personally too complicated for a first time reader trying to test your product.