Unify media controls

[melchoyce]

3.9 is bringing us tons of media improvements! This is super exciting. Let's make sure our new media elements have a unified UI. The attached image shows what an image, gallery, audio playlist, video playlist, and audio file currently look like in a post.

To quickly summarize where we currently stand:

• Images have a full-width, transparent black overlay with the "image" icon on the left and "x" on the right
• Galleries have an opaque black overlay with the "gallery" icon and "x" icon clustered together on the left
• Audio and playlists don't have an overlay; editing is brought up by double-clicking the block

How can we make all three of these a consistent experience? Should the "edit" media button be that specific media type's icon (image, gallery, audio, audio playlist, video playlist) or should we use a generic "edit" icon for all of these blocks?

[melchoyce]

I think we should add a control overlay to audio and playlists, personally. Until we have in-post previewing of audio and playlists, however, using each media type's icon will be repetitive, since the block uses an icon to identify what kind of media block it is. If we go with one edit icon for all of the media types, not only will we not have that issue, but we will also have a more consistent experience.

Related: #26797

[nacin]

I agree with anything that makes things feel consistent, usable, and simple. :-)

I'm not sure if there's a reason why they can't become actual rendered controls, or if we just haven't gotten to it yet, or if gcorne or wonderboymusic are looking into it. Either way: At the very least it'd probably be helpful for audio and video files to have something more than they have now. Even if it's a filename or something.

[helen]

Thinking: unified edit icon, using the look the gallery view controls have, definitely adding something to the audio/video placeholders (filename? maybe sneaking something else in if everything else goes smoothly?), keep/add double-click-view/placeholder-to-edit.

[gcorne]

It is probably worth also considering the audio / video players when deciding how the toolbar and selected states of wpviews might work since @wonderboymusic is trying to get them working. See #27389

[gcorne]

After discussing various ideas with @melchoyce, I put together an initial patch​ focused on tightening up the controls for the single image and gallery.

The patch incorporates the work done on #27376 and #27354, as well as trying to address the following:

1. Fix issue where the hidden clipboard div was wider than the gallery when the gallery contained a large number of media items.
2. Switch to using the pencil .dashicons-edit dashicon for both the image and the gallery
3. Use the gallery style toolbar for both the image and the gallery
4. Switch to a pale blue for the gallery selected state. This is the same blue as is used in 3.8 for the placeholders
5. Add an outline to the gallery selected state to match the single image selected state a bit better.

[azaozz]

In 27578:

TinyMCE:

• Update the styling of the image caption and gallery toolbars.
• Fix issue where the hidden clipboard div in wpView.
• Switch to using the pencil dashicon for Edit.
• Add max-width: 100%; to images in the gallery preview and adjust column widths.

Props cramdesign, mattheu, gcorne, melchoyce, see #27320, fixes #27376, fixes #27354

[azaozz]

In 27579:

TinyMCE: move the caption and gallery toolbars to the right, fix selected gallery border/outline, see #27320

[azaozz]

For the record: moved toolbar to the right for captions and gallery preview as discussed in ​#wordpress-dev.

[melchoyce]

Idea, as pictured above: in addition to swapping out the "audio" icon in the control overlay to the edit icon, let's use the extra space generated to display the title of the audio file.

[wonderboymusic]

Yes to that - looks cool, will work on that

[wonderboymusic]

27320.diff​ will make the title of the track show up in the MCE view when the shortcode is inserted. I need to spend some more time on this later.

[helen]

In 27628:

Further unify and refine media and view control styling. see #27320.

[helen]

In 27629:

Add the version string to wp-content.css to avoid tenacious caching woes. see #27320.

[wonderboymusic]

From [27640]:

Unifying media controls and supporting playlists in the editor:

