[RAM] UX: Snoozing a single rule

[mdefazio]

Summary

Provide the option to snooze a single rule from now until a certain amount of time.

Functionality Requirements:

• As a user, I would like to pause notifications/actions on a rule for a certain amount of time
• As a user, I would like to know the time the snooze finishes
• As a user, I would like to be able to cancel a snooze on a rule
• As a user, I cannot snooze or mute a rule with no actions assigned to it

UX stories:

• As a user, I would like to be able to adjust the snooze time relative to now
• As a user, I would like to see a basic set of pre-set snooze durations when choosing to snooze a rule (ex: 30m, 1h, 3h, 12h, 1d)
• As a user, I would like to be able to set a custom duration if the pre-set snooze options are not what I want
• As a user, I would like to see if there is a current snooze that applies to a rule in the rule table and rule details page
• As a user, I would like the snooze duration (ex: in a popover) to maintain my previously selected snooze for future rule snoozing

---

Tasks:

• Research/Wireframes Design doc
• Prototype Figma prototype link
• Design Figma designs

---

Designs (Stack Management)

Rule detail

Notes:

• Snooze option is disabled if the rule is disabled
• Thinking is that previous selection should show the selection from any other snoozed rules, not just the current one

Questions / TBD:

• How do we show the current snooze time remaining? Perhaps this is shown in the popover next to 'Snooze' (shows the end date or time for the snooze)
  

---

Terminology

Muting vs Snoozing

Muting is indefinite until changed
Snoozing is muting for a specific period of time and then automatically changed

In order to simplify the requirements a bit, I’m suggesting we have a single mental model for muting. So my options as a user would be the following:

Mute for 30 min
Mute for 3 hours
Mute for 1 day
Mute for 3 days
Mute for custom time
Mute forever

We currently allow a user to mute a rule indefinitely, however this is possibly no longer necessary with the addition of specific periods of time. So for the mvp, we will provide the option to mute indefinitely alongside our snoozing options. But all labeled as a singular model.

The main reason for this is that as a user, I don't want to have to choose between snoozing and muting. Additionally, it would be odd to be able to choose to mute a rule that is currently snoozed (and vice versa).

As we build up snoozing, scheduled muting, conditional muting, etc, it seems less and less likely that someone will want to mute a rule forever. One use case I keep coming back to where someone might want this is if there is an issue with the connector(s). However, a more flexible solution for this would be to disable the action (currently only delete is available).

[mdefazio]

Version 1

With this version, i'm only showing the interaction from the rule table. I'm drawing from patterns that we do for the date picker here, so hopefully it feels a bit familiar.

Notes:

1. We need to be clear about this referring to the actions, and not pausing the rule itself. Perhaps the placement of the badge could change, but the copy for the snoozing UI needs to refer to the actions.
2. We need clear use of terminology. I'm using the word 'indefinitely' and not mute—I'm curious if this is clear.
3. Should we move the custom time below 'commonly used'? I'm pulling from the super date picker here, but maybe this makes more sense flipped.
4. If I choose a time to snooze Rule 1, that time is listed as 'Previous' for snoozing Rule 2. <-- Is this how we think this should work?
5. The last few seconds of the screencast show an alternate option for the snoozed badge where we do not include the time frame (only on hover). This will likely be a necessity when we get to choosing a point in time rather than relative time.

cc/ @ryankeairns @XavierM @mikecote @arisonl

Prototype link (Figma)

Screenflow:

[mdefazio]

@XavierM @mikecote @ryankeairns The mockup / screencast for this has been updated to show the row updates from the O11y mockups (using the enabled/disabled/muted badges).

Remaining question: how do we want to show the remaining snooze time? Currently showing this in the mockup in the popover and showing the end date and time.

[Zacqary]

Remaining question: how do we want to show the remaining snooze time? Currently showing this in the mockup in the popover and showing the end date and time.

Do we want to show the end date and time in the popover or a relative time string, like "3 more days"? Maybe mouseover the relative string to see the exact end date/time in a tooltip?

EDIT: I was looking at the original post, not the updated screencast. I prefer the first option, showing relative time in the badge with exact date on mouseover.

In order to simplify the requirements a bit, I’m suggesting we have a single mental model for muting.

The main reason for this is that as a user, I don't want to have to choose between snoozing and muting. Additionally, it would be odd to be able to choose to mute a rule that is currently snoozed (and vice versa).

👍 to this, I have no preference between whether we pick the word "mute" vs "snooze" but it should be either one of them. "Snooze forever" sounds weird, maybe, so I'm leaning towards "mute"? But I'm sure we/users would get used to whatever.

[mdefazio]

@Zacqary Thanks for the feedback

I have no preference between whether we pick the word "mute" vs "snooze" but it should be either one of them. "Snooze forever" sounds weird, maybe, so I'm leaning towards "mute"? But I'm sure we/users would get used to whatever.

I agree that 'Snooze forever' sounds odd. I still question the use case for this though—I can snooze something for a year pretty easily. If I really don't want the actions to run, wouldn't I just remove them from the rule? So ideally this wouldn't be an option.

I tend to think of Mute as something that I have to disable, as opposed to snoozing would be a temporary change.

showing relative time in the badge with exact date on mouseover

I'll update this to show a tooltip with the exact end date on mouseover

[gmmorris]

This is looking great so far!

Playing around with this I realise you can't tell that a rule is snoozed when viewing the rule details page.
Should we add a small badge just so that it's clear when looking at that page?

We can explore the UX to actually snooze from there later, but it would be a simple enough enhancement to include some visual that makes this clear.

[mdefazio]

Updates on the snoozing to match implementation cc/ @Zacqary

Here's also screenshots for the rule detail views (thanks @gmmorris :) ):

• Removes switches for Enabled/Mute
• Moves control to left side before Rule type
• Removes border between header and Rule type/Enabled controls

Enabled

---

Snoozed

Current layout

Update
Note that these are slightly different layout than Observability. Stack does not currently have the definition block. Keeping the current setup with minimal changes for now but we will work to get these closer to each other in layout.

[Zacqary]

@mdefazio I've created two new issues (above) to track adding the Status badges to the Rule Details page, and to add the Previous functionality which I didn't see in the spec for my first PR.

Previous should be easy enough to get in asap. Adding these badges to the Rule Details page may or may not make it in before FF but I'll try.

[Zacqary]

@mdefazio I want to clarify, for the Previous functionality, where do we want to get the previous snooze time from? Do we store it for the current page load? i.e. user loads the page, snoozes one rule for 3 days, and this sets the "Previous" value for the next snooze, but then if the user refreshes the page, "Previous" is cleared?

[mdefazio]

Thanks @Zacqary.

I would think the Rule detail implementation of snoozing is more important than adding the previous functionality. I'm not sure it would make sense to have snooze on the table and not on the detail page. Especially since many users will simply reach those detail pages instead of the rule table. @XavierM do you agree? Any way to prioritize this more?

For the previous functionality—I will add in some thinking to the description of #128301 and comment on that issue for sake of context.