search

bharathcs / pe

0 stars 0 forks source link

Case sensitivity in tags / value #9

Open bharathcs opened 2 years ago

bharathcs commented 2 years ago

Searching filter -t ProductA yields results, but filter -t producta does not. This is a very common use case and expected to be handled by the application.

Same with filter -t Assignee:Mel vs filter -t Assignee:mel if such entries exist. A user may walk away expecting nothing was assigned to her. Unacceptable in this case. They should be insensitive to safeguard against such user error (or warned)

This is even worse when considering you can create tags with 'mel' and 'Mel' and result in this.

nus-pe-bot commented 2 years ago

Team's Response

This is clearly specified in the User Guide with no room for error whatsoever. Also, there are valid use cases when tags should be case-sensitive and we want to give users the flexibility of tagging. Therefore, this is not a feature flaw either.

image.png

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I understand that your UG has stated it quite clearly that this is expected behaviour, and I do not contest that. This is why it is a feature flaw. I believe the case sensitive nature of tags is not useful and not a beneficial part of the value proposition for the users of this application. You mentioned there are valid use cases, but I note you have not actually offered any such example.

Instead, I believe this hinders the use of the application as it is an overzealously rigid way to handle tagging, particularly when use cases where you want to answer questions like "checking who has what task assigned to them" should be as simple as possible and should not allow for a frighteningly simple user error like using the wrong case.

Given that such questions are a core part of the user experience, whether they are supervisors or telemarketers, this does feel like it should not be rejected.

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.High]

Reason for disagreement: The team seems to think that this is feature flow is of low value to the user. However, I must respectfully disagree. I do believe this is a major use case for the users of this application (even if you did miss that out in the Use Cases section of your DG).

A supervisor will often try to keep tabs on the workload of her team, and will want to quickly pull up such details. A telemarketer will need to check on the remaining / completed tasks. In all these circumstances, such a case sensitivity presents a rather high and commonly encountered hindrance to the user workflow.

Perhaps I am clumsy, but I myself accidentally typed the wrong case multiple times when trying to test out this feature, and then it had dawned on me that most users would similarly be terribly frustrated with this behaviour. This would be a tremednously useful feature if it had this, and I really do think it is a major and severe feature flaw.