This patch adds a more intuitive UI to the new image crop effect anchor widget. This is based off of the paradigm used by Photoshop and many other popular image editing applications. Discussion started here. http://drupal.org/node/371374#comment-1776588

This patch depends on #371374: Add ImageCache UI Core

The widget works by using javascript to add a class of .with-widget to the anchor widget table. Then in the CSS the radio buttons in the table are hidden and the arrows-sprite is used as a background for the table.

Javascript is then used to allow the user to click a td element in the table which toggles the hidden radio button.

You will also need to download the attached arrows-sprite.png file and place it into the modules/image/images/ directory

Caveat: I am not a designer at all, so if anyone has a better idea for the arrows-sprite please post it. This patch will fail tests miserably without the above patch and the image attached.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drewish’s picture

subscribing.

quicksketch’s picture

Just a note, I think we'd be better off with an set of arrow more like the attached image, because we'll need arrow not only going outward (like the original arrows) but inward also. Of course we could fix this by just flipping all the arrow directions and having an image twice as big, but there seems something pure about reusing the same image multiple times (maybe not though).

We'll have to decide if this "arrows going in" versus "arrows going out" is really something we need to consider at all. Since this makes the assumption that we know what size the image is to begin with before the cropping occurs. If we *do* know the size (such as when an image has been scaled to 40 height before the crop), then you get a situation where you might have arrows like this:

----------
|  |  |  |
----------
|->|  |<-|
----------
|  |  |  |
----------

Where the width is being cropped but the height is not.

quicksketch’s picture

FileSize
962 bytes

Right, and the arrows.

eojthebrave’s picture

Status: Active » Needs review
Issue tags: +Needs usability review, +ImageCacheInCore
FileSize
1.74 KB
5.86 KB

New version of the patch uses a single set of arrows and positions the sprite in each td as needed. Should be visually identical to what is shown in the screenshots in #1.

I'm not really sure that the arrows going in vs. out is really necessary, could you point me to an example of this in real world usage? Does Photoshop or any similar application do anything like this?

Attached cropping-arrows.png needs to be placed in modules/image/images/

quicksketch’s picture

I think it'd make sense to adjust the images via PHP and JavaScript adjusting classes (such as arrow-nw) rather than making CSS rules that match on 4+ different classes.

CSS such as:

+.image-crop-widget .left-top td.left-top,
+.image-crop-widget .center-top td.center-top,
+.image-crop-widget .right-top td.right-top,
+.image-crop-widget .left-center td.left-center,
+.image-crop-widget .center-center td.center-center,
+.image-crop-widget .right-center td.right-center,
+.image-crop-widget .left-bottom td.left-bottom,
+.image-crop-widget .center-bottom td.center-bottom,
+.image-crop-widget .right-bottom td.right-bottom {
+  background: #ccc;
+}

Seems particularly excessive. Is there anything wrong with this?

+.image-crop-widget td {
+  background: #ccc;
+}

As for arrow direction, yes Photoshop does this, which is where the crop-grid idea originated. I think it's fine if we decide to only use one direction for arrows, but it should probably be inward rather than outward, since the cropping operation will almost always size-down than image.

Bojhan’s picture

The selected box is not clear. I am not if I understand why we would need arrows going in?

quicksketch’s picture

The arrows are meant to indicate the effect cropping will have on the canvas. The arrows going in is meant to indicate "hey, the canvas is going to get smaller on these sides". In Photoshop if you adjust the canvas to be smaller, the arrows go in. If you adjust the canvas to be larger than the current size, the arrows go out.

eojthebrave’s picture

Alright, here we go. Less CSS more Javascript. I am by no means a Javascript expert so if someone has a more elegant solution to this please chime in. PHP changes are still the same.

You'll need to download the image from #4 and place it in modules/image/images/ for this to work correctly.

eojthebrave’s picture

@bojhan, suggestions for making the selected box better? Maybe a different color? Maybe an image like a small circle or something. I'm not coming up with anything that really jumps out at me.

eojthebrave’s picture

Changes the background color of he selected position to the blue color used in the new admin theme. See attached images.

Requires arrows from #4 be downloaded and placed in modules/image/images/ and renamed to cropping-arrows.png

Bojhan’s picture

Not the perfect colour, but this should be better.

drewish’s picture

FileSize
7.16 KB

In Safari the crop anchor isn't reloaded correctly when editing a crop. I did some clean up on the JS code to hopefully make it a bit easier to understand.

drewish’s picture

i should make it clear that i fixed the issue where the anchor selection wasn't be saved.

eojthebrave’s picture

Status: Needs review » Reviewed & tested by the community

This looks good to me. Note that you'll need to download the cropping-arrows.png from #4, rename the file to cropping-arrows.png and place it in modules/image/images/cropping-arrows.png

mcrittenden’s picture