• Support a caption attribute for audio and video shortcodes
• In wp.media.audio|video, rename update to shortcode to allow these models to share the same mixins as wp.media.collection subclasses
• When sending an audio or video shortcode to the editor, create a default caption if the user hasn't entered one. This currently only displays in the editor, not on the front end. Captions aren't tied to a specific attachment here because external sources are supported.
• In the wp.mce.media mixin, in the edit method, read attr instead of data when attempting to parse the encoded shortcode. data does not automatically update when the attribute changes. This was a blessing to debug.
• Add wp.mce.media.PlaylistView to support playlist views in TinyMCE
• Expose WPPlaylistView to global scope and suppress auto-parsing of playlist nodes when in the admin. Allow WPPlaylistView to be passed metadata on creation instead of requiring a JSON blob to be parsed.
• Remove all of the playlist logic from the wpgallery TinyMCE plugin.
• In wp_prepare_attachment_for_js() return more data for audio/video so that playlists can have parity in the admin/front end.

[nacin]

In 27645:

Merge two strings. see #27320, #27453.

[melchoyce]

#26797 was marked as a duplicate.

[gcorne]

The UX for selecting and deselecting the audio/video views is a bit different that the image selection and gallery selection UX. Personally, I prefer only showing the tools when the view is selected because the focus stays a bit more on the content, and the behavior matches the normal TinyMCE experience when editing images where the controls are shown on click.

[wonderboymusic]

let's say you click the player because you want to edit the video, what's supposed to happen?

1. Does the video play and reveal edit buttons?
2. Does the video not play and reveal the edit buttons?
3. Does the video play and then get immediately paused, then the modal opens?

When the buttons are already there, it's way more obvious what does what. Open to suggestions...

[ericlewis]

In attachment:27320.mov​, highlighting the utility of the "Cancel gallery/playlist" button across different contexts.

The "Cancel [Gallery/Video Playlist/Audio Playlist]" makes sense when the user is creating it initially. In the edit gallery/playlist context, it has no meaning or functionality. We should remove it there.

[ericlewis]

In attachment:27320.5.diff​, within the menu initializer methods galleryMenu, playlistMenu, and videoPlaylistMenu, check if we're coming from another state. If not, we can assume the user entered by clicking "Edit" on an existing playlist/gallery.

[gcorne]

Replying to wonderboymusic:

let's say you click the player because you want to edit the video, what's supposed to happen?

1. Does the video play and reveal edit buttons?
2. Does the video not play and reveal the edit buttons?
3. Does the video play and then get immediately paused, then the modal opens?

When the buttons are already there, it's way more obvious what does what. Open to suggestions...

Definitely a tricky UX problem, so I am curious to hear what others think.

FWIW, another reason for the selected state to be communicated somehow is that when a wpview is selected, you can copy/cut the view or hit the delete key to remove the view. Copying or cutting actually copies from a hidden element containing the text representation of the view.

[wonderboymusic]

In 27655:

General code cleanup and improving video sizing in the admin:

• Abstract the setting of a primary button and its callback in wp.media.view.MediaFrame.MediaDetails
• Account for the existence or non-existence of $content_width in the TinyMCE views for video
• Make sure video models always have dimensions, even if they are the defaults
• For browsers that are not Firefox, don't use a timeout when setting the MediaElementPlayer instance in TinyMCE views

See #27320.

[helen]

Meant to drop a comment after my last couple of commits noting that audio/video views still need some love. I almost wonder if it would be better if you had to click once to select, then again if you want to play/interact with it.

[helen]

Thought about this and talked to gcorne about it some more - I think having to select a view before interacting with it is the way to go, and then float the controls above the view instead of having dead space or issues with sizing. I'm also going to move the controls back to the left - they get lost if the item is wider than the editor, and muscle memory has been tripping quite a few people up.

[helen]

In 27777:

MCE view controls:

• Move controls back over to the left, as they were before. Wide images and muscle memory have been causing frustration.
• Improve the experience and unify the UI of media view controls. Audio and video views now require an initial click to select before further interaction.
• CSS clean up and organization.

fixes #27320, #27542.

[helen]

In 27792:

Affix the audio view toolbar to the bottom as opposed to the top of the view. Otherwise it's not accessible when the view is the first item in the content. Said views keep a newline underneath, so there's space for it to appear there instead. fixes #27548, see #27320.

[wonderboymusic]

In 27979:

[27640] supported a caption for audio and video shortcodes as part of a UX iteration for the related MCE views. These captions have since be excluded, so the extra code should be removed (it was there for this sole reason).

See #27320.