Open RyanQiu1 opened 1 year ago
Thank you sharing your idea, but there are a few reasons why we decided to user the original list for filter
Consistency
The find is to find based on the original list, therefore, to make the actions more consistent, we decided to filter based on the original list.
The intended behaviour
The aim of the "filter" is to filter out a group of student. So if we filter based on the already "filtered" list. It kind of defeat the purpose of why we having it in the first place.
The normal user flow
The other reason that you feel it is inconvenient is because your test flow is kind of reverse to the normal user flow. Normally, if user forgot a student's name, but he/she remember the student is a JC student, he/she will filter out the JC student to narrow down the list first, so the user can easily find the student. It does not really make sense that I know the student I want to find already, then I go to filter by group.
Potential extra command for user to key in
If we filter by filtered list, it means if the user want to go back to the original list, he/she need to type in "list".
We hope you can think about our points. However, your idea does also make sense, we will consider update the application based on your suggestion in the future. Thank you.
Team chose [response.NotInScope
]
Reason for disagreement: 2) Yes i understand, thus i have placed under feature flaws, which is a feature and usage that a user (tutor would like to have/normal for tutor function).
3) Regarding the normal user flow, what if the tutor had multiple students with the same name, but wanted to group the ones/filter the ones based on a certain criteria.
4) Do not think this is a problem with typing one command and separating the functions.
Reference: type.FeatureFlaw: Some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage. i.e., the feature is not 'complete'. In other words, an acceptance-testing bug that falls within the scope of v1.4 features. These issues are counted against the product design aspect of the project. Therefore, other design problems (e.g., low testability, mismatches to the target user/problem, project constraint violations etc.) can be put in this category as well. Features that work as specified by the UG but should have been designed to work differently (from the end-user's point of view) fall in this category too.
Lets say i find by john
The results of name john comes out, with 2 results
However if i want to filter more specifically by lets say tag "female"
It filters the original list with 5 results now. This can be a minor inconvenience when a user wants to filter further using tags after finding multiple names that are similar.