4

The Community Ads for 2016 have the nice feature that you can use an image that's double the size (i.e. 600×500px, instead of the standard 300×250px) and this will produce a better display in retina-like high-resolution devices that use a higher pixel density than normal.

One downside of this is that in the community ad threads on meta sites, each individual ad looks twice as big as will be displayed, and this (i) makes it harder to gauge how the ad will actually look when it goes live, and (ii) makes the ads clunkier and the thread harder to navigate around.

Fortunately, though, there is a nice markdown-like way to scale such images down. Consider, for example the advert

[![Detexify: automated LaTeX symbol recognition][1]][2]

  [1]: https://i.sstatic.net/E9D64.png
  [2]: http://detexify.kirelabs.org/classify.html

Detexify: automated LaTeX symbol recognition

with its huge big image. As it turns out you can get a medium-sized version of this image by appending an m to the file name, so that 

[![Detexify: automated LaTeX symbol recognition][1]][2]

  [1]: https://i.sstatic.net/E9D64m.png
  [2]: http://detexify.kirelabs.org/classify.html

will produce

Detexify: automated LaTeX symbol recognition

and give a much better sense of how the ad will display.

Before this can be used, though, it requires the parsing algorithm (the bit that grabs the images from the answers and serves them as ads) be adjusted so that the correct image will be displayed. Luckily this is a pretty easy feature request:

  • Please adjust the parsing algorithm so that it will remove the ms from any images that use it before displaying them as ads.

Alternatively, if this doesn't work, it would be nice to have some way to size down the images in the thread that doesn't impact the actual displayed size. As an example, the threads could use Mou-like syntax so that, say, 

[![Detexify: automated LaTeX symbol recognition][1]][2]

  [1]: https://i.sstatic.net/E9D64.png =300x250
  [2]: http://detexify.kirelabs.org/classify.html

also rendered at that width.

Straying a bit from the markdown route, it's always been possible to use explicit html image tags to set the displayed width. If the ad-processing algorithm can be updated to parse correctly posts of the form

[<img src="https://i.sstatic.net/E9D64.png" width="300" 
      title="Detexify: automated LaTeX symbol recognition">][1]

  [1]: http://detexify.kirelabs.org/classify.html

then that would also work.

Is either of these options a reasonable thing to implement?

Improve this question
7
  • Note that the m suffix serves a different, lower-resolution image file, so that would only replace the problem of not showing what the ad will look like with a different (possibly worse, even) problem of not showing what the ad will look like.
    – SevenSidedDie
    Commented Jul 7, 2016 at 18:44
  • @SevenSidedDie For sure, the ideal solution is the html-based one, or an explicit markup notation for image size. An alternative is altering the display engine for those threads (so the post shows the ad as it will be displayed) but that's not ideal to say the least.
    – E.P.
    Commented Jul 7, 2016 at 18:49
  • On the other hand, I'm not sure it doesn't show the ad as it will be displayed, at least on normal-res devices. The images are resized anyway when served to low-res devices, so it might actually show a better impression of the ad as it will be shown. But hopefully a team member can comment on the details?
    – E.P.
    Commented Jul 7, 2016 at 18:52
  • It doesn't show the ad as displayed. Currently on an iOS device and the two images above are obviously different: the second is badly blurred compared to the first. The m suffix reduces resolution server-side, which is what the double-sized ads are deliberately avoiding in order to give better images on high-res screens. The HTML option would work in that regard—its resizing is client-side and would serve the correct image—but yes, is technically challenging.
    – SevenSidedDie
    Commented Jul 7, 2016 at 18:54
  • Sorry, scratch my last comment - images aren't resized server-side when the client is low-res. The ideal solution is a Markdown or html-based resizing, which are not subject to the downsides you note.
    – E.P.
    Commented Jul 7, 2016 at 19:02
  • I'm not sure it's that technically challenging, though. All that's needed, on the html route, is a syntax parser for a format that can be very rigidly defined beforehand in the specs on the question. The mardown resizer is similar but it does require adding capabilities to the existing display engine. (But those capabilities are welcome anyway!)
    – E.P.
    Commented Jul 7, 2016 at 19:04
  • “Technically challenging” as in, it's asking for a non-trivial code change in at least two parts of the codebase (the parser/tidier and the renderer at least, but possibly others) and all the time and programmer salary (and inevitable bugs and more programmer salary) that go with that, for a relatively tiny feature gain. The technical aspects of the change are an inherent challenge for the feature request to overcome — that meaning of “technically challenging”. ;)
    – SevenSidedDie
    Commented Jul 7, 2016 at 21:34

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .