search

element-hq / element-web

A glossy Matrix collaboration client for the web.
https://element.io
Apache License 2.0
10.96k stars 1.95k forks source link

New download interaction hard to discover #18238

Closed nadonomy closed 3 years ago

nadonomy commented 3 years ago
Screenshot 2021-07-26 at 17 26 43

The UI on the left is non interactable. I spent a while wondering what was broken. The download interaction in the message action bar is nice, but I think you should be able to download files by just autopiloting to click on the large button/tile in the timeline too.

A simple pragmatic tweak for this would be to:

  1. Make the button on the left clickable.
  2. Ensure the cursor changes on hover to aid discoverability.
  3. Stretch if not difficult: Tooltips.
    1. If the filename doesn't fit on screen, show on immediate hover in one of our tooltips.
    2. Truncate filename (max chars 25-30ish?). Always show file extension.
    3. Show file size, stylising as e.g.: Filename.ext (20MB)

Given the entire component is visually stylised as a button, I have confidence in the interaction being discoverable enough for most users. However, we should be on alert to iterate if we get feedback otherwise.

If we learn users benefit from seeing file size in all cases, we should also iterate further on on the design.

HarHarLinks commented 3 years ago

In case of an image, "hiding" the download button makes sense, since the primary action is viewing the image (and clicking it to go full screen). Same for video and other media with visual primary interactions. In case of other files, their visualization is generated by the UI anyway. Things that are not interactive in-place should have download (or perhaps even default-open), as suggested by OP. I would even argue that these app-decided abstract UI things should have a visual cue to "hey click this to download/open", i.e. download button always. This would even apply for e.g. audio (may or may not to voice messages).

This can change when primary actions become something else, e.g. rich inline preview/display of code/plaintext files, however even then a download button should be right there.

In my opinion, the complete loss of what used to be a caption Filename.ext (size MB) *click to download* into nothingness and a hidden button is a big 3 steps backwards in the wrong direction.

nadonomy commented 3 years ago

@HarHarLinks thanks for the input, totally agree. I've just updated the main issue with some quick/pragmatic fixes we should be able to action to improve this within this release cycle.

@turt2live @dbkr I added a stretch goal on tooltips in 3. If you think this is too large a scope for this release cycle, let me know and I'll file as a separate issue for us to follow up on separately.

(@gaelledel also tagging for visibility; moving quickly/being a bit directive on this so we can act quickly!)

HarHarLinks commented 3 years ago

See also: #18197 and more

Here is some similar UI in app.cinny.in image This is similar to my suggestion of having a visible download button right on screen, where it is most useful for generic files.

image These are nicer than current stable element, but not the direction current develop is going. Perhaps the bar with info and buttons could instead appear (roll down) on hover? Mockup with develop as baseline: Element Mockup

turt2live commented 3 years ago

@nadonomy for simplicity, would it be okay to always show the tooltip on hover rather than checking on-screen-ness?

nadonomy commented 3 years ago

@HarHarLinks interesting! Please could you file any ideas as a new issue/feature request? We're using this issue to track some pragmatic changes we can action within our current release cycle. Ignore. Can see this is already being tracked in https://github.com/vector-im/element-web/issues/18197, thanks!


> @nadonomy for simplicity, would it be okay to always show the tooltip on hover rather than checking on-screen-ness?

@turt2live not sure I'm grokking your question exactly. Can you rephrase? I was trying to request/perhaps failing to communicate for us to (1) use our own tooltips, to avoid the lag on showing native HTML ones (2) on hover. Does that match?

SimonBrandner commented 3 years ago

@HarHarLinks interesting! Please could you file any ideas as a new issue/feature request? We're using this issue to track some pragmatic changes we can action within our current release cycle.

It already is a separate issues: https://github.com/vector-im/element-web/issues/18197

nadonomy commented 3 years ago

@SimonBrandner edited before your comment, but thx!

turt2live commented 3 years ago

@nadonomy essentially doing this to your requirements: image

😇

nadonomy commented 3 years ago

@turt2live ah gotcha. Sorry, thought you were trying to describe an alternate hover interaction related to on-screen-ness!

Yep as a first cut (and for this release). My concern is if it ends up feeling redundant. Would also be happy to quickly screen share and rubber duck through how it feels in practise if that would be the most productive.

HarHarLinks commented 3 years ago

image

nightly 21-08-02

could be slightly better: size unit is cut off in the main UI thing so it's useless, random linebreak in the tooltip.

tbh the tooltip could just always linebreak (right align)