nus-pe-script
commented
11 months ago Team's Response
No details provided by team.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Overzealous input validation - Event time
Current: As stated in the UG, event times that are past the current date cannot be put into the system
Expected: They should be able to, as course content states: "Example 2: A user might want to enter an appointment in the past, just for record keeping purposes.".
[original: nus-cs2103-AY2324S1/pe-interim#4026] [original labels: severity.Low type.FeatureFlaw]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
We have intentionally designed event times to be only in the present as it is the primary purpose of our application. Our application is a productivity application designed is to help university students manage their upcoming events and commitments more easily. We designed events to also be highlighted in red if it is in the past or "expired" to give the user a sense of urgency to finish their task/deadline. Our application is not designed to be a notetaking app or an app to keep track of your past events or appointments of whatsoever, adding multiple events in the past and highlighting all in red will make it hard for the user to differentiate between deadlines and appointments, and it totally defeats the purpose of our application designed to be a productivity application. In the context of the textbook is a feature flaw, but in the context of our application and our objective to help students manage their tasks better, it is not a feature flaw.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:**  "It is better to warn rather than to block when inputs are not compliant with the expected format, unless accepting such inputs can hinder the operations of the software". The question is whether blocking past events from being added is more appropriate than throwing a warning message. The onus is on the developers to justify this question. From my perspective, the developers are indeed overlooking that some users need to keep track of events that happened in the past, or just happened moments earlier. For the case of recurring events, the app in essence does not allow users to keep track of passed events, for the purpose of verifying the validity of upcoming events. _For example, a tenant stays in a rented room and he uses the app to keep track of when to pay rent every month to avoid late penalties. Let's say the tenant is supposed to pay the rent on the 30th of each month, but this month the landlord on the 20th asked the tenant to pay the rent slightly earlier as the landlord is experiencing tight finances. The tenant complied, however, he subsequently found out that he cannot add the event `pay rent` on the evening of the 20th as the event is past. Feeling frustrated, he decides to forget it and go to bed. On the 30th of that month, the tenant noticed that it is time to pay rent, and he transferred the money to the tenant for the second time, resulting in a double payment that month. Legally, the landlord is not obligated to return the money to the tenant as he willfully transferred the money twice to the landlord, and no one transferred the money on the tenant's behalf._ While one may argue that the user can simply delete the invalid upcoming event, this is fundamentally restricting how the user use the app. That day the user might be too tired to find the upcoming event that is void and delete it. He might prefer to do it another day. This is a compromise on the user experience. While reviewing the developers' response, it exposed another feature flaw in the app. That is, the user cannot add on-going events. If the start time has already passed and the end time is in the future, that event cannot be added as well.  This is a feature flaw because let's say the event that has already begun ends at 23:00 that day. What this means is the user can technically add events from the current time to 23:00 that day, resulting in a clash. `Our application is not designed to be a notetaking app or an app to keep track of your past events or appointments of whatsoever` `it totally defeats the purpose of our application designed to be a productivity application` The developers are imposing restrictions on the use of their app and prohibits user from using the app in a certain way. This is bound to prevent users from using the app in a way the developers did not anticipate and could annoy the users. `adding multiple events in the past and highlighting all in red will make it hard for the user to differentiate between deadlines and appointments` The developers' argument is questionable as they can simply sort past event to the bottom of the list. In conclusion, the developers' should have adopted 'warn rather than block' principle and their arguments in the response above does not justify how blocking is a better implementation compared to warning. An analogy is that users can freely add events that has passed in apple calendar and google calendar, and the developers did not actively restrict this behavior. The reason why apple and google allow adding passed events could be similar to the reasons I outlined above.
See the screenshot:
It is better to warn rather than to block when inputs are not compliant with the expected format, unless accepting such inputs can hinder the operations of the software. Allowing such flexibility can in turn allow the user to use the software in ways you didn't even anticipate while overzealous rejection of inputs can annoy the user:
In this case: A user might want to enter an appointment in the past, just for record keeping purposes.
Such overzealous input blocking can be considered a type.FeatureFlaw. However, it is fine (and recommended) to show a warning for such inputs to guard against the deviation being a mistake rather than intentional.
Command to replicate: add_event m/James meeting d/2023-10-05 s/1500 e/1700 n/James Ho n/ james ho n/ James Ho g/CS2103T g/CS2101