An interesting alternative could be for portrait images (which are the ones that present most of the problems when choosing a focus area) to do something like trello does when you open a card that has a portrait cover image

http://i.imgur.com/ihIkhx1.png (excuse the image example, it is just to show the case)

It shows the full miniature, but instead of showing black vertical bars at both sides of the image it colors the empty spaces with the most predominant color of the image. I think this can be an interesting point to consider, maybe combining this with a slight zoom+crop would be sufficiently aesthetically pleasant without losing most of the image.

There is definitely a lot to try and improve, I personally love having the images in the header.

On Sat, Dec 20, 2014 at 7:31 PM, Dmitry Brant <dbrant@wikimedia.org> wrote:

Note also that yesterday's beta update should fix the lead image clickability issue (that you raised (thanks!)), which may have been contributing to the confusion/frustration.

We don't consider the alignment of certain images to be a road block to releasing this feature because:
a) it takes one extra tap to view the full image.
b) most images are not poorly aligned (or alignment is irrelevant)
c) we'll be able to make incremental improvements to the functionality at any time afterwards (including any of Monte's excellent ideas). As others have said, because of the staggering diversity of our content, we can't possibly account for all edge cases; but we also mustn't let that stifle our progress.

On Sat, Dec 20, 2014 at 7:16 AM, Andy Mabbett <andy@pigsonthewing.org.uk> wrote:
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.

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l