nus-pe-bot
commented
6 months ago Team's Response
It is clearly stated in the User Guide that the users must execute the list-an command to view all patient's appointment notes. list only lists all patient records.
List and List-an each has a specific responsibility and function, so executing both logic at the same time as suggested by the Tester would bring about more confusion for the app user.
List-an command:
List command:
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: The issue is that the UI does not provide clarity, leading to an inconvenience to user (instead of just cosmetic issues which simply takes more effort from the user). This lack of clarity misleads the user, and does not inform the user of which appointment note list (whether it is for all patients or the patient with index 1 only) they are on; more effort would not be able to help if they are unaware (hence severity.Low instead of severity.VeryLow), as they are unable to take steps to rectify the issue properly. For example, following the steps above, the user may assume that:
User flow
1) There are only two appointments left when instead there should be more, inconveniencing them
2) Otherwise, they may assume that the appointment notes are lost for which they have two choices:
2) a) running list-an to try their luck and see if all the records are actually in the system, just that they forgot to run it (minor inconvenience)
2) b) re-adding the appointment notes all over again (which is prone to mistakes and is a major inconvenience).
Given the user flow that would occur (any of the above, each with differing levels of inconvenience caused) due to the lack of clarity, I would say that this is at least of severity.Low for inconveniencing the user.
However, I think that it could be of higher severity. I have detailed a work flow below:
1) On start-up, this is the list of appointment notes:
2) This is the list of appointment notes after running list-an 1 (Possibly checking patient 1's appointments after their visit) :
3) The user can then run any command(s) (in this case, the edit command is ran to edit the patient name to be more comprehensive; running the list command as per the original bug report would have the same effect) and this is the list of appointment notes after the command is ran (Possibly processing other patient records):
4) After running a series of commands/ returning to the GUI after completing other tasks, they may no longer able to recall if the appointment notes belong to all patients or only patient 1 (Possibly when attempting to refer to available appointment dates for the doctor for scheduling).
Given this work flow which would be normal (typical, common) usage of the app, I would say that this is potentially a severity.Medium bug (instead of severity.Low), as it will cause an occasional inconvenience.
A simple solution would be to include signposting. For example, the team could indicate the name of the patient in the particular appointment. This would allow the user to discern (with extra effort) that the list is only displaying a specific patient's appointments, and instead they could run list_an to get all patient's appointments instead. This aims to make step 2a of the user flow to rectify the issue even more likely, which provides the least inconvenience to users.
Alternatively, a better solution would be to update the header of the section depending on the user input. For example, running list-an 1 should alter the Appointment Note panel's header to "Appointment Notes for: Alex Yeoh", indicating that the appointment notes on the right belong to patient 1 only. Running list-an will then alter the Appointment Note panel's header to "Appointment Notes". This way, the result in the result display box is not temporal with regard to the latest command that was run, and users are constantly aware of the type of appointment notes actually displayed. This completely resolves the issue regarding the lack of clarity.
For example, when I tried to list patient 1's appointment notes, this is the view:
When I then do list to view all patients, this is the view:
There is no indication that the appointment notes on the right belong to patient 1 only, and users may be unaware that they should update the list with list-an.