Add description feature flaw?

[MorningLit]

Add description feature flaw?

[nus-se-bot]

Team's Response

We wanted to be uniform in our architecture when implementing our commands, this is so that we can maintain extensibility for our description commands.

Items for the Tester to Verify

❓ Issue response

Team chose [response.Rejected]

• I disagree

Reason for disagreement: Sorry, but I have to disagree. I am arguing from a fast typist point of view and I believe that these unnecessary prefixes if they could be removed, should be removed.
From my understanding of prefixes, the main reason why prefixes are used originally in the addressbook, was because the user had to type in long verbose commands of each type, and the prefixes exist to allow users to be flexible when inputting their long commands (such as add case t:hello s:active is equivalent to add case s:active t:hello).
However, for this situation, there is clearly no flexibility here. Thus, they should be removed for the sake of fast typists.
Not to mention but your entire project failed to account for users who are fast typists and there was no optimisation put in place for these users (some suggestions could be allowing prefixes of commands to be executed, eg. add c t:hello is equivalent to add case t:hello or the implementation of supporting smart-tab, where the users can type in the prefix of a command and then press tab, and the app would fill in the rest of the word with a valid command for the user)
I am also unsure what you meant by "maintain extensibility for our description commands." because, from my understanding, this is all handled by the individual distinct parser, not the individual commands.
Overall, after much reconsideration, I feel that this issue should be raised to a low or medium severity level, because it can cause much inconvenience to fast typists.

---