In my original answer, I've suggested adding 3 buttons: Next question, Submit, and Try again (if the submitted answer is wrong). That bothered me because such a design would be cluttered despite being highly detailed and not requiring much training. I wrote it late at night, not at the prime of my mental capacity, and, as a result, didn't think much of the real-life workflow in such a situation.
Let's have a look a student taking a test on paper:
- Step 1: Read the question
- Step 2: Attempt to solve the problem
- Step 2.1: If the problem is too hard, skip the question
- Step 2.2: If the problem is solvable, write the answer
- Step 3: Advance to the next question
- Repeat steps 1-3 until there're no more questions left
- Optional: Go back and review all answers
- Step 4: Submit the test to the teacher
From this workflow, we notice that the student indicates that she's done with the problem by advancing to the next one after either writing or not writing an answer. At the end, she submits the entire tests to the teacher for checking.
The only difference between a real-life test and this software is that the goal of a test is to solve correctly as many of the pre-selected problems as possible and the goal of this app is to solve correctly 10 randomly generated problems in a row. This means that each answer must be submitted separately and checked in real time. So how can we let users submit answers, skip questions, and advance to the next one with the fewest buttons possible?
Rather easily: it all requires just one button that changes its label depending on the content of the answer input box. If there's nothing entered, the button reads Skip & show the next problem. If there's anything entered, the button reads Submit & show the next problem.
The second part of the button label (after ampersand) can also be continue or advance to save horizontal space. If anyone is concerned about using "big words" in an app for children, remember:
- this is an educational app (no harm if a child learns a new word);
- it's just one word (there's no frustration for reaching for a parent or a dictionary every step of the way to explain a new word);
- the label doesn't matter much once the child is used to the application (motor memory for the location of the button that brings the new question trumps vocabulary knowledge).
Now, that we're done with confirming answers, let's take a look at going back to review or correct the wrong ones. This is the tricky part because it's mostly teaching methodology. You need to consult with an expert in the field to figure out which of the two approaches is best:
Emphasizing that 10 correct answers in a row are necessary. To do this, you need to allow users change their answers only before advancing to the next problem, show the correct answer upon advancing to the next problem, and allow users only to review past questions & answers along with the correct ones. The workflow would be
User writes answer ->
User taps "Advance" ->
System flashes a toast "Correct!" / "Incorrect. The answer is x" ->
User taps the old problem in the list and sees the problem, submitted answer, and the correct answer
Making the interaction resemble real-world experience. This way users will be allowed to go back to a skipped problem or one with an incorrect answer and try to answer it again. In this case, the system notice will be only Correct or Incorrect and the user won't know the answer until she enters it herself. The issue here is that the user may answer 10 questions, of which 2 will be wrong and 1 will be skipped, and then she will go back to those 3 to correct them and achieve the goal. While this workflow will be much closer to the paper test discussed earlier, it may be against the app's goal of teaching to solve math problems on the first attempt.
