Improve wording and position of "Display" and "Inline" in the web-UI.

[MoonlightWave-12]

Currently, "Display" opens a preview with technical information; while "Inline" opens the file directly.

When i upload multiple files and give someone a link to the list with them, they would either click the filename or the "Display"-link intuitively, which opens a page with technical information first, and a preview at the bottom (or a link to the file Bepasty cannot offer a preview for).

To many people, "Inline", which is what they probably should click on most of the time (to access the file directly), will not have a well understandable meaning in this context, which will likely result in many people ignoring it.
(I guess it means: "The link that is meant to be used in the same line as text.")

It would probably improve the usability of lists, if:

1. The position of "Display" and "Inline" were swapped, so that the first link (in the common from-left-to-right-order) is the one opening the file directly.
2. "Display" would be renamed to "Info", while "Inline" would be renamed to "Display".
3. The filename would open the file directly, like the current "Inline"-button.

[ThomasWaldmann]

It depends, as usual.

The "problem" with "inline" is that it navigates to a view with no user interface and also that browser behaviour varies depending on file type.

E.g. if you have a picture, it will only show the picture, but no UI with "download", "delete", etc.
If you have a .bin file, it would download just it. So naming that "display" or "download" would only be correct for some types and incorrect for others.

The missing UI is the main reason why this is not the default or "first link".

I agree that "inline" is maybe not the best understandable wording - it comes from the implementation, that uses the content-disposition: inline http header.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition

[MoonlightWave-12]

How about changing "Display" to "Preview" and "Inline" to "Open file" or "Open"?
To me, it seems like a good improvement, describing what will happen after choosing these options more accurately.

[ThomasWaldmann]

I don't see why Preview is better/different than Display.

"Open" does not fit for the file types which the browser would just save to the Download folder.

[MoonlightWave-12]

I don't see why Preview is better/different than Display.

Mostly for 2 reasons:

1. "Display" does not always just display the original file with UI around it.
   Images are scaled down to fit into the available area, if they do not fit already, while there is no way to show them at the original size in the Bepasty-UI (except for the "Inline"-link).
   When opening a PDF-file with it, there may be just a link to it, if the webbrowser cannot show it there; which is how it is with Firefox.
   With many other file-types it will only show "Can't render this content type." below the technical information.
   So, it tries to show a view of the file that does fit into the UI and it will give some information about the file, like type, size, checksum, and upload-date.
   That is essentially a preview-function, which may also show the whole file (if it happens to fit in there and is compatible with the webbrowser).
   With text it is actually more than a preview, though; so, maybe keep "Display" for text, and change it for other file-types?
2. Because it would seem like there were 2 options doing basically the same thing, if there were "Open" and "Display" in the same menu.

"Open" does not fit for the file types which the browser would just save to the Download folder.

It will be far more understandable what will happen after clicking/tapping on it, though.
With it being called "Inline", it is basically "try it and see what happens".

Also:
It will basically be opened in the webbrowser first, which then decides to download it.
What happens when opening a specific file-type can be configured by the user, if the webbrowser has settings for it; Firefox does have such settings, for example.

---

Apparently, on GitHub, CTRL + Return instantly submits a comment without asking for confirmation, so i sent a draft of this comment unintentionally.
I mentioned there, that Firefox was also downloading PDFs when opening them, but that is apparently dependent on something, because it didn't happen when i opened a PDF over Bepasty to verify it actually does so.

[ThomasWaldmann]

We can look at how github does this:

text file

https://github.com/bepasty/bepasty-server/blob/master/AUTHORS

• default view is rendered, including the github UI
• there is a "Raw" link in the UI that just displays the raw content (like "inline" does for bepasty)

image (svg)

https://github.com/bepasty/bepasty-server/blob/master/src/bepasty/static/app/bepasty.svg

• default view is rendered, including the github UI
• there is a "Raw" link in the UI that just displays the raw content (like "inline" does for bepasty)

pdf

https://github.com/pdf-association/pdf20examples/blob/master/Simple%20PDF%202.0%20file.pdf

• default view is rendered, including the github UI
• there is a "Raw" link in the UI that just downloads the PDF

