Skip to:
Content

BuddyPress.org

Opened 11 years ago

Closed 7 years ago

#5617 closed enhancement (maybelater)

Improved image size detection during cropping process

Reported by: boonebgorges's profile boonebgorges Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Media Keywords: trac-tidy-2018
Cc:

Description

Our interface for uploading and cropping avatar images is not friendly to people who are uploading small images. It encourages poor cropping, which results in ugly upsizing.

I have a few suggestions for improvement:

1. Do a better job determining the default size of the cropper box.

Our current logic https://buddypress.trac.wordpress.org/browser/tags/2.0/bp-core/bp-core-cssjs.php#L44 is to set the cropper size to a square that is half the width/height of the image. This works pretty well for large uploads. But for small images - say, a 200x200 image - it suggests a 100x100 crop, which is smaller than the default 'full' avatar dimensions of 150x150. I propose the following revisions:

  1. When the uploaded image is smaller than full-height/full-width (150x150 by default), cropper default should be the full image size.
  2. When the uploaded image is larger than 150x150, but smaller than 2x in either direction, cropper default should be 150x150.
  3. When the uploaded image is larger than 300x300, use the width-divided-by-2 formula currently in place

This is not perfect, but it's better than what we've got. In case (b) it will suggest a crop that will not be upsized (in contradiction to the current setup). In case (a) it will still suggest an image that needs upsizing, but at least the upsizing will be minimized.

See attached patch for implementation.

2. Display a warning when the uploaded image is smaller than full-width x full-height

See attached patch for suggested wording. In the patch, I'm using bp_core_add_message() to rely on our internal standards. But the resulting placement of the error box is far from ideal - it's way up on the page, and likely to be missed. Might want to think about something closer to the cropper. Also, if we're going to suggest uploading another image, we might want to have a "Back" button.

3. Prevent the use of undersized images altogether

Another strategy is simply to reject too-small images. That'll help us avoid some of the problems described above. If we decided to do this, my #2 above is irrelevant, as is #1 part (a) (part (b) is still relevant).

In any case, let's do *something*.

Attachments (1)

5617.patch (2.6 KB) - added by boonebgorges 11 years ago.

Download all attachments as: .zip

Change History (9)

@boonebgorges
11 years ago

#1 @DJPaul
11 years ago

  • Keywords commit added; 2nd-opinion removed

I'm sorry that no-one got to reviewing the patch until now. getimagesize can throw warnings so should go in a try/catch block, or prefixed with @, but other than that, I think the patch is OK.

It would be nice to get these improvements into 2.1 as it'll make a little bit better, which is much better than waiting for us to have a patch to make it perfect.

#2 @boonebgorges
11 years ago

In 8673:

Improved image size detection for uploaded avatar images

This changeset introduces two fixes that improve the UX for the avatar upload
process with original images of various sizes:

  • Be sensitive to the size of the original image when setting the initial dimensions of the crop box. If the uploaded image is smaller than the "full" avatar size, suggest a crop that contains the entire image; if slightly larger than the "full" size, suggest a crop equivalent to the "full" size.
  • When a too-small image is uploaded, throw a message that suggests a larger one.

See #5617

#3 @boonebgorges
11 years ago

  • Keywords has-patch commit removed
  • Milestone changed from 2.1 to 2.2

Thanks, DJPaul. I agree that this is a case where doing *something* is better than waiting for the perfect solution. I've just committed the patch (with your suggested improvements). I'll move this to the 2.2 milestone so we can return to some of the workflow questions I discuss above (like the placement of the error message).

#4 @boonebgorges
10 years ago

See #5923. Since these changes (or maybe independently? unclear) the aspect ratio seems to be busted in some cases.

#5 @DJPaul
10 years ago

  • Milestone changed from 2.2 to Future Release

#6 @DJPaul
9 years ago

  • Component changed from API - Avatars to Media

#7 @DJPaul
7 years ago

  • Keywords trac-tidy-2018 added

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: https://make.wordpress.org/chat/

#8 @DJPaul
7 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.