search

meatyturtle / pe

0 stars 0 forks source link

Celebrity cannot be his own point of contact #7

Open meatyturtle opened 5 days ago

meatyturtle commented 5 days ago

When I try adding a event for a celebrity Alex Yeoh and also make Alex Yeoh the point of contact, I get this error:

image.png

This error message does not make much sense, because a celebrity is a contact in contact list. Furthermore, functionality wise this would not make sense either because a celebrity realistically should be allowed to be their own point of contact if it is a private event meant for them only.

Suggestion: allow more flexibility in the p/ prefix

nus-se-script commented 1 day ago

Team's Response

We understand where you are coming from, but our team implemented the point of contact system as a way to include other points of contact apart from the celebrity, hence, we purposely implemented it this way to reduce clutter in the GUI.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Thank you for your response. While I understand your explanation regarding the point of contact system and the intention to reduce GUI clutter, this justification does not address the core issue: the error message is unintuitive.

This is a valid concern from a user's perspective. A user encountering this issue is likely to repeatedly try the same approach, failing to understand why it doesn’t work. This creates unnecessary frustration and confusion. Error messages are crucial for guiding users in resolving issues efficiently, and in this case, the current implementation fails to provide clear guidance.

If your team views this report as encompassing multiple issues and chooses to ignore the unintuitive error message, then that’s your prerogative. However, I urge you to consider the following:

If you genuinely understood where I'm coming from, the appropriate course of action would likely involve planning an adjustment to make this aspect more user-friendly and intuitive. This would align better with a response.NotInScope classification, indicating that while it wasn't addressed before the PE, it is a recognised issue for future improvement.

By outright rejecting this report, your message to users is essentially, "This is how it works, deal with it." This is not a constructive approach, especially when a user has identified a legitimate problem. Additionally, if the justification is that "it's not a bug, it's a feature xd", it highlights a deeper issue: the lack of communication to users about why the feature behaves this way. A more user-centric explanation in the user guide, as taught in CS2101, would help mitigate this confusion. Currently, the rejection feels dismissive and undermines the importance of user feedback.

The purpose of the PE is to evaluate the product's usability and functionality in real-world scenarios. Dismissing this as “not a bug” disregards the genuine confusion and frustration users might face. I strongly encourage your team to think about how this impacts the user experience and take the necessary steps to address it, if not now, then in future iterations.

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** I understand that you'd want to min-max your marks for the PE but a two-level jump is a bit of a stretch no? Is this truly a minor inconvenience when a user engages in completely logical behavior and cannot understand why it doesn’t work? While it’s true that users can continue to use the product, experiences like this detract from their overall satisfaction. Frustration from unintuitive error messages may cause users to lose confidence in the application and question whether it is worth continuing to use.