-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/20/2012 06:45 PM, Guido van Rossum wrote:

Nice and clean, but looks too similar to newer Google properties... Also I see that (like Google) you're falling for the fallacy of using less contrast. From an accessibility perspective that's questionable -- and I don't mean the legally blind, just people like myself whose eyes are getting a bit older. This also means I don't particularly like adding background color (no matter how light) to text samples.

+1. Even make comments low-contrast defeats their purpose (italic works fine for that). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9pFmsACgkQ+gerLs4ltQ7fpwCeOY5p2HnqotHrWrN5vqsHfcsl 2EYAn3cnlemVO/RKavU3SC4w5b+q66S6 =Oryl -----END PGP SIGNATURE-----

On 20.03.2012 23:45, Guido van Rossum wrote:

Nice and clean, but looks too similar to newer Google properties... Also I see that (like Google) you're falling for the fallacy of using less contrast. From an accessibility perspective that's questionable -- and I don't mean the legally blind, just people like myself whose eyes are getting a bit older. This also means I don't particularly like adding background color (no matter how light) to text samples.

Well, to be fair, the current theme also has a lot of shading, and the text in the sidebar is at lower contrast too. But I can see that the main text should remain at as high contrast as possible. Georg

On Tue, Mar 20, 2012 at 3:55 PM, John O'Connor wrote:

On Tue, Mar 20, 2012 at 6:38 PM, Georg Brandl wrote:

...

recently I've grown a bit tired of seeing our default Sphinx theme, especially as so many other projects use it.

I think regardless of the chosen style, giving the Python 3 docs a different look and feel also has a psychological benefit that might further encourage users to consider moving to Python 3. It could be a bit of a wake-up call.

+3 Of course you do realize that the only possible outcome of this thread which is *literally* about painting the docs bike shed is to have a row of dynamic "change my css theme" buttons somewhere with one for each person that has piped up in this thread. Which would lead to a stateful docs web server with cookie preferences on which css to default to for each and every viewer. This doesn't end well... ;) Good luck (and thanks for trying, I like seeing the new styles!) -gps

On 21.03.2012 00:17, R. David Murray wrote:

On Tue, 20 Mar 2012 23:38:53 +0100, Georg Brandl wrote:

...

Hi all,

recently I've grown a bit tired of seeing our default Sphinx theme, especially as so many other projects use it. I decided to play around with something "clean" this time, and this is the result:

http://www.python.org/~gbrandl/build/html/

The font looks better in my browser, but otherwise I prefer the current style. The biggest thing I don't like about the new style is the fact that the content is not set off from the chrome by shading. Having it shaded makes it easier for my eye to ignore it and just focus on the content.

Not sure what "the unshaded chrome" is -- only the header bar, since the sidebar is shaded already? Georg

On 21.03.2012 01:57, Raymond Hettinger wrote:

On Mar 20, 2012, at 5:37 PM, Antoine Pitrou wrote:

...

Georg Brandl mailto:g.brandl@gmx.net> wrote:

...

Hi all,

recently I've grown a bit tired of seeing our default Sphinx theme, especially as so many other projects use it. I decided to play around with something "clean" this time, and this is the result:

http://www.python.org/~gbrandl/build/html/

Not enough colours, and/or not enough visual cues for page structure.

cheers

Antoine.

Like Antoine, I'm having a hard time navigating the page. For me, the current theme is *much* better.

OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Georg

Turn your monitor portrait or make the window smaller :)

On Wed, Mar 21, 2012 at 09:33:13AM +0000, Jonathan Hartley wrote:

...

On Wed, Mar 21, 2012 at 07:00, Georg Brandl wrote:

...

OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. I realise this is bikeshedding by now, but FWIW, please don't. If

On 21/03/2012 08:25, Dirkjan Ochtman wrote: people want shorter lines, they can narrow their browser, without forcing that preference on the rest of us.

Seconded. My display is 1920x1200 but I use very large fonts and I'm satisfied with line lengths. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

21.03.12 14:38, Ned Batchelder написав(ла):

The best thing to do is to set a max-width in ems, say 50em. This leaves the text at a reasonable width, but adapts naturally for people with larger fonts.

It's good for books, magazines, and newspapers, but not for technical site. ;)

On 2012-03-21, at 11:06 AM, Łukasz Rekucki wrote:

