Syntax for testing MCQ questions

[nus-se-bot]

To test MCQ questions, I'm asked to open the question based on index using the open INDEX command. After this, I'm asked to test myself by using the test INDEX o/ANS syntax.

Why do I need to put an index in a second time? Aren't I already in the question that I want to try out?

The issue is worsened by the fact that there is no indication of which question I am currently viewing in the user interface.

I personally feel that this defeats the purpose of having the app optimized for typists if there is a need for repeated parameters

---

_{[original: nus-cs2103-AY2021S1/pe-interim#3418]}

[josiahkhoo]

Team's Response

Hi, thank you for giving us your feedback on the syntax for testing mcq questions.

To test MCQ questions, I’m asked to open the question based on index using the open INDEX command. After this, I’m asked to test myself by using the test INDEX o/ANS syntax. Why do I need to put an index in a second time? Aren’t I already in the question that I want to try out?

Our intent for include INDEX in test is to make it analagous with testing an open ended question, where you can test the open ended question without using open on it. Having INDEX in the both types of test commands, the user just needs to remember the to include the INDEX for both testing an open ended question and testing an MCQ, instead of having to remember two seperate path flows as suggested, which is:

• open 1 -> test o/ANS (for MCQ)
• test 1 ans/ANS (for OEQ)

Instead, by having the INDEX always there, you know for a fact that whether you open or not, you will still need the INDEX to test the question.

The issue is worsened by the fact that there is no indication of which question I am currently viewing in the user interface

We have included the up keystroke to go to the previous command you have typed, so that in case you forgot the INDEX that you typed moments ago, you can use the up keystroke to see the previous open INDEX. However, your suggestion is to include the indication of the question sounds good as well and we can include that in future version.

As this is a suggestion, under the PE rules as shown below, we will reject this issue:

Duplicate status (if any):

--