File preview on the file page only

[TaniaSchlatter]

Per discussion in the design meeting 3/30/17, users should preview a file on the file page, in the image window. Thumbnails should link to the file page.

Recommend that manipulating or exploring a mapped file should happen in the native application (World Map), and not in iframes or other intermediary windows.

Desired behavior by file type (per meeting with Mercè 4/11/17):

• Static files: .pdf & images load a larger image on the file page when clicked.
• Tabular data/data that can be processed: show variable info and summary stats, Explore button.
• Geospatial data: show preview image on the file page and Map Data button.

[TaniaSchlatter]

Mockups are in progress for testing.

Preview types we know of now:

• image (multiple sub types)
• .pdf
• video
• sound
• HTML
• Hypothesis annotations
• tabular
• shape
• Fits
• text
• .zip
• SBGrid molecular structures

Plan to provide previews of some types, and expand the idea of the external tools framework to generate previews that will be displayed on the file page.

[TaniaSchlatter]

Related issues:
#5746 - Host and preview HTML files in Dataverse
#5459 - Support for Hypothesis notations
#5456 - External tools for other mimetypes
#5738 - Add previewers as external tools in docs

[djbrooke]

• We should investigate contributing to the preview repos developed by QDR and having them provide a preview that can be displayed on the file page (@scolapasta is following up with @qqmyers )
• On the file page we need to add the infrastructure to display the preview provided by an external tool
• How should we handle guestbook/access restrictions (you can see the whole PDF through preview, so this could be a way to circumvent the usual flow)? Consider showing the on-page preview for files that aren't restricted.

[scolapasta]

Discussed with @qqmyers should be straightforward to add a preview mode (by sending additional parameter, possible something like "embedded=true".

So next step is for us to build up the infrastructure on the Dataverse side (as we can test even without preview being supported by the external tool and confirm we are able to display correctly the external site).

Basically, we need the ability to configure an external tool to be used as the previewer for that file type (should we add a table that has a column for file type and a foreign key to the external tool?*) and then embed that external tool in an iframe on the page. We can also decide on all the logic for when to show preview vs something else (e.g. file has to be public, questions on ToU / guestbook).

(*) others questions to figure out are: should any external tool be configurable here or should we define a subset of tills that are "previewers" (i.e. support the embed tag)? Will there be some tools that are only previewers?

[qqmyers]

@scolapasta - wr.t. "configure an external tool to be used as the previewer for that file type " - the tool table has already been extended to have a mimetype, providing a minimal solution. It might be nice to allow a previewer to be registered for multiple mime-types, e.g. the same image and video previewer works for multiple image/video mimetypes and that currently requires registering the same tool multiple times, which might get you back to a mimetype to tool table.

It's an interesting question regarding previewers versus external tools - my guess is that just categorizing by whether a tool supports embedding is enough and that it would be good to avoid trying to make previewers a, for example, read-only subset of tools. Right now, tools can get an apiKey which means that analysis tools can write and an embedded tool could potentially be more than a previewer (e.g. an image previewer that lets you tag faces/record metadata about the image.) Limiting to one previewer per file, or allowing only read-only tools to embed seem like artificial limits (versus allowing site admins to decide which previewers to enable and making tool developers responsible for making a usable GUI if they want to work in embedded mode.).

[djbrooke]

What we need before this is ready for development:

• The spike evaluating the technical feasibility to be successfully completed (Spike: embed external tool in file page as a preview #6048)
• Internal review of the functionality and planned UI
• Usability review by IQSS team and/or community members
• Front end code (before it's brought into a sprint or in a sprint)

[mheppler]

In the dev branch 3758-file-pg-preview, added TODO comments to file.xhtml listing remaining tasks, as outlined in my comment on the spike issue (#6048). Happy to help define and complete these tasks before, during or after development.

• configuration setting and render logic for external preview tools
• maintain WorldMap hard coded feature
• responsive sizing for iframe
• noframes option, appropriate role and title attributes [ref, ref]
• mixed content (HTTPS vs HTTP)
• lazy loading and/or defering scripts

[pdurbin]

support hasPreviewMode in the external tool manifest file (JSON format)

I tried this today as of 7118939 and it worked great! Thanks, @sekmiller ! You made working on #6210 easier. There's a new screenshot of how a tabular file looks in the Preview window as of that commit in a new pull request I just made at https://github.com/QualitativeDataRepository/dataverse-previewers/pull/27

[djbrooke]

Thanks @sekmiller for taking us through this. Feedback from Design Meeting:

• Change the magnifying glass preview button to another button (there was one that was used previously for Worldmap that may be used here)
• Discussion about whether or not to move the explore button to the bottom of the page, next to the preview. We could consider launch/open something else, but this potentially introduces another concept for users. We decided to add an "Open" button here below the folks.
• We should verify that the preview tools respect terms/restrictions.
• How are the tools ordered? Alpha for now is OK.

Removing @mheppler from this issue as it's the @sekmiller show for now!

[sekmiller]

@TaniaSchlatter, @djbrooke et. al. when a file is restricted or subject to Terms/Guestbook, (that is ineligible to have the download url posted) should we omit the preview tab or display the preview tab with some kind of message like "Preview unavailable for this file/dataset"?

Note: the public url is simply omitted from the metadata tab if the file has terms/guestbook.

[djbrooke]

@sekmiller @TaniaSchlatter yes, we should use the same logic that we use for displaying that download URL. I think the message should be the same for this case and for those file types that do not have previews. "Preview unavailable for this file" is fine with me.

[mheppler]

I suggest we hide the tab all together. We don't have an "...unavailable" msg for Download URL or any other feature we hide because of permissions.

If we wanted to spend another half day thinking+developing this, we could consider a workflow that adds a Preview btn to the top of the page, that displays the terms/guestbook when it is clicked, and launches the preview tool in a new window. This is how the explore tools work.

The fact that a dataset has terms/guestbook is not an uncommon trait. In fact, I'd guess that is becoming more the norm. If these preview tools provide any value, we should make them available to as many people as possible, for as many files as possible.

With DataTags (#871) in the pipeline, I am sure we will review terms/guestbook in much detail, and review features to improve the over all user experience for working with data files that have terms/guestbook (#1420, #4391, #4978).

[sekmiller]

I'm with @mheppler on this one. Displaying a "not available" message will be confusing/annoying to users. Adding a button to take you through the terms/guestbook popup would be a bit more work but probably worth it in the long run.

[djbrooke]

@mheppler @sekmiller thanks for the discussion. I don't feel strongly about hiding the tab vs. showing the tab and having a message, but I do think having the message about why a preview is not available is less confusing than just having the preview tab for some files and not others. A message provides us the opportunity to say a few words about why it's not available using a tool tip/popover or words in the message itself.

That being said, having someone click onto a preview tab (I assume in this case the metadata tab would be the default) with high hopes of seeing a preview and then just getting the message wouldn't be great either.

We can discuss briefly after standup. I can see the merits and drawbacks of either approach.

Tagging @TaniaSchlatter to give her a heads up on the discussion.

[djbrooke]

Thanks @scolapasta @TaniaSchlatter @mheppler @pdurbin for discussing after standup. At @TaniaSchlatter's suggestion, we said that I'd inventory the cases and then we'd get back together. The 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

Note that a file may meet one or more of these criteria. At this time, I don't want to build any workflows for accepting terms, filling out guestbooks, or requesting access to restricted files in the context of a preview. This is a question of scope for now and I understand that we want to do this eventually.

With this information, I hope we'll make a more informed decision about what to display in this no-preview case.

[TaniaSchlatter]

I broke out two types of restricted files in the list above. I'm ready to discuss. Or, I can just chime in with my 2 cents here; for near term I agree we should hide the preview tab in the cases listed above.

[djbrooke]

Thanks @TaniaSchlatter @sekmiller @mheppler for the discussion about this. We will show no preview tab for the file conditions listed above. On to Code Review!!!

[pdurbin]

If anyone is interested in "before" and "after" screenshots, you can find some at IQSS/dataverse-ansible#129

[pdurbin]

Here are screenshots of the final implementation:

screenshot 1

screenshot 2