soc-se-bot
commented
5 days ago Team's Response
Thank you for bringing this up. We understand your concern that the filter is removed after editing a person, which may seem unintuitive in certain cases. However, this behavior is intentional and designed to meet the practical needs of our primary users, restaurants.
For restaurants, the workflow typically involves quick edits followed by returning to the full list to view all records again, rather than continuing with a filtered view. Automatically reverting to the full list ensures that users can immediately see and work with all updated entries, which aligns with the operational requirements of restaurant management.
Additionally, when a person’s details are edited, the fields used for the previous filter may no longer match the updated data. Retaining the old, filtered view could lead to an outdated or inaccurate list, causing potential confusion. Resetting the filter ensures that the displayed list always reflects the most current state of the data, maintaining clarity and reliability for users.
In the example provided in the bug report, the workflow involves an employee finding "Jose" and editing their details. Once the edit is complete, the task is effectively finished, and there is no need to retain the filtered view of "Jose." Resetting the filter aligns with this workflow, as it assumes the user is ready to continue working with the full list of entries.
Given that this behavior aligns with the app’s design goals and supports the typical workflows of our primary users, restaurants, we consider this behavior intentional and not within the scope of changes for the current project. While we acknowledge that this might feel unintuitive in specific scenarios, it does not impact the app’s core functionality or usability.
Thank you for your feedback, and we appreciate your understanding as we focus on features that directly enhance usability for our target audience.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Thank you for the well thought-out response. However, in my opinion, this falls under the severity.Medium category. As per the course website, these are the definitions for severity.Low and severity.Medium: severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only. severity.Medium : A flaw that causes occasional inconvenience to some users, but they can continue to use the product. I believe that there is value to be derived from remaining the filtered view after editing a person. In response to: "For restaurants, the workflow typically involves quick edits followed by returning to the full list to view all records again, rather than continuing with a filtered view." This is a sweeping assumption that all restaurants do not do mass edits. It is not unreasonable to say that, there are cases where the restaurant will want to mass edit persons in the contact book. For example, suppose that there is a large order for a large party in location A with postal code S123456, and for the sake of using the Tags feature proposed in NomNomNotifier, the restaurant has also added every single attendee to make sure they know what kind of dietary restrictions to look out for. The party organiser suddenly calls the restaurant and says that the location of the party has changed, or that they forgot to tell the restaurant that certain groups of people are not able to eat meat on that day due to religious reasons. The ideal usage, and workflow is: 1. filter by postal code (to get all people in the party) 2. With easy reference to indexing, the user can edit the fields accordingly one by one to update the information. (E.g. with the filtered list maintained `edit 1 ...` `edit 2 ...` `edit 3 ...`) However, the current usage involves repeatedly searching for each person in the contact list to match their postal code. We can do this by either of two ways First option: 1. filter by postal code 2. Edit person `edit 1 ...` 3. Repeat steps 1-2 until all people in the party have been updated. If the number of people to be updated is n, this involves entering the filter command exactly n - 1 more times than the ideal usage, proving to be a great inconvenience for the user if the party size is large. Second option: 1. Search the list manually for postal code 2. Edit the persons (In the worst case, this involves searching the entire list of contacts which can be very large for big restaurants.) Additionally, the manual search can be extremely tedious because the default list seems to maintain contacts in chronological order in which they have been added to the contact book. If both person A and person B are going to the party, but person A is at index 1 but person B is at index 5000, then the user would have to scroll down the list all the way down from index 1 to index 5000 to find person B. This is an inconvenience for the user. In response to: "Additionally, when a person’s details are edited, the fields used for the previous filter may no longer match the updated data. Retaining the old, filtered view could lead to an outdated or inaccurate list, causing potential confusion." I believe that the bug, if fixed, should also have the filtered list be updated dynamically as soon as a person is editted. This is similar to how the default list should have a person's details updated in the GUI as soon as details are updated. The "filter may no longer match the updated data" is in itself a bug. Based on the above reasonings, I do not believe that this bug causes "a minor inconvenience only" as what the severity.Low definition tells us. Hence, it should belong in severity.Medium instead.
find joseedit 2 n/Jose-Poppinslistcommand after the edit.This can be confusing for users, especially older ones who may not be as tech-savvy, so their user experience is hindered.. And the UG does state that no prior technical experience is required.