Redesign the admin Image Editor

[afercia]

Splitting this out from #47136.

In #47136 the visual order and DOM order of the elements in the admin Image Editor was fixed. The discussion on the ticket highlighted the need for a major redesign of the Image Editor, which is pretty old and has room for improvements.

Quoting from ticket:47136#comment:16

this indicates the need to consider a redesign from ground up of the media interface. I know many already feel this. If we can from the start consider a11y and the best possible interactions, then we aren't forcing something or hitting the limits of an existing design

Quoting from ticket:47136#comment:35

Some initial redesign ideas were explored by @nrqsnchz see starting from https://core.trac.wordpress.org/ticket/47116#comment:11

As a first step, all the explorations made on #47116 should be moved to this ticket, including screenshots :) New design from the Design team is very welcome.

[joedolson]

Migrating https://core.trac.wordpress.org/ticket/47116#comment:11 by @nrqsnchz

---

The more I think about it, the more I don't think that having those options in the place where they currently are is ideal (if we want to also have labels).

It takes way too much space on small viewports and when the user zooms their browser. That last morkcup you shared @sabernhardt is a good example of what I mean.

I've been thinking about the possibility of having these buttons on the sidebar. We seem to have some related items in there already (Scale Image and Image Crop). So what if we grouped all of these together? (we can keep Undo and Redo in the same place)

The stuff that is currently in Scale Image and Image Crop can be revealed contextually. So, for example, if I click on Crop, the aspect ratio and selection settings can appear below it:

[joedolson]

Migrating https://core.trac.wordpress.org/ticket/47116#comment:25 by @karmatosed

---

Wow, this ticket moved on a bit, thanks for all the work everyone. Whilst I am not going to counter the work done here, I would like to offer some design feedback. I want to do this to not block but have us consider in beta a few points.

First, the position in the sidebar I feel is problematic from a cognitive and action point of view. It's removing a direct interaction from where it happens. I understand why now because the buttons are just too vast, however just putting them in the sidebar I don't feel solves this as removes from where they made sense to be. The placing in the sidebar is what for me takes this from bug to enhancement, so I agree with @mikeschroder on that. I understand labels put it in a bug, but this ticket does both.

I have concerns over moving and what plugins hook into this. For example, if a plugin adds icons/buttons here do we end up having lots in the sidebar? That could be seriously problematic on smaller screen heights and in general cause a lot of problems.

For me, the moving to the sidebar is done without exploring where the best possible location should be. I would love to see exploration as to that. I wonder if they are even buttons anymore like this? Why can't we have buttons that have tooltips/explanations for example? What about exploring hiding interactions in a toolbar of sorts even a drop-down? If text is desirable, I am sure another option can be found.

My advice at this point would be to not move to the sidebar in this as that takes it to an enhancement. If a better option is found for placing during beta 1, we could evaluate then, but for now my feeling is the sidebar doesn't do that. I am not commenting on text being by icon, but placement.

I will note, we are all pushing against the limits of the current interface so I recognise wins are hard in this confined space. That said, I think we shouldn't move buttons and actions without considering their impact in such a fixed design. What for example in a small sidebar happens to that text in translations, with plugins hooking in? It's for these and interaction reasons I am recommending we don't move them this release.

[joedolson]

Design patch from @nrqsnchz migrated from #47116

[joedolson]

Refresh patch from @nrqsnchz

[joedolson]

On reviewing this proposal, I agree with @karmatosed that moving the controls to the sidebar creates problems. Having the buttons to control your editing actions at such a distance from the editing target is a problem. The cancel/save buttons would also need to move, for control proximity.

I do very much like the proposal that the scale & crop controls open their respective panels, however.

[sabernhardt]

This needs more than a week, and it's more of an enhancement anyway. Moving the ticket to future release.

[antpb]

Just noting that this will likely not make it in 6.0 due to the amount of decisions still to be made in this effort. We're leaving in 6.0 until there is a 6.1 milestone to continue discussions on it through this release cycle.

[chaion07]

Thanks @afercia for reporting this. We reviewed this ticket during a recent core bug-scrub session. Considering Beta 01 coming to effect by the end of the day and the feedback received from the team we are updating the milestone to 6.1 to stay aligned with Anthony's most recent comment. It also helps everyone and the reports stay organized in such way.

Props to @costdev & @peterwilsoncc

Cheers!

[joedolson]

Work in progress patch for discussion

[joedolson]

Updated work in progress

[joedolson]

50523.3.diff continues the work in 50523.2. Additional changes include:

• Larger crop corners
• Slight additional increase in image preview size (640px)
• Add 'Apply Crop' button with crop settings
• Add keyboard shortcuts for undo/redo (Ctrl+Z, Ctrl+Y)
• Add listeners to track crop coordinates to inputs
• Show crop settings either when 'Crop' button clicked or if a crop is selected.
• Limit width of imgedit settings panel to prevent reflow when help info is expanded.

