Comment 7 for bug 1993824

* The ability to save grid filters is nice! My suggestion is to make it clearer that the "Manage Filters" button is to manage *grid* filters. My first thought when seeing the button was that it was for filtering the bib record search, or for filtering URLs somehow. Perhaps it could live in the Grid options menu, or just be called "Manage Grid Filters".

This now matches the suggested label.

* The statistical information (URLs extracted and URLs verified) that displays in the alert is useful, but there's no to get back to it once you've clicked "OK". It would be nice to just have that information available any time you navigate to the attempts screen.

Hrmm, okay, it's not persistent, but instead of window.alert, I'm pushing the string to the invoked interface via route parameters for display.

* It would be helpful for the attempts and URLs screens to have a way to get back to the main link checker screen.

This used to be a peeve of mine (people just not using browser navigation), but these days I see a benefit for this from an accessibility point of view, in that it can reduce a cognitive burden of remembering or figuring out the navigation history. Moreso if we include the title of the previous interface in the link. We have instances of that with hard-coded links, and we have admin page subpages using a Return button.

For now, I added an <eg-back-button></eg-back-button> component that any developer can use, and maybe later we can give it an option to display the title of the page it would take you back to, or just make that change without an option.

* In case it is useful, here is a rebased branch: user/sandbergja/lp1993824_linkchecker_rebased-again

Thanks! I saw it too late, and even made a mistake with my first rebase attempt. 😀

* The progress dialog would be much more useful if it reported progress instead of being indeterminate.

Agreed. Not a showstopper, though, yeah? Somehow these things become rabbit holes for me.

* There's a TODO to replace a window.alert().

I'm actually coming around to window.alert now that we have $localize, but the hobgoblins do beckon.

* Love the use of $localize.. I'm curious if it works with string concat vs. templated `here is a ${string} that translates`

I think the string interpolation would be better.

window.alert(
    $localize`Session ID = ${res['sessionId']}\n
    Title Hits = ${res['number_of_hits']}\n
    URLs Extracted = ${res['urls_extracted']}\n
    URLs Verified = ${res['verified_total_processed']}\n`
);

In my head, I was remembering the pain from $localize not fully supporting the ICU message format, and melding it with the OPAC's "l" function as if in some fever dream. So I thought restricting the translators to a label/value construct would be a minor sin compared to some of the things I've seen in Evergreen, like entire widgets breaking up translatable strings. 😀

But as I jump around between yours and Jane's bullet points, I now find us not having a modal popup at all for this information. I think that works.

* Some of the console.logs have TODOs to be replaced with toasts.

I came to the conclusion later that toasts are not very accessible, even for people who can see them as they go by. If some developer fixes that in the future (maybe via a semi-persistent notification area??), then I'll be more than happy to add those in.

* If you create a session without verifying up front, is there a way to verify the entire batch instead of going page by page?

Hrmm, I suppose one could just clone the session and verify the URLs, which also re-fires the search, which is probably a good thing more than it is a bad thing. However, I just added a Verify All URLs action.

* Would be handy if the Redirected To column showed or linked to something useful.

Agreed, but what it does show is on par with the legacy interface, and anything better is out of the scope of my project for this.

Alright, new branch at collab/phasefx/lp1993824_linkchecker_rebased2

Thanks guys! Let me know how it looks.