Wikipedia talk:Collaboration to convert graphs to SVG

I'd like to see a rationale for any of the style guidelines.

In particular I don't agree with either of:

Avoid colour as much as possible. The graph should still be useable when printed then photocopied.
Try to use the smallest discernible difference – e.g., clearly different shades of grey are better than red, green, and blue.

Since SVG can include media-specific CSS stylesheets, printable versions of graphs can be tailored to that medium. I don't know how MediaWiki implements SVG rasterisation but there's no reason it couldn't support that in the future.

It's particularly contradictory to juxtapose a point about accessibility for print with a point which is contrary to accessibility: people with poor eyesight may need very high contrast to discern differences when displayed in black and white. Careful use of colour could be very helpful.

It's good form to contract the X-axis values where possible, so use, for example, "1996, '98, 2000, '02, '04" rather than spelling each year out in full.

No, it's not. It's ugly. It's also contrary to the official guidelines for dates.

Although I prefer using abbreviated dates ("1994, '96, '98, 2000, '02..."), for the sake of consistency, we should definitely change the format to Wikipedia's recommendation. (I do note, however, that the recommendation was more intended for article text, not graph labels.) El T 15:48, 21 July 2006 (UTC)[reply]

I'd also suggest some additional guidelines:

The source should be optimised for editability. For example, group elements intelligently, such as pie slices with captions, and do not rely on one element obscuring another to convey statistical information.

Optimisation

Should the image look good in an application like Firefox or should it look good in an application like Inkscape? The example graph of Netscape use looks good in Firefox but the line widths look bad in Inkscape.

I say we should optimise for whatever Wikipedia's rendering engine is. I've seen the SVG graphs rendered at least five different ways (Opera, Firefox, Adobe SVG viewer, Adobe Illustrator, and Wikipedia's engine), and they're all slightly different. Wikipedia is the only common thread between us, so I suggest we optimise for its rendering engine. El T 15:48, 21 July 2006 (UTC)[reply]

Colour

Avoiding colour is a rule of thumb, rather than something cast in stone. There are four reasons to prefer B&W.

It's very hard to tell which colour combinations will be hard for colour-blind users, whereas no colour blindness causes people to mistake shades of black-white-grey. People whose vision is extremely poor can enlarge the image, or any web page.
Using B&W forces people with poor design skills to make graphs that look at least vaguely presentable, because it's quite hard to make something garish when you're avoiding colours.
A print-out of a page or graph (e.g., for personal reference or to hand out to a class) will often be printed in B&W, and will almost certainly be photocopied in B&W. It's much better for end users to be given a reliable form that doesn't require any mucking around to remain useful.
Colour is often used to create an abstract between a key/legend and the actual data when there are better ways of labelling.

Also, note that I did say the smallest clearly discernible difference, so quite similar shades of grey should be avoided. El T 15:48, 21 July 2006 (UTC)[reply]

Editability of code

I definitely agree that the code should be designed for legibility when editing, especially regarding the logical grouping of elements. El T 15:48, 21 July 2006 (UTC)[reply]