Changes already in 50523.2 include adding settings for starting coordinates, moving undo/redo to be collected with cancel/save, moving Save button after the 'Thumbnail Settings' data, increasing the preview image size, and using flex to place controls next to the image preview instead of all the way to the side.

[joedolson]

Current state for discussion

[joedolson]

Updated patch; continuing dev

[joedolson]

50523.5.diff adds a background grid for image reference, a 'clear crop' button, and continuing implementation improvements.

[joedolson]

Noting #44867 as a set of image editor changes that should be integrated as an enhancement after this is finished.

[chaion07]

Thanks @afercia for reporting this. We reviewed this during a ​recent bug-scrub session. Here's the summary of the feedback:

1. Adding keyword 'needs-testing'
2. The latest patch still applies cleanly against trunk
3. We plan to raise this ticket in the design channel to get more attention from Design Contributors.

Thanks!

Props to @costdev

[joedolson]

Punting to future release; will try to get in early for 6.2.

[bgoewert]

Test Report

Patch tested: 50523.5.diff

Steps to Test

1. Upload image (​random image)
2. Select image
3. Edit more details
4. Edit image
5. Crop
6. Undo
7. Scale
8. Rotate
9. Flip
10. Save
11. Restore

Expected Results

All image actions work

• Crop
• Undo
• Scale
• Rotate
• Flip
• Save
• Restore

Environment

• OS: Pop!_OS 22.04
• Web Server: Docker Desktop
• PHP: 7.4.33
• WordPress: 6.2-alpha-54642-src
• Browser: Firefox 108, Chrome 108
• Theme: Twenty Twenty-Three
• Active Plugins: None

Actual Results

• ✅ Crop
• ✅ Undo
• ✅ Scale
• ✅ Rotate
• ✅ Flip
• ✅ Save
• ✅ Restore

Additional Notes

• Are the crop/scale action settings supposed to be in a sidebar? Because they were not.
• Noticed that scale saves automatically and there is no way to undo a scale unless you restore the original image.
• Also noticed the scale ignores any additional unsaved changes and applies without those changes.
• After applying a crop, the "Crop Image" settings do not get removed unless you click crop again.

Supplemental Artifacts

Didn't embed images so as to not create a long comment.

Before applying patch
​https://i.imgur.com/7TR9LNS.png

After applying patch
​https://i.imgur.com/pUZCf9H.jpg

Cropping
​https://i.imgur.com/Wi7b7A5.png

After applying crop
​https://i.imgur.com/1NEa0Jy.png

Scaling
​https://i.imgur.com/6OoBdny.png

[audrasjb]

As per today's bug scrub, moving this ticket to Future Release to give it more time for testing and design feedback.

[joedolson]

One of the biggest recurring issues with the admin image editor is the clarity of the crop feature. See:

#52221, #50395, #48754, #17247

If the only thing this ticket accomplished was to clarify the use of the crop tool, I think that would be a valuable change. Let's try and finish this off for 6.3.

[joedolson]

Refreshed patch

[joedolson]

Updates to patch - group controls in menu, layout changes

[joedolson]

Moves notice position, changes numeric inputs to type=number, improves scale warning

[joedolson]

Modal view in 6.2

[joedolson]

Modal view after patch

[joedolson]

Attachment view in 6.2

[joedolson]

Attachment view after patch

[audrasjb]

As per today's bug scrub, let's remove the needs-design keyword since we already have a design for this change. Let's test the proposed patch to make sure it's ready to ship with other tickets marked early.

[audrasjb]

Note: let's wait for #26381 to be committed first.

[joedolson]

Refresh patch following r55859

[joedolson]

List of changes:

1) Organization: editing buttons are grouped together in a menu above the editing canvas and settings. This helps improve issues with proximity of controls and findability, and keeps all controls in a consistent location across views.

2) Crop button is no longer multifunction. It only activates or deactivates the crop tools. This makes the use of the tool more predictable. On activation, the crop tool panel is made visible & an initial crop selection is made. If the selection is changed, that selection is retained if the user re-opens the panel. There is now an explicit set of Apply/Cancel buttons for cropping.

3) Scale button added to menu. Scale button toggles the scale tool settings.

4) Sidebar tools have been removed from the sidebar design and placed directly next/after to the editing canvas. This makes sidebar changes & warnings more obvious when visual focus is on the editing canvas, and makes the visual relationship better.

5) Crop settings now include X and Y values so that a crop placement can be fully configured without use of a mouse.

6) Editing canvas has been enlarged and a grid background added for a visual editing reference.

7) Crop handles have been enlarged for easier mouse selection. (From 5px to 10px)

8) Cancel button has improved text specifying that you are cancelling the entire editing session, rather than cancelling a specific action taken (e.g., cancelling crop selection.)

