WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 7 weeks ago

#30155 assigned defect (bug)

Fix crop image functionality within edit flow

Reported by: sonjanyc Owned by: adamsilverstein
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 2.9
Component: Media Keywords: has-patch reporter-feedback needs-testing
Focuses: ui, accessibility, javascript Cc:

Description

The Image Flow team has done some user testing and the cropping functionality within the image editing flow is basically unusable, and not at all intuitive even for tech savvy users.

Several things would need to be fixed in order to make it more usable and user friendly:

  1. When the user clicks on "Edit image" in the image flow, NO tool should be selected in the initial state of editing mode
  2. Upon selection of Crop tool, dotted crop lines should be around the edges of the full image (currently user needs to make the selection and most of the users didn't realize that)
  3. User should be able to scale crop area with handles and reposition crop area by dragging it
  4. Aspect ratio should be a visual representation with text (see mockup attached), and an option to input custom aspect ratio should be available (original, custom, 1:1, 3:2, 2:3, 4:3, 3:4, 16:9, 9:16)
  5. Selecting an aspect ratio should lock selection, so when user resizes selection it contains the aspect ratio
  6. When a user clicks on "Original" aspect ratio, it should reset selection to full image and lock in the aspect ratio of the image aspect ratio
  7. "Selection" numbers inside "Image Crop" shouldn't be an input field, but rather just reflect the selected image size without the ability to manually edit it (confuses users)
  8. When user chooses to use a custom aspect ratio, we should add an "Apply" button to set the custom ratio (currently it doesn't work properly with pressing tab)
  9. To save and apply the crop there should be one prominent button called "Apply crop" (currently the user needs to click on the crop tool again, which makes no sense and none of our test users could figure it out)

Attachments (5)

image-flow-crop-ratio-1.jpg (88.2 KB) - added by sonjanyc 3 years ago.
Image crop aspect ratio (visual selection)
30155.diff (706 bytes) - added by adamsilverstein 8 weeks ago.
30155.2.diff (3.3 KB) - added by adamsilverstein 8 weeks ago.
30155.3.diff (3.3 KB) - added by adamsilverstein 8 weeks ago.
30155.4.diff (3.4 KB) - added by adamsilverstein 8 weeks ago.

Download all attachments as: .zip

Change History (28)

@sonjanyc
3 years ago

Image crop aspect ratio (visual selection)

This ticket was mentioned in Slack in #feature-imageflow by sonjanyc. View the logs.


3 years ago

This ticket was mentioned in Slack in #feature-imageflow by teamadesign. View the logs.


3 years ago

#3 @klosi
3 years ago

I have finally created the form for the Aspect ratios: https://docs.google.com/forms/d/1dEn6IiKjvgFuKh0Mv5Z9nxXaePbpmEIlLPy3ttYk8pM/viewform?usp=send_form

They cover the forms mentioned by you, plus a few others which are common in photography. I hope I can get some feedback from @ahockley about the relevance of them.

One common problem is the horizontal vs landscape format. A lot of aspect ratios are made for portrait (like micro fourt thirds (3:4)) and others are made for horizontal (16:9, Golden Ratio, etc.). I feel we should make the decision for the user and make only matching a/r's available... the form doesn't account for that yet, as I need more feedback first.

#4 @boonebgorges
3 years ago

  • Version changed from trunk to 2.9

#5 @afercia
2 years ago

  • Focuses accessibility added

Would propose to make an effort to consider also accessibility issues here, especially about keyboard accessibility. Everything should be operable using just a keyboard. See related #28864.
Many of the issues outlined here make perfectly sense and would benefit all users :) About point 7:

"Selection" numbers inside "Image Crop" shouldn't be an input field, but rather just reflect the selected image size without the ability to manually edit it (confuses users)

I would say the opposite :) instead of removing the input fields, we should improve them since it's the only way to make a selection using the keyboard. We should have 4 input fields, the first pair to set the top-left selection starting point and the second pair to set the bottom-right selection end.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


16 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


15 months ago

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


14 months ago

This ticket was mentioned in Slack in #core-media by mike. View the logs.


8 weeks ago

#11 @adamsilverstein
8 weeks ago

In 30155.diff:

