nus-se-bot
commented
8 months ago Team's Response
Thank you for raising this issue with us. We disagree that this is a valid bug.
Our target users are School of Computing students in NUS. In both DG and UG, we have clearly defined and narrowed our target users to SoC students in NUS only, not some Tom, Dick and Harry.
SoC students would have come across these terms regularly. Think about the introductory programming and/or computer organisation courses that SoC students have to take. These terms would have been taught to these students, and these students would have been very familiar with these terms.
In our opinion, it is also important to state that INDEX takes in an unsigned positive integer. Otherwise, users of our application may enter values such as "+1" or "1.0" etc., thinking that these values are valid when they are not accepted by our application at all. By stating clearly the requirements for INDEX for our target users, we actively prevent our target users from getting an error when they least expect one. These technical terms are also in the most simplified form ("Unsigned positive integer" is only 3 words, and we don't think there is a way to simplify it further without compromising on the requirements).
Indeed, it is better to be safe (state the requirements clearly) than to be sorry (get an error and wonder why the index provided is not valid).
Moreover, we have added hyperlinks to the Glossary section which clearly explains the terms that you have raised (Unsigned positive integer, MAX_INT). We did this for the small proportion of SoC students who may not be familiar with these terms. Once these students have read the definitions and explanations for these terms in the Glossary section, they would have gained clarity on the supposed technical jargon.
We do not see a problem with our current approach. Our target users who are SoC students, and we have also gone the extra mile to consider their varying levels of familiarity with these technical terms.
Given these reasons, we are rejecting this bug report.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: > Our target users are School of Computing students in NUS. In both DG and UG, we have clearly defined and narrowed our target users to SoC students in NUS only, not some Tom, Dick and Harry.
SoC students would have come across these terms regularly. Think about the introductory programming and/or computer organisation courses that SoC students have to take. These terms would have been taught to these students, and these students would have been very familiar with these terms.
There seems to be some contradiction with how they are defining their target users. They mentioned that as their target are SoC students, they would be familiar with technical information. However, in their DG, they have mentioned the learning curve of technical aspects of the app (such as the CLI) as a con in their design considerations for their target user. In their user stories, they also want "blur SoC students" to be able to learn. They have even stated in their reply to this issue that they included a glossary "for a small proportion of students who may not be familiar with these terms", meaning they acknowledge this.
As such, wouldn't the reduction of technical information simplify the learning process for their target user? Using MAX_INT, Unsigned Positive Integer, etc does not value add to a simple whole number greater than 0 as it is unlikely a user would have friends numbering to MAX_INT.
This also calls into question the profile of SoC students they are targeting. Are we talking about SoC students in general? Freshmen? Or students who have studied for a few semesters and would know these terms naturally. A simple anecdotal example would be that a freshmen coming into their first semester would not naturally understand these technical jargon despite being a SoC student.
In our opinion, it is also important to state that INDEX takes in an unsigned positive integer. Otherwise, users of our application may enter values such as "+1" or "1.0" etc., thinking that these values are valid when they are not accepted by our application at all. By stating clearly the requirements for INDEX for our target users, we actively prevent our target users from getting an error when they least expect one. These technical terms are also in the most simplified form ("Unsigned positive integer" is only 3 words, and we don't think there is a way to simplify it further without compromising on the requirements).
I am not disputing whether or not to state the requirements. I'm saying that this can be simplified considering their target audience includes fresh SoC students.
"We don't think there is a way to simplify it further without compromising on the requirements": Whole number greater than 0, or follow AB3.
Moreover, we have added hyperlinks to the Glossary section which clearly explains the terms that you have raised (Unsigned positive integer, MAX_INT). We did this for the small proportion of SoC students who may not be familiar with these terms. Once these students have read the definitions and explanations for these terms in the Glossary section, they would have gained clarity on the supposed technical jargon.
Meaning, they agree that it is possible for their target user to not be familiar with these terms. Once again, my issue is not with whether they have the most comprehensive glossary section defining each term clearly. Rather, it is about whether the technical jargon are needed in the first place, taking into consideration their target user and motivation to facilitate the learning process.
The target user might not understand the technical jargon (MAX_INT, Unsigned Positive Integer, etc) used. While the glossary is provided, perhaps such terms can be simplified and there is no need for the target user to know these technical jargon which is reserved for implementation details.