Not picking up on prefix due to unconstrained nature of major field

[javierng2knus]

Is it possible due to the unconstrained nature of the major field to miss out on other fields such as tag. The detection is done through white spaces so addstu n/A p/123 m/mymajor t/mytag e/a@f.com nn/E0123459 works.

However with other languages, the white space could be ignored: addstu n/A p/123 m/mymajor　t/mytag e/a@f.com nn/E0123459

Low severity as it can be explicitly stated in the UG or DG that the product is meant for a standard English keyboard.

[nus-se-bot]

Team's Response

In our UG, we have stated that Prefixes must have a space in front of them. The character that you have given is a Ideographic Space (U+3000), and not a Space (U+0020).

Strictly speaking, the prefix t/ does not have a space (U+0020) in front of it in your example.

Additionally, I believe that the character U+3000 is a problem caused by extreme user behaviour, as typical users would not use the U+3000 key when inputting a space, so it should not be considered a bug. The reason why typical users would not use the U+3000 key, is because of the need to switch keyboard layouts when typing. As the rest of the input text has to be English, such as the prefix and command word, a user would have to switch keyboard layouts intentionally to input U+3000, or paste U+3000 on purpose.

If the user is accidentally in such non-english language, they cannot type english characters easily, while remaining in that non-english keyboard layout (because it would automatically switch back to english if you continue typing english), because of the autocompletion by keyboard layout software they have, they would have to scroll through all the options provided in the autocompletion to get the english text.

So they would switch back to an english keyboard. It is unlikely that they would accidentally switch to a non-english keyboard in the middle of typing, although possible, because this means more keypresses.

So, a user would only input U+3000, only if they want major to be represented in another keyboard language, such as Chinese/Japanese/Korean. We believe that it is much more inconvenient for a user to determine what the actual translation of that major name is in that language and typing it out (as NUS webpages are in English), rather than just using the english name. This falls under extreme user behaviour, so it is not a bug.

Suppose google translate is used or by default, thus translating those languages, so that majors are in Chinese/Japanese/Korean on the website, then a user reading our user guide would still see in the examples (inside the codeblocks) that they are still in English, so would assume that only English should be used inside a command, so a typical user would use only english in the commands.

In all other cases, I believe it falls under extreme user behaviour, as only non-typical users would use non-english characters in the command, when the command format is in English, and also when English is the main language used in CS courses in NUS

Hence we will put not in scope for this issue, since we could indeed improve the validation checking for spaces to handle this situation, as the value it adds is very low as it only impacts a subset of users that uses alternative keyboard layouts.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---