Bisceto / pe

0 stars 0 forks source link

"Mark" and "Watch" in mark feature for videos #4

Open Bisceto opened 1 year ago

Bisceto commented 1 year ago

image.png

This can be confusing for the user, as if they input the "mark" command, they should expect to see a video being "marked". but instead it shows "Watched/Unwatched" instead. Both terms should be the same for clarity.

nus-pe-bot commented 1 year ago

Team's Response

Thanks for raising this.

We did consider using different terms during development but decided that this was the more clear and natural way of implementing it.

Saying that a video is "marked" does not make it clear that a video has been "watched". Hence, we feel that "watched" and "not watched" are the best way to describe a video's status. So, at this point, a better approach would be to change the name of the commands. However, that presents a different problem.

We considered "watched {video_name}" but realised that the equivalent opposite command would be "unwatched {video_name}" which sounded off. We feel that the way a command is read and sounded like plays an important role in helping the user remember the command. Hence, "unwatched" could create confusion where users may end up typing "unwatch {video_name}" instead as it sounded more natural. "notwatched {video_name}" did not sound right either. At this point, perhaps, going with "watch {video_name}" and "unwatch {video_name}" would be the best approach. However, "watch {video_name}" sounds as if we are watching the video and not that we have finished watching the video. This could cause users to mark videos as "watched" not in our intended way and thus not be able to make full use of the app's progress bar feature.

Ultimately, we felt the terms "mark" and "unmark" felt like the best fit for the command name. You mark a video as watched. You unmark a video (that is removed it's "watched" status) and thus it is "not watched". This feels like the most natural sounding and thus the best approach in terms of user experience.

However, the fact that you brought up this issue could be a sign that we should improve on this further. Perhaps more user testing is needed to determine the right cause of action. As it stands, we feel that our approach is sufficient and "rectifying it is less important (based on the value/effort considerations) than the work that has been done already". The current implementation is also as described in the UG. Hence, we would like to categorise this as not in scope.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: [replace this with your explanation]