soc-pe-bot
commented
3 weeks ago Team's Response
No details provided by team.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Instructions in UG don't work for all setup cases. Had to do java -jar 'filename.jar'
[original: nus-cs2113-AY2324S2/pe-interim#2026] [original labels: severity.Low type.DocumentationBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
No details provided by team.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [x] I disagree
Reason for disagreement: Thank you for acknowledging the validity of the documentation bug I reported. However, I must respectfully disagree with the assessment that this issue is a duplicate.
It appears that the "parent" issue addresses inaccuracies in the method described for launching the application. In contrast, the issue I reported concerns the lack of detailed instructions provided for downloading and setting up the application on a local machine.
To elaborate, I'll attach a screenshot of the "Getting started" section in the AB3 user guide:
I'll also attach a screenshot of the "Getting started" section from your UG:
As we can see, steps 1 to 3 in the AB3 UG are not present in your UG. I would contest that these steps are crucial, and should not be left out of the UG, as they help to make your UG more user-friendly.
-
Step 1 states the minimum version of Java required on the user's machine. As we are aware, CS2113 mandates the usage of JDK 11. If a user has a lower Java version on their computer (or worse, they don't even have Java on their computer), then the application will not work as intended on the machine. Thus, the omission of this step could lead to severe usability issues for users.
-
Step 2 provides the download link for the JAR file. Granted, for the purposes of this PE, the JAR file is provided to us testers. But consider that in a real world scenario, a user could've obtained a JAR file of your application from an unofficial source (or perhaps, they're reading the UG without even having downloaded the JAR file in the first place). In this case, the lack of a download link for your JAR file thus makes it difficult for a user to retrieve the correct, updated version of your application. Do consider:
- Suppose that they do not have the JAR file in the first place. How will they use your application if you don't provide a download link?
- Suppose that they have an outdated, buggy version of the app. Wouldn't this inconvenience the user, if they encounter old bugs that have been patched in newer versions?
-
Step 3 mentions how a user can designate a "home" folder for their install of the application. While this may not be too important, it doesn't hurt to at least let the user know that they can move the JAR file around their system, instead of leaving it in their Downloads folder. This flexibility thus increases user convenience.
Lastly, no justification was provided for deeming this issue as a duplicate. In light of the reasons I have outlined, I stand by my assertion that it was an incorrect decision to classify this bug as a duplicate.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
How will the user download your
mathGenius.javafile?