nus-pe-bot
commented
2 years ago Team's Response
Hi there,
Considering that most implementations of the help command brings up a pop-up window that has a button to copy to clipboard, our implementation, firstly, provides more upfront information on the Command Results Panel, should the user need more information, we will direct them to the UG. The difference that it makes to click a button and copy the link to the browser is insignificant as compared to copying the text and pressing CTR-C. As we do not believe that such an implementation would drastically optimize the CLI experience as the user still needs to use a mouse, we would not be accepting this as a bug.
Note there is no need to type out the long address as a CTR-C CTR-V would do the trick just fine hence rendering this bug find invalid.
Best Regards!
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Thanks for your response! I disagree with this decision based on the following:
-
Firstly the application is tested standalone and not respect to the other teams in the cohort. I don't think "This is an issue but everyone else has done mostly the same" is a valid line of argument.
-
At default window size, the entire url is not even shown and scrolling is not fast (need 5 revs to see the second line :( )
- Thus it's not just a mere
CTR-C CTR-V, but additional scrolling; manually selecting the entire url and then copy paste.
I'm sorry if this being too picky but I do strongly believe that it is quite a hassle to the end-user simply because it was for me and it stuck out to me easily. Plus, I'd imagine an actual user would visit this link multiple times compounding this issue.
Therefore, I do believe this restrains the CLI optimization of the application
Best Regards!
On running
help, a link is shown at the bottom, which isn't clickable (not a hyperlink). Its not user-friendly at all to expect the user to type this long address out. This is a help feature flaw.