[Python-ideas] Coloured documentation
Konrad Delong
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
_______________________________________________
Python-ideas mailing list
Python...@python.org
http://mail.python.org/mailman/listinfo/python-ideas
Jeremy Banks
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.
Sridhar Ratnakumar
> The documentation underhttp://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.
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.
CTO
On May 6, 9:55 am, Konrad Delong <kon...@gmail.com> wrote:
> The documentation underhttp://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
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
Leonardo Santagada
On May 6, 2009, at 2:22 PM, Sridhar Ratnakumar wrote:
> On 09-05-06 06:55 AM, Konrad Delong wrote:
>> The documentation underhttp://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.
>
> 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.
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
Georg Brandl
> On 09-05-06 06:55 AM, Konrad Delong wrote:
>> The documentation underhttp://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.
>
> 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.
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
MRAB
>
> On May 6, 2009, at 2:22 PM, Sridhar Ratnakumar wrote:
>
>> On 09-05-06 06:55 AM, Konrad Delong wrote:
>>> The documentation underhttp://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.
>>
>> 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.
>
> 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).
>
through Python 2.0 green to Python 3.0 blue. Not sure what happens when
we get to ultraviolet. New monitors? :-)
Georg Brandl
> Leonardo Santagada wrote:
>>
>> On May 6, 2009, at 2:22 PM, Sridhar Ratnakumar wrote:
>>
>>> On 09-05-06 06:55 AM, Konrad Delong wrote:
>>>> The documentation underhttp://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.
>>>
>>> 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.
>>
>> 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).
>>
> I was thinking of running through the spectrum from Python 1.0 red
> through Python 2.0 green to Python 3.0 blue. Not sure what happens when
> we get to ultraviolet. New monitors? :-)
Please no. The docs are already considered a bit too colorful by some people.
(Also, Python 1.0 is green and Python 2.0 is blue.)
Georg
Greg Ewing
> 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).
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
Greg Ewing
> I was thinking of running through the spectrum from Python 1.0 red
> through Python 2.0 green to Python 3.0 blue. Not sure what happens when
> we get to ultraviolet. New monitors? :-)
So for 3.2 we'll need sunblock, for and 3.5 we'll
need welding goggles... X-ray shielding for 4.0?
--
Greg
Leonardo Santagada
On May 6, 2009, at 10:32 PM, Greg Ewing wrote:
> Leonardo Santagada wrote:
>
>> 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).
>
> 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.
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
_______________________________________________
Talin
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
spir
Greg Ewing <greg....@canterbury.ac.nz> s'exprima ainsi:
> Leonardo Santagada wrote:
>
> > 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).
>
> 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.
>
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
Mathias Panzenböck
> On 09-05-06 06:55 AM, Konrad Delong wrote:
>> The documentation underhttp://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.
>
> 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.
+1 for sidebar, -1 for colour codes
8% to 10% of men have dyschromatopsia. encoding something in colour might be
good as some sort of enhancement, but all informations have always to be clearly
visibly for colourblinds, too.
-panzi
CTO
>
> 8% to 10% of men have dyschromatopsia. encoding something in colour might be
> good as some sort of enhancement, but all informations have always to be clearly
> visibly for colourblinds, too.
>
> -panzi
No harm in doing both, right?
Geremy Condra