From Wikipedia, the free encyclopedia

Avian Flu Vaccine

Flow chart for the creation of an avian flu vaccine using recombinant DNA technology and reverse genetics.
  1. I am nominating this diagram because it portrays a relatively sophisticated process in a clear and aesthetically pleasing manner (much much more clearly than could be done with text alone). Furthermore, avian flu is a hot-topic in the news and as the subject of this illustration, it should generate significant interest in the articles on the technologies portrayed.
  2. Technically: it is very high resolution. No compression artifacts - JPG but I doubt we will get a vector version, as a wikipedian was not the creator.
  3. It appears in vaccine - the only illustration there, and reverse genetics.
  4. Created by the NIH, it's public domain.
  • Nominate and support. - Debivort 21:05, 3 December 2006 (UTC) reply
  • Support This is a clear diagram producing a wealth of information. Very few jpeg artifacts. HighInBC (Need help? Ask me) 21:10, 3 December 2006 (UTC) reply
  • Oppose. Basically the textbook example of what not to make into a jpeg. Also this picture is worth the thousand words that appear all over it- and that could explain it just as well outside of an unneccessary, almost 2MB image -- froth T C 21:35, 3 December 2006 (UTC) reply
  • Comment. I simply don't know whether this picture is the best way to present the information it contains, but I'm in favour of novel types of FP (i.e. not just panoramas and satellite photos) and would not oppose this simply because of its file format (though I understand why SVG is a desirable format). Pstuart84 22:24, 3 December 2006 (UTC) reply
  • Oppose This is very well done but in order to view this I have to: 1. Click through to the image description page. 2. Click on the image to get it in full view. 3. Wait for it to download and shrink to fit into the browser window. Once it's shrunk it's readable but doesn't look very good – the text looks aliased. If I expand it I can't read it without scrolling because the image size is bigger than my screen resolution. So the image pretty usurps the job of an encyclopedia but makes it more cumbersome for the user to access the information. The images are all well done and should be used separately with accompanying text as copy text in the article. ~ trialsanderrors 00:26, 4 December 2006 (UTC) reply
  • Oppose per Trialsanderrors. ( UserTalk) 01:32, 4 December 2006 (UTC) reply
  • Support per nom. Sharkface217 04:55, 4 December 2006 (UTC) reply
  • Oppose. great hand-out, but as an illustration for an article I'd rather see this one chopped into smaller pics and have the text in the caption. Fileformat is just wrong, too. -- Dschwen 12:34, 4 December 2006 (UTC) reply
  • Weak Oppose - sorry, but this really should be either PNG, or if possible SVG, but definitely not JPG. — Vanderdecken ξ φ 17:52, 4 December 2006 (UTC) reply
I'm just going to go on the record once here with my opinion about JPG/SVG/PNG. I'm not trying to start a debate about this particular nomination - just sharing my broader thinking:
1) I believe SVG is an inferior format, on multiple platforms, in multiple browsers, with images generated from multiple graphics programs, it routinely suffers from a) failing to render text in thumbnails, b) taking too long to render full size, c) scaling text size inconsistently with image size, and d) changing fonts from the original design. Whether being able to translate the text or modify the vectors outweighs these problems is a matter of opinion; I believe the technical problems trump the wikiability.
2) PNG vs JPG boils down to quality vs size. JPG can be made of sufficiently high quality to display illustrations with no or extraordinarily minor artifacts, such as this image. Sometimes JPGs like this are too large. Obviously PNG addresses this, and is my format of choice.
3) When we do not have access to the source image, greater tolerance should be shown in format preference, just as is shown for technical quality of historic photos (for which there is no access to the source subject).
4) I believe people often use technical justifications for opposing nominations when they actually oppose for some other reason. It is extraordinarily easy to fall back on "blown highlights," "needs to be SVG," or "DOF too shallow" when one really means "another boring landscape," "too much text in the diagram / not pretty enough," or "another boring bee on a flower." I believe this is often done (perhaps unconsciously) to spare the feelings of the nominator. Fine, but this will inevitably reduce the efficacy of the FPC process to get us images that we do like.
5) Thank you for humoring the rant. Debivort 18:18, 4 December 2006 (UTC) reply
SVG is superior to raster graphics for diagrams and symbols because the data can easily be represented with a few lines of XML instead many kilobytes of data to define individual pixels. Also SVG is perfectly scalable- thumbnails are wikipedia's fault and it'll be fixed eventually -- froth T C 19:10, 4 December 2006 (UTC) reply
Until it's fixed, it remains an inferior format for wikipedia. Debivort 19:46, 4 December 2006 (UTC) reply
And until then you plan to chase off SVG and instead pile up images which are actually inferior? Well, I cannot disagree more on 1) but you hit it right with 4). -- Dschwen 21:40, 4 December 2006 (UTC) reply
I don't believe I've chased off anything. Like I said, 1) is a matter of opinion (rather than actually anything) - it's how each of us evaluates wikiability vs bugginess. If SVG becomes not buggy, the question will be moot. Debivort 21:55, 4 December 2006 (UTC) reply
It's not a matter of opinion; SVG is the ideal data type for these types of things. -- froth T C 20:32, 5 December 2006 (UTC) reply
I'm not sure what you are arguing. It may be "ideal" theoretically, but by your own statements, it is implemented poorly here. Surely that should lead us to consider alternatives until it is fixed. Debivort 21:06, 5 December 2006 (UTC) reply
Wouldn't it (in cases where the rendering bugs are noticable) be a reasonable compromise to upload both, the original SVG and a PNG rendered the way its intended to look, and crosslink them on their image pages? Its additional work, but atleast the sourcecode of the image (SVG) gets preserved and we can switch to it as soon as the bugs are fixed. -- Dschwen 08:03, 6 December 2006 (UTC) reply
A very good idea. I just hope people will be tolerant of the PNG component when it is explained that SVG is buggy - as they have indeed on some occasions. Debivort 13:33, 6 December 2006 (UTC) reply

Not promoted Raven4x4x 02:28, 11 December 2006 (UTC) reply