nus-pe-script
commented
2 years ago Team's Response
Reject this Bug.
The intended usage of the reminder window is for users to get a reminder on command. The reason we have the reminder window be opened on the startup of our application is to save the users time keying in the reminder command and also avoid a situation where the user forgets to remind himself or herself.
The reminder window was not implemented to provide live updates either. It will not update just because the local time on the user's device has ticked over.
The use case proposed in this issue is an example of "extreme user behaviour". While we do not expect users to always close the reminder window that gets opened on startup, we also do not expect users to refer to the same instance of the reminder window after hours have lapsed and then accept that an interview that was supposed to happen hours ago still is happening. If accepted as a bug, it would be more appropriate to consider this a Low Severity Functionality Bug in our opinion.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: If the intended usage of the reminder window were to allow the user to get reminders on command, then the app should not have opened the reminder window on startup. Opening the reminder window on startup would suggest to a user that it should be left open (it would be strange for the app to open a window and request for the user to close this window for the app to function properly). Hence the team's response itself is contradictory. I understand that the team wanted to save the user time in keying in the command (in an attempt to help the user), but this went against their intention of the window opening on command.
I disagree that the use case is an example of "extreme user behaviour" as well. I do not believe that the action of not closing a window that the app automatically opened for me is an extreme behaviour. In the original bug report, there was no extreme user behaviour as well. I simply keyed in a valid interview timing (not extreme behaviour), and left the window (that the app opened for me) open.
Nevertheless, ignoring our differences regarding the team's response, it does not change the fact that the reminder window (and thus the app) did not provide the functionality promised in the UG. If the team wished for the user to close and reopen to view the latest changes (which would be a valid ask), then the UG should have specified this. However, since the UG did not, the app's behaviour differed from the UG's specifications. For all intents and purposes, a user's experience in the usage of the app was affected.
:question: Issue type
Team chose [type.FunctionalityBug]
Originally [type.FeatureFlaw]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
The reminder window seems to not display applications where the interview date and time is before the current time. E.g. if it is 16 April 3pm right now, it is designed to not show applications where the interview date and time is 16 April 2pm.
However, if the application is left running over a long period of time, it is possible where the reminder window can still display applications where the interview is already over.
Steps to reproduce:
1) Suppose the current date and time is 16 April 2022, 2.52pm.
2) Enter
edit 1 idt/16-04-2022 14:53. (i.e. set the first application's interview time to be 1 min from now)Expected behaviour:
Application 1 shows up in reminder window (valid, as the interview is upcoming)
After the interview time is over, Application 1 disappears from the reminder window.
Actual behaviour:
Application 1 shows up in reminder window (valid, as the interview is upcoming)
After the interview time is over, Application 1 remains in the reminder window.
Screenshot:
Note the current date and time, and the date and time of Application 1.