nus-se-bot
commented
1 year ago Team's Response
Disputing bug type
This is probably not the intended behaviour
If the tester feels that the behaviour is unintended, it should be a functionality bug rather than a feature flaw.
Justifying rejection
The behaviour is intended.
Regarding the tester being confused that a video can be "not watched" but have a timestamp. "watched" can be interpreted as fully watched. "not watched" can be interpreted as not yet fully watched. A user might have watched a lecture partially and thus specify a timestamp of where they stopped at. However, since the user has not fully watched the lecture from start to end, they do not mark it as "watched". Hence, a situation where a video is "not watched" but has a timestamp is possible. Preventing such a case could be considered overzealous input blocking which would degrade the user's experience.
The user can of course use the timestamp and watch status in other ways as well. For example, specifying that a video is "watched" as long as they have begin to watch it and then using timestamp to track where they stopped at. We do not restrict the user's freedom in such cases.
Regarding the tester's suggestion, if we were to restrict the user from specifying a timestamp unless they change the video's state to "watching" (a new field / watch status), that feels like adding additional steps for the user to accomplish their goal. We feel that this would not improve the user experience.
Ultimately, this seems to be a disagreement in design decision with regards to providing the best user experience.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: > Hence, a situation where a video is "not watched" but has a timestamp is possible. Preventing such a case could be considered overzealous input blocking which would degrade the user's experience. ... We do not restrict the user's freedom in such cases.
I do not believe that it is overzealous input blocking, as it is to ensure clarity of what the user is doing. There is also no clear definition of what "watched" and "unwatched" is in the user guide, especially when "unwatched" can mean they are still partially watching the lecture. I believe that "not restricting the user's freedom" in this scenario makes this feature unclear in its usage. A user's interpretation of such a feature can also change subconsciously over time, and there is no clarification in the user guide to address its definite usage. Thus I still believe that it is a feature flaw as it can provide confusion for the user.
Regarding the tester's suggestion, if we were to restrict the user from specifying a timestamp unless they change the video's state to "watching" (a new field / watch status), that feels like adding additional steps for the user to accomplish their goal. We feel that this would not improve the user experience.
Of course, my suggestion is one of the many solutions that can be used to address this. However, at the minimum, there should be a suggested/definite usage that is defined by the dev team in the user guide
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** I do not think it is a functionality bug, as the implementation of the feature seemed in line with the developers' description in the user guide. Errors are also handled appropriately, so I do not think there is anything wrong with the implementation. I categorised this as a feature flaw due to the design decisions considered by the team. I believe that this feature is incomplete, due to the main reason that it provides ambiguity to the reader.
As of now, I am able to edit the timestamp of where to watch the video from even though it is "Unwatched"
This is probably not the intended behaviour, and a user should only be able to edit the timestamp if they are "watching" the lecture (could be new field), but it is quite confusing as to how i can have a timestamp when the video is still "unwatched".