nus-se-script
commented
2 years ago Team's Response
Overloading the sensory of the user can prove to be annoying and decrease readability. While we should predict the user's movement and activities, it should not be a case in which we are laying out every possible case scenario. It is more likely that after typing in an incorrect command, a beginner user would refer to the user guide for further instructions for all the possible flags, or an experienced user would realise that he forgotten to key in a flag, which he would then do after. It shouldnt be a case in which we should dish out the "how to use this command" error message after every error.
More importantly, all the information for the different flags are available in the User Guide.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I do not think catching missing parameters should be considered "laying out every possible case scenario".
I believe that the User Guide serves the purpose of giving an over-arching idea of what Networkers does (how it can value-add to the network technician's existing processes) and give an overview of the functions supported by the app.
Error messages should give enough of an explanation of an easily-caught and easily-made user mistake, which I think is a reasonable detail in this case.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
While the other command error messages indicate an example use of the command and more details regarding the parameters, the error message for
editProcjust states one line: "At least one field to edit must be provided".More details on the
costflag are given when the c/ flag is added, but the user may not even get to that stage when the error message before does not indicate details on the parameters and flags required to run the command.