nus-se-script
commented
1 year ago Team's Response
We do have a reason for allowing blank module names but not blank tags but we felt that it is not information that is essential to be included in the UG. This is because we feel that knowing or not knowing the reason does not hinder or aid the user in any way when it comes to using our application to fulfill their needs. If anything, including it might add more bloat to our UG and might just end up as information that our target user will ignore.
In case you are curious, our reason for allowing blank module names is because that is our way of allowing the user to not specify the module name should they feel there is no need to do so. Our application identifies modules uniquely via their module code and thus module names are not essential information that is required for the application to function. Here's a hypothetical scenario, user A commonly refers to his modules by their module code and doesn't bother to remember the names of his modules. When user A adds a module to the application, if he is forced to specify the module name, it'll likely feel like a hindrance.
Our reason for not allowing blank tags is because we feel having a blank tag is the same as not having a tag at all. Let's say a user wants to add a tag to a module, we are unable to come up with a scenario for why the user would want to add a blank tag to the module. Wouldn't it be the same as just not adding any tags to the module?
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: > Our reason for not allowing blank tags is because we feel having a blank tag is the same as not having a tag at all. Let's say a user wants to add a tag to a module, we are unable to come up with a scenario for why the user would want to add a blank tag to the module. Wouldn't it be the same as just not adding any tags to the module?
Agreed with this point, perhaps I may have mixed up the argument format with the explanation of the various fields. Indeed, if a user were to specify a tag in a command, it should not be left blank.
We do have a reason for allowing blank module names but not blank tags but we felt that it is not information that is essential to be included in the UG. This is because we feel that knowing or not knowing the reason does not hinder or aid the user in any way when it comes to using our application to fulfill their needs.
I will refute this point, as I disagree with their opinion that is information not essential in the UG. There should be a justification as to why a module name can be left blank, considering the module name is arguably the next important attribute after the module code. Especially if this is meant to be a tracker for module lectures, the user often will key in a module name when they add a module.
When user A adds a module to the application, if he is forced to specify the module name, it'll likely feel like a hindrance.
Since this is a command to add a module, the command would be used significantly less frequently, so adding a compulsory name field should not be a major inconvenience for users.
This issue has raised another feature flaw to whether a module name should be allowed to leave blank when adding a module, but it is not relevant to this discussion. Ultimately, a justification should be given in the UG as to why the module name can be left blank. In my opinion, the response the dev team has given is sufficient, and should have been included.
From argument format in UG:
There is no reason to justify why it can be blank/not blank. In fact, shouldn't module name be not allowed to be blank while tags can be blank?