FYI, the current paragraph font size on docs.python.org is 16px, while for http://www.python.org/~gbrandl/build/html/ it's 13px, so increasing that should help readability :) You can use @media queries to adjust it to screen resolution, which should solve the problem with long lines.

+1. It's much harder to read text in the new design. I would also make links a bit darker. - Yury

21.03.12 18:00, Guido van Rossum написав(ла):

(Can you see why I invented a whitespace-sensitive language? I have a whitespace-sensitive brain. :-)

It should be added to favorite quotes.

On 21/03/2012 09:33, Jonathan Hartley wrote:

...

On Wed, Mar 21, 2012 at 07:00, Georg Brandl wrote:

...

OK, that seems to be the main point people make... let me see if I can come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. I realise this is bikeshedding by now, but FWIW, please don't. If people want shorter lines, they can narrow their browser, without forcing that

On 21/03/2012 08:25, Dirkjan Ochtman wrote: preference on the rest of us.

+ sys.maxint Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

On 3/21/2012 7:09 AM, Antoine Pitrou wrote:

On Tue, 20 Mar 2012 21:39:41 -0400 Terry Reedy wrote:

...

On 3/20/2012 6:38 PM, Georg Brandl wrote:

The current green on the front page is too heavy.

Green? hmm... you mean blue, right? :)

Yeh, a muddy slightly greenish blue. I would prefer what I call a real blue, as in the logo, or the quoted text above on Thunderbird. -- Terry Jan Reedy

On Tue, 20 Mar 2012 21:58:57 -0400 Ned Batchelder wrote:

...

Let me know what you think, or play around and send some improvements. (The collapsible sidebar is not adapted to it yet, but will definitely be integrated before I consider applying a new theme to the real docs.) Not to add to the chorus of tweakers, but if I could change just one

On 3/20/2012 6:38 PM, Georg Brandl wrote: thing about the current theme, it would be to remove full justification of the text.