Does anybody else find this less intuitive than the radio buttons we have now? Not that the radio buttons are a good solution (because they're definitely not), but these arrows are just confusing to me. The fact that they point towards the part of the image that will be cut off sort of looks like they're stretching in some way towards that direction, not that it's getting cut off. But if I'm the only one then feel free to ignore.

eojthebrave’s picture

@mcrittenden I think that this is fairly typical of UI design for image manipulation programs. Almost every application that I can think of uses some similar widget for selecting an anchor when cropping/resizing the canvas or the image. It will at least be very intuitive for anyone that uses any desktop image manipulation tools.

mcrittenden’s picture

@eojthebrave: that works for me...I guess my GIMP-only click-and-drag experience threw me off :) Thanks for the examples.

joshmiller’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
58.94 KB

That crop icon is confusing because in reality, the arrows pointing out are the result of an image that is not changing size or getting bigger. Attached are screenshots of photoshop and what the arrows do when cropping.

drewish’s picture

I think we might need to have double arrows <-> because we don't really know if we'll be expanding or contracting. We're cropping against *all* images so they could be larger or smaller in both dimensions.

joshmiller’s picture

FileSize
1.15 KB

If that is the case, then I suggest we simply indicate where the anchor point will be, attached is from Adobe Illustrator (same can be seen in InDesign, Photoshop, Flash, etc...)

This simplifies the icon considerably. The only problem becomes explaining this piece of information.

drewish’s picture

josh, I'm not really sure that's an improvement... might as well just leave it radio buttons in that case. i think the arrows are much more helpful.

eojthebrave’s picture

Okay, here's an updated version that works again, and has arrows that point in both directions. Just noticed that the current styling for the anchor widget is messed up in both FF and Safari. See attached screenshot.

It would be nice to get this in, but if nothing else we should at least fix what we've got currently.

mcrittenden’s picture

Status: Needs work » Needs review
FileSize
550 bytes
3.05 KB
3.28 KB

@#22, If we're forced to just fix what we have, the one line patch from #553938: Tweak CSS for image anchor table will do that, although it will probably need a re-roll. I'm attaching it here just to keep everything in one place.

Marking CNR for discussion. I'd LOVE to get #22 in. I tested it, it works well, is a pretty significant UX improvement IMO, and I couldn't find any problems with the code.

MichaelCole’s picture

#23: anchor.patch queued for re-testing.

franz’s picture

#23: anchor.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Needs usability review, +ImageCacheInCore

The last submitted patch, anchor.patch, failed testing.

franz’s picture

Version: 7.x-dev » 8.x-dev
Status: Needs work » Needs review
Issue tags: +Needs backport to D7
FileSize
303 bytes

re-rolled latest patch. However, I'd really love to see the UI change in #22

Bojhan’s picture

Issue tags: -Needs usability review

Needs image/screencast for review.

franz’s picture

Bojhan, there is one on #22

Bojhan’s picture

Whoa, ok - then its really confusing :)

xjm’s picture

Status: Needs review » Needs work
Issue tags: +Novice

I take #30 to mean #22 is a definite improvement, and I'd agree. However, do we have a non-graphical fallback for this? We'd want invisible labels like "Upper right," etc., or maybe some text that appears on hover.

Can we get a reroll of #22 (and check for the element labels)? Not sure if that is backportable, but we could use #27 as the D7 backport if needed. (We might also want to backport the label fixes.)

Tagging as novice for the task of rerolling the Drupal 8.x patch.

star-szr’s picture

Status: Needs work » Needs review
Issue tags: -Novice
FileSize
4.9 KB

Rerolled #22 for 8.x and #1217006: Clean up the CSS for Image module.

Two changes/notes:

  • Removed CVS ID tag and trailing whitespace from image.js.
  • The .image-anchor selectors were refactored a bit in #1217006: Clean up the CSS for Image module. I mostly went with HEAD except for adding table to the initial .image-anchor selector due to the markup changes introduced in this patch.

I did a bit of manual testing and the patch works as expected.

One hiccup - we're missing the two-way arrow graphic! I was able to test using the one-way arrow icon PNG in #4 but I don't think the two-way arrows shown in #22 ever got uploaded to this issue. So that graphic may need to be recreated unless @eojthebrave can upload it here.

The arrows in question:

eojthebrave’s picture

I had to dig a bit to find this but I did! Sweet.

I also renamed the file to image-crop-arrows.png and moved it to core/misc/ as that seemed more appropriate.

You need to either download the attached .png and place it in core/misc/image-crop-arrows.png or use the 525716-33-with_image.patch version of the patch which was created using `format-patch` and contains the image as well.

Finally, this seems like a good candidate for #d8ux so adding that tag.

The last submitted patch, 33: 525716-33-with_image.patch, failed testing.

mgifford’s picture

Issue summary: View changes

What happened to image_crop_form()? I can't seem to grep it.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

marvil07’s picture

Status: Needs review » Needs work

Patch does not apply, moving to NW.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.