When should a download button in the content tab be shown

[mslw]

The change in 498c2787ebb78c618f32e0857255d0455e43a20e 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 https://github.com/psychoinformatics-de/sfb1451-projects-catalog/pull/50#issuecomment-1749094255

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:

• The change in question was prompted by https://github.com/psychoinformatics-de/sfb1451-projects-catalog/issues/43 where @jsheunis provided an analysis of what happens for (rather atypical) URL values that look like paths and are treated as relative.

[jsheunis]

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