Skip to content

/ dataverse

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Preview Tools - Remove external preview tools connection to Explore btn on dataset/file pgs #6919

Open
mheppler opened this issue May 19, 2020 · 4 comments
Open

Preview Tools - Remove external preview tools connection to Explore btn on dataset/file pgs #6919

mheppler opened this issue May 19, 2020 · 4 comments
Labels
Feature: External Tool Medium
Projects
IQSS/dataverse

Comments

@mheppler
Copy link
Contributor

@mheppler mheppler commented May 19, 2020 •
edited

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.

Screen Shot 2020-05-19 at 4 05 07 PM

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 djbrooke added this to Up Next 🛎 in IQSS/dataverse May 19, 2020
@djbrooke
Copy link
Contributor

@djbrooke djbrooke commented May 20, 2020 •
edited

  • 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)
@djbrooke djbrooke added the Medium label May 20, 2020
@scolapasta
Copy link
Contributor

@scolapasta scolapasta commented May 20, 2020 •
edited

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.
@adam3smith
Copy link

@adam3smith adam3smith commented May 21, 2020 •
edited

@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
Copy link
Contributor

@djbrooke djbrooke commented May 21, 2020

Thanks @adam3smith for the feedback! There are still a few items in front of this, so we will have time to discuss.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature: External Tool Medium
Projects
IQSS/dataverse
Up Next 🛎
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
@adam3smith @mheppler @scolapasta @djbrooke
You can’t perform that action at this time.