Wikipedia Beta Android app update

List overview All Threads
Download

newer

older

experimental error reporting...

Dmitry Brant

17 Dec 2014 17 Dec '14

9:12 p.m.

Hi everyone, We're very excited to bring you our latest update to the Wikipedia Beta app, which should be available on the Google Play Store shortly[1]. The updated app packs a ton of awesome new features, the biggest of which are: * 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) * 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. It also displays the caption, as well as author and license information, overlaid on top of the image (tap once on the image to make the descriptions slide away). There are also options, accessible from the toolbar on the top right, for sharing the image, saving it to the photo gallery on your device, showing miscellaneous information (Exif) about the image, and navigating to its File: page on Wikipedia. * Search enhancements -- We have improved the search experience (accessible from the top toolbar) to intelligently incorporate search results from title-only searches, as well as full-text searches, so that typing a search term will give you the most relevant result, without having to switch between Title and Full-text search. More minor enhancements include: * Wikidata descriptions in Nearby search results. * Improved design of collapsed infoboxes and tables. * Improved design of the main toolbar and search interface. * Now bundling license information for open-source libraries that we use in the app (accessible from the More -> About screen) * Now using ProGuard in some portions of the app package, making it a bit smaller in size. * Numerous bug fixes for crashes and compatibility with various device types. We hope you enjoy using the updated app, and as always, we welcome your feedback! Cheers, Dmitry Brant Mobile Apps Team (Android) Wikimedia Foundation https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering [1] https://play.google.com/store/apps/details?id=org.wikipedia.beta

Attachments:

attachment.htm (text/html — 2.8 KB)

Show replies by thread

Andy Mabbett

18 Dec 18 Dec

9:55 p.m.

On 17 December 2014 at 21:12, Dmitry Brant <dbrant(a)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_… 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

Dmitry Brant

11:01 p.m.

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 <andy(a)pigsonthewing.org.uk> wrote:

...

On 17 December 2014 at 21:12, Dmitry Brant <dbrant(a)wikimedia.org> wrote:

are

properly aligned in the viewing area)

* 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

Vibha Bamba

11:17 p.m.

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 <dbrant(a)wikimedia.org> wrote:

...

On 17 December 2014 at 21:12, Dmitry Brant <dbrant(a)wikimedia.org> wrote:

persons are

properly aligned in the viewing area)

* 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

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.

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

Andy Mabbett

19 Dec 19 Dec

9:44 a.m.

On 18 December 2014 at 23:01, Dmitry Brant <dbrant(a)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

Andy Mabbett

9:46 a.m.

On 18 December 2014 at 23:17, Vibha Bamba <vbamba(a)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

Dan Garry

7:22 p.m.

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

Andy Mabbett

8:08 p.m.

On 19 December 2014 at 19:22, Dan Garry <dgarry(a)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_-_201… 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

9:58 p.m.

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 <andy(a)pigsonthewing.org.uk> wrote:

...

On 19 December 2014 at 19:22, Dan Garry <dgarry(a)wikimedia.org> wrote:

Given the above, we're not going to block releasing the feature because

this.

I'm very disappointed to hear that.

It's such a massive step forwards in terms of visual appeal

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

Andy Mabbett

11:27 p.m.

On 19 December 2014 at 21:58, Dan Garry <dgarry(a)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

Monte Hurd

20 Dec 20 Dec

4:04 a.m.

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 <andy(a)pigsonthewing.org.uk> wrote:

On 19 December 2014 at 21:58, Dan Garry <dgarry(a)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.

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.

Monte Hurd

4:22 a.m.

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 <andy(a)pigsonthewing.org.uk> wrote:

On 19 December 2014 at 21:58, Dan Garry <dgarry(a)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.

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.

Monte Hurd

4:26 a.m.

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 <andy(a)pigsonthewing.org.uk> wrote:

On 19 December 2014 at 21:58, Dan Garry <dgarry(a)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.

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.

Vibha Bamba

6:16 a.m.

...

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 <andy(a)pigsonthewing.org.uk> wrote: > > On 19 December 2014 at 19:22, Dan Garry <dgarry(a)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_-_201… > > 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(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l >

Andy Mabbett

11:59 a.m.

On 20 December 2014 at 06:16, Vibha Bamba <vbamba(a)wikimedia.org> wrote:

...

I'd like to know how the image linked above could be considered

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_-_201… ) - 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

Andy Mabbett

12:16 p.m.

On 20 December 2014 at 04:04, Monte Hurd <mhurd(a)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

Jon Robson

5:49 p.m.

...

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.

Dmitry Brant

6:31 p.m.

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(a)pigsonthewing.org.uk> wrote:

...

On 20 December 2014 at 04:04, Monte Hurd <mhurd(a)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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

Joaquin Oltra Hernandez

22 Dec 22 Dec

4:40 p.m.

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(a)wikimedia.org> wrote:

...

On 20 December 2014 at 04:04, Monte Hurd <mhurd(a)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

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

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,

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

3413

days inactive

3418

days old

mobile-l@lists.wikimedia.org

Manage subscription

18 comments

7 participants

tags (0)

participants (7)

Andy Mabbett
Dan Garry
Dmitry Brant
Joaquin Oltra Hernandez
Jon Robson
Monte Hurd
Vibha Bamba