handing this over to @Sarai-WMDE for a mockup

Initial mocks are available in this Figma page.

Some open questions:

1. Button placement: I don’t think it’s a problem, but if we feel that the first file download button competes too much with the 'Download statistics' button, then we could either: a) Place the ‘Download csv’ button in the bottom right corner of the upload card.; or b) Align the ‘Download statistics’ buttons to the left.

2. Button copy & icon: Is there a clearer way to express the action (e.g. 'Download csv file')?

3. Flow: Once users click the ‘Download csv’ button to trigger the download... a) Are they redirected to a different page (e.g. one displaying the raw content of the csv) where they can see the full file download URL? ; or b) No separate page is open. In the latter case, the URL might be difficult to see (+ not possible to copy and edit).

In general, as discussed, the current agreed solution addresses the problem very roughly, not making it possible for mismatch providers to have easy access to reviews for their uploads. I'd like to suggest planning follow-up improvements to provide a better experience: these could involve the introduction of simple search capabilities in the Import Status tab of the Mismatch store. This way, users would be able to retrieve specific uploads (e.g. using the ID). This would require, of course, listing all uploads in the store (pagination would be on our side here).

In T304794#8457425, @Sarai-WMDE wrote:

Initial mocks are available in this Figma page.

\o/ That looks great to me.

Some open questions:

1. Button placement: I don’t think it’s a problem, but if we feel that the first file download button competes too much with the 'Download statistics' button, then we could either: a) Place the ‘Download csv’ button in the bottom right corner of the upload card.; or b) Align the ‘Download statistics’ buttons to the left.

I don't have a strong opinion either way and trust your judgement.

2. Button copy & icon: Is there a clearer way to express the action (e.g. 'Download csv file')?

How about something like "Download review results" or "Download review decisions" or "Download results"?

3. Flow: Once users click the ‘Download csv’ button to trigger the download... a) Are they redirected to a different page (e.g. one displaying the raw content of the csv) where they can see the full file download URL? ; or b) No separate page is open. In the latter case, the URL might be difficult to see (+ not possible to copy and edit).

I was thinking they stay on the page and you're right about that then being not in-your-face how to get to the URL. Right-click and copy URL would work though, right? It does for the current Download statistics button. Not perfect but would be acceptable to me if we don't have a better solution.
Sending people to a different page doesn't seem great to me somehow.

In general, as discussed, the current agreed solution addresses the problem very roughly, not making it possible for mismatch providers to have easy access to reviews for their uploads. I'd like to suggest planning follow-up improvements to provide a better experience: these could involve the introduction of simple search capabilities in the Import Status tab of the Mismatch store. This way, users would be able to retrieve specific uploads (e.g. using the ID). This would require, of course, listing all uploads in the store (pagination would be on our side here).

👍

@Lydia_Pintscher: In task breakdown, we decided that the URL should look like https://mismatch-finder.toolforge.org/store/imports/<import-id>/results.csv; however, we think it would make sense to add a response header so that the name under which the file is saved is not just results.csv, but also includes additional information like the import ID and also the date or timestamp at which the CSV was downloaded (e.g. results-10-2022-12-14T14:25:40Z.csv). Should we add that as an extra subtask?

Makes sense. Extra subtask or not: As you prefer.

2. Button copy & icon: Is there a clearer way to express the action (e.g. 'Download csv file')?

How about something like "Download review results" or "Download review decisions" or "Download results"?

Thanks for the copy proposals! They would all make a lot of sense if the button was enabled only if results were available, but since –I'm interpreting from the ticket's description– the action will appear by default (regardless of whether any reviews have been collected), it might sound misleading 🤔

In order to manage users' expectations regarding the availability of results, we could:

1. Apply some logic to enable/disable the 'Download results' buttons?
2. Indicate if any results have been collected in the upload information box and provide default 'Download csv' buttons.

I was thinking they stay on the page and you're right about that then being not in-your-face how to get to the URL. Right-click and copy URL would work though, right? It does for the current Download statistics button. Not perfect but would be acceptable to me if we don't have a better solution. Sending people to a different page doesn't seem great to me somehow.

It's all quite opaque, yes... Right-clicking and copying the URL from a link is more obvious, but doing the same with a button (which is intended to represent an action) is definitely less common. Again, this task seems to only represent a first step towards completing the final goal of giving mismatch providers access to reviews for their uploads. Tried to collect next steps to improve the experience in a separate task T325368: [MFv3] Allow all mismatch providers to easily access reviews for their uploads.