binary (can't be rendered by browser)

https://github.com/borgbackup/borg/blob/master/src/borg/testsuite/archiver/repo12.tar.gz

• default view just has a link to "raw" file
• there is a "Raw" link in the UI that just downloads the file

[MoonlightWave-12]

This became a lot more complicated than i expected when i opened this issue, but anyway, here are my thoughts about it.

---

The context is a Bepasty-list like this one:

Currently, what i am still asking for is this:
Change the label of the "inline"-button to something more understandable, and change other labels to avoid ambiguity if necessary.
The default-option could probably be better discussed in a separate issue.

This is what i think about the "inline"-label:
"inline" does not make much sense on a UI about accessing files; and clicking the button that is labeled with it will do exactly what the webbrowser does when it opens a given file.
If that results in a download, then that is what the webbrowser has been configured to do, and it will be one step closer to actually opening the file in an appropriate app, by, for example, clicking on it in the download-list of the webbrowser.

So "open" would currently be the best option for replacing the label "inline".

However, having both "display" and "open" would be a bit ambiguous, so my suggestion is to rename "display" to "preview", which would be an even more accurate label for it, because it does show many files, especially images, less accurately than a webbrowser (or another appropriate app) would, if they were opened directly with it.

---

We can look at how github does this:

GitHub labels it as a "Preview" when it shows files other than text/code, it seems:

there is a "Raw" link in the UI that just displays the raw content (like "inline" does for bepasty)

"Raw" (as in "raw file"/"raw data"), can probably be understood by GitHub's intended user-group (which is developers), so that is somewhat okay on GitHub; it would be better understandable as "Raw file"/"Raw data" though, or even just "Open", like i am suggesting.

People without relevant technical knowledge would probably not understand well enough what it does when just reading "Raw".
Actually, i understand some technical things, but did not understand that it would directly open a file either, until i just tried it after looking around the entire UI for a way to open a file directly and noticing that the other options there would not do that.
"Raw" still feels to me like a badly chosen wording that should be improved, even after knowing about it for months.

[ThomasWaldmann]

Yeah, guess it could be:

• Preview (or Info) instead of Display
• Download
• Open instead of Inline

"Info" would indicate that it also shows related metadata of the file (but would not necessarily imply that it tries to show a preview also). "Info & Preview" maybe? Or "Details"?

BTW, had a look at the code:

blueprint.add_url_rule('/<itemname:name>', view_func=DisplayView.as_view('display'))
blueprint.add_url_rule('/<itemname:name>/+download', view_func=DownloadView.as_view('download'))
blueprint.add_url_rule('/<itemname:name>/+inline', view_func=InlineView.as_view('inline'))

So the download/inline labels directly correspond to the URL (having /+download and /+inline) and display is the default URL (with that /+action) part.

The views:

class DownloadView(MethodView):
    content_disposition = 'attachment'  # to trigger download

    ...

class InlineView(DownloadView):
    content_disposition = 'inline'  # to trigger viewing in browser, for some types

So, InlineView is exactly the same as DownloadView, just that they use a different content-disposition http header.

So, the code and URLs are somewhat consistent.

[MoonlightWave-12]

Yeah, guess it could be:

• Preview (or Info) instead of Display
• Download
• Open instead of Inline

Yup, that is what i was imagining. :)
preview, download, open, delete, (un)lock.

"Info" would indicate that it also shows related metadata of the file (but would not necessarily imply that it tries to show a preview also). "Info & Preview" maybe? Or "Details"?

It would probably be good to just change it to "preview" and "open" for now.
The other options would either: more strongly affect what people click first, introduce style-issues, or require some more work.

• "Info & Preview" does give more information, and that is good; but it would then be the only noun among verbs related to "file" or "list":
  Info & Preview, download, open, delete, (un)lock.
  It is more informative, it explains better what it will show, but looks a bit out of place, especially when considering that the column is labeled "Actions". It would be a bit of a trade-off between style and usability.
  I also think that "preview" should be mentioned before "info", because it is currently supposed to be the primary purpose of it.

• "show preview and info" (or "show preview and details") would work better, but would be quite long.
  show preview and info, download, open, delete, (un)lock.
  I guess one could also make it like this; on 2 lines, if there is enough space:
  show preview and info
download, open, delete, (un)lock.
  It would make it more obvious which one is supposed to be "the one to click first" too.
  When there is not much space, it could be reduced to "preview"

• "Details" and "Info" would usually be clicked first, when one wants more information about the file.
  If the preview-page-button would be labelled only with either of these, people would probably usually click open or the filename first, if they want to see the image.

BTW, had a look at the code:
…
So the download/inline labels directly correspond to the URL (having /+download and /+inline) and display is the default URL (with that /+action) part.
…
So, the code and URLs are somewhat consistent.

One could add /+open and make it behave exactly like the current +/inline.
The +/inline-URLs should continue to work as before, because such links have been shared/used.

---

I just noticed that "preview" would not work ideally with Bepasty-lists that are opened from another listing, because it is their intended view, and not just a preview.
Handling this in an ideal way would require labelling buttons depending on the file-type, i guess.
Labelling Bepasty-lists with "view list" seems good to me.

So, much, discussion, about, changing, two, words! 😆