Select full image on load, making cropping more intuitive. Maybe would be better to only select on crop button click? Feedback appreciated.

Last edited 8 weeks ago by adamsilverstein (previous) (diff)

This ticket was mentioned in Slack in #core-media by adamsilverstein. View the logs.


8 weeks ago

#14 @adamsilverstein
8 weeks ago

  • Keywords has-patch reporter-feedback needs-testing added

30155.2.diff is an alternate version that more closely matches the description of steps 1-3 from @sonjanyc -

  • The crop button is always 'enabled'
  • Clicking the crop button with no selection selects the entire image
  • Clicking the crop button with the entire image selected doesn't do anything
  • Clicking the crop button with a selection crops as expected

Here is a screencast:

https://cl.ly/451l2H1E0W24/Screen%20Recording%202017-06-23%20at%2008.48%20AM.gif

Appreciate testing/review/feedback. Shall we get this in and then continue to work on the image ratio buttons?

#15 @adamsilverstein
8 weeks ago

In 30155.3.diff

  • correct a math issue. math!

#16 @adamsilverstein
8 weeks ago

In 30155.4.diff

Use img.innerWidth() and img.innerHeight() in place of img[0].width and img[0].height, matching the method used in imgAreaSelect adjust() and ensuring full image is selected without artificially adding 1.

#17 follow-up: @afercia
8 weeks ago

I like the direction 30155.4.diff is taking. That leads me to a general consideration about the UI and one possible improvement. Not saying it's something that should be necessarily done now, but maybe it's something worth considering for future iterations and I'd greatly appreciate feedback from designers /cc @melchoyce @karmatosed etc. :)

One of the general patterns across all the WordPress admin UI, is that it's always displaying everything, even when you don't need it. I guess this is something that comes from old design trends, with user interfaces full of controls, links, buttons, etc. Thinking at interfaces designed 10 years ago, they often follow this pattern. Instead, more modern interfaces, especially with the advent of mobile devices, tend to display UI sections and controls only when you need them.

In this specific case, the "crop" feature is changing in something that requires an explicit user action to be activated: users have to press the "Crop" button to get the full selection (actually they can still drag on the image to get a first selection but this is a minor point).
Considering this, I'm wondering if always displaying the ratio and selection fields still makes sense:

https://cldup.com/EHqBOx-dwJ.png

Wouldn't be better to show them only when users press the "Crop" button or make a selection dragging on the image? They could be displayed under the main buttons, in a sort of toolbar as many image editing software do. See the screenshot below, made quickly editing in the browser and not pretending it's perfect, just to give you an idea:

https://cldup.com/0jZlYG-tXR.png

A cleaner, simplified interface would benefit all users. Revealing the additional fields can be perfectly accessible if done in the right way. Any thoughts welcome!

#18 in reply to: ↑ 17 @adamsilverstein
8 weeks ago

Replying to afercia:

Considering this, I'm wondering if always displaying the ratio and selection fields still makes sense:

Great point. Based on your screenshots alone, I can see that only showing these ratio/crop imput fields when the crop tool is active would be a big win from a usability standpoint. I totally agree with your perspective that decluttering the interface improves comprehensions/reduces confusion.

How would we deal with these types of dynamically present fields and screen reader, eg. would we announce that new fields are added when the user entered the crop mode, or expect them to tab around to find the new fields?

#19 @adamsilverstein
8 weeks ago

  • Owner set to adamsilverstein
  • Status changed from new to assigned

#20 @afercia
8 weeks ago

would we announce that new fields are added when the user entered the crop mode, or expect them to tab around to find the new fields?

Usually, the best option is to use an aria-expanded attribute on the control that expands "the thing" so users are informed something appeared on the page. Then, placing the additional fields right after the "Crop" button would be key, as users would find them with ease (that could be done with some absolute positioning, I guess). It also makes sense to be able to tab directly from the Crop button to the ratio/selection fields.

Last edited 8 weeks ago by afercia (previous) (diff)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 weeks ago

#22 @afercia
7 weeks ago

See also #37750.

This ticket was mentioned in Slack in #core-media by adamsilverstein. View the logs.


7 weeks ago

Note: See TracTickets for help on using tickets.