Positioning and behavior look great! Nevertheless, the 'Download CSV' button seems to be inheriting the app's font styles (font-weight and family), which are overriding the WiKit component's styles. Here's a screenshot of the two buttons for comparison:

This made me realize that the Mismatch Finder store is not using WiKit font styles. I guess solving this would be part of the solution, although we might want to focus on the button for now and fix that later in a separate task? Not sure what the best order would be.

Moving back to To Do since style is not fixed yet

In T304794#8497452, @Sarai-WMDE wrote:

Positioning and behavior look great! Nevertheless, the 'Download CSV' button seems to be inheriting the app's font styles (font-weight and family), which are overriding the WiKit component's styles. Here's a screenshot of the two buttons for comparison:

This made me realize that the Mismatch Finder store is not using WiKit font styles. I guess solving this would be part of the solution, although we might want to focus on the button for now and fix that later in a separate task? Not sure what the best order would be.

Hi, @Sarai-WMDE I am a bit confused by the comment. Which one has the correct font?

Hi, @Sarai-WMDE I am a bit confused by the comment. Which one has the correct font?

The primary WiKit button used to 'Download statistics' displays overall the right styles (although the line-height is off, should be 1.25). The font styles of the new 'Download CSV' button seem to be completely overridden by the application's styles. For now, applying the default font family, weight and line-height to the new button would solve the issue.

Fun fact: the difference between the buttons’ font-family is

-'Lato', sans-serif
+-apple-system, "BlinkMacSystemFont", "Segoe UI", "Roboto", "Lato", "Helvetica", "Arial", sans-serif

so a developer without Apple, Microsoft or Android fonts couldn’t even have noticed this difference – on my system they both use Lato ^^

Fix for review: https://github.com/wmde/wikidata-mismatch-finder/pull/531

Indeed! Thanks for the exhaustive value/token replacement, Lucas 🙏🏻

Even if the token replacement was correctly done, the Mismatch Store buttons are not displaying the same styling as WiKit buttons when active. My guess is that this might be due to the order of the pseudo-classes: compare WiKit with MMStore. It might also be necessary to specify box-shadow: none; for said state in the app.scss file (see source).

Alright, I think it was the box-shadow indeed (at least I didn’t notice a difference when reordering the pseudo-classes): https://github.com/wmde/wikidata-mismatch-finder/pull/532

Hey, @LucasWerkmeister. Thanks so much for looking into this!
Sorry for being so vague in that initial comment. The difference in styling is not only related to the box-shadow, but to the active background and border colors. The buttons have the right active styles applied to them, but they don't present the right appearance on click. It looks like they rather display focus styling when activated. Here's a comparison (please note, the following are gifs):

WiKit	Mismatch Store

In our special circumstances (with a migration in the horizon), I'd say we shouldn't spend any more time on this unless the fix is apparent right away. The active state is deliberately pronounced in all our systems, but not applying it here won't most likely disturb the user's workflow.

I'd say we shouldn't spend any more time on this unless the fix is apparent right away.

I mean, I’ve uploaded what I think is a fix… and when I try that pull request locally, it looks to me like the Wikit GIFs you posted.

I mean, I’ve uploaded what I think is a fix… and when I try that pull request locally, it looks to me like the Wikit GIFs you posted.

Yep. Should have taken a look at the PR before posting that. Your previous comment made me assume that the only change done there was removing the box-shadow, but now I see that there was some pseudo-class reordering too. I unfortunately don't have a way to visualize the changes (haven't set up the local environment yet).

After our quick review: All looking great! Thanks for the changes again 💯 PR #532 approved.

Okay, should be ready to verify at https://mismatch-finder.toolforge.org/store/imports now :)

LGTUX! Buttons looking awesome and consistent. Thanks, Lucas!

This looks all good according to the acceptance criteria!

Thank you so much :)

But just wondering if we should keep the button on failed uploads?

But just wondering if we should keep the button on failed uploads?

Agh, good point. Sounds like a big oversight to me. The primary use of that button would be to allow mismatch providers to check the updated status of their CSV files. Failed uploads won't collect any reviews, so it sounds obvious that the button shouldn't be displayed in those cases. Unless I'm missing any other use case that the button could fulfill there. Subtask?