On 20 December 2014 at 04:04, Monte Hurd mhurd@wikimedia.org wrote:
what about the following ideas:
Thank you for the constructive suggestions. I'd be agld to see anything whcih offers a improvement over the current beta
We could top align or align nearer the top. Experimenting with this has seemed to produce fewer edge cases for me. (I'm implementing the same functionality in the iOS app.)
That won't work for images like https://en.wikipedia.org/w/index.php?title=File:Nycticebus_coucang_002.jpg (the Slow Loris example discussed here recently)
We could, if the article image dimensions are not conducive to being cropped, use the next image in the article which is.
I infer form that that the problem is largely with portrait format images?
We could, instead of showing a single image in the cropped area, show a mosaic layout of the main image and a few others from the article scaled and sized to present a seamless bird's eye gallery in the crop box.
That might work; but the detail might also become very small - and some infobox images are already mosaics.
We could animate a cross fade between all of the article images in the crop box.
We could, if we detect an image ill suited to the crop box, slowly pan from center to top left, then top right, then bottom left, then bottom right, then back to center.
We could start the image zoomed out such that no cropping is evident, with black bars in the narrower dimensions margins, the zoom in to aspect fill the crop box.
These three (and your subsequent " rotational 3D transform" idea) would need to satisfy WCAG guidelines on movement; and be tested by people with susceptibility to such.