nus-pe-script
commented
1 year ago Team's Response
class/ and exam/ are just 6 and 5 characters each respectively, which should not hinder the user's typing speed too much. On another note, if we make the prefixes c/ and e/, it might not be intuitive enough for the users to remember them as well. Both methods have their pros and cons, hence our team feels that this is not a valid issue.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Although class/ and exam/ are just a small number of characters, the developer guide states that the product scope involves managing about "about 60 to 100 students" which suggests that these parameters are used quite frequently as part of the addStudent command. The more characters the commands contain, the easier it is for the user to commit a typo. Furthermore, not accounting for the use of any edit commands or readding of students in the case of mistakes, the number of keypresses can add up and significantly invalidate the benefits of a CLI-based application, especially since it would be much faster in a spreadsheet, to simply add one single column header for class, and type the exam name only once in the column header followed by filling in the columns with data, as opposed to continuously typing class/1A and exam/CA1 50 ... for each command. On the other hand, I fail to see why c/ and e/ as parameter tags would not be intuitive, especially since the user is expected to type at least 60 of the same commands - it would be expected that they've at least gotten used to the command parameters by the 4th or 5th entry. Additionally, these parameter tags consist of the first letter of what they are supposed to represent and do not come into conflict with any other tags. With no documentation on the design considerations against using c/ and e/ instead, I am unable to determine why this should not be a valid issue, or at the very least, a valid alternative (response.NotInScope).
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: The team has not provided any reason for the downgrade in severity. The product scope involves managing about "about 60 to 100 students with varying needs". This means that at the bare minimum, users would have to input at least 60 addStudent commands with the full name of the arguments class/ and exam/, for a total of at least 120 words, not accounting for the use of any edit commands or readding of students in the case of mistakes. As such, I fail to see why it occurs in very "rare" situations as specified by severity.Low when these parameters are used by all users of the application, and quite frequently too. Although I have left it on medium severity as users can still use the application, the severity might even qualify for severity.High it affects all users, and can completely invalidate the benefits of a CLI-based application if a user feels they could more easily carry out their actions in a GUI application which doesn't require retyping the words exam and class, and can edit mistakes using the click of a button instead of typing out the full command.
Most of the arguments provided to the commands consist of one or more letters, or sometimes even the full words themselves in the case of
class/,exam/which can significantly slow down CLI users. Affects all users but the application can still be used.