Page MenuHomePhabricator

UI of SelectFileWidget may not be sufficiently obvious (unclear how to choose the file?)
Closed, ResolvedPublic

Description

The UI of SelectFileWidget may not be sufficiently obvious. The usual interface possibly does not look very clickable (and has very delicate hover effect), it has been modelled on DropdownWidget apparently. The drag-drop interface does not make it sufficiently obvious that you can click it to browse.

MediaWiki theme
Apex theme

Event Timeline

Jdforrester-WMF assigned this task to Prtksxna.
Jdforrester-WMF raised the priority of this task from to Needs Triage.
Jdforrester-WMF updated the task description. (Show Details)
Restricted Application added subscribers: Matanya, Aklapper. · View Herald TranscriptAug 19 2015, 5:17 PM

The patch https://gerrit.wikimedia.org/r/#/c/231220/, adds a config to SelectFileWidget that makes it look like this, without changing the functionality.

Normal

Drop/Hover

(edited conversation from the patch)

@Esanders
I think the design needs some work. The border is too strong, as is the hover state.
I'm also not sure about using the drop target as a select file button as it makes that feature (browse to select) less discoverable.


@Prtksxna

The border is too strong, as is the hover state.

Do you like the one in Apex better?

Also it shouldn't have a hover state, but a drag over state

I thought having both can't hurt.

I'm also not sure about using the drop target as a select file button as it makes that feature (browse to select) less discoverable.

When this config option is selected, we don't need to highlight the 'click to browse' feature. The primary action that the user should understand is that a file needs to be dropped in this area. If they discover the additional functionality by hovering, or clicking on it, then its a bonus.
Is that the right way to think about this? What do you think?


@Esanders

Do you like the one in Apex better?

Yes, but maybe the text should be draker, given that it's more of an important instruction than a typical placeholder?

I thought having both can't hurt.

Depends on the next question:

When this config option is selected, we don't need to highlight the 'click to browse' feature. The primary action that the user should understand is that a file needs to be dropped in this area. If they discover the additional functionality by hovering, or clicking on it, then its a bonus.
Is that the right way to think about this? What do you think?

I think drop to upload is almost always considered as an addition to "normal" browse upload, and this is what you see on most sites. I suspect it's a considerably more accessible process too and as an accessibility feature we should keep it visible. Personally, I don't think drop is ever the primary action, but rather: "if you already have the folder open, this might be quicker"


@Anomie

I think drop to upload is almost always considered as an addition to "normal" browse upload, and this is what you see on most sites. I suspect it's a considerably more accessible process too and as an accessibility feature we should keep it visible. Personally, I don't think drop is ever the primary action, but rather: "if you already have the folder open, this might be quicker"

I agree. In my environment I don't have any easy way of dragging and dropping files, for example, which makes T165: Provide a way to upload a file in Phabricator if drag'n'drop is not available or not wanted annoying.


@matmarex
For me dragging and dropping is always more convenient than looking up the directory again, except when I have the exact file path copied from console or something.


@Prtksxna

PS3: Make label darker and update default label.
People use both, and we can support both without much trouble. Hitting enter still opens the browse dialog, so its keyboard accessible.


@Esanders
The browse feature is not discoverable though. Another part of accessibility is having the correct messages on the screen. This only has "Drag files here" so nothing to indicate they should try clicking/pressing enter.
For users who just prefer/have to use browse - this would be confusing. It wouldn't add much to the control to include both, and it is a pretty common design for file upload widgets.


@Prtksxna

This only has "Drag files here" so nothing to indicate they should try clicking/pressing enter.

As I mentioned in my second to last comment, I've updated this.


@Esanders
That feels like a bit of a half fix to me. Personally I think the regular upload widget is a bit lacking in this area too, it should a clearly clickable primary action (i.e. a button), but something that looks like a text widget is the next best thing. Here we have something that doesn't look clickable but that says "you can click me", so I still think the target should be separate.

This comment was removed by Prtksxna.
Prtksxna added a comment.EditedAug 20 2015, 11:46 AM

I think the regular upload widget is a bit lacking in this area too, it should a clearly clickable primary action (i.e. a button), but something that looks like a text widget is the next best thing.

Browsers on MacOS have the Button and Label combination. No text field at all. Is this something we want to move to?

ChromeFirefoxSafari
No file
File selected

The only thing I dislike about this patterns that its never clear how much space the widget is taking. The older ones on Windows did not have this problem:


I couldn't find the file input element in Polymer, and Bootstrap doesn't add any styles to the element. Nothing in the Semantic UI framework either, but a https://github.com/Semantic-Org/Semantic-UI/issues/403#issuecomment-36206643comment in their issue tracker did catch my fancy:


Adding a label to that button might be a good idea. We already use a similar pattern in the NumberInputWidget.


But I've digressed, what do we do about the drag-drop config?

matmarex renamed this task from Add optional drag-and-drop UI to the SelectFileWidget to UI of SelectFileWidget may not be sufficiently obvious (unclear how to choose the file?).Aug 21 2015, 1:55 PM
matmarex updated the task description. (Show Details)
matmarex set Security to None.

(I rephrased slightly what needs to be done, since I went ahead and merged the related patch https://gerrit.wikimedia.org/r/#/c/231220/ / 955c21aeaccff531251d31e1baf1bae45105aa2a.)

Given we haven't sorted out the drag-drop config issue (whether it's shown on it's own, or alongside the 'normal' control) can we not merge that patch (231220).

I think the last example given

is pretty good (with a label as you say)

With drag and drop enabled, we can show a drop target above/below, although there will need to be some visual cue connecting the two so it's obvious they're part of the same input.

Jdforrester-WMF moved this task from Backlog to Next-up on the OOUI board.Aug 26 2015, 1:40 AM

The recent change that uses a separate button has the problem of not knowing how wide the widget would be (I am not sure if that was the case earlier too).

From a previous comment

The only thing I dislike about this patterns that its never clear how much space the widget is taking…

This is more of a problem when the widget is in a dialog:

I don't know how to fix this. Making .oo-ui-selectFileWidget-label an inline-block with a max-width of 100% doesn't help. Will we have to specify an absolute em value? If yes, what?

Jdforrester-WMF triaged this task as Medium priority.Sep 4 2015, 6:50 PM
Jdforrester-WMF moved this task from Untriaged to Doing on the Multimedia board.
Esanders closed this task as Resolved.Sep 6 2015, 10:19 AM
Jdforrester-WMF moved this task from Doing to Done on the Multimedia board.Sep 14 2015, 11:26 PM
Jdforrester-WMF moved this task from Next-up to Reviewing on the OOUI board.Sep 18 2015, 3:23 PM