Open hweinian opened 1 week ago
Hi,
We thought that while they prefer typing, for something so minor, they would be able to use their mouse, as this is only one click to copy, one click to close.
Furthermore, we thought of copying the link to their clipboard but this runs the risk of overriding important copied info in their clipboard. Lastly, they would anyways have to use their mouse to scroll down the user guide, so we thought one more click won’t hinder their experience.
Team chose [response.Rejected
]
Reason for disagreement: Thanks for the response, while your claim is that it is minor to use their mouse to “click” to copy, one click to close. The user still needs to use their mouse to navigate through the user guide and search for information. This result in more than just one click to copy, and close.
One simple solution as shown in the image to resolve this would be to put the usage of each feature into the help window. This way, the user does not need to always access the user guide to get information on each feature. This would allow the user to avoid more usage of the mouse and focus more on the keyboard which aligns with what a fast typist wants.
I agree that this is of severity.low as users would definitely not use this feature often, but this issue is definitely not completely incorrect (By the definition of response.Rejected), as optimising the help function usage of each function, would thereby reduce the use of a mouse, which thereby fits the purpose of a fast typist better. This would fall closer to response.NotInScope as there is indeed a slighest chance of improvement by optimising the help command, but since the developers did not pick this option, I would say it falls in severity.Low.
Description
To access the help command, i would need to use my mouse to access the link. This slows down a fast typist as they would need to use their mouse.
Screenshot