wp-admin/media-new.php is a terrible experience

[helen]

media-new.php is a holdover, not just from the pre-4.0 media library grid view days, but from the pre-3.5 media modal days. The way it handles showing completed uploads at the bottom is ugly as all, and it involves opening new tabs and other rough interactions.

Per ​ryan's musings and vizrec:

• Offer grid view’s uploader interface in list/bulk view as well.
• Remove media-new.php.
• Remove the Media > Add New submenu.
• Celebrate.

[ericnkatz]

(I purposefully didn't embed directly in view because they are kind of big and obtrusive and better looked at in a new tab/window.)

Current Grid Add New view:
[Image(​http://ericnkatz.com/admin-ui/new-media-current-grid.png)]

Proposed List Add New view:
[Image(​http://ericnkatz.com/admin-ui/new-media-proposed-list.png)]

Suggested Proposal for giving no-js users default upload options from within both grid/list upload views (which ever is set to user's default):
[Image(​http://ericnkatz.com/admin-ui/new-media-proposed-no-js.png)]

Styling / messaging should probably be adjusted for the suggested view for no-js users. I didn't completely remove the Add New shortcuts in the sidebar or in the adminbar because it keeps it inline with Posts/Pages as far as structure. But obviously this idea is still on the table.

Additional ideas I'm playing around with:

• Hiding old media library items when uploader is used to kind of help guide the experience and next steps in editing or updating the file in WordPress Media.
• If keeping the Add New: Backbone updating 'current' status in sidebar when 'Add New' click event is fired. PHP to set initial current status now based on some sort of extra url parameter ie: upload.php?new=true
• UI tweaks

Do you guys have any thoughts on this?

I still have to clean up some stuff but I can share a patch on here so people can play with the set up / testdrive changes.

[DeBAAT]

From a UI consitency and backwards compatibility view, I support Eric's suggestion to keep the "Add New" menu entry.
Can we design it in such a way it shows (toggles?) the "Add" box?
That way, the Add box doesn't consume any precious screen space when not in use, which I presume is most of the time.

[helen]

Replying to ericnkatz:

Proposed List Add New view:
[Image(​http://ericnkatz.com/admin-ui/new-media-proposed-list.png)]

I'm assuming that the intention for list view with JS on is to have the add new form toggle, with drag-and-drop-anywhere enabled even when it's not toggled on.

Suggested Proposal for giving no-js users default upload options from within both grid/list upload views (which ever is set to user's default):
[Image(​http://ericnkatz.com/admin-ui/new-media-proposed-no-js.png)]

For no-JS, let's drop the message and make the form as compact as possible - right inline next to the h2 might even work, though I'd have to see it (can be a mockup, doesn't have to be code) to really evaluate. I think the message ends up being essentially useless - if JS is off, it's either purposeful or because something has broken JS (usually a theme or plugin). Without help getting JS turned back on in the latter case (which we can't really detect), it just ends up being scary. Grid view is not really available for no-JS - right now it should show a message to go to the list view, and I don't think we need to add anything to that.

Additional ideas I'm playing around with:

• Hiding old media library items when uploader is used to kind of help guide the experience and next steps in editing or updating the file in WordPress Media.
• If keeping the Add New: Backbone updating 'current' status in sidebar when 'Add New' click event is fired. PHP to set initial current status now based on some sort of extra url parameter ie: upload.php?new=true

Not completely sure what each of these means/entails. Could you elaborate?

---

As discussed in Slack, long-term it probably makes sense to have list view really be another view (in the Backbone sense) for what's currently the grid view. That's not something we can realistically do in the course of one cycle, though, as it would be unwise to do it without addressing the bigger picture of how we handle hooks and actions in a non-PHP context, both in terms of implementation as well as upkeep and back-compat. I don't think we're trying to do that here by any means, but I wanted to document that somewhere less ephemeral :)

[helen]

No patch - even an initial one could have saved us for 4.3, but so it goes. Let's try again in 4.4 - meaning, patch now, still. :)

[desrosj]

I'm going to add a close suggestion here and circle back in a few months to wontfix this unless someone feels strongly otherwise. With the block editor and full site editing, menus are now blocks, and the experience is completely different. Investing time to fix the legacy experience is outside of the project's current priorities.

[desrosj]

🤦🏼‍♂️ This is media new not menu new, as my brain just read through this one. That changes my opinion and makes it more relevant to the current user flows, but still not sure how much time we should invest in this one.

[joedolson]

I think that we should probably close this. There are some features in the Add New Media page that aren't available elsewhere, such as bulk uploading a collection of attachments where you need to get their URLs, thanks to the 'Copy URL' functionality added relatively recently.

Closing as wontfix, and moving directly onto stage 4.