Ow, I hate non-justified text myself :( Bikeshedding Antoine.

On 3/21/2012 9:44 AM, Serhiy Storchaka wrote:

21.03.12 03:58, Ned Batchelder написав(ла):

...

Books, magazines, and newspapers look good with full justification, web pages do not. Can we switch to left-justified instead?

You can add line

p {text-align: left !important}

to your browser custom stylesheet.

If you are using Firefox or Chrome (Chromium), for them there are extensions (Stylish) that allow to apply the style to the particular site.

Any of the tweaks people are suggesting could be applied individually using this technique. We could just as easily choose to make the site left-justified, and let the full-justification fans use custom stylesheets to get it. The challenge for the maintainer of the docs site is to choose a good design that most people will see. We're bound to disagree on what that design should be, and I suggest that probably none of us are designer enough to come up with the best one. Perhaps we could find an interested designer to help? --Ned.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com

On Wed, Mar 21, 2012 at 7:18 AM, Ned Batchelder wrote:

The challenge for the maintainer of the docs site is to choose a good design that most people will see.  We're bound to disagree on what that design should be, and I suggest that probably none of us are designer enough to come up with the best one.  Perhaps we could find an interested designer to help?

I've come to the conclusion that "good design" is not so much a matter of finding the "best" of anything (font, spacing rules, colors, icons, artowork, etc.). Good design is highly subjective to fashion, and the people who are recognized to be the best designers are more often than not just those with a strong enough opinion to push their creative ideas through. Then other designers, who are not quite as good but still have a nose for the latest fashion, copy their ideas and for a while anything that hasn't been redesigned looks "old-fashioned". (Before you say something about limitations of old technology, note how often designers go back to older styles and manage to make them look fashionable again.) If you want something that attracts attention through controversy, get one of those initial thought leaders. If you want something that looks "current" today but which will probably be out of style next year, use one of the style-following designers. If you want something that is maximally useful, get a scientist with an ounce of style sense to do your design... Oh hey, Georg *is* a scientist! And he's got more than an ounce of style. So just let him do it and let's not try to micromanage things. (I had to speak up about the low contrast because Georg has young eyes and may not realize that this issue exists for older Pythonistas.) -- --Guido van Rossum (python.org/~guido)

On 3/21/2012 3:45 PM, Ethan Furman wrote:

Guido van Rossum wrote:

...

On Wed, Mar 21, 2012 at 7:18 AM, Ned Batchelder wrote:

...

The challenge for the maintainer of the docs site is to choose a good design that most people will see. We're bound to disagree on what that design should be, and I suggest that probably none of us are designer enough to come up with the best one. Perhaps we could find an interested designer to help?

I've come to the conclusion that "good design" is not so much a matter of finding the "best" of anything (font, spacing rules, colors, icons, artowork, etc.). Good design is highly subjective to fashion, and the people who are recognized to be the best designers are more often than not just those with a strong enough opinion to push their creative ideas through. Then other designers, who are not quite as good but still have a nose for the latest fashion, copy their ideas and for a while anything that hasn't been redesigned looks "old-fashioned".

(Before you say something about limitations of old technology, note how often designers go back to older styles and manage to make them look fashionable again.)

If you want something that attracts attention through controversy, get one of those initial thought leaders. If you want something that looks "current" today but which will probably be out of style next year, use one of the style-following designers. If you want something that is maximally useful, get a scientist with an ounce of style sense to do your design... Oh hey, Georg *is* a scientist! And he's got more than an ounce of style. So just let him do it and let's not try to micromanage things. (I had to speak up about the low contrast because Georg has young eyes and may not realize that this issue exists for older Pythonistas.)

+1000

Deriding the entire discipline of design because some of its practitioners are hacks is like pointing at PHP kiddies as the reason why you don't need "software architects." Yes, we could make the mistake of over-designing it, and that would be a mistake. The science you seek is something that designers are well-versed in. --Ned.

On Mar 21, 2012, at 6:28 PM, Greg Ewing wrote:

Ned Batchelder wrote:

...

Any of the tweaks people are suggesting could be applied individually using this technique. We could just as easily choose to make the site left-justified, and let the full-justification fans use custom stylesheets to get it.

Is it really necessary for the site to specify the justification at all? Why not leave it to the browser and whatever customisation the user chooses to make?

It's design. It's complicated. Maybe yes, if you look at research related to default usage patterns, and saccade distance, reading speed and retention latency. Maybe no, if you look at research related to fixation/focus time, eye strain, and non-linear access patterns. Maybe maybe, if you look at the subjective aesthetic of the page according to various criteria, like "does it look like a newspaper" and "do I have to resize my browser every time I visit a new site to get a decent width for reading". As has been said previously in this thread several times, it's best to leave this up to a design czar who will at least make some decisions who will make some people happy. I'm fairly certain it's not possible to create a design that's optimal for all readers in all cases. -glyph

On Mar 23, 2012 9:16 PM, "Greg Ewing" wrote:

Glyph Lefkowitz wrote:

...

"do I have to resize my browser every time I visit a new site to get a

decent width for reading".

If all sites left the width to the browser, then I would be able to make my browser window a width that is comfortable for me with my chosen font size and leave it that way. The only time a site forces me to resize my window is when it thinks it has a better idea than me how wide the text should be.

Weird - I have the exact *opposite* problem, where I have to resize my window because somebody *didn't* set their text max-width sanely (to a reasonable value based on ems instead of pixels), and I have nearly 1920 pixels of raw text spanning my screen. Bloody impossible to read that way. But I guess this is going to turn into one of those vi vs. emacs holy war things... (Personally, I prefer jEdit, or nano if absolutely forced to edit in a terminal. Heretical, I know. To the comfy chair with me!)

On Sat, Mar 24, 2012 at 1:32 AM, Greg Ewing wrote:

PJ Eby wrote:

Weird - I have the exact *opposite* problem, where I have to resize my

...

window because somebody *didn't* set their text max-width sanely (to a reasonable value based on ems instead of pixels), and I have nearly 1920 pixels of raw text spanning my screen.

If you don't want 1920-pixel-wide text, why make your browser window that large?

Not every tab in my browser is text for reading; some are apps that need the extra horizontal space. That is, they have more than one column of text or data -- but no individual column spans anywhere near the full width. (Google Docs, for example, shows me two pages at a time when I'm reading a PDF.)

On 3/24/2012 5:41 PM, Ben Finney wrote:

It's madness to expect web designers to hobble the flexibility of a web page to cater preferentially for one minority over others. But largely, the 99% that makes the rest of them look bad, do, in fact, do exactly that.

On Sun, Mar 25, 2012 at 2:56 AM, Stephen J. Turnbull wrote:

But since he's arguing the other end in the directory layout thread (where he says there are many special ways to invoke Python so that having different layouts on different platforms is easy to work around), I can't give much weight to his preference here.

You're misconstruing my argument there: I said, rather, that the One Obvious Way to deploy a Python application is to dump everything in one directory, as that is the one way that Python has supported for at least 15 years now. Calling this a "special" way of invoking Python is disingenuous at best: it's the documented *default* way of deploying and invoking a Python script with accompanying libraries. In contrast, the directory layout thread is about supporting virtualenvs, which aren't even *in* Python yet -- if anything is to be considered a special case, that would be it. The comparison to CSS is also lost on me here; creating user-specific CSS is more aptly comparable telling people to write their own virtualenv implementations from scratch, and resizing the browser window is more akin to telling people to create a virtualenv every time they *run* the application, rather than just once when installing it.

On Mon, Mar 26, 2012 at 11:23 PM, Stephen J. Turnbull wrote:

...

On Sun, Mar 25, 2012 at 2:56 AM, Stephen J. Turnbull

wrote:

...

But since he's arguing the other end in the directory layout thread (where he says there are many special ways to invoke Python so that having different layouts on different platforms is easy to work around), I can't give much weight to his preference here.

You're misconstruing my argument there: I said, rather, that the One Obvious Way to deploy a Python application is to dump everything in one

On Tue, Mar 27, 2012 at 1:35 AM, PJ Eby wrote: directory,

...

as that is the one way that Python has supported for at least 15 years now.

It's not at all obvious on any of the open source platforms (Cygwin, Debian, Gentoo, and MacPorts) that I use. In all cases, both several python binaries and installed libraries end up in standard places in the distro-maintained hierarchies, and it is not hard to confuse the distro-installed Pythons.

Really? I've been doing "dump the app in a directory" since 1998 or so on various *nix platforms. And when distutils came along, I set up a user-specific cfg to install in the same directory. ISTR a 5-line pydistutils.cfg is sufficient to make everything go into to a particular directory, for packages using distutils for installation. Being confident that one knows enough to set up a single directory correctly

in the face of some of the unlovely things that packages may do requires more knowledge of how Python's import etc works than I can boast: virtualenv is a godsend. By analogy, yes, I think it makes sense to ask you to learn a bit about CSS and add a single line like "body { width: 65em; }" to your local config. That's one reason why CSS is designed to cascade.

That line won't work - it'll make the entire page that width, instead of just text paragraphs. (Plus, it should only be the *maximum* width - i.e. max-width.) Unfortunately, there's no way to identify the correct selector to use on all sites to select just the right elements to set max-width on - not all text is in "p", sometimes preformatted text is in a p with styles setting the formatting to be preformatted. (In other words, I actually do know a little about CSS - enough to know your idea won't actually work without tweaking it for different sites. I have enough Greasemonkey scripts as it is, never mind custom CSS.)

The comparison to CSS is also lost on me here; creating user-specific CSS is

...

more aptly comparable telling people to write their own virtualenv implementations from scratch, and resizing the browser window is more akin to telling people to create a virtualenv every time they *run* the application, rather than just once when installing it.

Huh, if you say so -- I didn't realize that virtualenv did so little that it could be written in one line.

Around 3-5 lines for dumping everything into a single directory. If you need multiple such directories at any one time, you can alternately pass --install-lib and --install-scripts to "setup.py install" when you install things. Or you can use easy_install and just specify the -d (--install-dir) option. Or, you could use the PYTHONHOME solution I described here in 2005: http://svn.python.org/view/sandbox/trunk/setuptools/EasyInstall.txt?r1=41220&r2=41221 Ian Bicking turned those instructions into a script, which he then gradually evolved into what we now know as virtualenv. Before that happened, though, I was deluged with complaints from people who were using "dump it in a directory somewhere" on *nix platforms and didn't want to have anything to do with those danged newfangled virtual whatchacallits. ;-) I mention this for context: my generic perception of virtualenv is that it's a fancy version of PYTHONHOME for people who can't install to site-packages and for some reason don't just dump their files in a PYTHONPATH directory like all those complaining people obviously did. ;-) All I know (and care) is

that it promises to do all that stuff for me, and without affecting the general public (ie, the distro-provided Python apps).

And that's why I think the width of pages containing flowed text should be left up to the user to configure.

Your analogy is backwards: virtualenv is a generic, does-it-all-for-you, no need to touch it solution. User CSS and window sizes have to specified per-site. (Note that it doesn't suffice to use a small window to get optimal wrap width: you have to resize to allow for navigation bars, multiple columns, etc.) I think we should just agree to disagree; there's virtually no way I'm going to be convinced on either of these points. (I do, however, remain open to learning something new about virtualenv, if it actually does something besides make it possible for you to deal with ill-behaved setup scripts and installation tools that won't just let you point them at a single directory and have done with it.)

On Tue, Mar 27, 2012 at 9:02 PM, Ethan Furman wrote:

PJ Eby wrote:

...

Really? I've been doing "dump the app in a directory" since 1998 or so on various *nix platforms. And when distutils came along, I set up a user-specific cfg to install in the same directory. ISTR a 5-line pydistutils.cfg is sufficient to make everything go into to a particular directory, for packages using distutils for installation.

Perhaps somebody could clue me in on the best way to handle this scenario:

I develop in a single directory:

c:\source\loom\ loom.py test_loom.py

because test_loom could at some point be executed by somebody besides me, while living in site-packages, I have test_loom.py create its needed files, including dynamic test scripts, in a temp directory. While this works fine for site-packages, it doesn't work at all while testing as the test script, being somewhere else, won't be able to load my test copy of loom.

I know I have at least two choices: - go with a virtualenv and have my development code be in the virtualenv site-packages - insert the current path into sys.path before calling out to the dynamic scripts, but only if the current path is not site-packages

Suggestions?

At first I didn't understand the question, because I was misled by your directory layout sketch -- AFAICT it's completely irrelevant to the real problem, which is simply making sure that the directory containing loom.__file__ is on sys.path. I'm somewhat hard-pressed to see, "embed the virtualenv tool in my test script" as superior to either "Copy the modules I want to the temp directory alongside the modules" or "setup sys.path when running the scripts" (e.g. by altering the PYTHONPATH in the child environment). (I'm not clear on why you want to skip the path alteration in the site-packages case - is there something else in site-packages you don't want having top import priority? And if not, why not?) All that being said, I can see why under certain circumstances, a virtualenv might be an optimal tool to reach for; it's just not the *first* thing I'd reach for if a sys.path[0] assignment or environment variable setting would suffice to get the needed module(s) on the path.

~Ethan~

On Sat, Mar 24, 2012 at 8:41 PM, Ben Finney wrote:

PJ Eby writes:

...

On Sat, Mar 24, 2012 at 1:32 AM, Greg Ewing

...

If you don't want 1920-pixel-wide text, why make your browser window that large?

Not every tab in my browser is text for reading; some are apps that need the extra horizontal space.

So, again, why make your browser window *for reading text* that large?

Because I have one browser window, and it's maximized. And I can do this, because most websites are designed in such a way that they have usable margins for text flows. Even PEPs and Python mailing list archives, for example, have sane text margins -- shall we go back and make *those* dependent on window width instead? Also, looking at the email I got from you, it has sane text margins in it. If you don't believe in text margins, why are you using a client that wraps lines and thereby prevents me from viewing your email with full-screen-width text? ;-) (In fairness, I am using a client that *doesn't* wrap the lines, AFAICT. But if Gmail had such an option I would probably use it if I knew where it was in the vast assortment of settings. Which ties in nicely with my next point, below...) Everyone has different needs for how large the text should be and how

much of it should go across the window. Every one of us is in a minority when it comes to those needs; that's exactly what a configuration setting is good for.

Designers' rules of thumb for text width are based on empirical observations of focal length, saccades, etc. If you have special needs visually, you're more likely to require the text read to you, than to have narrower text, and I at least am unable to conceive of a visual disability that would be helped by *increasing* the text width. In other words, there is a well-established *majority* need for how many characters should appear in an unwrapped line of text, based on majority physiology. Designers who limit it based on pixel size are Doing It Wrong; the max width should be based on em's rather than pixels. (Font sizes are a separate issue.) Done correctly (as visible, say, on any plaintext PEP), you may resize the window and change the font size to your heart's content without affecting the text width in characters. (Also, as a side note: adding lots of configuration options to an interface design is what adding lots of code is to a software design: a smell that the designer isn't *designing* enough.)

On 3/26/2012 10:19 AM, R. David Murray wrote:

Like Philip, I have*one* window. My window manager (ratpoison) is more like 'screen' for X: you*can* split the window up, but it is*much* more useful to have only one window visible at a time, most of the time.

I'm amazed at the number of people that use maximized windows, one application at a time. I have 2 1600x1200 displays, with 10-30 overlapping windows partially visible, and sometimes wish I had 3 displays, so I could see more windows at a time... but then I'd have to turn my head more, so maybe this is optimal. Two displays lets me get my autohidden taskbar in the vertical center, for quick access from either side. I occasionally maximize a window on one screen or the other (one portrait, one landscape mode), mostly for picture viewing, but a few other times as well.

I realize that I'm in the minority, though

No doubt I am too :) Everyone is a minority, when all idiotsyncrasies [sic] are considered!

On 3/26/2012 10:58 AM, Ethan Furman wrote:

Glenn Linderman wrote:

...

On 3/26/2012 10:19 AM, R. David Murray wrote:

...

Like Philip, I have *one* window. My window manager (ratpoison) is more like 'screen' for X: you *can* split the window up, but it is *much* more useful to have only one window visible at a time, most of the time.

I'm amazed at the number of people that use maximized windows, one application at a time. I have 2 1600x1200 displays, with 10-30 overlapping windows partially visible, and sometimes wish I had 3 displays, so I could see more windows at a time... but then I'd have to turn my head more, so maybe this is optimal. Two displays lets me get my autohidden taskbar in the vertical center, for quick access from either side.

I also have two monitors, I use goScreen for three virtual desktops (I'm stuck with XP -- which is to say MS), and each application I use is full-screen while I'm using it. I find windows that I'm not using at that moment a distraction.

Interesting. I guess I'm always distracted :) But I often need data or information from multiple applications in order to make progress on a project... which is why each application seldom gets maximized. I even use multiple Firefox profiles concurrently, to have multiple browsers open for different purposes, as well as multiple tabs within each of them. Sometimes I even need multiple instances of Emacs, as well as multiple windows for a single instance, but that is usually very temporary, due to an interruption (distraction). So my pet peeve about web sites is those that, although they seem to dynamically adjust to different monitor sizes, seem to miscalculate, and display a horizontal scroll bar, and consistently chop stuff off on the right edge of my non-maximized window.

On 3/21/2012 1:04 PM, Serhiy Storchaka wrote:

If I can get my five cents, I will tell about my impressions. I really liked the background of allocated blocks (such as notes and code snippets) has become less diverse (but still visible). The border around these blocks have become more accurate and more pleasant to emphasize blocks. It is very good that the sidebar is no longer confused look. And everything looks quite nice. But the font is a little bit small for my eyes (on the contrary current theme font a little bit big). This leads to too long (in characters) lines. Less obvious was the structure of the document (due to decrease the font size of the header and the removal of the dividing lines).

You can use Ctrl-+ to increase the size of the text, and modern browsers remember that for the next time you visit the site. --Ned.

I would like to that the background color of ".note tt" has become a little lighter and quieter.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com

On Wed, Mar 21, 2012 at 2:46 PM, Guido van Rossum wrote:

That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default.

Yet 90% of designers (or more) insist on making text insanely small, commonly specifying the size in pixles or (if we're lucky) points. Not sure there's any lesson to be learned from this, aside from designers really having it out for anyone who needs to read. -Fred -- Fred L. Drake, Jr.    <fdrake at acm.org> "A person who won't read has no advantage over one who can't read."    --Samuel Langhorne Clemens

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/2012 03:13 PM, Ned Batchelder wrote:

On 3/21/2012 3:06 PM, Fred Drake wrote:

...

On Wed, Mar 21, 2012 at 2:46 PM, Guido van Rossum wrote:

...

That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default. Yet 90% of designers (or more) insist on making text insanely small, commonly specifying the size in pixles or (if we're lucky) points.

Not sure there's any lesson to be learned from this, aside from designers really having it out for anyone who needs to read. There are bad designers, or more to the point, designers who favor the overall look of the page at the expense of the utility of the page. That doesn't mean all designers are bad, or that "design" is bad. Don't throw out the baby with the bathwater.

Designers who care more about utility / accessibility more than their hipster karma seem to be a tiny minority in the current web world (without even counting "web designers" who think a Photoshop document is the final deliverable). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9qPBEACgkQ+gerLs4ltQ5fMwCcD8cHLDch/cIlBpVY4htmlDN4 fzQAmgNUVVn+uByZRBI22TB7ETdkLzmP =ZHdF -----END PGP SIGNATURE-----

On 3/21/2012 4:38 PM, Fred Drake wrote:

On Wed, Mar 21, 2012 at 3:13 PM, Ned Batchelder wrote:

...

There are bad designers, or more to the point, designers who favor the overall look of the page at the expense of the utility of the page. That doesn't mean all designers are bad, or that "design" is bad. Don't throw out the baby with the bathwater. I get that. I'm not bad-mouthing actual design, and there are definitely good designers out there.

It's unfortunate they're so seriously outnumbered. Yeah, just like software architects... :-(

--Ned.

-Fred

In article <4F6B5B33.9020406@pearwood.info>, Steven D'Aprano wrote:

... My first impression of this page:

http://www.python.org/~gbrandl/build/html/index.html

was that the grey side-bar gives the page a somber, perhaps even dreary, look. First impressions count, and I'm afraid that first look didn't work for me.

But clicking through onto other pages with more text improved my feelings. A big +1 on the pale green shading of code blocks.

The basic design seems good to me. I'd prefer a serif font for blocks of text, while keeping sans serif for the headings, but that's a mild preference.

Looking forward to seeing the next iteration.

I like the overall design, but one thing seems to be missing is an overview of what Python is (hence what the page is about). Naturally we don't need that, but a one-line overview with a link to more information would be helpful. -- Russell

On 22.03.2012 20:05, Russell E. Owen wrote:

...

I like the overall design, but one thing seems to be missing is an overview of what Python is (hence what the page is about). Naturally we don't need that, but a one-line overview with a link to more information would be helpful.

-- Russell

I'm afraid my last sentence was incoherent. I meant to say:

Naturally we, as Python users, don't need that; but a one-line overview with a link to more information would be helpful to others who are not familiar with the language.

Hi Russell, note that the page is not supposed to replace python.org, but is just a new styling of the Python documentation, docs.python.org, where it is kind of assumed that you know what Python is... Georg

On Fri, Mar 23, 2012 at 6:50 AM, Glenn Linderman wrote:

3. Make the sidebar separately scrollable, so that it stays visible when scrolling down in the text.  This would make it much easier to jump from section to section, if the TOC didn't get lost in the process.

-1. The downside of separate scrolling is that you lose the ability to scroll-wheel the main docs if your mouse is over the TOC. I'd rather it stay as a single page, so it doesn't matter where my pointer is when I scroll. But I realise I'm bikeshedding this a bit. Bottom line: I'll use Python, and docs.python.org, regardless of the design and layout... so I'll let the expert(s) decide this one. ChrisA

On Fri, 23 Mar 2012 07:57:18 +1100, Chris Angelico wrote:

On Fri, Mar 23, 2012 at 6:50 AM, Glenn Linderman wrote:

...

3. Make the sidebar separately scrollable, so that it stays visible when scrolling down in the text.  This would make it much easier to jump from section to section, if the TOC didn't get lost in the process.

-1. The downside of separate scrolling is that you lose the ability to scroll-wheel the main docs if your mouse is over the TOC. I'd rather it stay as a single page, so it doesn't matter where my pointer is when I scroll.

I agree, and I don't use a mousewheel much. I use pentadactyl, and in that case sometimes the keyboard focus ends up in the TOC and then the scrolling keys scroll the wrong thing (or appear to do nothing, since such things are generally shorter than my screen...) and I can never remember the key sequence to change the focus, because *most* sites I don't have that problem with. For whatever that's worth :) --David

Wiadomość napisana przez Ethan Furman w dniu 22 mar 2012, o godz. 22:18:

Glenn Linderman wrote:

...

After looking at both a while, my suggestions would be: 1. Preserve the collapsability of the TOC, but possible enhance its recognizability with an X in the upper right of the TOC sidebar, as well as the << in the middle. 2. Make the header fixed, so that the bread crumb trail at the top is available even after scrolling way down a long page. 3. Make the sidebar separately scrollable, so that it stays visible when scrolling down in the text. This would make it much easier to jump from section to section, if the TOC didn't get lost in the process.

+1 +1 and, of course, +1

Something like that: http://packages.python.org/lck.django/lck.django.tags.models.html ? (breadcrumbs are at the bottom) -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o.

On Thu, Mar 22, 2012 at 11:56 PM, Greg Ewing wrote:

Can we please get rid of the sidebar, or at least provide a way of turning it off? I don't think it's anywhere near useful enough to be worth the space it takes up.

+1. It seems to mostly duplicate the headline next/previous buttons already duplicated in the footer, it doesn't give you the whole TOC, and the whole TOC already present in many nodes. The "Search bar" is a standard feature of most headers (and sometimes footers), and I like the "Report a Bug" link because it confirms to the reader that Python developers actually care what they (readers) think. I guess there is enough room for both of those in the header even after subtractiing the horizontal space for the sidebar.

A table of contents as a separate page is a lot more usable for me.

I agree, but with emphasis on the *for me* part. I suspect this is a personal preference.

Also I agree about the grey text being suboptimal.

+1 for black text or a perceptibly darker grey.

Deliberately throwing away contrast, especially for the main body text, is insane.

It does *look* nice, though. Overall, very nice job, Georg!

On Wed, Mar 21, 2012 at 12:12 PM, Ned Batchelder wrote:

On 3/21/2012 2:46 PM, Guido van Rossum wrote:

...

On Wed, Mar 21, 2012 at 11:40 AM, Ned Batchelder  wrote:

...

You can use Ctrl-+ to increase the size of the text, and modern browsers remember that for the next time you visit the site.

That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default.

Yes, sorry, that was exactly my point earlier in this thread.  I was being a bit snarky with Serhiy.  Seems the standard here is for people to request their personal favorite tweaks, and then tell others that they can use browser customizations to get what they want.

Guido, you encouraged us to use science, but only after describing my science-based maximum line-length suggestion as "coddling," then said we should let Georg get on with it, but only after reiterating your personal favorite tweak (which I happen to agree with).

I have a fair number of strong usability gripes about current (and past :-) design trends, but I know I can't design a decent looking website myself if my life depended on it.

There's no way a committee (which this thread effectively is) will come up with a good design.  Everyone will dislike something about it.  I think it would be interesting to use the power of the web to provide docs whose style could be adjusted a few ways to make people happy, but that is probably more than anyone is willing to volunteer for, I know I can't step up to do it.

I think it's fine to have a bunch of folks submit their pet peeves (and argue them to the death :-) to the design czar and then let the czar (i.e. Georg) decide.

Personally, I think two Python projects that have focused on docs and done a good job of it are Django and readthedocs.org.  Perhaps we could follow their lead?

I think they are actually more trend-followers,and they seem to make a bunch of the mistakes I've fulminated against here. But again, I'll leave it to Georg. -- --Guido van Rossum (python.org/~guido)

On 21.03.2012 20:39, Guido van Rossum wrote:

...

Guido, you encouraged us to use science, but only after describing my science-based maximum line-length suggestion as "coddling," then said we should let Georg get on with it, but only after reiterating your personal favorite tweak (which I happen to agree with).

I have a fair number of strong usability gripes about current (and past :-) design trends, but I know I can't design a decent looking website myself if my life depended on it.

...

There's no way a committee (which this thread effectively is) will come up with a good design. Everyone will dislike something about it. I think it would be interesting to use the power of the web to provide docs whose style could be adjusted a few ways to make people happy, but that is probably more than anyone is willing to volunteer for, I know I can't step up to do it.

I think it's fine to have a bunch of folks submit their pet peeves (and argue them to the death :-) to the design czar and then let the czar (i.e. Georg) decide.

...

Personally, I think two Python projects that have focused on docs and done a good job of it are Django and readthedocs.org. Perhaps we could follow their lead?

I think they are actually more trend-followers,and they seem to make a bunch of the mistakes I've fulminated against here. But again, I'll leave it to Georg.

Thanks for the vote of confidence. I'll know what to consider for the next iteration thanks to the lively participation here :) Georg