Jump to content

Wikipedia talk:Collaboration to convert graphs to SVG

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Ravedave (talk | contribs) at 17:50, 22 October 2006 (Vertivle lines). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Style guidelines

Colour
I'd like to see a rationale for any of the style guidelines. In particular I don't agree with either of the following statements.

  1. "Avoid colour as much as possible. The graph should still be useable when printed then photocopied."
  2. "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.

Dates

"It's good form to contract the X-axis values where possible, so use, for example, "1996, '98, 2000, ' '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.

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.

—The preceding unsigned comment was added by 81.179.70.169 (talk • contribs) 22:58, 3 July 2006.

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 was always told never *ever* to use contractions or "ditto" symbols in tables, charts or graphs (my area is math/CS), so I was rather surprised to read that bit about contractions being "good form". Phils 11:46, 25 July 2006 (UTC)[reply]
It's more a rule of thumb than a "never ever" thing. There's a lot of potential for confusion if you start abbreviating things, especially in tables. However, in the limited scope of the x-axis where the pattern is perfectly clear (especially if the contraction is marked with an apostrophe), then it lessens clutter on the graph, which makes the graph far neater. Using contractions and ditto marks has always been good form in well-designed graphs and tables. Spelling things out fully often creates clutter and conceals meaningful data. El T 14:25, 26 July 2006 (UTC)[reply]


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. —The preceding unsigned comment was added by 24.20.211.228 (talk • contribs) 04:42, 20 July 2006.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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]

Comments

Concerning #2. The majority of digital graphs are computer-generated, if not all of them. Someone with "poor design skills" can only ever make the mistake of choosing hues of colors that hurt to look at. There's no reason to enforce a militant look for graphs in lieu of a "might look like crap" safety net. Granted, color and style are not the most important aspects of a graph, but we should at the very least be encouraging individuals to follow guidelines for visual appeal, instead of nixing the aspect altogether. —The preceding unsigned comment was added by 134.174.110.5 (talk • contribs) 11:34, 7 August 2006 .   ( User 134.174.110.5 performed a minor copyedit at 11:35, 7 August 2006 . )

Concerning #3. Why not just enforce CMYK-safe color palettes, or offer a Grayscale alternative version for printing? —The preceding unsigned comment was added by 134.174.110.5 (talk • contribs) 11:35, 7 August 2006 (UTC)

Response. Very few people know about CMYK-safe colours, let alone understand them. And print alternatives wouldn't work for most people, who just print the main article page and hope for the best. (El T 13:54, 9 August 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]

Vertivle lines

I noticed that none of the charts have vertical lines, can that be added to the standard? It may not look as nice but it makes the chart more useful. An example: Image:Population_of_the_United_States,_1790-2000.png (not svg but similar style). When did the population flatten out? Without knowing history and without holding a piece of paper to the screen it is very hard to tell which year. -Ravedave (help name my baby) 17:50, 22 October 2006 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Collaboration_to_convert_graphs_to_SVG&oldid=83036433"