soc-se-bot
commented
1 week ago Team's Response
All the functions are still working correctly. Commands formats are accessible in help window or error message, there is no need for users to remember the limitations of it. However, we could plan to enhance it further.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: I would understand if it took substantial effort to make it so that the edit or note features would accept indexes instead of names. However, the default implementation of the AB3 features used indexing as such it realistically would not take much effort to use indexes instead of names. On the other hand it could be argued that the team wanted for these features to accept names for some reason and allowing both names and indexes would take more work, which may be understandable if the other features in the product didn't already accept both names and indexes. As such it is only a few specific features that only accept names making it more of a deliberate choice, despite the option to allow the command to either accept indexes or both indexes and names not taking much more effort as they both have been implemented in other commands already. As such I do not believe that this should be considered as NotInScope as the team could realistically implement these features without much more effort and as such would not hinder their ability to implement other features of the product.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:**  I would understand if by default the features accepted names only and as such making features accept indexing would take more effort. However, since it is a deliberate choice to use names for note and edit with no given reason, compared to using indexing it will inconvenience users to have to type out names for these commands, slowing them down significantly. Comparing the amount of time and effort it takes to enter 'note 4 m/ibuprofen' compared to 'note Desmond tan m/ibuprofen' or 'note Tharman Shanmugaratnam m/ibuprofen'. Even for relatively short names it will cause an inconvenience compared to just typing an index but the inconvenience caused increases greatly the longer the name gets. Realistically long names are not that uncommon and one of the primary goals of the product is to be more efficient for fast typists but if you are required to type out a person's full name each time a note or edit needs to be made it could become less efficient and practical than a GUI feature even for fast typists. For long names you either have to find the name through other commands and then edit or note it which defeats the point of not using an index in the first place, or you have to remember the whole name and type it without any spelling errors which is also very difficult and inconvenient. Since the commands note and edit are likely to be used often especially the note commands which encompasses many of the utility features of product, such as adding remarks and medication, but especially the adding of appointment timings which is likely to be used regularly. Since most users will likely be making using of these commands regularly this feature flaw is likely to affect most of the userbase. As such I believe that it qualifies for a medium severity, as it causes at least occasional inconvenience to at least some users.
Restricting certain features to require names to be typed feels like it is an unnecessary limitation that only slows down the user especially for clients who have extremely long names, since some commands already allow users to use either name or index there shouldn't be any reason to limit them for specific commands like edit and note. Since it is inconsistent throughout the application it can also frustrate users as they either have to remember the limitations of each individual command or only use names. This unnecessarily inconveniences the user.