[cartpauj]

Closes #271

Why reopen this

#271 was closed on the reasoning that stacked toasts mean there's data to fix. But the fix for a duplicate or unknown bib usually happens in the edit pane, and the sticky toasts sit right on top of its DELETE button. The toasts block the action that resolves them. (#189 item 3 reported the same thing after Bear 100 2024.)

This keeps the toasts exactly as visible and as sticky as they are now. It only moves them out of the way while the edit pane is open.

What

• While a right-side drawer (the edit pane) is open, the toast stack slides left by the drawer's width (26rem) so it sits beside the pane instead of over it
• When the pane closes, the stack slides back to the corner
• Toasts stay on the top layer, so edit-pane warnings (e.g. saving with no bib) are still fully visible and clickable

How

• Drawer marks itself with data-right-drawer-open while open on the right
• The portal root carries a group/portal class
• The toast container uses group-has-[[data-right-drawer-open]]/portal:right-[26rem]

Tests

Styling only, no unit test. Confirmed Tailwind generates the rule. Not yet checked manually in the app.

🤖 Generated with Claude Code

[cartpauj]

Fixed by shifting toasts to the left of the edit pane when opened.

Screenshot:

[cartpauj]

With panel closed, same as before:

[JordenLuke]

We discussed this before but decided to keep them where they were so users had to read and close out the Toasts before editing. The intent was to make it hard for them to ignore them.

[cartpauj]

See screenshots, it just shifts them to the left, so the buttons are still usable, and the toasts are still visible.

[JordenLuke]

See screenshots, it just shifts them to the left, so the buttons are still usable, and the toasts are still visible.

It looks good, but by blocking the buttons they had to close out the toast and hopefully read them before doing extra work. I am fine with going this way I just wanted to give you the reason we closed out the original ticket. That is on us for not putting reasons in it before close. I know we went through lots before this dev cycle in a chat and closed them with out adding a reason.

[cartpauj]

Yeah, the reasoning makes sense, but in some cases it might force them to close a toast unrelated to the item they're fixing. So shifting them left seems like a better solution to me.

[rleikis]

Note that the explicit reasoning for this has already been documented in detail, ad nauseum.

Delete is often not the appropriate action to resolve a duplicate, nor should it be something we want to be executed quickly. So, the controls used most often to resolve a duplicate have not been obscured, and thus this issue was downgraded and dismissed.

Also, in practical workflow dismissing the toast and deleting a single timingRecord was already reviewed by the team and deemed acceptable. Is it is rare that you need to delete more than one in quick succession. This was not a workflow we wanted to support.

Yeah, the reasoning makes sense, but in some cases it might force them to close a toast unrelated to the item they're fixing. So shifting them left seems like a better solution to me.

This is valid. I don't have a problem for that. However, the toasts that require user action are intended to be more difficult. I don't think I am in support of changes that make them easier, especially when it is saving at most one user interaction.

[cartpauj]

In my case running on a smaller screen, toasts were blocking the apply button as well.

[cartpauj]

Though, to be fair it was infrequent that the apply button was fully covered. But feel free to close out this PR if you don't think it's a good solution.

That being said, it doesn't close the toast, they still have to manually close it, it just makes the edit panel fully visible.

[rleikis]

In my case running on a smaller screen, toasts were blocking the apply button as well.

I suppose we assumed that with the new scaling controls users would scale it to represent the normal presentation of the app. Perhaps we need to auto scale the UI so there is a common experience in the UI.

@JordenLuke I'm thinking that if such a small thing is garnering this much repeated attention, then its time to revisit the fundamental design of the toast and user limiting mechanics entirely. Let's look at it from a higher level and see if this mechanism is really serving us.

[rleikis]

I suppose we assumed that with the new scaling controls users would scale it to represent the normal presentation of the app. Perhaps we need to auto scale the UI so there is a common experience in the UI.

Devil's advocate for a moment, there is no way that we can keep designing features based around an poorly scaled UI. At some point we have to assume that you will have some shared experience.

[cartpauj]

My personal opinion is that maybe we give this a try and see if it helps alleviate the frustrations with the toasts. My biggest complaint with the toast was that they were always in the way when trying to edit something. And I feel like this solves that pretty easily without losing access to either the toasts or the edit screen.

[JordenLuke]

My personal opinion is that maybe we give this a try and see if it helps alleviate the frustrations with the toasts

I was wondering if some of these frustrations could be alleviated via some work flows that we have discussed. Either way I think we need have a discussion. On this topic.