Yttruire / pe

0 stars 0 forks source link

Friend IDs should be expected to accept multiple words or at least support symbols #4

Open Yttruire opened 2 years ago

Yttruire commented 2 years ago

CLI Input: friend --add my_friend_id or friend --add my in game name or friend --add my-in-game-name

Expected output: Friend should be successfully added

Actual output:

image.png

Rationale: Since "gitGud is a desktop application for storing and managing your friendsʼ gaming information and schedules", I think it would be reasonable to include spaces and symbols as that is what is allowed for the player gaming IDs for many existing gaming platforms such as steam and discord. At the minimal, symbols like underscore to replace whitespace could be allowed for gamers to add friend IDs with multiple words.

I think that this would be quite a major inconvenience as friend IDs (especially those who do not know each other irl) would have to be stored as-is (with multiple words or symbols as per their in-game ID) in order for the gamer to identify them (I.e. cannot use substitute name to identify a friend).

The issue could be compounded by friends who use similar IDs that would be very similar or even become duplicates if the whitespace and symbols within the name were removed. There would be no reasonable way to resolve this conflict in naming within the application.

This shouldn't be too difficult to implement as the original AB3 already allows names with whitespace.

nus-pe-bot commented 2 years ago

Team's Response

Result

We are rejecting this bug.

Rationale

We designed the FRIEND_ID to be a unique identifier for use within the application and unrelated to game usernames. As stated in the user guide, the FRIEND_ID is intended to be a simple reference for a user to type in fast and be easy to remember. Having multiple word or special symbols in the id would defeat the whole purpose of having a "simple" reference.

This is similar to wanting email addresses to be able to support spaces which is not a bug because it is their intended functionality.

This is especially important since gitGud is a typing-based application and hence focus on having "simple" references which is frequently used to refer to friends is important.

Evidence

image.png

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: While FRIEND_ID has been designed to be a unique, simple reference for the user to type and easy to remember, the "easy to remember" portion is not a very strong argument as the purpose of the gitGud application is to be able to track our friends and games as well. I agree that having symbols may cause the FRIEND_ID to become difficult to type, but there is no reason to restrict FRIEND_ID` from having whitespace at the minimum as it may not necessarily take away from typing speed, while making certain IDs easier to remember as they are clearly separated by word.

However, I believe that in the end the flexibility should just be given to the user to decide whether or not they want to keep the symbols in their friend's IDs, and the restriction on symbols/whitespace could be a recommendation instead. The restriction of names to such a simple form can cause some critical problems for the target audience. E.g. Online friends that gamers make online, but have complicated IDs that are not possible to be replicated with 20 alphanumeric characters alone (I.e. The user may not find a good enough alphanumeric simplification for a complicated username that their friend uses) and have no idea to make up a different FRIEND_ID to represent that online friend, which may not be that rare due to the nature of online gaming. If the restriction is lifted, and the recommendation given, users may still reap the benefits of having "simple" references if they choose to, without being inconvenienced when trying to store more complicated FRIEND_IDs.

As it stands, these users, who have online friends with special IDs, stand to suffer occasional inconvenience when they are unable to input a good representative of their friend's ID into the application. I thus argue that this is indeed a featureFlaw based on the following criteria.

Under "Feature Flaws" section of the "Guidelines for bug triaging":

image.png image.png

I argue for this being a feature flaw on the basis that:

1) (First point from the screengrab) The feature can be implemented to work in a better way (from the end-user's point of view) without much additional effort by supporting whitespace, and preferably symbols as well (AB3 already supports names with whitespace, which FRIEND_ID is likely morphed from).

2) (Second point from the screengrab) While not about the command format, I argue that FRIEND_ID is unnecessarily restrictive, preventing whitespace and symbols when there is no need to (becoming not as inclusive for all types of gamers), other than adhering to a format that may be better as a recommendation than a feature.


:question: Issue severity

Team chose [severity.Low] Originally [severity.Medium]

Reason for disagreement: As it stands, the target audience (gamers), who have online friends with special IDs (which is not very rare due to the nature of gamers who make friends that they only know online and games allow for a much more flexible name format), stand to suffer occasional inconvenience when they are unable to input a good representative of their friend's ID into the application. Even "simple" references with whitespace is not allowed, which is very restrictive, and there are IDs whereby the removal of whitespace in order to fit this criteria will cause the ID to become harder to read/recognise. The reference being "easy to remember" is not a suitable criteria as the names can be easily referred to within the application. The exclusion of whitespace could cause certain names to be harder to type when the original name is better understood as multiple words.

But the main point is that there is a portion of the target audience that will suffer occasional inconvenience as some of their friends' IDs may be unable to be represented reasonably although they can still continue to use the product. Arguably, being unable to add a reasonable representation of their friends' IDs (Critically essential to the purpose of the application), makes the product almost unusable for some users too.

image.png