Unify styling of file upload buttons with drop zone

[mirka]

Related to #62743

What problem does this address?

I noticed we have two "file upload" buttons that have different custom styling for no apparent reason. This is non-ideal for both code maintainability and UX.

Font upload

CleanShot.2024-09-14.at.02.06.43.mp4

Set featured image

CleanShot.2024-09-14.at.02.14.07.mp4

What is your proposed solution?

Possible solutions include:

• Use the standard "secondary" Button variant.

• Introduce a new Button variant with guidance that it should be used for file upload buttons, and use that consistently.

• Introduce a new UI pattern that denotes a "file upload button with drop zone". For reference, here is another one of these that appears in a block placeholder:

  

cc @WordPress/gutenberg-design

[jameskoster]

Introduce a new Button variant with guidance that it should be used for file upload buttons, and use that consistently.

Could it make sense to update DropZone for this purpose, so that it behaved more like this example in Polaris? The option to include help text would be handy, as would the sizing props.

Additionally we might include a state where the uploaded file(s)a are presented in the UI with actions to reset / replace, this could address the a11y issues in #62743.

[mirka]

Could it make sense to update DropZone for this purpose, so that it behaved more like this example in Polaris? The option to include help text would be handy, as would the sizing props.

We might want to start by spec'ing a UI pattern that works for all the instances in the OP, and document that pattern as a story for DropZone.

Additionally we might include a state where the uploaded file(s)a are presented in the UI with actions to reset / replace, this could address the a11y issues in #62743.

This could also start as a pattern documented in a story somewhere. I don't think we have enough occurrences yet to commit to an API.

[jameskoster]

Something like this might work:

It's essentially one big secondary button with design cues from #64744.

The on-canvas version may need a different treatment to ensure visibility against a multitude of backgrounds.

[mmjoubert]

It still seems unclear that a "standard" design offers a drop-to-upload option. I think it would be more helpful to abandon the "standard" design and combine the "With icon button" and "With help text" designs to create a whole new "standard" design.

[iamleese]

I agree to standardize the look of the DropZone, however we need to address smaller drop zones like the "Set featured image"

From an accessibility standpoint, it's hard for users with impaired vision and motor skill issues to focus a drop in a small area. Previously, the featured image area used to have a larger box where it was obvious where you could drop an image, at the same time, there was a button below to select images from the media library.

Taking the suggestion of @jameskoster maybe we can revert back to the former style but using a standardized look for the drop zone.

[richtabor]

Previously, the featured image area used to have a larger box where it was obvious where you could drop an image, at the same time, there was a button below to select images from the media library.

Taking the suggestion of @jameskoster maybe we can revert back to the former style but using a standardized look for the drop zone.

You can also select this featured image DropZone area to open the Media Library. It's unlikely it needs duplicative UI.

[afercia]

See related #65745 about localization issues.

[jameskoster]

Some additional considerations for the design of a new DropZone/Upload button:

• What does the DropZone/Upload button look like when a file has been selected but not uploaded?
• How does the user deselect or remove the uploaded file?
• Does it need a busy state, if so how does that look?
• What does it looks like when a file has been uploaded?
• What about multiple files?
• Should consumers have the ability to provide users with upload options; open media library / upload directly from the computer / both?

[afercia]

From an accessibility standpoint, it's hard for users with impaired vision and motor skill issues to focus a drop in a small area. Previously, the featured image area used to have a larger box

Totally agree. The redesign fo the Post Summary made the Featured image drop zone ways smaller, which I'd consider an usability and accessibility regression. Any drop zone needs to be bigger.

[ciampo]

I'm now trying to take sides, but could we consider drag-and-drop just an alternative to clicking? Just a way to offer different interactions that achieve the same purpose, ie. layers of redundancy. Users with impaired vision and motor skills would be able to interact with the UI widget by clicking the button.

[jameskoster]

If we treat the dropzone as a regular button (in terms of visuals) then how would users know they can drop files on it? I have to say, looking at the featured image upload button in the OP I would not interpret it is a drop zone.

A minimum size (overall area) for dropzones seems reasonable, but I can't find any guidelines about that.

[jameskoster]

Thinking about this one a little more, I wonder if a new component might make sense. Something like 'FileControl', which would essentially be a wrapper for the native input type="file" with an enhanced design that makes use of DropZone, plus any other affordances we deem worthwhile.

However I also realise that many use cases for such a component in WP would require coupling with the media library and/or post meta. For example consider the control for setting a featured image; once you drop a file on it, that file is simultaneously uploaded to the media library and set as the 'post thumbnail'. This all occurs automatically without having to submit the file. Would this integration with the media library be something that is built into the component, or would it be something that consumers extend the component to add ad hoc?

[ciampo]

Thinking about this one a little more, I wonder if a new component might make sense. Something like 'FileControl', which would essentially be a wrapper for the native input type="file" with an enhanced design that makes use of DropZone, plus any other affordances we deem worthwhile.

That could be a good idea, since it would leverage native platform features, like native drag-n-drop and clicability — although we'd need to look into it a bit more.

However I also realise that many use cases for such a component in WP would require coupling with the media library and/or post meta. For example consider the control for setting a featured image; once you drop a file on it, that file is simultaneously uploaded to the media library and set as the 'post thumbnail'. This all occurs automatically without having to submit the file. Would this integration with the media library be something that is built into the component, or would it be something that consumers extend the component to add ad hoc?

We'd keep the WP-specific part of of the component. Consumers would be able to listen to events, ie. onChange (or any other name), and use the callback data to take actions (ie. upload to media library, set as thumbnail, etc). This is very similar to how DropZone already works via the onDrop onFilesDrop and onHTMLDrop props

[jameskoster]

We'd keep the WP-specific part of of the component

Just clarifying; you mean the wp-specific part would be kept out of the component, right? :)