Hey Andy, While we await commonsdata and the ability to do an image focal area micro contribution, what about the following ideas:
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.) We could make the image not only tap-able but also vertically drag-able so with a simple flick up or down any hidden bit could come into view. If we do the item above and detect that there is some overlap we could do a subtle vertical pan of the image within its crop box when an article loaded to give the user a hint that there's more to see. A variation on that could be subtle scale adjustment hinting. We could, if the article image dimensions are not conducive to being cropped, use the next image in the article which is. 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. We could do the item above only on the condition that the article image dimensions are ill suited to cropping. We could animate a horizontal slide between all of the article images, in a subtle, non distracting fashion, of course, within the crop box. 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. Any of these are doable, quite easily, in isolation or some combined fashion. Do any of these sound like good ideas? -Monte > On Dec 19, 2014, at 3:27 PM, Andy Mabbett <a...@pigsonthewing.org.uk> wrote: > >> On 19 December 2014 at 21:58, Dan Garry <dga...@wikimedia.org> wrote: >> >> I'm sorry that you feel our efforts are not good enough. > > I didn't express a view on our efforts (I've no doubt they're > commendable); it's the results which are causing me concern. > >> That said, for the reasons I mentioned, we've made a decision, both within >> the team and at the highest level of the Wikimedia Foundation, to not let >> perfect be the enemy of the good. Both with this feature, and in general. > > Great. Perfect should never be the enemy of the good. > > The problem is, the proposed change is not good; it's the opposite. > >> We can't make software that has zero edge-cases. If we tried to do that, we'd >> never release anything. > > Indeed not. Perhaps you could explain the basis for implying that the > instances I found (perhaps I was unlucky) are "edge cases". Maybe > there's some research on that you could share? > >> Especially with only two engineers. > > Yes; you mentioned that before. I suspect, therefore, that there's > some underlying yet serious issue about resourcing for your team. I'd > be happy to support you if you make a call for extra resources to > solve this and other issues, and to enable more or faster improvements > in the future. But I don't see it as justification for proceeding with > what appears to be a significant bug still in place, and one for which > no solution appears to be in sight. > > -- > 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
