Preview Tools - New external tool preview type config setting, icon btn on dataset/file pgs

[mheppler]

PROBLEM

How do I set a preview tool ONLY, with no explore tool btn displayed?

When a sysadmin configures one of the Dataverse Previewers (e.g. Text Preview or PDF Preview) external tools to their installation, it adds not only a "Preview" tab with embedded tool view to the file pg, but also an "Explore" button to both the file pg and the dataset pg (the same Explore btn tools like Two Ravens, World Map and Data Explorer are linked from, see screenshot below, example on Harvard Dataverse).

In our UI, both the preview and explore workflows are linked to the same tool. This implies the same tool provides two features, when in fact all the Dataverse Previewers external tools configured in Harvard Dataverse provide only one "preview" feature. When you click the "Explore" btn, you are provided the exact same view of the file that is embedded on the file pg, with no additional features, with the exception of the citation and download btn -- the same information also provided on said file pg. The full version of the Dataverse Previewers external tools look so similar to the file pg, in fact, that I question the value it provides the user when they click the "Explore" btn.

PROPOSAL

I suggest there is more value having users go to the file pg as opposed to clicking Explore and go to the landing pg of an external preview tool when said tool is embedded directly on the file pg. As such, we should remove preview tools from being linked to the Explore btn of the dataset and file pgs. In the Preview tab, the "Explore on {PREVIEW TOOL NAME}" btn should instead be labeled "Open preview tool in new window..." or something more succinct, to remove any implication of additional features when clicking the button.

[djbrooke]

• 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)

[scolapasta]

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 now 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 merge master into beta #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.

[adam3smith]

@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.

[djbrooke]

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

[TaniaSchlatter]

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:

[djbrooke]

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!

[qqmyers]

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.

[adam3smith]

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).

[TaniaSchlatter]

@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.

[adam3smith]

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.

[TaniaSchlatter]

Summary of the discussion the in design meeting July 8:

• Previews are configured to display only for open data.
• Previewers only work without terms in place.
• Cases where a file preview may not be available are:
  • Restricted files with access request
  • Restricted files without access request
  • Datasets that have guestbooks enabled
  • Datasets that have terms that need to be agreed to
  • Files that are of a type that don't currently have a previewer associated
• Previews are currently coupled with, and enabled by "Explore". Enabling Explore enables the Preview button and Preview tab
• This issue decouples Explore and Preview.
• We assume that QDR will be able to keep their Preview as part of enabling Explore, as now.

[TaniaSchlatter]

Next steps

• create new “preview tool” config setting (more detail required from Gustavo)
  • NOTE GDCC preview tools require hasPreviewMode parameter in new config setting
• add new Preview btn to file-level actions in file table on dataset pg
  • new btn added to filesFragment, needs render config logic, similar to getExploreToolsForDataFile
• add render logic to Preview tab on file pg for new config setting
  • NOTE no new render logic should be added to Explore btn on dataset or file pgs
• in preview tab, change btn label text from “Explore on {TOOL NAME}” to “Open {TOOL NAME} in New Window”
  • NOTE review if necessary once new preview render logic is added, might not need to change for explore config
• add display of guestbook/terms, accept btn in preview tab to prompt user before tool loads
  • validate proposed approach from the technical standpoint: file pg loads with dataset terms displayed in Preview tab in place of embedded preview tool (see mock up below), user agrees to terms (QDR, not restricted files), page will reload and display the embedded view of the preview tool
  • NOTE terms and guestbook functionality are in the same popup, request access is separate, and is only for restricted files
• update UI msgs (e.g. help, tooltip, info, error, success, et al)
  • change to "file access" ... terms tab > guestbook help msg ref to "file download" but as includes explore, preview, et al
• test with several external preview types
• update guides to explain new config options and clarify that not all EXTERNAL tools are EXPLORE tools
  • review all mentions of TwoRavens, GeoConnect/Worldmap, explore tools, make clear these tools are modular, and that other external explore tools may be configured (Revise Explore Tools documentation to reflect modularity #4429)
• release note outlining new option for configuring the GDCC preview tools, explain nothing needs to be changed if you set up these tools as “explore” tools with the hasPreviewMode parameter and prefer them listed in the UI under the Explore btn

Mockup