InfoBox metadata table in connector popup

[abaevbog]

After translation, display a mini version of itemBox when user clicks on the chevron next to the name of a regular item.
On update, metadata is sent to the local Zotero server to update the data of the newly added item. That way,
one can verify what the metadata looks like and make adjustments without going back to the desktop app:
https://forums.zotero.org/discussion/comment/510105/#Comment_510105

In this example, you could manually add a missing abstract from a website whose metadata doesn't expose it:

Screen.Recording.2026-04-09.at.3.51.09.PM.mov

This could be a stepping stone for two future features: a more intelligent way to fetch metadata from the webpage when translation misses something (with an LLM call), and to enable handling of a duplicate item that the user already has saved in their library. In both of these cases, we would need a way to display the data and allow some kind of conflict resolution (e.g. #512 (comment)).

I am not 100% sure on the best design choice here, so @yexingsha, let me know what you think. I thought I would put this together so we have something concrete to look at.

cc: @dstillman (we very briefly discussed it in the context of why one would need to use "Webstite" as a new item type) and @adomasven - let me know what your thoughts are!

---

I also added a progressWindow_preview.html to load progressWindow.html popup and to allow claude to see the changes in the preview. It found it helpful to iterate on the popup faster (e.g. Claude can look at screenshots, which helps with layout work) - but it's not essential for this.

[adomasven]

While it's cool that you built this, I'm not sure if this really belongs in the connector or encourages what we want for Zotero.

If we want to make sure users get correct data via Zotero Connector, we should make sure translators are correct. This on the other hand discourages users from reporting incorrect metadata/translators, since you can just "quickly fix it". Although I'm not even sure if this is much faster than doing it in the Zotero UI.

In the end, if we want to improve saving correctness, we could consider adding a "provide feedback" button where users could submit feedback about translators somehow. LLMs could even be employed at that level to attempt to fix translators, by receiving human-curated feedback about what data is wrong. Although I'd probably consider starting with popping open a new thread on Zotero forums with some prefilled template text.

As for providing conflict resolution UI, I'd imagine we want to do something simpler in the Connector that shows just the key information, and if we want a complex conflict resolution workflow, we would probably reuse the UI/dialogs available from the Zotero client.

[abaevbog]

@adomasven, thank you for the notes! I think I didn't fully explain my reasoning for the use case initially - I added some more context below. Maybe the ItemBox like this is not exactly the perfect solution - what do you think could be the alternative?

---

If we want to make sure users get correct data via Zotero Connector, we should make sure translators are correct.

As the linked post states, sometimes the info is not exactly right just because of how it is provided and we cannot always anticipate all variations in which the metadata can come. Even in the example URL I used for the recording, provided author in COinS format is "Patric Lyon", but the recommended citation at the bottom of the page uses "Patric J. Lyon". And this other article will provide us with the author but not the editors - those are just listed in-line at the bottom in the "Recommended Citation" section. I don't think it's realistic to expect that a translator would be able to cover all these cases (e.g. parsing out the editor correctly from a simple <p> node) for all the websites out there.

So I'm under impression that at least some kind of manual intervention sometimes cannot be avoided? And if so, I can see how having to go to the browser first to save the page and then go back to the main Zotero window to do the edits would feel like extra friction. We strongly encourage people to use the connector, and actually enforce it in some cases by disabling the "Website" as the item type for new items in Zotero. So we might as well try to make this workflow smoother?

Although I'm not even sure if this is much faster than doing it in the Zotero UI.

My impression is that it's not about it being faster per se but about not having to jump between windows if you feel the need to ensure the data is correct. If you have a website open, and you save it to Zotero, you need to jump to the Zotero window just to have a look at what kind of metadata was saved to confirm all looks good, and then return to the browser. The connector already knows what metadata is being saved, so why not at least allow one to see it and save the going back-and-forth between windows?

In the end, if we want to improve saving correctness, we could consider adding a "provide feedback" button where users could submit feedback about translators somehow. LLMs could even be employed at that level to attempt to fix translators, by receiving human-curated feedback about what data is wrong.

From the user perspective, providing feedback on which metadata is wrong on which page is likely too much work when you are in the middle of research. If the saved data is wrong, most people would just fix it manually, and then proceed with their work.

But if, say, there was a button to try to fetch data with the help of an LLM, it may be more appealing, since it can actually help you get the data right there and now and would be just 1 click. I would expect it to actually be used in scenarios with metadata that needs edits. We could then keep track of websites where such requests would come from to identify if we could add/update translators for those pages.

As for providing conflict resolution UI, I'd imagine we want to do something simpler in the Connector that shows just the key information, and if we want a complex conflict resolution workflow, we would probably reuse the UI/dialogs available from the Zotero client.

Yeah, I just mentioned it because it felt somewhat adjacent to displaying of the metadata - it may or may not be actually appropriate here.