9) Crop & scale inputs changed to number inputs.

Patch is large, but most of that is because the order of controls has changed.

Update image editor design in core.

Trac ticket: https://core.trac.wordpress.org/ticket/50523

Trac ticket: https://core.trac.wordpress.org/ticket/50523

[joedolson]

Design revisions screenshot

[joedolson]

Design updates, per conversation with @karmatosed

Places image rotation & flip controls grouped in a submenu. The menu behaves much like a standard menu (role=menu), but doesn't use the menu role. I did not use the menu role because the modal takes control of esc, left arrow, and right arrow, and using those keys could be destructive to a user's progress.

The menu opens on enter/space/click, moves focus to the submenu, and closes when an action is performed. Because the only way to rotate 180 previously was to use 90 twice, I added a rotate 180 option.

Todo: either add a 180 icon or remove all secondary rotation function icons. Probably remove those icons

[prashantbhivsane]

I think we can separate out Rotate and Flip menus, Rotate would have Rotate Left, Rotate Right, and Rotate 180
Flip Menu would have Flip Vertical and Flip horizontal. Lmk if I have misread or misunderstood anything...

[joedolson]

Having these in a single menu was an intentional choice, for two reasons. First, because having too many controls that only exist to access other controls is not a great user interface (e.g., clicking a button to reach two other buttons), and second, to match the control layout to other common systems. This is the same tool layout that Adobe Photoshop uses.

[prashantbhivsane]

agreed, just to clear the confusion, I saw the divider between flip buttons and thought there could have been a different button altogether for Flip (separate buttons for rotate and flip to be specific)! nevertheless, combining them make sense.

[ababir]

Duotone buttons can be added to the image editor.

[joedolson]

Duotone controls aren't really suitable here. They aren't mechanisms for editing an image; they're only applied within posts using CSS.

Thanks for all your comments!

[joedolson]

In 55919:

Media: Update admin image editor design.

Significant restructure of the admin image editor interface, but no new functionality. Reorganize editing buttons into a common region at the top of the editor. Move image rotation tools into a pop-out menu. Add 180 degree rotation option. Add scale button to control group. Move sidebar tools next to the editing canvas to improve visual proximity between action and result. Enlarge editing canvas and crop handles. Separate activating crop functions from applying crop. Add numeric inputs for crop & scale values.

A long term goal is to move undo/redo and cancel/save into the modal title bar, but that is not feasible without significant updates to the modal framework.

Props afercia, karmatosed, nrqsnchz, antpb, chaion07, costdev, peterwilsoncc, antpb, sabernhardt, prashantbhivsane, joedolson.
Fixes #50523.

[joedolson]

In 55920:

Build/Test Tools: Revert accidental change to .env

Follow-up to [55919] to restore .env state.

Props joedolson.
See #50523.

Closed in https://core.trac.wordpress.org/changeset/55919

[azaozz]

Seems there is an unintentional code duplication in [55919]. See https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/image-edit.php#L344 (both divs are hidden, so it's hard to spot).

[joedolson]

You're referring to https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/image-edit.php#L326; line 344 is presumably where it was prior to committing the change to image sizes.

Definitely looks like an unintentional duplication; will get that taken care of! Thanks.

Accidental duplication in refreshing patch

Trac ticket: https://core.trac.wordpress.org/ticket/50523

[joedolson]

In 55936:

Media: Remove duplicate div containers.

Follow-up to [55919]. Remove two hidden divs accidentally duplicated in patch refreshing.

Props azaozz.
Fixes #50523.

Closed in r55936

[joedolson]

In 56228:

Media: Set default state for image rotation button.

Adds aria-expanded="false" as default state for image rotation toggle in admin image editor. See #50523.

Props joedolson.
Fixes #58800.

[joedolson]

Minor bug to fix, found by @costdev; the scaling input field for height is getting the max value for the meta width, which causes problems if trying to scale an image to a height between the width and height.

Patch coming.

[joedolson]

Fix incorrect max value reference

[joemcgill]

50523.10.diff Looks good to me.

[joedolson]

In 56277:

Media: Fix height max value in image scaling.

Set the max attribute in the height input for image scaling to reference the image height, instead of the width. Follow up to [55919].

Props costdev, joedolson, joemcgill.
Fixes #50523.

[audrasjb]

Reopening for 6.3 backport.

Also Adding dev-reviewed as I'm also providing a second committer review :P

[audrasjb]

I dunno how, but it appears that this was already somehow backported to branch 6.3 😅
Can we close it as fixed?

[joedolson]

Backported in [56278]. Closing as fixed!

[TimothyBlynJacobs]

I may be doing something wrong, but I noticed when running precommit that we are getting an error that I believe originates in this change.

autoprefixer: src/wp-admin/css/media.css:1126:2: start value has mixed support, consider using flex-start instead