feat(menu-bar): Enhanced visual feedback for "Mark me as done"

[liza-kl]

Description

• Implemented the enhanced feedback behaviour for the "Mark me as Done" tooltip, as stated in #4269.

• The cases are handled as follows (or at least this was the intention):
  • Voting is active / No timer → Showing the open tooltip after 2 seconds and leaving it open until the user clicks. Clicking logs the toggle interaction. If a user decides to unmark them, the feedback shall not be shown.
  • Voting is active / timer is active / votes are used up before the timer ends → Showing the tooltip after 2 seconds and leaving it open a) until the user clicks or b) until 30 seconds after the timer expires and the user is set to ready automatically

• Voting not active / Timer is active → After timer expires and the user is not ready, showing the tooltip after 2 seconds until 30 seconds after expiration and then setting the user automatically to done.

• Voting is active / timer has expired / votes are not used up: same behaviour as Voting is not active, but timer is active
• Voting not active, timer active, user toggles their state twice within 30 seconds after expiration -> don't show the open tooltip for the second time.

Changelog

• Add hooks that implement logic in MenuBars.tsx
• Add tests for implemented logic

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• The light- and dark-theme are both supported and tested
• The design was implemented and is responsive for all devices and screen sizes
• The application was tested in the most commonly used browsers (e.g. Chrome, Firefox, Safari)

(Optional) Visual Changes

[Schwehn42]

I'm admittedly kinda confused by the behaviour:

• when a timer is active, all participants get set to ready after 30secs. The 30s don't start after the timer has expired but after the timer was started, which can't be right, can it?
• that is also the case when a voting is active, and it doesn't matter whether one actually votes
• the timer itself doesn't seem to disappear after 30s after expiration

[Schwehn42]

I believe there still are some edge cases to be looked at, e.g. when setting yourself ready before the timer runs out, then unready yourself within 30 seconds, you get reset to ready 30 secs after that. I would expect that it doesn't set you to ready since I intentionally set to not ready.

[brandstetterm]

b) until 30 seconds after the timer expires and the user is set to ready automatically

Nice work! Two questions: Why do participants get set to ready 30s after the timer has ended automatically? What makes you confident that the participants are in fact ready?

[liza-kl]

b) until 30 seconds after the timer expires and the user is set to ready automatically

Nice work! Two questions: Why do participants get set to ready 30s after the timer has ended automatically? What makes you confident that the participants are in fact ready?

This was a technical requirement (No. 3) stated in #4269. However, I see that I haven't implemented the "closes the timer automatically". Shall we remove the 30s rule then, in general?

[brandstetterm]

This was a technical requirement (No. 3) stated in #4269. However, I see that I haven't implemented the "closes the timer automatically". Shall we remove the 30s rule then, in general?

Thanks for the clarification! To be honest, I'm not really keen on automatically marking participants as ready, as we can never be sure that they are actually ready. However, I also don't want to simply change requirements for features that @SelinaBuff has defined. I think I'm going to start a discussion in our Slack channel to find out what the others think.

[liza-kl]

This was a technical requirement (No. 3) stated in #4269. However, I see that I haven't implemented the "closes the timer automatically". Shall we remove the 30s rule then, in general?

Thanks for the clarification! To be honest, I'm not really keen on automatically marking participants as ready, as we can never be sure that they are actually ready. However, I also don't want to simply change requirements for features that @SelinaBuff has defined. I think I'm going to start a discussion in our Slack channel to find out what the others think.

That's a good idea. Maybe we should also discuss the edge case @Schwehn42 pointed out :)

[Schwehn42]

Still some issues with it, especially when adding a new timer or resetting it after it ran out. Didn't test with the votes yet, just the timer.
Hard reset means concluding the current timer before starting a new one, while soft reset means just initializing a timer, even though the old one is still active (despite being at 0s).

Use Case	Shows Banner
initial timer	✅
mid soft reset	✅
mid add +1	✅
post soft reset	⛔
post add +1	⛔
post hard reset	⛔

[liza-kl]

• New "simplified" logic (was discussed and approved)
  • Every time a condition for a ready state is fulfilled (e.g. timer expired, or votes are used up), show the extended tooltip after 2 seconds for another 28 seconds.

[github-actions]

The deployment to the dev cluster was successful. You can find the deployment here: https://4383.development.scrumlr.fra.ics.inovex.io
This deployment is only for testing purposes and will be deleted after 1 week.
To redeploy rerun the workflow.
DO NOT STORE IMPORTANT DATA ON THIS DEPLOYMENT

Deployed Images

• ghcr.io/inovex/scrumlr.io/scrumlr-frontend:sha-30476de

• ghcr.io/inovex/scrumlr.io/scrumlr-server:sha-30476de

[laila-rin]

Looks good!