Command not suitable/optimized for fast typists

[jamz903]

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.

[nus-se-script]

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.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: What is defined as response.NotInScope:

lower priority than the work already done in v1.4

As I cannot determine what was done in v1.4 by your team, I will assume that this was indicated as NotInScope as you had other features that were higher in priority. However, I would like to explain here why I believe command aliases are important, and reply to some of your comments:

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.

To clarify, by common abbreviations I meant to use what is generally already convention (i.e. used by other apps/cmd), and as a mentioned example, that would be ls instead of list. What is common is to also use the first letter of commands that have multiple words (i.e. the other mentioned example, having cs instead of clearschedule). To be clear to users, you can construct a table that clearly states what abbreviations are used. This is commonly seen in other apps, and well documented by IBM

This would result in some amount of User Guide clutter, especially as :

1. 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.

2. The user guide would have to emphasise aliases in addition to the full name

3. This feature would only best benefit a subset of more experienced users.

I disagree with this. It is quite easy to document this clearly to the user, where in the UG under every command you can add a line where you include Command Words Accepted: list, ls which would be clear enough for users to understand. Since your target user is fast typists, this would most likely benefit your entire target group, as fast typists would definitely prefer shorter commands and would be able to use them as long as you document it in your UG. If it happens that your user did not spot the aliases in the documentation, then it would most likely be due to one of these two cases:

1. they used a shortcut they are used to that your application accepts. (good!)
2. they use the full command as they didn't know about the abbreviations (also good!)

Either way, it proves to be beneficial to implement this.

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.

The reason why I flagged this out as a feature flaw is because I believe that this is an important utility to all of your prospective users, and in particular to your target group. I personally think that not having command aliases in your application in particular undermines your value proposition, especially given that your commands also have multiple tags/prefixes that make the command usage long.

TLDR: I do agree that this isn't a big issue for users, and that is why I indicated it as a Severity.VeryLow bug. However, I do believe that this is a flaw of the application that should have been implemented early on to cater to the target user of the application, and should not have to be pushed to the next iteration.

View pt 4:

---