Tag search only matches full words

[gavingoh99]

Currently, tag search has been implemented to only match full words e.g dis will not match disabled

However, this could add to difficulties in finding certain clients when the tags are more complicated words. schizophrenia is a relatively complex word which might present in some clients that social workers work with. In this case, if the user intends to search for the client that had been tagged with schizophrenia previously, they would need to be able to spell the word exactly and with precision. Such complex words may not come as easy to all users and more time could be needed to search up the exact spelling before the search by tag is successful.

This in turn impedes users who may be fast at typing but may not be as familiar or strong in their spelling.

Steps to reproduce:

1. edit 1 --tags=schizophrenic
2. find-tag schiz

Resultant output:

[nus-pe-bot]

Team's Response

For users who may not be as familiar or strong in their spelling, they can tag this client as "schiz" if they find "schizophrenia" difficult to spell.

Then, they can search for this client by typing "find-tag schiz".

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: Thanks for the response and providing a workaround!

I refer to the workaround provided by the team. In order to allow users to fully utilize the method, they are recommended, according to what has been suggested in your response, to include a short form of the condition for instance.

I see two possible problems from this:

1. Loss of information: while schizophrenia is admittedly a condition with a relatively unique and unambiguous spelling, there could be other conditions like diarrhoea, diabetes and dizziness which all start with the prefix di, so if a user were to be bad at spelling and chose to store these prefixes, it could be inherently difficult to re-obtain the information to be used to fill up document details for the client for instance.

2. The workaround is basically a substring search: it seems that the workaround encourages users to store a shorter form of the word that is easier for them to spell. But isn't this the same as asking the users to store a substring to then search by? In my opinion, the workaround feels like a substring search with extra steps. Given that the solution provided is for the user to follow a specific sequence of steps to fully utilize the feature, it does feel like the search by tag function is 'incomplete', hence why I feel it warrants a FeatureFlaw

---

## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I refer to the information provided in the course website:  Classifying the report as `severity.VeryLow` implies that it is mostly a cosmetic / UI issue which I have to disagree with. Social workers tend to work with clients facing potentially a variety of medical conditions which are inherently complicated terms. Given their day-to-day tasks, they are likely to look to leverage on the search by tag feature to swiftly access clients whom they may only remember by conditions as specified by their tags. In the initial report, I noted that searching by tag is inherently difficult because of the lack of substring search. The team's suggested workaround is for the users to store substrings on their end - as above, I note that this can create ambiguity for conditions that may share similar prefixes and result in some confusion when attempting to restore the initial information. Additionally, making the users store the substring instead of implementing a substring search only adds to the difficulty in fully utilizing the feature as-is! A logical response from the team could be to store the condition in the notes instead, but I further note that SWEE only allows one note per client. The `edit` command also makes editing of the note field prohibitively difficult since it replaces the note field with the provided argument - necessitating copying the entire existing note in order to add more information! Given that users are likely to use the feature often for their day-to-day tasks and responsibilities, I feel that the inconvenience caused from the initial approach and even the team's solution warrants a `severity.Medium`

---