Keep track of multiple attempts + improve saving

[luttje]

[luttje]

Besides allowing us to keep track of multiple attempts, this also fixes how saving works. There was a problem where if you made changes, and then opened any modal, those changes would be saved without having to actively press the save button. This happened because all changes were deferred until the first action. That worked fine when save was the only action, but later we added modals for opening flood fill or attempt editting, which caused this to fail

[bartjroos]

Adding ideas from discussion in the Issue for further context / reference;

Interface design; maybe like a 'stack'... You click a box which has multiple attempts behind it, and it will fold out like a 'stack' of old attempts was behind it?

How to indicate if you want a new attempt.. maybe like it's always a new attempt, but you can hold down a key, or set a global switch to enter edit mode?

Another idea for an interface that's less preferable, but easier to implement:

User edits the number As the focus is lost they get a modal with these options: Edit attempt #last Add new attempt The same modal could be used to visualize the stack of attempts if the user wants to see them. Perhaps on mouse over a small stack button could appear for opening that view.

[luttje]

My thinking in how I designed the interface in this PR was as follows:

1. Teacher wants to insert scores for all students for a first attempt
2. They start inserting scores
3. At student X they make a small typo in the score entry
4. They correct that score for student X
5. The teacher continues inserting scores.

In this situation, changing a score in step 4 should not add a new attempt.

This led to the current design, which also reduced code complexity for this first prototype.

If we want to change behavior where sometimes it changes the score and other times it adds a new attempt we'll have to somehow predict the intent of the user. I think the two modes you suggested may clearly signal to the user that score entry behavior is different.

[bartjroos]

If we want to change behavior where sometimes it changes the score and other times it adds a new attempt we'll have to somehow predict the intent of the user.

That's a great way to put it!

At student X they make a small typo in the score entry

I can see how this would happen, we need to account for this.

Maybe we need these two modes with a very clear switch at the top:

1. Viewing - mainly for mentor's, you basically just see the matrix as it is now, just without editing capabilities. In this mode you see all the points that actually count, so the latest or highest attempt (depending on what we decide).
2. Entering - teacher will open entering mode specifically for one subject. Entering a point will create a new attempt, but only after leaving the entering-mode (=saving). So you go into entering-mode, input the scores, you double check, correct any mistakes, and then go back to view-mode (thus saving the scores and creating new attempts). Any corrections within the same entering-session do not cause a new attempt, because they haven't been saved yet.

This would also account for the following situation: student scored 5 out of 6 points in first attempt. In second attempt the student scored 4 out of 6 points. Hightest attempt counts. So teacher will enter the entering-mode, change 5 into 4 and go back to view mode. Now the 4 dissapears in favor of the 5. To make this make sense, we need the sharp difference between view/enter-mode.

Now what about editing after saving? Maybe this is where the existing modal comes in to play to edit an existing attempt?

Maybe postpone this to a next release?

In about one week we will begin introducing the new Smartpoints to all teachers. This feature needs to be complete and merged OR postponed to a next release over the summer holidays.