Command not suitable/optimized for fast typists

[nus-se-script]

Command abbreviations are not accepted at all in this application, but a few commands can be shortened to apply for their specified users. In the UG, it is specified that If you are a fast typer Then Connexion is for you

However, as a fast typist, common abbreviations should be accepted. i.e. for list, ls should be accepted. for longer commands like clearschedule, cs should be accepted as well.

---

_{[original: nus-cs2103-AY2324S1/pe-interim#525] [original labels: type.FeatureFlaw severity.VeryLow]}

[imkwokyong]

Team's Response

1. It is difficult to define "common abbreviations", as what the user thinks is common is most likely different from what the developer thinks is common. We then run into two issues : Either implement a series of hard-coded aliases with dubious value to be gained, or add a system to add user-defined aliases.

With regards to the first :

1. In addition to having to second-guess what the user would expect as a "good" alias, there would be some dev overhead in tweaking the class structures to recognize multiple command words.
2. This would result in some amount of User Guide clutter, especially as :
3. It is very possible that some aliases assigned might end up making it easy to confuse commands for each other or obfuscating their semantic meaning.
4. The user guide would have to emphasise aliases in addition to the full name
5. This feature would only best benefit a subset of more experienced users.
6. Together, we believe the value proposition of adding more features to add more utility to all prospective users, an approach we have adopted, outweighs the value proposition of adding an alias system to benefit only some users, and to a dubious degree at that.
7. Hence, we believe this is of a lower priority and can be delayed to future iterations.

With regards to the second :

2. A way to mitigate some of the problems above is to let the user define the abbreviations themselves, but this requires a new feature which takes even greater effort.
3. The utility from this system still disproportionately targets a subset of users rather than all prospective users.
4. A general system to allow self-defined abbreviation is of less priority and can be delayed till future iterations.

Thus, we mark this report with response.NotInScope.

Duplicate status (if any):

--