• We should include a release note for this and include doc changes
• @mheppler to check in with @qqmyers to check that this makes sense for QDR previewers (annotations?)
• There is currently functionality that allows a tool to be set up with explore and preview. We don't have a way of setting up a tool to just have preview, and no explore.
• We should also remove the explore button on the dataset page (noted above, but putting emphasis here)
• There are a few ways to make this change in the backend (@scolapasta to add some thoughts)

Current design is that all tools are "Explore" tools (or "Configure" but that's a different case) and that a subset of those "Explore" tools can be preview the "hasPreviewMode" boolean is true.

In order to support tools that are not explore tools, but have preview, here is a quick brain dump of some ideas:

1. change this boolean to allow for not just true false, but something like "preview", "explore", "both". The challenge here is that we have a 2nd attribute called "type" where a tool is defined as "Explore" or "Configure". So it would be strange for a tool to be of type Explore but not be considered Explore.
2. keep the boolean, and if true, don't show as explore. if you want something to be both have two rows. Has the same issues as (1) and also duplicated info (like, name, description, etc), that would need to change in two places.
3. Have a new "type" of tool: Preview. That is for preview and not explore. Explore tools could still be both if hasPreviewMode is set to true. Still not great, as you know have a weird hasPreviewMode for tools that are of type Preview.
4. Only have this type, and remove the boolean; using multiple rows for ones that have both. Has same duplicate issue as (2).
5. Solution #1, but change the "types" from Explore and Configure to different terms that are more precise on what they mean. "Explore" real means, users have read access; "Configure" means users have write access. However, not sure what the modes for the hasPreview non boolean would now be since I earlier described them as "preview", "explore", "both".

I'm not sure what my preferred approach is but thought I'd get these down to hear others thoughts, any other ideas.

@qqmyers flagged this for me -- for QDR this wouldn't be great. We have many projects with 50-1000 files for which the previewers provide a quick way to look at some files. They're also easy to discover for users browsing the repository.
Relegating them to the file page would mean:

• an extra click for every previewed file
• less chance for casual users to even discover this is an option

This is not specific to the annotation previewer. I'd actually say it most applies to the PDF one, but it's a general concern.

Thanks @adam3smith for the feedback! There are still a few items in front of this, so we will have time to discuss.

HI @adam3smith, thanks for chiming in. In many cases this change would not add a step or hide functionality, as there would be a "Preview" button on the dataset page in the file table where "Explore" is now (see images), that loads the preview on the file page.

At first we thought that previews would be truncated views, but this is not what is happening.
Previews in file pages provide much of the same functionality as when the Preview is opened in its own page, as happens now with Explore. (example: https://dataverse.harvard.edu/file.xhtml?persistentId=doi:10.7910/DVN/J1WUVW/Q7LPOD&version=1.0, or even https://openforestdata.pl/file.xhtml?fileId=58&datasetVersionId=31)

In some cases there is benefit to seeing the previews in the context of the file page, as file page functionality is more readily discoverable. One idea is to allow users to click through file pages/previews in a dataset on the file page, without having to go back to the dataset page.

I see that for QDR having the preview on the file page would mean the "acceptance" popup would be between users and the file page. How do you see that the previews facilitate discovery on QDR?

QDR:

Dataverse 5.0:

Hey @adam3smith, good to see you at a few of the Dataverse Community Meeting events last week. Do you have any thoughts on @TaniaSchlatter's note above? We'll be spending some time in this area in the near future. Thank you!

One thing I'm not sure I've seen noted yet - previewers in the page are only allowed for public data so far. The buttons work for restricted datafiles (because they can trigger the terms and conditions dialogs).
And a thought if there isn't consensus - the 'preview' flag that was added to the externalTools manifests currently adds 'shows up in the page' but doesn't stop the 'shows up as a button' - reworking how such flags work could make it a decision for the admin when you register tools as to how they show up.

I'm not 100% sure I follow exactly how the 5.0 relationship between file pages and previewers will look, so I may be off here and/or require another round of clarifications.

So this

In many cases this change would not add a step or hide functionality, as there would be a "Preview" button on the dataset page in the file table where "Explore" is now (see images), that loads the preview on the file page.

and the screenshot look good to me. Would the previews then be accessible on both the file landing page (directly in the preview tab) and via button in the dataset landing page's file list (which would then go to the preview tab or would it go to an external page)? That'd definitely be nice and I have no concerns.

I see that for QDR having the preview on the file page would mean the "acceptance" popup would be between users and the file page. How do you see that the previews facilitate discovery on QDR?

That might be a problem -- less from a user perspective than from a DOI best practice perspective: landing pages for DOIs should always be accessible, even when the actual file is restricted, and they should not require registration (and presumably no pop up requiring interaction accepting terms&conditions either).

@adam3smith, the previews would be accessible on both the file landing page (directly in the preview tab) and via button in the dataset landing page's file list, which goes to the preview tab.

Good point about the DOI for the file not being accessible if there is an acceptance popup before users get to the file page. I wonder about a flow like:

• user clicks eye/preview button in the file list on the dataset page

• file page is loaded with acceptance popup content and checkbox in the Preview tab, instead of the preview

• user accepts terms, and the preview loads in the preview tab on the file page.

Would providing access to the file DOI while keeping the preview hidden until the user accepts terms address the concerns you raise? Displaying simple form in a tab to enable access to content in the tab would be a unique interaction/UI convention, which is not ideal. We can discuss and see about additional approaches if the functionality meets the needs.

Functionality-wise that'd absolutely work, yes.
I'd share your worry that an accept dialog in the preview tab is a bit unexpected, but I would be cautiously optimistic that users would get it, especially if worded&styled right.