@ppelberg I agree that if there’s only one issue, navigation might feel unnecessary. However, if there are two (or more) checks and the user resolves all except one, the navigation would disappear if we hide it when only a single check remains. To address this, we could:

• Option 1: Keep the navigation visible always, even when there is only one issue (as it's implemented now).
• Option 2: Hide the navigation when there is only one issue in the Pre-save, but show it if multiple issues exist and all but one have been resolved.

Wdyt?

In T404798#11188898, @bmartinezcalvo wrote:

@ppelberg I agree that if there’s only one issue, navigation might feel unnecessary. However, if there are two (or more) checks and the user resolves all except one, the navigation would disappear if we hide it when only a single check remains. To address this, we could:

• Option 1: Keep the navigation visible always, even when there is only one issue (as it's implemented now).
• Option 2: Hide the navigation when there is only one issue in the Pre-save, but show it if multiple issues exist and all but one have been resolved.

Wdyt?

Trying "Option 2" sounds like a good step to me. Thank you for proposing, Bárbara.

To avoid the issue Barbara identified, we now need to keep track of how many checks existed when the pre-save dialog opened. Not also that in the future the number of checks could go up/down as you resolve a check, as check resolution becomes more complex. So another example:

• I get one pre-save check, no counter is shown
• Resolving that check introduces two new problems (e.g. I removed a problematic link, but now another check says there aren't enough links), now we need to show a counter

I think this highlights that doing this is just introducing inconsistency and complexity for not very much gain. I don't think showing "1 of 1" is that distracting or problematic. Arguably it is actually helpful as it clarifies that this is only check we are going to show you and so are close to completing your edit.

@Esanders I originally suggested hiding pagination when there is only one item to reduce visual noise and avoid showing empty information when only a single card is present. After thinking through the dynamic cases you described (where resolving one check can introduce new ones), I agree that keeping pagination visible always could be the most consistent approach. If removing pagination for the single-item case adds implementation complexity, it doesn’t worth implementing a new behavior, especially if showing pagination will add consistency in those cases you comment.

Resolving that check introduces two new problems (e.g. I removed a problematic link, but now another check says there aren't enough links), now we need to show a counter

In fairness, pre-save explicitly doesn't let checks cascade that way. There's the initial list, and we don't regenerate it as checks edit the document.

(I do, however, think we should just show the pagination always, because it makes it more clear whether you're in pre-save mode or mid-edit mode.)

In fairness, pre-save explicitly doesn't let checks cascade that way.

They probably should though, if the promise of a pre-save check is that any issue it matches is flagged to the user before saving.

We can certainly revisit it — it’d make the technical design simpler to not have to accommodate that. I remember we went back and forth about it a bunch back when we were doing the multiple-checks design, but at the time there were a lot of hypotheticals about how future checks might interact, and now we’re at the point where it could actually happen.

I agree that keeping pagination visible always could be the most consistent approach. If removing pagination for the single-item case adds implementation complexity, it doesn’t worth implementing a new behavior, especially if showing pagination will add consistency in those cases you comment.

@bmartinezcalvo: +1.

I'm glad you raised these complicating cases, @Esanders.

Moving this ticket to the backlog for now.