soc-pe-bot
commented
11 months ago Team's Response
Currently, the command words are designed such that the command words themselves are intuitive to the user (e.g. addContactEvent is self-explanatory to the user that it adds an event to the contact), so that they will not have to consistently reference the UG to look up what the command does. As such, shortening the command word carelessly might take away the intuitive nature of our command words, which we believe outweighs the benefits of typing a few less letters. While we believe that there might possibly be room for improving upon the command words, it is an optimisation that is of lower priority compared to implementing the features for v1.4.0 as our target users are fast typists, so a few extra letters would not be severely inconvenient for them.
On the other hand, if your suggestion is to add additional commands with shorter command words as an alternative to the current existing ones, that would be a quality of life feature that we plan to implement in the future after the higher priority features are already added. In fact, we already have one such planned, mentioned in the DG:
Nonetheless, we appreciate you for your suggestion and we will certainly try to implement command aliasing in a future iteration.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: > As such, shortening the command word carelessly might take away the intuitive nature of our command words, which we believe outweighs the benefits of typing a few less letters.
The issue is on providing aliases. You can still have the normal form of the command where users type out everything painfully AND you can also have shortened variations for each command. They are not mutually exclusive. As such, weighing of benefits is not relevant here since you can incorporate both types of commands.
In fact, we already have one such planned, mentioned in the DG:
Is one command even sufficient to satisfy the constraints of the project for fast typer. Are you insinuating this will be the most used command by the users? It would not require much effort to simply add a shortened command i.e. alias for every command. As such, it is not proven to be out of scope.
It is an optimisation that is of lower priority compared to implementing the features for v1.4.0 as our target users are fast typists, so a few extra letters would not be severely inconvenient for them.
Just because you can do things faster does not mean it will not be inconvenient to you. The inconvenience is still present for everyone. As a product for fast typist, I would want to type even faster. Typing fewer characters and words would imply a faster typing speed.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** The team attempts to justify that it is out of scope, but does not justify properly as to the lowered severity. In fact, this would have been medium-high since your target users would have been fast typers. Having to type out the long unshortened form for each command is an inherent flaw that causes inconvenience to most users but they can continue to use the product. By course guidelines, i should then pick medium since it is in between 2 severities.
This application does not support any form of aliasing of commands which can make typing out the full commands extremely tiring. Thus, it does not fulfill the constraint of supporting fast typers. Adding shortened commands is relatively trivial as it is essentially the same logic just with different command word. As such, this is of medium-high severity as all users will be impacted severely by this inconvenience.