nus-pe-bot
commented
3 years ago Team's Response
Thank you for your feedback. This is actually the expected behaviour of our app. All text inputs are treated as being case-sensitive except for the findC command.
At CoLAB, we believe our application should be as flexible as possible for users, especially given that they are command line users who likely expect a certain level of flexibility. This means that as far as possible we try not to unnecessarily add any constraints to their input. This is common not just in our app, but in other similar software as well. For example, in most unix based (or unix-like) OS's filenames are case sensitive, which means FILE, file and File are considered different files.
We do not believe that having projects with the same name but different case will be confusing to the user. As our target audience is students, we expect them to have between 1-7 projects (assuming that they overload, or have their own external projects). That is why our side panel is not optimised for many projects (though it can be scrolled if unable to display all projects). At one glance, users should be able to see all their projects in the side panel. This means that it is extremely unlikely that a user adds the same project with different name casing by accident.
On the other hand, there is a valid case for users to add projects with different casing. For example, using this app ourselves we have at times added temporary projects with the same name but different casing, as a quick way to differentiate the two. Since projects with long names might be truncated in the sidepanel, we find it more convenient to change casing rather than adding a number at the end.
It is also wrong to assume that a word with same spelling with different case means the same thing. For example, in the english language there is a class of words called Capitonyms who's word changes meaning depending on the case of the word.
We have rejected this issue and classed it as a very low severity bug, as firstly this does not affect the way users use the application or inconvenience them in any way, and secondly there are valid use cases where the user might want to use case to differentiate projects.
We have also classed this as a feature flaw rather than a functionality bug because the behaviour is the expected behaviour of the application. The tester is arguing that the feature should behave differently, not that the functionality of the feature has any issues.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I agree with the team that it is wrong to assume that a word with the same spelling in a different case means the same thing. What about "CS2103 pe" and "cs2103 PE"? Having such a design that the same task with different cases could lead to possible problems. The user could possibly add the same task twice into the system without getting notified that the task actually exists in the system already. It would lead to subsequent problems such as the user adding some tasks to the first project and some other tasks into the second project. In this case, it defeats the purpose of a flexible CLI application.
:question: Issue type
Team chose [type.FeatureFlaw]
Originally [type.FunctionalityBug]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
:question: Issue severity
Team chose [severity.VeryLow]
Originally [severity.High]
- [x] I disagree
Reason for disagreement: As mentioned, it may lead to subsequent problems for the user.
Issue description
The same project with case-insensitive names can be added multiple times without any error.
Steps to reproduce the issue
What's the expected result?
What's the actual result?