Images have different aspect ratios, this makes it such that most cards have empty space around the image making them look fragmented. Since the goal of the image is to provide context, Pau has recommended a "cover" strategy instead of the "contain" one (in css: background-size: cover; background-position-y: 33%;) To better fit most pictures of people, adjusting the image origin to one third (where the face tends to be). Other teams (in the mobile apps or mobile web areas) may have some APIs available to extract the relevant part of images with more advanced approaches.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | leila | T134900 [Epic] Article recommendation to more users | |||
| Resolved | Sabya | T134293 Improving the fitting of images in lists |
Event Timeline
Comment Actions
I tried this.
Is it OK if some images become pixelated? See attachments for what I mean. Cover strategy looks much better though.
Comment Actions
Here is the pull request:
https://github.com/wikimedia-research/translation-recs-app/pull/49
Comment Actions
What if instead we did something like having the original image in the foreground, and have a blurred version covering the empty space in the background:
Comment Actions
@Pginer-WMF, can you have a look at schana's recommendation and let us know if there is any issue we should be aware of? If not, do you recommend that we push the change?
Comment Actions
That's an approach that has been used frequently with vertical videos. The problem is that it still looks like two elements on top of each other, which adds to the overall visual complexity given that we are showing multiple images in a grid in our case.
I'd prefer to just cover the area with the image since the goal of it is to provide a general idea of what the article is about. I think this provides the simple approach to achieve our goal here. Even if some images may get some parts cropped, I think that's not a problem in this context.
I think the example using this approach looks really good:
Comment Actions
We specifically request the image be a certain size here. I don't see any options in the api request to specify a preference for landscape or portrait, but we could increase the size. It just will take longer to load for slower connections.
Comment Actions
In that case, I think 250px for width is good enough; as the size of a card size is around 248px X 128px.
But, I am noticing something strange. According to this doc, pithumbsize is supposed to ask for width, but the response of the following API, I think it is considering this parameter as height. Am I missing something?
Example:
One more thing to keep in mind, there are some articles like this, where the original image is less than 250px. In that case, there is no way to avoid pixelation, I guess?
Comment Actions
According to the api doc, it's just the maximum dimension. Right now we're requesting 256. If we bump that up to 512, that should be sufficient to cover the width even if it's a 2x1 portrait picture.
One more thing to keep in mind, there are some articles like this, where the original image is less than 250px. In that case, there is no way to avoid pixelation, I guess?
Yeah, I don't think there's anything we can do about that.
Comment Actions
I think that we can consider the case of having images smaller than 250px as a separate case. Solving for it should not affect the most common case.
For images with a width smaller than 250px, we can do one of the following:
- Ignore the image and treat them as if the image didn't exist. Articles without an image are already presented that way.
- Expand the image, and accept that some images will be pixelated if it is not too distracting as a background.
- Do not expand the image. A background (plain color, blurry version of the image or other) can be used just for those specific cases.
The simple solution could be not to use the image if it is not detailed enough for the card, but we can evaluate how other approaches work for these cases.
Comment Actions
Question:
I can see that some articles do have images but the query API does not return any. What could be the reason? Example:
API for http://en.wikipedia.org/wiki/Mister_Sinister
This doc says:
Currently it uses the first non-meaningless image used in the page.
So does the API think above articles don't have meaningful images? Or is it missing something?
Comment Actions
@schana - I've updated the pull request to fetch bigger images (512px). Please LMK if it is good enough for the merge.
@Pginer-WMF - Going ahead with the simplest solution right now, that is, let some images be pixelated if they are smaller than 256px in width. I did around 7-10 tests, number of images getting pixelated was rare.