Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep track of multiple attempts + improve saving #31

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

luttje
Copy link
Member

@luttje luttje commented Dec 22, 2023

image
image

@luttje luttje changed the title first draft tracking multiple attempts Keep track of multiple attempts + improve saving Dec 22, 2023
@luttje
Copy link
Member Author

luttje commented Dec 22, 2023

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

@luttje luttje marked this pull request as ready for review December 22, 2023 19:47
@luttje luttje requested a review from bartjroos December 22, 2023 19:47
Copy link
Contributor

@bartjroos bartjroos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, great work in preparing this feature! Although I feel it's not quite there yet, in terms of UX / clearness to the user. We might need the figure out the desirable workflow?

For me, editing a point directly should lead to a new attempt being recorded. I feel like this is the most commonly used workflow? Editing a point without creating a new attempt would still be possible via the modal.

As a teacher, I would also prefer the attempts to be more visible. Some indication that this student has had multiple attempts. Like maybe a very small 0/1/2/... badge in the corner of a field?

Now that I'm thinking this through... To implement this in the best way possible, without cluttering the UI too much, we might need to make a distinction between a "view"-mode for the matrix and an "edit"-mode:

  • View-mode would be much like it is now, this would primarily be used by mentor's. They usually don't care about the number of attempts etcetera, just about how many points does the student have now. (should probably be possible to check the attempts, but this could be hidden in a modal)
  • Edit-mode would be used mainly by teachers entering and/or editing points. Maybe even per 'vak'?! Like I could enter the edit-mode specifically for "PRA", and only for those fbm's I would see all the information about how many attempts, and only those would be editable. This is also a protection to make sure you don't accidentally edit a field an thereby create a new attempt.

Todo:

  • Do not allow points higher than maximum in attempt-modal
  • Show attempt in student view somehow (maybe not all attempts, just the one that counts + some indication if it's first attempt or not)
  • Decide whether last or highest attempt counts?
  • Decide whether editing a point automatically leads to a new attempt?
  • Decide whether we need separate view-/edit-modes?

@bartjroos
Copy link
Contributor

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
Copy link
Member Author

luttje commented Jan 15, 2024

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants