Re: [WikimediaMobile] Wikipedia Beta Android app update
On 20 December 2014 at 06:16, Vibha Bamba vba...@wikimedia.org wrote: I'd like to know how the image linked above could be considered helpful to a reader. Regarding this specific querry: We have actually tested this. We spoke to a few users and seeing the combination of an image, the title and the wikidata description immensely helps visual learners. Not all users learn by reading text. For example: This is especially important for articles related to flora fauna. Hope this helps You'll note that I asked about how **the image linked above** could be considered helpful to a reader. (emphasis added; that image was https://commons.wikimedia.org/wiki/File:Wikipedia_mobile_app_beta_bug_-_2014-12-18_-_06.png ) - indeed, you refer to my 'specific' query. Are you really saying that you tested that image? (Or even anything like it?) Or did you test using images where the cropping applied didn't result in such inanity? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Wikipedia Beta Android app update
On 20 December 2014 at 04:04, Monte Hurd mh...@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
Re: [WikimediaMobile] Wikipedia Beta Android app update
You'll note that I asked about how **the image linked above** could be considered helpful to a reader. (emphasis added; that image was https://commons.wikimedia.org/wiki/File:Wikipedia_mobile_app_beta_bug_-_2014-12-18_-_06.png ) - indeed, you refer to my 'specific' query. Are you really saying that you tested that image? (Or even anything like it?) Or did you test using images where the cropping applied didn't result in such inanity? From a developers point of view catching every possible edge case is difficult to do first time round but I have every confidence in the app development team that these examples are in a minority and this will improve over time. I'm not sure where the image comes from right now but in future I envision this is also part of the editorial process and editors can help with this by choosing appropriate images, optimising for this sort of display (maybe a Wikidata app image property). Thinking out loud here but really what I'm saying is I'm happy to see us innovating, and I don't think we should get too distressed by certain cases which don't quite work, software is never done. We hit similar issues early on with the nearby feature for mobil web where we had instances of articles that were not nearby showing up in the UI and being incorrectly positioned due to problems with the API. As a result apps were able to get the nearby feature in really easily and even added a cool orientation aspect to push it to the next level! With people raising these bugs the software got better and the end result even more so. ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Wikipedia Beta Android app update
On 18 December 2014 at 23:01, Dmitry Brant dbr...@wikimedia.org wrote: , the other images being suboptimally aligned simply exposes the fact that we're not always able to detect the best possible alignment for the image I wouldn't say not always able to detect the 'best' possible alignment; I'd say unable to display images in an adequate manner. For now, all we can do is default to centering the image in that viewing area. I trust this feature won't go live until the issue is properly resolved. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Wikipedia Beta Android app update
On 18 December 2014 at 23:17, Vibha Bamba vba...@wikimedia.org wrote: focal point repositioning for images as a micro-contribution Where can we find out more about this development, please? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Wikipedia Beta Android app update
Hey Andy, Thanks for testing our beta and for taking the time to give us feedback! We have had quite a few issues with this work on Android 2.3. Thanks for forwarding those screenshots, they were very helpful for diagnosing the issues! We've written a fix for the issue you reported with the tap zone for the image viewer being larger than expected, and we're working on a fix for the Read more section appearing underneath the article content now. In terms of images not centring correctly, we knew going in to this that it wouldn't be possible to have a perfectly centred image in every case. We've taken several steps to alleviate the problem of images not being perfectly centred: 1. Tapping on any image (including a lead image) will always show you the full size image in the image viewer, so if it was awkwardly cropped then you can see the full image that way. 2. The image in the lead panel is copied there, not moved there, so it's also still visible in its original context in the article. 3. If there's a face in the lead image, we try to use a library built in to Android that can do face detection and centre the image using that. Given the above, we're not going to block releasing the feature because of this. It's such a massive step forwards in terms of visual appeal that we don't think not releasing it because of a few edge cases makes sense. If our team was much larger, we would spend more time on this problem, but alas, we are a small team (two engineers on the Android app). In terms of making it a contribution mechanism to lets users centre the image correctly, we're not focussing on that right now. It's definitely something we'll think about in the future, but right now our goals are based on readership, not contribution mechanisms. With such a small team we can't afford to tackle both at once whilst also maintaining the Android platform. Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Wikipedia Beta Android app update
I'm sorry that you feel our efforts are not good enough. 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. We can't make software that has zero edge-cases. If we tried to do that, we'd never release anything. Especially with only two engineers. Dan On 19 December 2014 at 12:08, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 19 December 2014 at 19:22, Dan Garry dga...@wikimedia.org wrote: Given the above, we're not going to block releasing the feature because of this. I'm very disappointed to hear that. It's such a massive step forwards in terms of visual appeal I beg to disagree. This: https://commons.wikimedia.org/wiki/File:Wikipedia_mobile_app_beta_bug_-_2014-12-18_-_06.png is not a step forwards in terms of visual appeal; much less a massive one; it's a retrograde step that makes the encyclopedia look slipshod and amateur. our goals are based on readership I'd like to know how the image linked above could be considered helpful to a reader. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] Wikipedia Beta Android app update
Hi, As a heads-up, we've released another update of the beta app a few minutes ago. This a more of a bug fix release: * Fix lead image click area in 2.3. This made it really hard to use the app on Android 2.3. * Go to first suggestion when search submit button is pressed instead of taking the entered text literally. * Updated share icon in image viewer. * Fix various crashes. Cheers, Bernd Mobile Apps Team (Android) Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Wikipedia Beta Android app update
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
Re: [WikimediaMobile] Wikipedia Beta Android app update
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
Re: [WikimediaMobile] Wikipedia Beta Android app update
Oh, or we could do a subtle rotational 3D transform about the x axis which tracked with the device rotation about the x axis, but reversed, and clipped to, say, +- 5 degrees. The effect would be, if you tilt the device away from yourself, the image would ever so subtly appear to maintain perpendicular orientation from your perspective. In so tilting, the top and bottom cropped bits would be progressively revealed/hidden. It would be another neat clue and super discoverable - if you move you'd notice it, and maybe want to tap it :) I love apps. 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
Re: [WikimediaMobile] Wikipedia Beta Android app update
One more - probably a bad idea, but we could disrespect the original image aspect ratio and do an aspect fit scale. Nothing would be cropped, but things could stretch/squish. 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
Re: [WikimediaMobile] Wikipedia Beta Android app update
I'd like to know how the image linked above could be considered helpful to a reader. Regarding this specific querry: We have actually tested this. We spoke to a few users and seeing the combination of an image, the title and the wikidata description immensely helps visual learners. Not all users learn by reading text. For example: This is especially important for articles related to flora fauna. Hope this helps Vibha Vibha Bamba Senior Designer | WMF Design On Sat, Dec 20, 2014 at 1:38 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 19 December 2014 at 19:22, Dan Garry dga...@wikimedia.org wrote: Given the above, we're not going to block releasing the feature because of this. I'm very disappointed to hear that. It's such a massive step forwards in terms of visual appeal I beg to disagree. This: https://commons.wikimedia.org/wiki/File:Wikipedia_mobile_app_beta_bug_-_2014-12-18_-_06.png is not a step forwards in terms of visual appeal; much less a massive one; it's a retrograde step that makes the encyclopedia look slipshod and amateur. our goals are based on readership I'd like to know how the image linked above could be considered helpful to a reader. -- 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
Re: [WikimediaMobile] Wikipedia Beta Android app update
On 17 December 2014 at 21:12, Dmitry Brant dbr...@wikimedia.org wrote: * Lead Images -- When navigating to an article, the app now displays the most relevant image from the article at the very top, with the image expanded to fit the width of your screen, and the title of the article overlaid onto it. This provides a much improved visual context of the article, and a better entry point into starting your reading experience. (We're even doing face-detection in the image, so that photos of persons are properly aligned in the viewing area) I've found a number of bugs with this (all on HTC Desire HD, running Android 2.3.5, native browser), which can be seen in: https://commons.wikimedia.org/wiki/Category:Wikipedia_mobile_app_beta_bugs_-_2014-12-18 They include text over key parts of images (images numbered 3 and 4) and badly cropped images (2, 5, 6 ,7), (Image 1 shows a different problem, with the featured article.) * Image Viewer -- Tapping on any image in an article (including the lead image) will take you to a full-screen image viewer where the image may be panned and zoomed. I found this happened when I tapped on other parts of the page, even when the image was scrolled off-screen. * Wikidata descriptions in Nearby search results. When will we get the pins-on-map view back? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Wikipedia Beta Android app update
Thanks Andy! +1 to what Dmitry said. Apart from what you brought up, in many articles maps show up as lead images. Maps that you can't interact with are a frustrating experience. This first leg of work on lead images improves 90% of the articles. Getting everything 100% right just isn't possible with the large amount of unstructured information and annotation we have around images. Once we introduce focal point repositioning for images as a micro-contribution, these weak areas start to get ironed out. Thanks Vibha Vibha Bamba Senior Designer | WMF Design On Fri, Dec 19, 2014 at 4:31 AM, Dmitry Brant dbr...@wikimedia.org wrote: Hi Andy, Thanks for uploading the screenshots! Image #1 looks like a bona fide bug that we'll need to investigate. However, the other images being suboptimally aligned simply exposes the fact that we're not always able to detect the best possible alignment for the image (our face detection algorithm cannot yet detect faces of wallabies, owls, or lorises!). For now, all we can do is default to centering the image in that viewing area. You may still tap on the image to view it in full-screen mode. (We'll also investigate the other issues you mentioned.) -Dmitry On Thu, Dec 18, 2014 at 4:55 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 17 December 2014 at 21:12, Dmitry Brant dbr...@wikimedia.org wrote: * Lead Images -- When navigating to an article, the app now displays the most relevant image from the article at the very top, with the image expanded to fit the width of your screen, and the title of the article overlaid onto it. This provides a much improved visual context of the article, and a better entry point into starting your reading experience. (We're even doing face-detection in the image, so that photos of persons are properly aligned in the viewing area) I've found a number of bugs with this (all on HTC Desire HD, running Android 2.3.5, native browser), which can be seen in: https://commons.wikimedia.org/wiki/Category:Wikipedia_mobile_app_beta_bugs_-_2014-12-18 They include text over key parts of images (images numbered 3 and 4) and badly cropped images (2, 5, 6 ,7), (Image 1 shows a different problem, with the featured article.) * Image Viewer -- Tapping on any image in an article (including the lead image) will take you to a full-screen image viewer where the image may be panned and zoomed. I found this happened when I tapped on other parts of the page, even when the image was scrolled off-screen. * Wikidata descriptions in Nearby search results. When will we get the pins-on-map view back? -- 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 ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
