The documentation under http://docs.python.org/ could have different colour schemes for Python 2.5, 2.6, 2.7, 3.0, 3.1 and so on. This way one would know on sight which docs one's reading. It would also cause a lot of bikeshed talk for every release :) Konrad
I'm +1 if it could be implemented without much hassle. Perhaps the bikeshedding could be minimized by deciding in advance on how the colors would be calculated. Something like... R = (MAJOR + MINOR / 16) / 5 G = 1 - ((MAJOR + MINOR / 16) / 5) B = REVISION / 16 So the change would be more dramatic between larger changes. On 2009-05-06, Konrad Delong <konryd@gmail.com> wrote:
I've found through experimentation that Georg's default CSS color scheme looks pretty good when you apply a hue rotation. (I.e. convert to HSB, add a delta to H, then convert back to RGB.) In fact, if you are using Sphinx and you want something that looks (a) pretty, and (b) different than the default, but you don't want to spend a lot of time tweaking all of the colors, a global hue rotation is the easiest way to go. The net result is that light colors stay light, dark colors dark, and complementary colors stay complementary, and the whole thing stays readable. A 30 degree rotation for each release would allow for adjacent releases to be visually distinct, and would allow for 12 releases before the color scheme repeats. If more schemes are needed, you can generate additional permutations by swapping color components. -- Talin Jeremy Banks wrote:
On 09-05-06 06:55 AM, Konrad Delong wrote:
Good idea, although I'd rather have a vertical bar instead of color schemes. For example, the vertical bar here, http://www.w3.org/TR/2009/PER-xpath-functions-20090421/ that reads "W3V Proposed Edited Recommendation" could read "2.6" in slightly bigger font for the Python docs.
On May 6, 2009, at 2:22 PM, Sridhar Ratnakumar wrote:
I'm +1 for the color bar idea like w3c and also we should just choose a color palette and then jus choose a color for each new release of python (and of course the back ones). No color formulas based on versions please (this would just end up in ugly colors and no one knowing how to decode the version from the color anyway). -- Leonardo Santagada santagada at gmail.com
Leonardo Santagada wrote:
Instead of just one colour, parts of the page could be coloured according to different parts of the version number, e.g. header from the major version and sidebar from the minor version, with maybe a stripe somewhere for the revision. The digits could be encoded using the standard resistor colour code: 0 - black 1 - brown 2 - red 3 - orange 4 - yellow 5 - green 6 - blue 7 - purple 8 - grey 9 - white Then there would be no problem recovering the version number from the colour scheme. -- Greg
On May 6, 2009, at 10:32 PM, Greg Ewing wrote:
Without an emoticon I can't know for certain if this is a joke (but I'm pretty sure it is). (maybe an even funnier one would be to put a sidebar with the version written all over it vertically, forming a texture). The thing is that having a border (maybe just on the right side) on the online version of the docs help to give people guidance, if they are used to the python 2.6 docs they will know when something is changed when looking at the 3.1 docs. But maybe one color for each version is too much, maybe just one color for the 2.x series and another for the 3.x series, maybe people who had this problem more than I did can say if they got confused around different 2.x versions or only 3 to 2 diffs. -- Leonardo Santagada santagada at gmail.com
Le Thu, 07 May 2009 13:32:08 +1200, Greg Ewing <greg.ewing@canterbury.ac.nz> s'exprima ainsi:
I like the idea. We could hardly find a simpler encoding colour scheme for the version. Also, the resistor colour sequence include the common rainbow sequence (2..7). About layout, I don't think we need big colour bars or such invasive things. A little symbol at the lower left or right corner could do the job: ##### major @ @ minor If you know what the symbol means, you don't need it big. If you don't, having it big does not help. It's easier to add it to the current layout, too. The issue is that python's doc holds many very long pages split into sections and sub-sections, etc.. so that it's common to land somewhere inside in a page (either from a toc or external link). The colour mark should then be static if we want it be really useful, but it's a much more difficult thing and does not fit at all with the present layout (no static top or side bar). Another possibility is to use the version color as title backgroud in place of the present gray. I wouldn't find this agressive, as long as the colors are rather pastel than bright, because the same colour would be used on the whole page. But surely there would be much resistance to this idea. Denis ------ la vita e estrany
Sridhar Ratnakumar schrieb:
First, it's not like the docs' version is not displayed on every page at the top and bottom :) Still, I can see that it would be helpful if it was kept visible all the time. I've experimented with some CSS to make the top navigation bar sticky; however I could not find a way to do this without the heading being hidden when jumping to an anchor. If someone has a patch, please step forward, but please let's put this discussion on the doc-SIG. cheers, Georg
On May 6, 9:55 am, Konrad Delong <kon...@gmail.com> wrote:
Great idea, I get bitten by this all the time. Also looks like its just a simple tweak- <URL: http://sphinx.pocoo.org/theming.html>. Geremy Condra
I'm +1 if it could be implemented without much hassle. Perhaps the bikeshedding could be minimized by deciding in advance on how the colors would be calculated. Something like... R = (MAJOR + MINOR / 16) / 5 G = 1 - ((MAJOR + MINOR / 16) / 5) B = REVISION / 16 So the change would be more dramatic between larger changes. On 2009-05-06, Konrad Delong <konryd@gmail.com> wrote:
I've found through experimentation that Georg's default CSS color scheme looks pretty good when you apply a hue rotation. (I.e. convert to HSB, add a delta to H, then convert back to RGB.) In fact, if you are using Sphinx and you want something that looks (a) pretty, and (b) different than the default, but you don't want to spend a lot of time tweaking all of the colors, a global hue rotation is the easiest way to go. The net result is that light colors stay light, dark colors dark, and complementary colors stay complementary, and the whole thing stays readable. A 30 degree rotation for each release would allow for adjacent releases to be visually distinct, and would allow for 12 releases before the color scheme repeats. If more schemes are needed, you can generate additional permutations by swapping color components. -- Talin Jeremy Banks wrote:
On 09-05-06 06:55 AM, Konrad Delong wrote:
Good idea, although I'd rather have a vertical bar instead of color schemes. For example, the vertical bar here, http://www.w3.org/TR/2009/PER-xpath-functions-20090421/ that reads "W3V Proposed Edited Recommendation" could read "2.6" in slightly bigger font for the Python docs.
On May 6, 2009, at 2:22 PM, Sridhar Ratnakumar wrote:
I'm +1 for the color bar idea like w3c and also we should just choose a color palette and then jus choose a color for each new release of python (and of course the back ones). No color formulas based on versions please (this would just end up in ugly colors and no one knowing how to decode the version from the color anyway). -- Leonardo Santagada santagada at gmail.com
Leonardo Santagada wrote:
Instead of just one colour, parts of the page could be coloured according to different parts of the version number, e.g. header from the major version and sidebar from the minor version, with maybe a stripe somewhere for the revision. The digits could be encoded using the standard resistor colour code: 0 - black 1 - brown 2 - red 3 - orange 4 - yellow 5 - green 6 - blue 7 - purple 8 - grey 9 - white Then there would be no problem recovering the version number from the colour scheme. -- Greg
On May 6, 2009, at 10:32 PM, Greg Ewing wrote:
Without an emoticon I can't know for certain if this is a joke (but I'm pretty sure it is). (maybe an even funnier one would be to put a sidebar with the version written all over it vertically, forming a texture). The thing is that having a border (maybe just on the right side) on the online version of the docs help to give people guidance, if they are used to the python 2.6 docs they will know when something is changed when looking at the 3.1 docs. But maybe one color for each version is too much, maybe just one color for the 2.x series and another for the 3.x series, maybe people who had this problem more than I did can say if they got confused around different 2.x versions or only 3 to 2 diffs. -- Leonardo Santagada santagada at gmail.com
Le Thu, 07 May 2009 13:32:08 +1200, Greg Ewing <greg.ewing@canterbury.ac.nz> s'exprima ainsi:
I like the idea. We could hardly find a simpler encoding colour scheme for the version. Also, the resistor colour sequence include the common rainbow sequence (2..7). About layout, I don't think we need big colour bars or such invasive things. A little symbol at the lower left or right corner could do the job: ##### major @ @ minor If you know what the symbol means, you don't need it big. If you don't, having it big does not help. It's easier to add it to the current layout, too. The issue is that python's doc holds many very long pages split into sections and sub-sections, etc.. so that it's common to land somewhere inside in a page (either from a toc or external link). The colour mark should then be static if we want it be really useful, but it's a much more difficult thing and does not fit at all with the present layout (no static top or side bar). Another possibility is to use the version color as title backgroud in place of the present gray. I wouldn't find this agressive, as long as the colors are rather pastel than bright, because the same colour would be used on the whole page. But surely there would be much resistance to this idea. Denis ------ la vita e estrany
Sridhar Ratnakumar schrieb:
First, it's not like the docs' version is not displayed on every page at the top and bottom :) Still, I can see that it would be helpful if it was kept visible all the time. I've experimented with some CSS to make the top navigation bar sticky; however I could not find a way to do this without the heading being hidden when jumping to an anchor. If someone has a patch, please step forward, but please let's put this discussion on the doc-SIG. cheers, Georg
On May 6, 9:55 am, Konrad Delong <kon...@gmail.com> wrote:
Great idea, I get bitten by this all the time. Also looks like its just a simple tweak- <URL: http://sphinx.pocoo.org/theming.html>. Geremy Condra
participants (11)
-
CTO -
Georg Brandl -
Greg Ewing -
Jeremy Banks -
Konrad Delong -
Leonardo Santagada -
Mathias Panzenböck -
MRAB -
spir -
Sridhar Ratnakumar -
Talin