Skip to content
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

When should a download button in the content tab be shown #380

Open
mslw opened this issue Oct 5, 2023 · 1 comment
Open

When should a download button in the content tab be shown #380

mslw opened this issue Oct 5, 2023 · 1 comment

Comments

@mslw
Copy link
Collaborator

mslw commented Oct 5, 2023

The change in 498c278 makes the catalog display a file download button in the content tab only if the file content URL is http(s). I think it is overly restrictive.

As an alternative, I would propose that a download button should be reported for any URL that has a scheme (in Python terms, that would mean urlparse(url).scheme != "" instead of urlparse(url).scheme.startswith("http")). That would eliminate the situation where a url is treated as relative to the catalog location without excluding things like e.g. (s)ftp.

Premises:

  • It is ok if a url cannot generally be accessed (due to credentials, specific network, required handler).
    • It might be for some users (who have credentials, etc.).
    • Displaying such URL still communicates information (knowing it exists, what the netloc is).
  • Protocols like (s)ftp are, I suppose, less common but also reasonable to use for content urls.
    • While a browser may be unable to open them, other programs can be registered as handlers (alternatively copy&paste).
  • Being http(s) does not guarantee that its content can be accessed, and we can't know that from looking at the url alone (see first point)

This is not to suggest a quick change, but rather to understand better what is the desired behavior and role of the URL/download display in the content tab.


Counterpoint by @jsheunis from sfb1451/metadata-catalog#50 (comment)

I agree the current state is a somewhat blunt "fix". I do think the UX is important though, and having a download button that always fails is bad UX. I would suggest more fit-for-purpose functionality, such as having a scheme for interpretation and having different renderings and UX accordingly.


Previous discussions:

@jsheunis
Copy link
Member

jsheunis commented Oct 6, 2023

Thanks for the write-up! Will get back to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants