Talk:Reading/Features/Article lead image

The suggested redesign aims at providing a different display of media and content that makes content display more consistent and helps a quicker flow of reading and extracting information from our articles. We are sharing the suggestions here in order to help voice out and incorporate community suggestions around the proposed alternative. Please feel free to list your suggestions below, and lets see how we can incorporate them in next iterations.

Thanks :) --Melamrawy (WMF) (talk) 21:23, 17 August 2015 (UTC)

Looks great

Can't wait for it go live.--Anders Feder (talk) 23:56, 17 August 2015 (UTC)

discussion with Issara :)

Had a brief irc chat with Isarra and it went as below:

• (PDT 04:58:02 ) Isarra: Well, images, and for some topics they can be particularly effective for not just telling folks they're in the right place, but also information about the topic, but they do have limitations. Too big and they make it harder to get to the actual content, and some folks also have very limited bandwidth on mobile (mine's so limited I never even use it unless I'm utterly desperate), but they do need to be big enough to actually show the thing.
• (PDT 04:58:10 ) Isarra: And there's also some topics where they just won't do anything.
• (PDT 04:58:51 ) Isarra: But if you can make a way for editors to actively choose the image, I could see it being very effective.
• (PDT 04:59:49 ) Isarra: A bit like how they select images for featured articles on the mainpage, you can't assume the infobox will have anything relevant, or that the first image on the page in general will be appropriate
• (PDT 05:04:42 ) Isarra: Or just be able to disable it entirely, in some cases. Set it to no image.

On the page, you've linked this to phab:T77925. Isn't phab:T91683 more/as relevant?--Anders Feder (talk) 21:38, 18 August 2015 (UTC)

TheDJ

• I like the idea of moving the first paragraph above the infobox. It's way more logical to my expectations as a reader. The only reason that the infobox is where it is currently is due to the positioning on Desktop, requires it to be 'logically' above the first paragraph, but semantically and editorially there is no reason why it has to be there.
• The lead images go nicely with the repositioned infobox. The duplicate nature and appropriateness of the selected image have me concerned. The editorial options here are very limited and this should be a focal point. As an desktop user, i want to be able to quickly find out what image has been selected, and I want to know how I can at least influence that decision.
• WikiData descriptions have been a good experience for me so far. I do worry however that it again makes it a bit cluttered, but we can always remove them again. Also suggest making these more visible in the desktop site however, editors need to be able to check the reader experience on mobile in this regard.
• Last edited at the bottom seems sensible. It's where users expect this information I think and I don't think it was particularly good at giving us a human face..
• "Page issues + Disambiguation" i'm missing information on this front. Please explain this part further. Especially the disambiguation part.

I think that "page issues" means the appalling drive-by boxes that get slapped on the top of articles urging somebody else to fix problems like a lack of references. "Disambiguation" probably means the hatnotes that live in the vicinity of the "page issues". --RexxS (talk) 00:58, 19 August 2015 (UTC)

This point was clear, the unclarity is on what the proposed change would actually look like and what are the pros and cons etc. —TheDJ (Not WMF) (talk • contribs) 08:02, 19 August 2015 (UTC)

Wikidata

"The description for the Wikidata item will be shown below the title. The purpose is to provide a very quick description that also helps to disambiguate." - has this been discussed, on Wikidata, with the Wikidata community? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:10, 18 August 2015 (UTC)

We don't have consensus on en-wp to use Wikidata beyond inter-language links and inside infoboxes. The following is taken from w:Wikipedia:Wikidata #Inserting Wikidata values into Wikipedia articles:

Before considering the use of Wikidata in any particular article, editors should be aware of the conclusions of w:Wikipedia:Requests for comment/Wikidata Phase 2 (May 2013) which state:

There are two points discussed here and while the line between them is not entirely clear, there is nevertheless agreement that:

• It is appropriate to modify existing infoboxes to permit Wikidata inclusion when there is no existing English Wikipedia data for a specific field in the infobox (option 4 of the first question). There is sufficient support for option 3 however, to indicate that this modification should be done carefully and deliberately, at least at first.
• It is, on the other hand, not appropriate to use Wikidata in article text on English Wikipedia at this time (option 1 of the second question). There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but not consensus regarding this has been reached in this discussion.

I believe that if there are good arguments to expand the use of Wikidata in en-wp, then a new RfC will be needed. The last one is over two years old and it would be good to retest editors' opinions. --RexxS (talk) 00:40, 19 August 2015 (UTC)

Cropped images

Has the bug causing badly cropped images, which I identified when this method was used in the Android app, been resolved? I would consider it a blocker, if not. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:14, 18 August 2015 (UTC)

I'd strongly recommend giving editors the ability to select an image to use for the top, allowing them to over-ride the automatically-generated cropped one. There are multiple reasons for that, but principally it would ensure that human judgement could be used to make up for any deficiencies in the automated process, either technically or aesthetically. In the wiki model of editing, we are quite likely to have sufficient human resources for this kind of idea to be practical. --RexxS (talk) 00:47, 19 August 2015 (UTC)

I think what you need here is what Facebook does with their banner images as well. The ability to slightly position an image to make sure that the point of attention is correct. —TheDJ (Not WMF) (talk • contribs) 08:05, 19 August 2015

The wikidata page banner extension currently deployed on Wikivoyage solves this problem via an origin parameter and PAGEBANNER magic word. In theory this could be applied to this idea. If there are no plans to use it on desktop we would need to make its output non rendering. You can see it on wikivoyage:london. As User:TheDJ points out we would need to create some snazzy editing tool for it to get wide adoption. Definitely doable! :) Jdlrobson (talk) 00:47, 26 August 2015 (UTC)

In the app

If I visit the Nellie Bly article on my phone in the web browser, it looks like the image provided on the left, but if I use the app it looks more like the one on the right, only the infobox is collapsed by default with an option to view it. So some people are already seeing something more like what you're advocating. ONUnicorn (talk) 14:31, 19 August 2015 (UTC)

Page issues

task T93922 refers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:13, 20 August 2015 (UTC)