soc-pe-bot
commented
4 months ago Team's Response
The intention for restricting add and edit the start time to be not earlier than the now time is a reasonable behavior to protect the users. If the user mistyped a date that is in the past. What can happen is that they will be completely unaware of the existence of the appointment when the patient arrives for the appointment.
Example: Appointment should be 2 Apr 2024, but they mistyped to 2 Apr 2023. This appointment will not be shown in the calendar and will cause even more issues such as overbooking.
Furthermore, by the design convention for appointments, they could only happen in the future. The appointment feature is purely for making plans and reservations. There will not be a use case when users need to modify the start time of an appointment that is already in the past. For real clinics, the assistant will contact the patient before the appointment date to confirm whether they are able to attend the appointment or not and make adjustments about the start time. If the patient arrived 30 minutes late, the clinic assistant could recognize it immediately and update the start time once the patient arrived. After the appointment ends, there will be no need to edit the start time anymore.
If the user really wants to change to a date in the past, they can just edit using the json.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: While I agree with the merits of such a constraint, I still believe that it is overly restrictive and leaves much to be desired, which can be easily fixed.
The example cited by the team is valid, but the same could be said if they mistyped the date to 3 Apr 2024 instead of 2 Apr 2024. This would cause issues such as overbooking as well, since 3 Apr would be overbooked, and 2 Apr would be underbooked. I argue that the fact the appointment does not show up in the calendar is a plus point, since it can be easily detected by the user immediately, and will prompt the user to double check why the appointment didnt appear at all. The constraint doesn't effectively protect the user from such scenarios.
I think that my case in point is regarding the correctness of the data which is not addressed. With regards to the team's response, I agree that from a patient / customer point of view, the only appointments that I care about are those in the future, and once the appointment is over, it doesn't matter to me anymore.
However, I think for the target audience of clinic managers, this would not be the case. A vital aspect of clinic management is bookkeeping, and ensuring the correctness of data. I don't think it is entirely correct to say once the appointment is over, it doesn't matter if the data is correct or not. Given any real world management operations, ensuring correctness of records of past events is definitely not trivial.
Additionally,
If the patient arrived 30 minutes late, the clinic assistant could recognize it immediately and update the start time once the patient arrived. After the appointment ends, there will be no need to edit the start time anymore.
To do this, by the current implementation, since the clinic assistant would not be able to edit the start time to any past timing or date, it would require the clinic assistant to effectively see into the future and predict when the patient will arrive (e.g. in 2 mins) and edit the appointment information within the next 2 minutes. I don't think that's possible. Additionally, even if such was the case, it does not leave the assistant any room for error: If the assistant left for the toilet, and a patient arrived, they would be doomed, since they would have no way to edit the appointment start time to reflect when the patient had arrived, i.e. in the past.
Hence, I still believe that this overly restrictive constraint heavily hurts the usability of the product, and should at least be taken into consideration instead of brushed off. Additionally,
If the user really wants to change to a date in the past, they can just edit using the json.
I don't think the target audience would know what a json is, let alone how to edit it.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** Team didn't give any explanation for lowering severity. Still believe that it causes a major flaw, and makes it quite unusable. For example, if google calendars didn't allow me to edit any of my appointments I had in the past, I think I would use yahoo instead.
Currently the edita function does not allow editing of start time to be earlier than now time. This limits usability as a clerk might want to edit to reflect what happened, e.g. if patient arrived 30mins late and dr pushed the appointment 30 mins later, the clerk would not be able to edit this to reflect it at the end of the day.
Constraint seems to limit the usability for clerks to edit the appointment data in case they previously mistyped it in a week ago, or day ago etc. This makes it such that wrong appointment times that were mistyped, and the time already passed, cannot be rectified, which causes a major problem, limits usability majorly.