From tim.parkin at pollenationinternet.com Wed Oct 1 12:03:21 2003 From: tim.parkin at pollenationinternet.com (Tim Parkin) Date: Wed Oct 1 12:03:46 2003 Subject: [Pydotorg-redesign] What are the goals? In-Reply-To: <20030929225815.GC6728@panix.com> Message-ID: <011a01c38835$90637ff0$0a00a8c0@JASPER> Aahz: >I'm not prepared to >spend time looking at it until either most other people have approved it >or it's available in HTML. I'm just not going to download pictures of >an evolving design. http://pollenation.net/assets/public/python-lynx.html http://pollenation.net/assets/public/python-lynx-interior.html These pages are built with the intention of showing how the proposed design will render in Lynx. As a by product, they also show how the 'worst case scenario' netscape 4.x look will render. They are also the starting point for developing the CSS for the site. Some changes will be made in implementing the CSS but these are unlikely to affect the semantic part of the HTML. Some of the order of items may not seem totally straightforward but this is to do with ensuring the accessibility for speech readers. Some changes to the order can be made, however the exact order of these items will affect how the site may be built using html and css and hence some orderings may generate more than a justifiable level of extra work. This is a preliminary design, and like all designs there may be small variances between this and the finished product. The (X) HTML may not validate at the moment. Tim From tim.parkin at pollenationinternet.com Wed Oct 1 17:55:10 2003 From: tim.parkin at pollenationinternet.com (Tim Parkin) Date: Wed Oct 1 17:55:17 2003 Subject: [Pydotorg-redesign] What are the goals? In-Reply-To: <011a01c38835$90637ff0$0a00a8c0@JASPER> Message-ID: <016301c38866$b5c627d0$0a00a8c0@JASPER> >http://pollenation.net/assets/public/python-lynx.html >http://pollenation.net/assets/public/python-lynx-interior.html For people without easy access to Lynx, http://pollenation.net/assets/public/python-lynx-main.gif http://pollenation.net/assets/public/python-lynx-interior.gif Tim From aahz at pythoncraft.com Thu Oct 2 11:26:19 2003 From: aahz at pythoncraft.com (Aahz) Date: Thu Oct 2 11:26:24 2003 Subject: [Pydotorg-redesign] What are the goals? In-Reply-To: <011a01c38835$90637ff0$0a00a8c0@JASPER> References: <20030929225815.GC6728@panix.com> <011a01c38835$90637ff0$0a00a8c0@JASPER> Message-ID: <20031002152619.GA20433@panix.com> Thanks for the Lynx page; I'm going off for a long weekend today, so I don't know when I'll get to it. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan From skip at pobox.com Tue Oct 7 07:15:50 2003 From: skip at pobox.com (Skip Montanaro) Date: Tue Oct 7 07:15:59 2003 Subject: [Pydotorg-redesign] CSS Layout Reservoir Message-ID: <16258.41062.338438.679349@montanaro.dyndns.org> While looking for information on css @import stuff I came across this site: http://www.bluerobot.com/web/layouts/ Folks interested in using css across a wide variety of web browsers might want to take a look. The examples worked fine for me in Safari. In Lynx and Netscape 4, the margin content appeared below the main body text. That may be a problem if you expect your content to read roughly left-to-right, top-to-bottom. FYI. Skip From aahz at pythoncraft.com Tue Oct 7 15:15:32 2003 From: aahz at pythoncraft.com (Aahz) Date: Tue Oct 7 15:15:35 2003 Subject: [Pydotorg-redesign] CSS Layout Reservoir In-Reply-To: <16258.41062.338438.679349@montanaro.dyndns.org> References: <16258.41062.338438.679349@montanaro.dyndns.org> Message-ID: <20031007191532.GA11621@panix.com> On Tue, Oct 07, 2003, Skip Montanaro wrote: > > http://www.bluerobot.com/web/layouts/ > > Folks interested in using css across a wide variety of web browsers > might want to take a look. The examples worked fine for me in Safari. > In Lynx and Netscape 4, the margin content appeared below the main > body text. That may be a problem if you expect your content to read > roughly left-to-right, top-to-bottom. That's easy enough to fix by putting the menu before the content in the HTML itself. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan From tim.parkin at pollenationinternet.com Tue Oct 7 16:25:25 2003 From: tim.parkin at pollenationinternet.com (Tim Parkin) Date: Tue Oct 7 16:25:58 2003 Subject: [Pydotorg-redesign] CSS Layout Reservoir In-Reply-To: <20031007191532.GA11621@panix.com> Message-ID: <014701c38d11$2a4ce9f0$0a00a8c0@JASPER> >> The examples worked fine for me in Safari. >> In Lynx and Netscape 4, the margin content appeared below the main >> body text. That may be a problem if you expect your content to read >> roughly left-to-right, top-to-bottom. > >That's easy enough to fix by putting the menu before the content in the >HTML itself. It would be of great benefit if possible, to have the main menu at the bottom of the content and to provide a 'skip to navigation' link of some sort at the top of the page. I have been told by the blind and partially sighted users that I have had focus groups with, that the most annoying thing is to have the menu read out on every page. The shortcut is generally to offer a skip-menu feature which is ok but the best is to have a 'skip to nav' with associated accesskey. I'll leave this one open to debate as the html I've been building will work both ways. I've added a reference regarding it from a very well thought of accessibility book and also a link to Mark Pilgrim's Dive into Accessibility website. Tim http://diveintoaccessibility.org/day_10_presenting_your_main_content_fir st.html Joe Clark - Building Accessible (p150) "Visitors who cannot readily skip all those links must either page through them (as with Lynx, a text-only browser), or move the cursor to select each link in turn (as with some mobility-impaired people using any kind of browser), or attempt to skip the links using software commands, if that is even possible. But in doing so, visitors may skip links they actually want along with those they do not. As a veteran Lynx user, let me tell you how it works. When presented with dozens of navigation links, I press the spacebar over and over again to bypass them a screenful at a time. If the first link of any resulting screenful happens to be a text field (e.g., a search box), I have to move the cursor off the field with the Downarrow or Tab keys, then keep on paging through the links. Or I can guess how many screenfuls of links are present and skip beyond that screenful: Typing 5P (p for page) brings me to the fifth screenful. But I have it easy. While some mobility-impaired people do in fact repeatedly press the Tab key to move around a page, some people with more severe disabilities use adaptive technology that runs through a sequence of possible actions ("switch access").You have to wait until the keyboard action comes up, then home in on the Tab key (which itself could take many steps), then actuate it. How would you like to go through that 99 times just to skip nagavation? Then what if the link you really want is actually near the bottom of the page? How long would you put up with that, if you don't already?" From tim at pollenation.net Fri Oct 10 05:25:13 2003 From: tim at pollenation.net (Tim Parkin) Date: Fri Oct 10 05:25:26 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <16258.41062.338438.679349@montanaro.dyndns.org> Message-ID: <02b301c38f10$72993dc0$0a00a8c0@JASPER> Hi, Heres the first stab at HTML for the python redesign. http://pollenation.net/assets/public/draft-oct10.html It's only a preliminary try but seems to work and also validates. It still needs some accessibility additions (rel links and accesskeys and also tabindex adjustments) but it's enough to start commenting on. I'm very busy at work at the moment and will also be getting married at the start of december. I'm going to have a crack at the home page HTML sometime before then, if possible, and also try to get a draft release of the supporting document for the proposal. Tim From richardjones at optushome.com.au Fri Oct 10 19:04:01 2003 From: richardjones at optushome.com.au (Richard Jones) Date: Fri Oct 10 20:03:26 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <02b301c38f10$72993dc0$0a00a8c0@JASPER> References: <02b301c38f10$72993dc0$0a00a8c0@JASPER> Message-ID: <200310110904.01532.richardjones@optushome.com.au> On Fri, 10 Oct 2003 07:25 pm, Tim Parkin wrote: > Heres the first stab at HTML for the python redesign. > > http://pollenation.net/assets/public/draft-oct10.html In general, I like this design - it's nice and clean. A few points: 1. Please remove the font sizing for the main body text 2. Not sure what the "dev" link in the top bar is... 3. "Download" and "documentation" are present twice in the sidebar. Surely only one instance of each would be enough (I'd advocate the lower instance of both) Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20031011/5ae94914/attachment.bin From tim at pollenation.net Sat Oct 11 06:55:44 2003 From: tim at pollenation.net (Tim Parkin) Date: Sat Oct 11 06:55:55 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal Message-ID: <35244.195.92.194.17.1065869744.squirrel@webmail.pollenation.net> >> Heres the first stab at HTML for the python redesign. >> http://pollenation.net/assets/public/draft-oct10.html >In general, I like this design - it's nice and clean. A few points: >1. Please remove the font sizing for the main body text Hmm... not sure why you want this as the current text size is adjustable via the browser menu *and* is also larger than the current default python text size. I am going to be looking at adding an accessibility style switcher that will allow you to change the default stylesheet, offering a few options including a different size text. This will need javascript and also cookies if you want it to remember the settings. A comparison of the text sizes between redesign and existing site at default is here :- http://pollenation.net/assets/public/text-comparison.gif I may be adjusting body text colour to make it slightly darker (although this is the recommended contrast for reading, I think some monitors will show this at a lower contrast than others). >2. Not sure what the "dev" link in the top bar is... Have a look at http://pollenation.net/assets/public/python-developer-oct05.png for a preliminary idea of what the developer link would be. It's intended as a home for python developers (not python language developers, that confusion needs to be addressed separately). Theres a lot of thinking behind doing this that I won't go into here. >3. "Download" and "documentation" are present twice in the sidebar. Surely > only one instance of each would be enough (I'd advocate the lower > instance of both) I wanted to have deep links that jump straight to popular pages. These can be adjusted if we find out that people use other links. We don't want to adjust the main menu all the time however. The quick links might change depending on what section you are in (if you are in the downloads section it may show the main downloads. In mailing lists, the most popular lists) It's a way of getting quick links on the left hand bar, where people scan first, without messing with the main menu. Tim From amk at amk.ca Sat Oct 11 11:33:15 2003 From: amk at amk.ca (amk@amk.ca) Date: Sat Oct 11 11:33:20 2003 Subject: [Pydotorg-redesign] User comments on python.org References: <1Ivhb.193919$hE5.6560510@news1.tin.it> Message-ID: [This message has also been posted to comp.lang.python.] On Fri, 10 Oct 2003 12:58:49 GMT, Alex Martelli wrote: > they're referring to the .net rather than the .org site. "Annotatable" > docs (perhaps with some overview) sure sounds like a way-cool idea, but > I have no first-hand experience of how well it works in practice. Well, let's get some experience. python.org already has a Wiki, so we have a facility for editing text. It would be straightforward to have a "View/Edit comments" link on each page that directed the user to a corresponding Wiki page, perhaps popping it up in a separate window. Questions: * Including comments in the page is difficult; I looked at modifying MoinMoin to do this, but it's not easy. So how can the link be made fairly obvious? Links at the bottom of page aren't very obvious. A sidebar link perhaps? (Even if we don't do annotation for the current site design, it might be worth coming up with a good indicator for the redesigned version.) * Should comment links be on every single page, or should they just be limited to certain sections, such as /doc/current/? * Does the Wiki stylesheet need to be tweaked for this use? (Perhaps by suppressing the sidebar, for a start. Pity, after Jurgen went to all that effort to put it there.) --amk From roy at panix.com Sat Oct 11 18:08:42 2003 From: roy at panix.com (Roy Smith) Date: Sat Oct 11 18:08:53 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <02b301c38f10$72993dc0$0a00a8c0@JASPER> Message-ID: <7962B5BF-FC37-11D7-AFC5-0050E405C35A@panix.com> On Friday, October 10, 2003, at 05:25 AM, Tim Parkin wrote: > Hi, > > Heres the first stab at HTML for the python redesign. > > http://pollenation.net/assets/public/draft-oct10.html > Overall, I like it a lot. A minor technical glitch. When I viewed the page in Safari (Mac OSX), if I made the window too narrow, the left-hand and right-hand text in the nav bar run into each other and overlap. I've attached a small screen shot to illustrate what I'm talking about. It's unclear if this is really something worth worrying about -- if you make anything too narrow, something's going to give somewhere. -------------- next part -------------- A non-text attachment was scrubbed... Name: overlap.pdf Type: application/pdf Size: 8597 bytes Desc: not available Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20031011/3de60ccf/overlap.pdf -------------- next part -------------- From tim at pollenation.net Sun Oct 12 03:57:33 2003 From: tim at pollenation.net (Tim Parkin) Date: Sun Oct 12 03:57:38 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal Message-ID: <31341.193.35.129.169.1065945453.squirrel@webmail.pollenation.net> Roy >> Heres the first stab at HTML for the python redesign. >> http://pollenation.net/assets/public/draft-oct10.html >> > >Overall, I like it a lot. > >A minor technical glitch. When I viewed the page in Safari (Mac OSX), >if I made the window too narrow, the left-hand and right-hand text in >the nav bar run into each other and overlap. I've attached a small >screen shot to illustrate what I'm talking about. > >It's unclear if this is really something worth worrying about -- if you >make anything too narrow, something's going to give somewhere. It is inevitable that a website will become unusable at certain widths. However I can make a small change to put a background on the utility nav which will mean that it will slide over the breadcrumb trail as the window gets smaller. As the utility nav is probably more important than the breadcrumb, I think this is the correct choice, can't upload yet as I'm away from civilisation but will do later. I've also played with a print css sheet and a large text css sheet that should work quite niceley. Tim Tim From lac at strakt.com Sun Oct 12 04:18:42 2003 From: lac at strakt.com (Laura Creighton) Date: Sun Oct 12 04:19:20 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message from "Tim Parkin" of "Sun, 12 Oct 2003 07:57:33 -0000." <31341.193.35.129.169.1065945453.squirrel@webmail.pollenation.net> References: <31341.193.35.129.169.1065945453.squirrel@webmail.pollenation.net> Message-ID: <200310120818.h9C8Igh9008694@ratthing-b246.strakt.com> I like >>> http://pollenation.net/assets/public/draft-oct10.html a lot as well. Indeed, I think its wonderful. However, you know me, always finding another nit .... :-) I still would like the google text input window to be wider, all over the top of the page, so that the search-widget-thing started, say just over the I in DB-API. I'm not so fond of the blue hook at the edge of the search-thing which makes it look like a can-opener to me, but all I want to do is mention that once -- I don't dislike it a lot, and not enough to fuss. I will fuss about typing window size in search-things. I want more room, or a good explanation why I shouldn't get it. Laura From tim at pollenation.net Sun Oct 12 09:56:09 2003 From: tim at pollenation.net (Tim Parkin) Date: Sun Oct 12 09:56:18 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310120818.h9C8Igh9008694@ratthing-b246.strakt.com> Message-ID: <03b101c390c8$9d3793b0$0a00a8c0@JASPER> Laura : >I like >>>> http://pollenation.net/assets/public/draft-oct10.html >a lot as well. Indeed, I think its wonderful. :-) >..I still would like the google text input window to be wider, all over >the top of the page, so that the search-widget-thing started, say >just over the I in DB-API. I don't know where that would be as the search box is referenced to the rhs and the db-api to the lhs. I'll make it as big as I think the design can get away with.. Just as a matter of interest, what is the problem with having smaller search box windows? Just comparing sizes of other major sites :- Google : 208 px BBC Homepage : 180 px *Proposed Search Width : 170 px Amazon.co.uk : 168 px Php : 162 px *Current Search Width : 154 px Developer Works : 123 px Java.sun.com : 112 px News.bbc.co.uk : 95 px I'll up it to 170px as any more than that and the python logo and the search box will collide at 640 wide (a browser width near to that which many people with larger monitors use whilst arranging multiple windows). As a side not, this size is also 15% bigger than Jakob Nielsen's Recommendations for search box width. >I'm not so fond of the blue hook at the edge of the search->thing which >makes it look like a can-opener to me, but all I want to do is mention >that once -- I don't dislike it a lot, and not enough to fuss. You'll have to enlighten me as I can't work out what that might be.. Heres a screenshot of what I get. http://pollenation.net/assets/public/screenshot-oct12.gif I presume it's a browser bug of some sort. If you can send a screenshot of what you have a your browsers type, browser version and operating system that would be great. >I will fuss about typing window size in search-things. I want more >room, or a good explanation why I shouldn't get it. I've not problem about making it bigger in this case but would love to know why you see it as so important. Taking the java page as an example, what problems do you feel the small search window causes or what limitations does it place on you? I just want to learn as a convincing argument in any situation is always useful. Tim From lac at strakt.com Sun Oct 12 10:51:32 2003 From: lac at strakt.com (Laura Creighton) Date: Sun Oct 12 10:52:07 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message from "Tim Parkin" of "Sun, 12 Oct 2003 14:56:09 BST." <03b101c390c8$9d3793b0$0a00a8c0@JASPER> References: <03b101c390c8$9d3793b0$0a00a8c0@JASPER> Message-ID: <200310121451.h9CEpWh9010774@ratthing-b246.strakt.com> In a message of Sun, 12 Oct 2003 14:56:09 BST, "Tim Parkin" writes: >Laura : >>I like >>>>> http://pollenation.net/assets/public/draft-oct10.html >>a lot as well. Indeed, I think its wonderful. > >:-) > >>..I still would like the google text input window to be wider, all over >>the top of the page, so that the search-widget-thing started, say >>just over the I in DB-API. > >I don't know where that would be as the search box is referenced to the >rhs and the db-api to the lhs. I'll make it as big as I think the design >can get away with.. Just as a matter of interest, what is the problem >with having smaller search box windows? I get really uncomfortable when what I want to paste into the search box doesn't fit. Or when I type in long things. Here I am being really precise to limit my search nicely, and I cannot see ... It really gives me the willies. Like being blindfolded. > >Just comparing sizes of other major sites :- > > Google : 208 px > BBC Homepage : 180 px >*Proposed Search Width : 170 px > Amazon.co.uk : 168 px > Php : 162 px >*Current Search Width : 154 px > Developer Works : 123 px > Java.sun.com : 112 px > News.bbc.co.uk : 95 px > >I'll up it to 170px as any more than that and the python logo and the >search box will collide at 640 wide (a browser width near to that which >many people with larger monitors use whilst arranging multiple windows). >As a side not, this size is also 15% bigger than Jakob Nielsen's >Recommendations for search box width. > >>I'm not so fond of the blue hook at the edge of the search->thing which >>makes it look like a can-opener to me, but all I want to do is mention >>that once -- I don't dislike it a lot, and not enough to fuss. > >You'll have to enlighten me as I can't work out what that might be.. >Heres a screenshot of what I get. > >http://pollenation.net/assets/public/screenshot-oct12.gif > >I presume it's a browser bug of some sort. If you can send a screenshot >of what you have a your browsers type, browser version and operating >system that would be great. Yes its a bug. Its not happening at work, but on myu laptop at home. Bug me to send you that if I forget. > >>I will fuss about typing window size in search-things. I want more >>room, or a good explanation why I shouldn't get it. > >I've not problem about making it bigger in this case but would love to >know why you see it as so important. Taking the java page as an example, >what problems do you feel the small search window causes or what >limitations does it place on you? I just want to learn as a convincing >argument in any situation is always useful. Having what I type in vanish 'underneath' makes my skin crawl. I fear we may need a psychologist to explain why ... > >Tim Thanks Tim. Laura From tim at pollenation.net Sun Oct 12 17:38:33 2003 From: tim at pollenation.net (Tim Parkin) Date: Sun Oct 12 17:38:39 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310121451.h9CEpWh9010774@ratthing-b246.strakt.com> Message-ID: <03e001c39109$363f09e0$0a00a8c0@JASPER> >I get really uncomfortable when what I want to paste into the search >box doesn't fit. Or when I type in long things. Here I am being >really precise to limit my search nicely, and I cannot see ... Well I made it bigger now... The new version is at http://pollenation.net/assets/public/draft-oct13.html And has an alternate large text style sheet and try print previewing for a nicer output. And the utility menu rides over the breadcrumb now too. Tim From richardjones at optushome.com.au Sun Oct 12 18:24:20 2003 From: richardjones at optushome.com.au (Richard Jones) Date: Sun Oct 12 18:24:51 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <03e001c39109$363f09e0$0a00a8c0@JASPER> References: <03e001c39109$363f09e0$0a00a8c0@JASPER> Message-ID: <200310130824.25478.richardjones@optushome.com.au> On Mon, 13 Oct 2003 07:38 am, Tim Parkin wrote: > >I get really uncomfortable when what I want to paste into the search > >box doesn't fit. Or when I type in long things. Here I am being > >really precise to limit my search nicely, and I cannot see ... > > Well I made it bigger now... > > The new version is at > > http://pollenation.net/assets/public/draft-oct13.html > > And has an alternate large text style sheet and try print previewing for > a nicer output. And the utility menu rides over the breadcrumb now too. Looking great! Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20031013/22cb8b2d/attachment.bin From richardjones at optushome.com.au Sun Oct 12 01:03:51 2003 From: richardjones at optushome.com.au (Richard Jones) Date: Sun Oct 12 18:38:12 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <35244.195.92.194.17.1065869744.squirrel@webmail.pollenation.net> References: <35244.195.92.194.17.1065869744.squirrel@webmail.pollenation.net> Message-ID: <200310121503.51322.richardjones@optushome.com.au> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20031012/2f68066a/attachment-0001.bin From lac at strakt.com Sun Oct 12 19:15:12 2003 From: lac at strakt.com (Laura Creighton) Date: Sun Oct 12 19:15:46 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message from "Tim Parkin" of "Sun, 12 Oct 2003 22:38:33 BST." <03e001c39109$363f09e0$0a00a8c0@JASPER> References: <03e001c39109$363f09e0$0a00a8c0@JASPER> Message-ID: <200310122315.h9CNFCh9012813@ratthing-b246.strakt.com> In a message of Sun, 12 Oct 2003 22:38:33 BST, "Tim Parkin" writes: >>I get really uncomfortable when what I want to paste into the search >>box doesn't fit. Or when I type in long things. Here I am being >>really precise to limit my search nicely, and I cannot see ... >Well I made it bigger now... > >The new version is at > >http://pollenation.net/assets/public/draft-oct13.html you sure Tim? On Mozilla on my laptop it looks the same. And I get the can opener effect as well. Do you know any good way for me to just save all the bits on my screen as a png or something so I can mail it to you? I don't. Is this how I ask my mozilla to tell me what version it is so I can tell you? about: under help menu says ... Mozilla 1.0 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 Right now the S in Search is aligned just about between 'in' and 'relational' and I would like to yank it all the way over to above the I in API. Were I doing this for me, I would skip the 'search' if google allows that. For me, everything that is not a button and a text window is wasted space. I just tried it under konquerer, and it looks really bad. I've got to learn a way to send you the bits of my screen so you can see it, but it is nothing like what you are asking for ... But now I need bed more than anything else. Laura >Tim > From matt at pollenation.net Sun Oct 12 20:30:48 2003 From: matt at pollenation.net (Matt Goodall) Date: Sun Oct 12 20:31:54 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310122315.h9CNFCh9012813@ratthing-b246.strakt.com> References: <03e001c39109$363f09e0$0a00a8c0@JASPER> <200310122315.h9CNFCh9012813@ratthing-b246.strakt.com> Message-ID: <3F89F238.7060306@pollenation.net> Laura Creighton wrote: >In a message of Sun, 12 Oct 2003 22:38:33 BST, "Tim Parkin" writes: > > >>>I get really uncomfortable when what I want to paste into the search >>>box doesn't fit. Or when I type in long things. Here I am being >>>really precise to limit my search nicely, and I cannot see ... >>> >>> >>Well I made it bigger now... >> >>The new version is at >> >>http://pollenation.net/assets/public/draft-oct13.html >> >> > >you sure Tim? On Mozilla on my laptop it looks the same. And I get >the can opener effect as well. Do you know any good way for me to >just save all the bits on my screen as a png or something so I can >mail it to you? I don't. > It depends what you're using. GNOME 2.2 has a built in screenshot utility (available as a panel button), KDE has something called ksnapshot, Imagemagick includes a command line app called import. >Is this how I ask my mozilla to tell me what version it is so I can tell >you? about: under help menu says ... > >Mozilla 1.0 >Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 > Wow, are you really using Debian Stable? I thought everyone immediately switched to testing ;-). This must be a Mozilla 1.0 problem as the page works ok in 1.4 and seems to work ok in 1.1 and 1.3. I may be able to install 1.0 to help Tim but is it honestly worth it? Anyone know how many Moz 1.0 users the site gets? [snip] >But now I need bed more than anything else. > Me too! Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt@pollenation.net From tim at pollenation.net Mon Oct 13 02:57:44 2003 From: tim at pollenation.net (Tim Parkin) Date: Mon Oct 13 02:57:48 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310130621.h9D6LFh9014278@ratthing-b246.strakt.com> Message-ID: <040a01c39157$53d3fd50$0a00a8c0@JASPER> No attachment!! :-) I'm sure they'll arrive soon... ---------------------------------------------- Tim Parkin Managing Director Pollenation Internet Ltd www.pollenation.net m : 07980 59 47 68 t : 01132 25 25 00 -----Original Message----- From: Laura Creighton [mailto:lac@strakt.com] Sent: 13 October 2003 07:21 To: Matt Goodall Cc: Laura Creighton; tim@pollenation.net; pydotorg-redesign@python.org; lac@strakt.com Subject: Re: [Pydotorg-redesign] Draft HTML for redesign proposal In a message of Mon, 13 Oct 2003 01:30:48 BST, Matt Goodall writes: >It depends what you're using. GNOME 2.2 has a built in screenshot >utility (available as a panel button), KDE has something called >ksnapshot, Imagemagick includes a command line app called import. Ksnapshot it is, then > >>Is this how I ask my mozilla to tell me what version it is so I can tell >>you? about: under help menu says ... >> >>Mozilla 1.0 >>Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/ >1.0.0-0.woody.1 >> >Wow, are you really using Debian Stable? I thought everyone immediately >switched to testing ;-). Well, at work, I use unstable. But this is my laptop, which has to work on airplanes, trains, and other places where I cannot just get the odd file when something breaks .... > >This must be a Mozilla 1.0 problem as the page works ok in 1.4 and seems >to work ok in 1.1 and 1.3. I may be able to install 1.0 to help Tim but >is it honestly worth it? Anyone know how many Moz 1.0 users the site gets >? Don't do it for me -- or for the can opener. > >[snip] > >>But now I need bed more than anything else. >> >Me too! > >Cheers, Matt Ok, awake now. Here are 2 pngs, the first from my laptop mozilla, the second from my laptop konqueror. From tim at pollenation.net Mon Oct 13 02:58:44 2003 From: tim at pollenation.net (Tim Parkin) Date: Mon Oct 13 02:58:48 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310130621.h9D6LFh9014278@ratthing-b246.strakt.com> Message-ID: <040b01c39157$77e5ff90$0a00a8c0@JASPER> It may be better to mail the attachments directly to me for now. That goes for everyone else too.. I'll put them up on a site for demonstrations if they're not instantly fixable. Tim From lac at strakt.com Mon Oct 13 02:21:15 2003 From: lac at strakt.com (Laura Creighton) Date: Mon Oct 13 03:10:49 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message from Matt Goodall of "Mon, 13 Oct 2003 01:30:48 BST." <3F89F238.7060306@pollenation.net> References: <03e001c39109$363f09e0$0a00a8c0@JASPER> <200310122315.h9CNFCh9012813@ratthing-b246.strakt.com> <3F89F238.7060306@pollenation.net> Message-ID: <200310130621.h9D6LFh9014278@ratthing-b246.strakt.com> In a message of Mon, 13 Oct 2003 01:30:48 BST, Matt Goodall writes: >It depends what you're using. GNOME 2.2 has a built in screenshot >utility (available as a panel button), KDE has something called >ksnapshot, Imagemagick includes a command line app called import. Ksnapshot it is, then > >>Is this how I ask my mozilla to tell me what version it is so I can tell >>you? about: under help menu says ... >> >>Mozilla 1.0 >>Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/ >1.0.0-0.woody.1 >> >Wow, are you really using Debian Stable? I thought everyone immediately >switched to testing ;-). Well, at work, I use unstable. But this is my laptop, which has to work on airplanes, trains, and other places where I cannot just get the odd file when something breaks .... > >This must be a Mozilla 1.0 problem as the page works ok in 1.4 and seems >to work ok in 1.1 and 1.3. I may be able to install 1.0 to help Tim but >is it honestly worth it? Anyone know how many Moz 1.0 users the site gets >? Don't do it for me -- or for the can opener. > >[snip] > >>But now I need bed more than anything else. >> >Me too! > >Cheers, Matt Ok, awake now. Here are 2 pngs, the first from my laptop mozilla, the second from my laptop konqueror. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90951 bytes Desc: not available Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20031013/859cea8d/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 85073 bytes Desc: not available Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20031013/859cea8d/attachment-0003.png -------------- next part -------------- And I think I understand what is happening. Tim has made something I am going to call a Google-widget. It is that pretty grey box with the Google advertising and Search and the Go button, and of course the all important text window. Now, as far as I am concerned, anything but the Go button and the text window is 'chart junk'. (for those of you who are reading this, and haven't read Tufte, I am being constructively critical here. And reading Tufte is a joy). However, 'Google' is a legal requirement, and, I don't know, maybe there are some people on the planet who don't recognise a search window when they see it. My problem is that Tim's Google-widget is of fixed size. You resize the window, and the Google widget moves back and forth, stuck to the right hand border of the window, and eating up the space between the 'Python' and its left most border as needed. I want a different Google-widget, one that automatically sizes its text window to take up all the space that is available. I want the left most border of the Google-widget glued to some space just to the right of 'Python' the logo, the right most border glued to the rhs, wherever that is, and the whole thing to float in width as I resize it. That way I can paste things like: 'Haskell monadic modular interpreters' into the window, and see whether we have had a discussion about them someplace, before I start another round of 'making Python more Haskell-like' or whatever is my favorite poison of the moment. (I am assuming that I will get to access the mailing lists via this Google-widget as well, and I think that a 'advanced search' click link for people who only want to search the mailing lists, say, would be useful.) Am I making any sense? Laura From lac at strakt.com Mon Oct 13 03:31:08 2003 From: lac at strakt.com (Laura Creighton) Date: Mon Oct 13 03:31:45 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message from "Tim Parkin" of "Mon, 13 Oct 2003 07:57:44 BST." <040a01c39157$53d3fd50$0a00a8c0@JASPER> References: <040a01c39157$53d3fd50$0a00a8c0@JASPER> Message-ID: <200310130731.h9D7V9h9014729@ratthing-b246.strakt.com> In a message of Mon, 13 Oct 2003 07:57:44 BST, "Tim Parkin" writes: >No attachment!! :-) I'm sure they'll arrive soon... > >---------------------------------------------- >Tim Parkin >Managing Director >Pollenation Internet Ltd >www.pollenation.net >m : 07980 59 47 68 >t : 01132 25 25 00 They are delayed awaiting moderator approval because they are big. I have to go to the dentist. Back later. Laura From tim at pollenation.net Mon Oct 13 04:41:31 2003 From: tim at pollenation.net (Tim Parkin) Date: Mon Oct 13 04:41:32 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310121503.51322.richardjones@optushome.com.au> Message-ID: <042001c39165$d36ff4c0$0a00a8c0@JASPER> Ruchard > >Attached is the comparison on my system. You can see that on my system, the >specifying pf 100% (as in the current pydotorg site) and 86% (as specified in >the new stylesheet) actually results in text sizes reflecting those >specifications, unlike on your system, which somehow renders the 86% font >larger than your default font size... Could you send your operating system type and version and also your browser type and version. Also if you've made any changes to the properties for your browser those would be good too as it looks very strange. It would also be great if you could take a screenshot of this page for me and send to my email address (we don't want to flood the list with screenshots). What makes me think something strange is happening is that 99% of browsers use serif fonts for default text (times-roman usually) and yours looks like a sans serif. http://pollenation.net/assets/public/font-test.html Cheers Tim From amk at amk.ca Mon Oct 13 14:07:25 2003 From: amk at amk.ca (amk@amk.ca) Date: Mon Oct 13 14:07:32 2003 Subject: [Pydotorg-redesign] Re: User comments on python.org References: Message-ID: [This message has also been posted.] [CC'ing to pydotorg-redesign, and setting followups there, too.] On Sat, 11 Oct 2003 19:19:41 -0500, Ian Bicking wrote: > I don't really know how the Python site is set up now, but could > comments be included inline as an SSI? Like I don't think SSIs are currently enabled, but it wouldn't be hard to turn them on. However, I have two worries about this: 1) Fitting the comments into the page design -- a page with a lot of comments would be really, really lengthy. 2) What if people post obscenities or harmful material? Showing comments by default would be embarrassing; if you have to explicitly choose to view them, this is less worrying. Python.org has a really good Google PageRank, I expect, making it a good target for link spam, so this is something to worry about. The Wiki has mostly escaped such vandalism; presumably it's unobtrusive enough that spammers haven't noticed it. > the page content and the barest of controls). I think it would be best > done as a separate wiki, maybe with a namespace that fits the library > documentation structure better. Or maybe both are possible. It would Perhaps. Wiki names can contain '/', so we can have annotations for every single page on the site by just using the full path name. The question is whether we need that level of support; perhaps the docs are the only place where comments are valuable. I do think that comments on the reference manual or the Distutils manuals would be useful. (Possibly PEPs, too?) I did a bit of experimenting with the separate page, adding JavaScript to ht2html's output and adding an ugly 'view comment' link. If we're interested in pursuing this, I'm willing to do the following: 1) Make a set of experimental pages with comment links, so we can see what they look like and how they work in practice. 2) If 1) looks worthwhile, then I'll make a new Wiki for user notes that has minimal styling. What I'd really need is presentation suggestions: *how* to show the comment link? --amk From skip at pobox.com Mon Oct 13 15:00:13 2003 From: skip at pobox.com (Skip Montanaro) Date: Mon Oct 13 15:00:45 2003 Subject: [Pydotorg-redesign] Re: User comments on python.org In-Reply-To: References: Message-ID: <16266.63037.503883.538848@montanaro.dyndns.org> amk> 1) Fitting the comments into the page design -- a page with a lot amk> of comments would be really, really lengthy. I would prefer to see a little icon next to paragraphs with comments. That minimizes the change in length. Click 'em to pop up a window (or something) with the relevant comments. amk> 2) What if people post obscenities or harmful material? ... amk> The Wiki has mostly escaped such vandalism; presumably it's amk> unobtrusive enough that spammers haven't noticed it. That and the fact that a few people subscribe to changes to most pages, or at least to the RecentChanges page, so they are alerted quickly to changes. Juergen, Guido and I have all reverted Wiki changes. In my experience, most changes are one of two types: * Someone tries to slip their website's URL into the Wiki in hopes it will score higher with more search engines as a result * Comments like, "Are you aware anyone can change this page? Isn't that a bug?" I'd be against anything which actually modified the content of a page as a result of adding a comment, if for no other reason than it would have to integrate with ht2html+CVS, at least for the forseeable future. Skip From amk at amk.ca Mon Oct 13 15:39:41 2003 From: amk at amk.ca (amk@amk.ca) Date: Mon Oct 13 15:39:46 2003 Subject: [Pydotorg-redesign] Re: User comments on python.org In-Reply-To: <16266.63037.503883.538848@montanaro.dyndns.org> References: <16266.63037.503883.538848@montanaro.dyndns.org> Message-ID: <20031013193941.GA21348@rogue.amk.ca> On Mon, Oct 13, 2003 at 02:00:13PM -0500, Skip Montanaro wrote: > I would prefer to see a little icon next to paragraphs with comments. That > minimizes the change in length. Click 'em to pop up a window (or something) > with the relevant comments. Too difficult; we'd need a way to identify paragraphs, and then a way to modify page content to insert the icon. The W3C way would be to use ID attributes on paragraphs and then use XPath (or just an ID reference), but there's no way to make that work without server-side processing. For this reason, the link text would have to be generic, something like 'View/add notes'; we can't have a link that's only there if there's already a note. --amk From cs1spw at bath.ac.uk Mon Oct 13 16:11:26 2003 From: cs1spw at bath.ac.uk (Simon Willison) Date: Mon Oct 13 16:10:24 2003 Subject: [Pydotorg-redesign] Re: User comments on python.org In-Reply-To: References: Message-ID: <3F8B06EE.5040207@bath.ac.uk> amk@amk.ca wrote: > I don't think SSIs are currently enabled, but it wouldn't be hard to turn > them on. However, I have two worries about this: > > 1) Fitting the comments into the page design -- a page with a lot of > comments would be really, really lengthy. The coolest way of handling this problem I've ever seen is on www.kuro5hin.org - load up one of their full story links, then select "dynamic minimal" from the Display menu and hit the "set" button. This causes all comments attached to an entry to be displayed as just the title with a blue arrow icon - clicking the icon dynamically loads that comment without reloading the page. Despite using some pretty advanced Javascript, the technique works in both IE and Mozilla. Browsers that do not support the javascript (such as Opera) can still see the comments, but have to put up with a round trip to the server when they click on a link. A less cool solution would be just to paginate the comments. > 2) What if people post obscenities or harmful material? > Showing comments by default would be embarrassing; if you have to > explicitly choose to view them, this is less worrying. > Python.org has a really good Google PageRank, I expect, making it > a good target for link spam, so this is something to worry about. The way PHP.net handles this is that ALL comments are placed in a moderation queue and only appear on the site once they have been manually approved. This solution would be a disaster if comments were meant for discussion, but on PHP.net comments are meant as annotations to the page in question hence it doesn't matter if there is a delay of a few hours bewteen the comment being posted and it going "live". I would suggest the same approach for Python.org. I have to admit, much as I love Wikis I don't see that Wiki style functionality is the best way to go about adding user comments to pages of Python.org. Wikis are fantastic tools for fleshing out ideas and allowing a small group of smart, dedicated people to collaborate. User comments on a high profile site like Python.org are less of a community driven thing - people drop in to the site every now and then and maybe comment on a feature of the language they have just used. Cheers, Simon Willison http://simon.incutio.com/ From ianb at colorstudy.com Mon Oct 13 17:13:32 2003 From: ianb at colorstudy.com (Ian Bicking) Date: Mon Oct 13 17:18:02 2003 Subject: [Pydotorg-redesign] Re: User comments on python.org In-Reply-To: Message-ID: <19C8D5B3-FDC2-11D7-94FE-000393C2D67E@colorstudy.com> On Monday, October 13, 2003, at 01:07 PM, A.M. Kuchling wrote: > [CC'ing to pydotorg-redesign, and setting followups there, too.] > > On Sat, 11 Oct 2003 19:19:41 -0500, > Ian Bicking wrote: >> I don't really know how the Python site is set up now, but could >> comments be included inline as an SSI? Like > > I don't think SSIs are currently enabled, but it wouldn't be hard to > turn > them on. However, I have two worries about this: > > 1) Fitting the comments into the page design -- a page with a lot of > comments would be really, really lengthy. Sites that have this usually offer versions of the documentation with and without comments. I can imagine three places where comments would become excessive -- the documentation has problems, the domain is inherently confusing or large (the cgi module turns into a tutorial on CGI), or significant recipes are included. These are all basic Wiki refactoring problems -- editing the original documentation (to make it less ambiguous, so the comments aren't needed, or otherwise improve it); or creating more documentation (perhaps linking to other Wiki pages that go on at length on a topic). > 2) What if people post obscenities or harmful material? > Showing comments by default would be embarrassing; if you have to > explicitly choose to view them, this is less worrying. > Python.org has a really good Google PageRank, I expect, making it > a good target for link spam, so this is something to worry about. I think it will be better when the comments are included inline, because many more people will view the comments. The same is true for general accuracy. Spam and such is best handled on a Wiki when there's lots of people to fix it. But maybe php.net or other places would have more experience on this (php.net does put comments at the end of each page). Maybe user logins are a good way to raising the bar to discourage useless (or worse) comments. I also like the idea of using Wiki pages instead of the traditional appended comments -- I think it would be more constructive. > The Wiki has mostly escaped such vandalism; presumably it's unobtrusive > enough that spammers haven't noticed it. > >> the page content and the barest of controls). I think it would be >> best >> done as a separate wiki, maybe with a namespace that fits the library >> documentation structure better. Or maybe both are possible. It would > > Perhaps. Wiki names can contain '/', so we can have annotations for > every > single page on the site by just using the full path name. The > question is > whether we need that level of support; perhaps the docs are the only > place > where comments are valuable. I do think that comments on the reference > manual or the Distutils manuals would be useful. (Possibly PEPs, too?) There's definitely places besides the library reference that could use these comments, but I think they could all be listed out explicitly. A little rewrite magic could keep it in a flat hierarchy. > I did a bit of experimenting with the separate page, adding JavaScript > to > ht2html's output and adding an ugly 'view comment' link. If we're > interested in pursuing this, I'm willing to do the following: > > 1) Make a set of experimental pages with comment links, so we can see > what they look like and how they work in practice. > 2) If 1) looks worthwhile, then I'll make a new Wiki for user notes > that has > minimal styling. > > What I'd really need is presentation suggestions: *how* to show the > comment > link? I think it should *not* be in the sidebar -- the sidebar is navigational and it's implied that it's specific to the site or section, not that particular page. But the library reference doesn't really have a sidebar, so nevermind that... In the top bar then, by the TOC/modules/index links... or maybe the arrows, since those are context-sensitive, where the other links are global. Then maybe a larger link at the bottom of the page (kind of a further reading link). If the comments aren't included inline, I feel like it would be important to indicate if there *were* any comments. It's annoying and discouraging to be in a site that hints at things that aren't there -- and there will be a lot of "not there" when this feature is first added. But I think implementing that would be fairly hard to do. But important. But hard. Sigh. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org From tim at pollenation.net Mon Oct 13 17:23:51 2003 From: tim at pollenation.net (Tim Parkin) Date: Mon Oct 13 17:23:59 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310122315.h9CNFCh9012813@ratthing-b246.strakt.com> Message-ID: <04bc01c391d0$5332a940$0a00a8c0@JASPER> >>> >>>http://pollenation.net/assets/public/draft-oct13.html >> >I just tried it under konquerer, and it looks really bad. I've got to >learn a way to send you the bits of my screen so you can see it, but it >is nothing like what you are asking for ... I can tweak things a little when we get some feedback as theres no point making many small tweaks only to find out that something needs changing and have to go through the whole process again. The konquerer version you are using in debian stable is 2.2.2 which is 2 years old and did have many css rendering problems. I'll still have a try to get it usable if possible but can't promise anything. How would it seem if I used a javascript method for checking for konqueror and used an alternative stylesheet. This stylesheet could be selected manualy for people with javascript disabled. This would offer a custom stylesheet in the same vein as netscape 4. I think this method could be used to extend the usabilty of the site to close to 100% of users, albeit with a manual intervention needed for a very small percentage (automatically applied for those with javascript enabled). I've also been trying out something else which is not polished yet but wanted to know what people think. http://pollenation.net/assets/public/collapsetest The left hand menu has a collapse text. I don't currently like this positioning. As it would only really be used at the "document" level, I thought it could be added to the rhs document level navigation box. It would also have an associated 'hot key' so power users wouldn't need a menu item at all. Oh and theres not 'back to default size' on the make text larger link. Tim From tim at pollenation.net Tue Oct 14 03:29:04 2003 From: tim at pollenation.net (Tim Parkin) Date: Tue Oct 14 03:29:04 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal Message-ID: <04f501c39224$df0aa2c0$0a00a8c0@JASPER> Laura: >>> >>>http://pollenation.net/assets/public/draft-oct13.html >> >I just tried it under konquerer, and it looks really bad. I've got to >learn a way to send you the bits of my screen so you can see it, but it >is nothing like what you are asking for ... I can tweak things a little when we get some feedback as theres no point making too many small tweaks only to find out that something needs changing and have to go through the whole process again. The konquerer version you are using in debian stable is 2.2.2 which is 2 years old and did have many css rendering problems. I'll still have a try to get it usable if possible but can't promise anything. How would it seem if I used a javascript method for checking for konqueror 2 and used an alternative stylesheet. This stylesheet could be selected manualy for people with javascript disabled. This would offer a custom stylesheet in the same vein as netscape 4. I think this method could be used to extend the usabilty of the site to close to 100% of users, albeit with a manual intervention needed for a very small percentage (automatically applied for those with javascript enabled). I've also been trying out something else which is not polished yet but wanted to know what people think. http://pollenation.net/assets/public/collapsetest The left hand menu has a collapse text. I don't currently like this positioning. As it would only really be used at the "document" level, I thought it could be added to the rhs document level navigation box. It would also have an associated 'hot key' so power users wouldn't need a menu item at all. Oh and theres not 'back to default size' on the make text larger link. Tim From bokr at oz.net Mon Oct 13 22:58:45 2003 From: bokr at oz.net (Bengt Richter) Date: Tue Oct 14 03:32:26 2003 Subject: [Pydotorg-redesign] Re: User comments on python.org References: Message-ID: <3f8b658a.1086493284@news.oz.net> On Mon, 13 Oct 2003 13:07:25 -0500, "A.M. Kuchling" wrote: >[CC'ing to pydotorg-redesign, and setting followups there, too.] (somehow the email address got into the newsgroup slot for me, so I had to fix it) > >On Sat, 11 Oct 2003 19:19:41 -0500, > Ian Bicking wrote: >> I don't really know how the Python site is set up now, but could >> comments be included inline as an SSI? Like > >I don't think SSIs are currently enabled, but it wouldn't be hard to turn >them on. However, I have two worries about this: > >1) Fitting the comments into the page design -- a page with a lot of > comments would be really, really lengthy. > >2) What if people post obscenities or harmful material? > Showing comments by default would be embarrassing; if you have to > explicitly choose to view them, this is less worrying. > Python.org has a really good Google PageRank, I expect, making it > a good target for link spam, so this is something to worry about. > >The Wiki has mostly escaped such vandalism; presumably it's unobtrusive >enough that spammers haven't noticed it. > >> the page content and the barest of controls). I think it would be best >> done as a separate wiki, maybe with a namespace that fits the library >> documentation structure better. Or maybe both are possible. It would > >Perhaps. Wiki names can contain '/', so we can have annotations for every >single page on the site by just using the full path name. The question is >whether we need that level of support; perhaps the docs are the only place >where comments are valuable. I do think that comments on the reference >manual or the Distutils manuals would be useful. (Possibly PEPs, too?) > >I did a bit of experimenting with the separate page, adding JavaScript to >ht2html's output and adding an ugly 'view comment' link. If we're >interested in pursuing this, I'm willing to do the following: > >1) Make a set of experimental pages with comment links, so we can see > what they look like and how they work in practice. >2) If 1) looks worthwhile, then I'll make a new Wiki for user notes that has > minimal styling. > >What I'd really need is presentation suggestions: *how* to show the comment >link? Have a look at http://www.xml.com/axml/testaxml.htm for a way of associating commentary with (it says, at least) unchanged original matter (in this case the XML spec). It's pretty easy on the eyes. I don't know the implementation, but I think that separation of pristine original from comment material would be good. The above site probably has the advantage of heavy xml tagging in the original that the commentary database can used for retrieving associated commentary, I would guess. Since full comment generation for dynamic javascript-controlled interaction is somewhat computer-costly, caching results of generating responses to comments would make sense, I think, and I don't think generating it should be the default. If the python.org server is able to insert an optional footer chunk just before the when so configured to do it for a directory or a file (I don't know if Apache can do that, since I just made it up, but ISTM it would be a useful option ;-), then that footer could contain a link for viewing commentary. The link would go to a comment-server URL, e.g., commentary.python.org/coments.cgi, The cgi program will see HTTP_REFERER from the page the user clicked the comments link on, and it can either get a copy via HTTP, or look it up on the local hard disk if it's local. The URL can also be used as a key into a database of commentary, where also commenter-accounts could be maintained to keep out spammers. With the original page plus a database of commentary, the problem becomes building a new image of the original with unobtrusive commentary navigation. With javascript you could do floating hint text from commentary title lines associated with paragraphs or other elements you were mousing over. Clicking might put the commentary in a separate popup window. Right clicking on a previous comment might mean pop a form to add your 2 cents. Right clicking on the main page where no comment hint is being displayed would pop up the same but with an option to give it a title, since it's new commentary. All of this is pretty much paragraph oriented. Indexing locations, which have to be w.r.t. unmarked text in the original can do some kind of soft hash of

sections in the original as indices instead of using line numbers, so the data base can have the hashes as keys, and not get thrown too much by updates in the original. Actual anchor targets and tag ids can be used too I suppose (I'm just thinking out loud ;-) Anyway, you get the idea. If it makes you rich, I want a piece ;-) my 2 cents ;-) Regards, Bengt Richter From Mike at Geary.com Tue Oct 14 04:50:32 2003 From: Mike at Geary.com (Michael Geary) Date: Tue Oct 14 04:50:41 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <04f501c39224$df0aa2c0$0a00a8c0@JASPER> Message-ID: Hi Tim! You know what I'm going to say, don't you? :-) Yeah, it's the text. It's a lot better than it was before--the font size is completely reasonable now. (As a reminder, I use a Thinkpad A30p with a 15" 1600x1200 display, i.e. 133 pixels per inch--a typical pixel density for high-end notebooks. I'm running Windows XP with ClearType enabled, using Mozilla Firebird with 18 pixel Georgia as my default font and a minimum font size of 14 pixels.) Here's what I don't like, though: * Not black. I know that you consider less contrast to be easier on the eyes, but I have to tell you that with my eyes, on my computer, it just ain't so. I spend all day, every day, looking at text, and I've tried lots of variations of font and color. Black on white is by far the best for me. This is especially true now that I use ClearType--black on white gives ClearType the most room to work with, and colored text suffers especially because it severely limits how much subpixel antialiasing can be done. But even before I used ClearType, black on white was the best on my LCD displays. * Arial font. I saw your discussion on your site about Arial vs. Verdana, but for me Verdana is really quite a bit more readable. Also, I think that the fact that Verdana distinguishes between upper case "I" and lower case "l" is a big point in its favor on a site where that distinction may be significant. * But why force a sans-serif font at all? I know that traditionally, serif fonts have suffered from poor readability on a computer display, and the traditional default browser font has been a serif font, so web designers have forced sans-serif fonts in an attempt to gain more readability. But for me, the combination of the Georgia font, ClearType, and the high-resolution LCD panel have changed that completely. For the first time, I can really make use of the benefits of a serif font (which as you know is more readable than sans-serif in print). Do me a favor and beg, borrow, or steal a notebook with a high-resolution LCD like mine--a 15" 1600x1200 or a 14.1" 1400x1050 will do the trick--and take a look at this: http://www.geary.com/python/pyfonts.png The text on the left is from your sample, and the text on the right is from the original python.org page using my default browser font settings (black Georgia), both rendered in Mozilla Firebird. I don't know how they will compare on a lower resolution LCD or on a CRT (ClearType might mess both of them up on a CRT), but on my high-resolution LCD there's no contest. But what the heck, I could live with a sans-serif font if it were black Verdana. :-) Sorry if I sound like a one-trick pony, but when I'm reading text, text is what I care about. Thanks for listening to my input! -Mike From Mike at Geary.com Tue Oct 14 05:25:10 2003 From: Mike at Geary.com (Michael Geary) Date: Tue Oct 14 05:25:16 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message-ID: (Read this after my other message for it to make the most sense...) p.s. Realizing that you may prefer the sans-serif font, I did another side-by-side example, this time with 16-pixel Verdana on the right: http://www.geary.com/python/pyfonts2.png I do like the bit of extra line spacing the text on the left has, but I like the font and color better on the right. And just so it's all in one place, here's the one with 18-pixel Georgia again: http://www.geary.com/python/pyfonts.png Again, these use ClearType and are meant for a high-resolution LCD. Also, it goes without saying--make sure your browser doesn't shrink the images when you look at these! :-) Thanks, Mike From tim at pollenation.net Tue Oct 14 07:09:05 2003 From: tim at pollenation.net (Tim Parkin) Date: Tue Oct 14 07:09:12 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message-ID: <050501c39243$9b37b7d0$0a00a8c0@JASPER> Michael Greary: >* Not black. I know that you consider less contrast to be easier on the >eyes, but I have to tell you that with my eyes, on my computer, it just >ain't so. I spend all day, every day, looking at text, and I've tried lots >of variations of font and color. Black on white is by far the best for me. >This is especially true now that I use ClearType--black on white gives >ClearType the most room to work with, and colored text suffers especially >because it severely limits how much subpixel antialiasing can be done. But >even before I used ClearType, black on white was the best on my LCD >displays. I think perhaps you're right when you're using clear type on an LCD display 15" monitor at 1600x1200. What I propose doing is adding an alternate sytlesheet which removes all styling from the body content. This means that for 99% of people who don't set their default fonts (and probably don't know how to) and who would see times roman if they didn't (one of the most unreadable fonts when non-antialiased, which is how ie shows it) get to see an optimum view. For those power users who have exceptional circusmstances, there will be an alternate stylesheet available, which is how the w3c proposes handling situations similar to this . I agree that the contrast is a little low and am now implementing a stylesheet specifically for people who have dyslexic style reading difficulties. I don't want to use full black on white as a lot of people have complained that this is too stark for them so I'm upping the contrast to 80%. Then, people who see this as too dark can set their own contrast by using the default view stylesheet. People who see this as too light can also do the same. >* Arial font. I saw your discussion on your site about Arial vs. Verdana, >but for me Verdana is really quite a bit more readable. Also, I think that >the fact that Verdana distinguishes between upper case "I" and lower case >"l" is a big point in its favor on a site where that distinction may be >significant. I don't think the l versus I is a big issue, context provides incredible clues and we don't read letter by letter any way. As an example, does this look like the plural or virus? VIRll... Or did it read as Virll? I can imagine a situation in an olde world drama about roman gods "So lo, daughter of Inachus" but maybe this is most unlikely. I personally think that verdana is too extended (opp. Condensed) and also I chose arial to match the opus/officana font used in the Python logo, not the main consideration but it works niceley nevertheless. If a majority of people complain about the use of arial and all state a preference for verdana I shall obviously change it. However I will make sure that people who wish to set their own custom styles will have the opportunity. >* But why force a sans-serif font at all? I know that traditionally, serif >fonts have suffered from poor readability on a computer display, and the >traditional default browser font has been a serif font, so web designers >have forced sans-serif fonts in an attempt to gain more readability. But for >me, the combination of the Georgia font, ClearType, and the high-resolution >LCD panel have changed that completely. For the first time, I can really >make use of the benefits of a serif font (which as you know is more readable >than sans-serif in print). Because the vast majority of people use browser/os combinations that don't support clear type, that don't anti alias fonts and that default to times-roman, it would be remiss to configure for this as the default. But I do agree, good size monitors with high dpi's and a system like cleartype is more like print and hence serif fonts work very well for narrative. >Do me a favor and beg, borrow, or steal a notebook with a high-resolution >LCD like mine--a 15" 1600x1200 or a 14.1" 1400x1050 will do the trick--and >take a look at this: I have a sony vaio PCG-C1MHP which is an 8.9" UW-SXGA which equates to 160dpi (your monitors are 133dpi and 124dpi respectively). Like I said, if I activate cleartype and boost font size it looks great. If I don't do this then sans-serif looks better. >Sorry if I sound like a one-trick pony, but when I'm reading text, text is >what I care about. No problem, I appreciate the detailed reply and have made some changes that go toward what you are after. I hope these are enough to balance the satisfaction of the individual power user and the majority passive browser. (I'll upload the changes this evening) Tim From tim at pollenation.net Tue Oct 14 07:29:00 2003 From: tim at pollenation.net (Tim Parkin) Date: Tue Oct 14 07:29:05 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message-ID: <050601c39246$63fa2610$0a00a8c0@JASPER> Michael >p.s. Realizing that you may prefer the sans-serif font, I did another >side-by-side example, this time with 16-pixel Verdana on the right: Just my comparison of serif vs sans-serif as would be viewed in majority of browsers compared with viewed with cleartype. http://pollenation.net/assets/public/python-fonts-serifs.gif http://pollenation.net/assets/public/python-fonts-sans.gif I've also shown the contrast that I'd prefer to use. http://pollenation.net/assets/public/python-fonts-contrast.gif Tim From tim at pollenation.net Tue Oct 14 07:44:47 2003 From: tim at pollenation.net (Tim Parkin) Date: Tue Oct 14 07:44:51 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message-ID: <050701c39248$99b32160$0a00a8c0@JASPER> Final note... Verdana is actually a bigger font than arial, to this effect, I've modified the font sizing to reflect this. http://pollenation.net/assets/public/python-fonts-arialverdana.gif Tim From lac at strakt.com Tue Oct 14 08:44:54 2003 From: lac at strakt.com (Laura Creighton) Date: Tue Oct 14 08:45:30 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message from "Tim Parkin" of "Tue, 14 Oct 2003 08:29:04 BST." <04f501c39224$df0aa2c0$0a00a8c0@JASPER> References: <04f501c39224$df0aa2c0$0a00a8c0@JASPER> Message-ID: <200310141244.h9ECisXR002844@ratthing-b246.strakt.com> My laptop died yesterday. The screen is shot. I'm sorry, but I cannot help you any more .... at least until I can see if I can get it repaired. SInce I hate the thing, I am sort of hoping _not_ ... YOu may have fixed the rendering problem by removing the one user who had it. Boy, do I need to learn that trick for some customers of mine. :-) Laura In a message of Tue, 14 Oct 2003 08:29:04 BST, "Tim Parkin" writes: >Laura: >>>> >>>>http://pollenation.net/assets/public/draft-oct13.html >>> >>I just tried it under konquerer, and it looks really bad. I've got to >>learn a way to send you the bits of my screen so you can see it, but it >>is nothing like what you are asking for ... >I can tweak things a little when we get some feedback as theres no point >making too many small tweaks only to find out that something needs >changing >and have to go through the whole process again. > >The konquerer version you are using in debian stable is 2.2.2 which is 2 >years old and did have many css rendering problems. I'll still have a >try to get it usable if possible but can't promise anything. How would >it seem if I used a javascript method for checking for konqueror 2 and >used an alternative stylesheet. This stylesheet could be selected >manualy for people with javascript disabled. This would offer a custom >stylesheet in the same vein as netscape 4. I think this method could be >used to extend the usabilty of the site to close to 100% of users, >albeit with a manual intervention needed for a very small percentage >(automatically applied for those with javascript enabled). I use mozilla and firebird for me, so I don't care about konqueror myself. But I think that it is well used, so I wanted to see how it looked, and it wasn't good ... > >I've also been trying out something else which is not polished yet but >wanted to know what people think. > >http://pollenation.net/assets/public/collapsetest Interesting, now I get the canopener effect at work too. You not getting it? > >The left hand menu has a collapse text. I don't currently like this >positioning. As it would only really be used at the "document" level, I >thought it could be added to the rhs document level navigation box. It >would also have an associated 'hot key' so power users wouldn't need a >menu item at all. Oh and theres not 'back to default size' on the make >text larger link. > >Tim Really making this window very narrow is --- odd. But I'm not saying that it is wrong. more 'interesting' to me .... i might get perverse and like it. Laura From roy at panix.com Tue Oct 14 08:52:55 2003 From: roy at panix.com (Roy Smith) Date: Tue Oct 14 08:53:03 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <050601c39246$63fa2610$0a00a8c0@JASPER> Message-ID: <545668B2-FE45-11D7-A42B-0050E405C35A@panix.com> On Tuesday, October 14, 2003, at 07:29 AM, Tim Parkin wrote: > I've also shown the contrast that I'd prefer to use. > > http://pollenation.net/assets/public/python-fonts-contrast.gif > Could just be my 40-something eyes, but I find the black text significantly easier to read than the 80% text. I'm looking at this on a 17" CRT set to 24-bit color, 1280 x 960, 75 Hz, which works out to about 90 dpi. From lac at strakt.com Tue Oct 14 08:53:13 2003 From: lac at strakt.com (Laura Creighton) Date: Tue Oct 14 08:53:20 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message from "Michael Geary" of "Tue, 14 Oct 2003 01:50:32 PDT." References: Message-ID: <200310141253.h9ECrDND002902@ratthing-b246.strakt.com> I really like serifs on my fonts as well. Laura From tim at pollenation.net Tue Oct 14 08:59:00 2003 From: tim at pollenation.net (Tim Parkin) Date: Tue Oct 14 08:59:01 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310141244.h9ECisXR002844@ratthing-b246.strakt.com> Message-ID: <051501c39252$f6488ff0$0a00a8c0@JASPER> >My laptop died yesterday. The screen is shot. > YOu may have fixed the rendering problem by removing the one user >who had it. Boy, do I need to learn that trick for some customers of >mine. :-) Took me a lot of hacking to make that happen ;-) >I use mozilla and firebird for me, so I don't care about >konqueror myself. But I think that it is well used, so I >wanted to see how it looked, and it wasn't good ... I think It's 2.2.2 as I said, so it won't look v good >Interesting, now I get the canopener effect at work too. You not >getting it? Not unless I use konquerer 2.2.2 >Really making this window very narrow is --- odd. But I'm not saying that >it is wrong. more 'interesting' to me .... i might get perverse and like it. I'm sorry I probably don't understand the context. You mean making the browser narrow makes it odd or the screen goes narrow when you collapse the menu? Tim Ps cheers for feedback From tim at pollenation.net Tue Oct 14 09:32:03 2003 From: tim at pollenation.net (Tim Parkin) Date: Tue Oct 14 09:32:09 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310141415.01671.anna@aleax.it> Message-ID: <051601c39257$94f39fb0$0a00a8c0@JASPER> Anna (although the reply is a general one): >So far, my favorite is the antialias Verdana. It shows up clear and clean on >Opera 7.11. The nonantialias versions are worst - with Arial slightly worse >than Verdana... Unfortunately most users (most windows and some linux) won't have a choice of using anti-alias. The argument about legibility of fonts can be confused as there are two types of reading. One if word reading, where the individual letter clarity is important, and for this verdana wins hands down. The other is sentence reading, where word shapes are more important as the brain doesn't process letter by letter. For this, in my opinion, arial wins as it's condensed face creates word shapes that are more in line with the typical narrative word shapes used in print etc. Like Michael says, if we were to have very highresolution with excellent anti-aliasing, I would choose a serif font for body content. Unfortunately we have low resolution with no anti-alias being the default, majority view and for this, I feel arial wins due to it's familiar rendering of word shapes. This is also why you don't tend to see body content in 'Avant Garde' but you do see a lot in 'helvetica' where the screen versions of these are, loosely, 'verdana' and 'arial' respectivley (arial was ms's rendering of helvetica for screen and verdana was the same but optimised for ultra low resolution, non-antialiased. At the end of the day this probably says it all... http://usability.gov/guidelines/fonts.html http://www.acm.org/sigchi/chi95/proceedings/intpost/tst_bdy.htm In summary.. "Research shows no reliable differences in reading speed or user preferences between 10-point Times Roman, Georgia serif fonts, Helvetica, or Verdana sans serif font" Although contrast did produce some differences :- http://hubel.sfasu.edu/research/AHNCUR.html In this case it was noted that in no survey did black on white produce the best response times. This was typically produced at lower contrasts, although in these case the background was adjusted rather than the foreground. On my monitor here (22" Iiyama CRT) black on white makes my eyes water and I prefer a low contrast foreground. Perhaps I suffer from a dyslexia type disorder, but I find 80% contrast so much more readable than 100%. If it turns out I am the exception then I'll have to change it but if what I suffer at 100% contrast is repeated for a large percentage of the population then I'd be very reluctant to give in on this point. Tim From skip at pobox.com Tue Oct 14 11:27:33 2003 From: skip at pobox.com (Skip Montanaro) Date: Tue Oct 14 11:27:46 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: References: <04f501c39224$df0aa2c0$0a00a8c0@JASPER> Message-ID: <16268.5605.245292.164605@montanaro.dyndns.org> Michael> Do me a favor and beg, borrow, or steal a notebook with a Michael> high-resolution LCD like mine--a 15" 1600x1200 or a 14.1" Michael> 1400x1050 will do the trick--and take a look at this: Michael> http://www.geary.com/python/pyfonts.png Can you add the other two combinations to that png (low-contrast serif font and high-contrast sans serif font) just for completeness? Thx, Skip From skip at pobox.com Tue Oct 14 11:38:14 2003 From: skip at pobox.com (Skip Montanaro) Date: Tue Oct 14 11:38:29 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <545668B2-FE45-11D7-A42B-0050E405C35A@panix.com> References: <050601c39246$63fa2610$0a00a8c0@JASPER> <545668B2-FE45-11D7-A42B-0050E405C35A@panix.com> Message-ID: <16268.6246.908547.321982@montanaro.dyndns.org> >> http://pollenation.net/assets/public/python-fonts-contrast.gif Roy> Could just be my 40-something eyes, but I find the black text Roy> significantly easier to read than the 80% text. Ditto here (Mac 15" PowerBook, 1280x854, nearly 50-something). Skip From anna at aleax.it Tue Oct 14 05:45:55 2003 From: anna at aleax.it (Anna Ravenscroft) Date: Tue Oct 14 12:42:17 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: References: Message-ID: <200310141145.55438.anna@aleax.it> On Tuesday 14 October 2003 10:50 am, Michael Geary wrote: > Here's what I don't like, though: > > * Not black. I know that you consider less contrast to be easier on the > eyes, but I have to tell you that with my eyes, on my computer, it just > ain't so. I spend all day, every day, looking at text, and I've tried lots > of variations of font and color. Black on white is by far the best for me. My feeling exactly. I consider the font to be eyestraining very quickly. The size is fine (most websites I tend to zoom to 110% just to read the font; I don't need to do that here), but the impact is too low. Please, can you put in a new ribbon and retype it so it's dark enough to read? Oh, sorry - it just brought me flashbacks of old days... ;-) Seriously though, it reminds me of a copy done on a copier running out of toner. I can read it but I feel like I need to strain a lot... and it's easy for my eyes to get distracted to other parts of the page. I keep finding my eyes skipping off the text to other parts of the page... The font and size are fine... I just really dislike the low contrast. Thanks for listening Anna running Opera 7.11 -- There is a type 3 error in which your mind goes totally blank whenever you try to remember which is which of type 1 and type 2. -Richard Dawkins From Mike at Geary.com Wed Oct 15 02:07:04 2003 From: Mike at Geary.com (Michael Geary) Date: Wed Oct 15 02:07:11 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <16268.5605.245292.164605@montanaro.dyndns.org> Message-ID: > Michael> Do me a favor and beg, borrow, or steal a notebook with a > Michael> high-resolution LCD like mine--a 15" 1600x1200 or a 14.1" > Michael> 1400x1050 will do the trick--and take a look at this: > > Michael> http://www.geary.com/python/pyfonts.png >From Skip: > Can you add the other two combinations to that png (low-contrast > serif font and high-contrast sans serif font) just for completeness? It looks like Tim's additional samples covered those--or are there still some cases missing? -Mike From Mike at Geary.com Wed Oct 15 02:26:12 2003 From: Mike at Geary.com (Michael Geary) Date: Wed Oct 15 02:26:23 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <051601c39257$94f39fb0$0a00a8c0@JASPER> Message-ID: > From: Tim Parkin > Unfortunately most users (most windows and some linux) won't have > a choice of using anti-alias. Hmm... Just about all Windows users have the option of using anti-aliasing. Of course, only Windows XP users will have ClearType available, but nearly all new Windows machines come with XP. > The argument about legibility of fonts can > be confused as there are two types of reading. One if word reading, > where the individual letter clarity is important, and for this verdana > wins hands down. The other is sentence reading, where word shapes are > more important as the brain doesn't process letter by letter. For this, > in my opinion, arial wins as it's condensed face creates word shapes > that are more in line with the typical narrative word shapes used in > print etc. Interesting. You really find Arial to be more readable than Verdana for body text? For my eyes, Verdana wins at small type sizes whether it's anti-aliased or not. At larger type sizes--once the stems get to be two pixels thick--I don't mind either one. Like Michael says, if we were to have very highresolution > with excellent anti-aliasing, I would choose a serif font for body > content. Unfortunately we have low resolution with no anti-alias being > the default, majority view and for this, I feel arial wins due to it's > familiar rendering of word shapes. This is also why you don't tend to > see body content in 'Avant Garde' but you do see a lot in 'helvetica' > where the screen versions of these are, loosely, 'verdana' and 'arial' > respectivley (arial was ms's rendering of helvetica for screen and > verdana was the same but optimised for ultra low resolution, > non-antialiased. > > At the end of the day this probably says it all... > > http://usability.gov/guidelines/fonts.html Ha! They *say* it doesn't matter, but they *use* Verdana!!! ;-) (Well, they use Verdana for *most* of their body copy, but they mix in a bit of Arial too--really a bad idea to switch back and forth like that.) > http://www.acm.org/sigchi/chi95/proceedings/intpost/tst_bdy.htm That's a very old paper that predates Verdana, anti-aliased text, and LCD displays. I'd tend to take anything it says with a grain of salt. > In summary.. > > "Research shows no reliable differences in reading speed or user > preferences between 10-point Times Roman, Georgia serif fonts, > Helvetica, or Verdana sans serif font" > > Although contrast did produce some differences :- > > http://hubel.sfasu.edu/research/AHNCUR.html OUCH! That paper really is painful to look at. Green on yellow? What were they thinking? > In this case it was noted that in no survey did black on white produce > the best response times. This was typically produced at lower contrasts, > although in these case the background was adjusted rather than the > foreground. On my monitor here (22" Iiyama CRT) black on white makes my > eyes water and I prefer a low contrast foreground. Perhaps I suffer from > a dyslexia type disorder, but I find 80% contrast so much more readable > than 100%. If it turns out I am the exception then I'll have to change > it but if what I suffer at 100% contrast is repeated for a large > percentage of the population then I'd be very reluctant to give in on > this point. Forgive a dumb question, but what kind of refresh rate are you running your monitor at? I remember back in the day when all I had was a 60 Hz monitor, I went to great lengths to turn down the contrast. I even recall patching the Windows 1.x/2.x display drivers to force white backgrounds to be light gray. But when I finally got up to a decent refresh rate, black on white started looking fine. And it's always looked great on LCDs. (One observation here--we just got in some new computers and monitors at Adobe, and I noticed that just about everyone who got a new monitor chose an LCD.) Naw, you're a designer (and a darn good one, despite our differences on type style ), you wouldn't have a monitor with a bad refresh rate--would you? :-) Also, just out of curiosity, what resolution do you run the 22" monitor at? Thanks! -Mike From Mike at Geary.com Wed Oct 15 02:37:19 2003 From: Mike at Geary.com (Michael Geary) Date: Wed Oct 15 02:37:24 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <050701c39248$99b32160$0a00a8c0@JASPER> Message-ID: > From: Tim Parkin > Verdana is actually a bigger font than arial, to this effect, I've > modified the font sizing to reflect this. > > http://pollenation.net/assets/public/python-fonts-arialverdana.gif Am I seeing things, or is the Verdana in that sample less tall than the Arial? It looks like the widths are about the same, and Verdana is a wider font than Arial, so it would make sense that it's less tall. Both are too small for easy reading on my display--but of course they would end up bigger when rendered at my 120 DPI setting. -Mike From tim at pollenation.net Wed Oct 15 04:10:20 2003 From: tim at pollenation.net (Tim Parkin) Date: Wed Oct 15 04:10:28 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message-ID: <007f01c392f3$cd012b60$0a00a8c0@JASPER> Michael: >> From: Tim Parkin >> Unfortunately most users (most windows and some linux) won't have >> a choice of using anti-alias. >Hmm... Just about all Windows users have the option of using anti-aliasing. >Of course, only Windows XP users will have ClearType available, but nearly >all new Windows machines come with XP. This still leaves the majority of users having no idea or not having the capability of antialiased fonts. I can't find the option of switching antialiasing on in windows 2000 or NT, and I asked a few friends to switch it on for their windows XP boxes and most couldn't find how. Those that did find it rightly pointed out that it's meant for LCD monitors. >Naw, you're a designer (and a darn good one, despite our differences on type >.style ), you wouldn't have a monitor with a bad refresh rate- >-would you? :-) 22" Colour Balanced CRT with 100Hz or 150Hz Refresh depending on res. >(One observation >here--we just got in some new computers and monitors at Adobe, and I noticed >that just about everyone who got a new monitor chose an LCD.) I guarantee any designers worth there wages will choose crt's and more than likely colour balanced Lacie monitors (typically with a calibratpr to ensure no colour drift over time) eg http://www.lacie.com/products/product.htm?id=10036 I couldn't afford one :-( I do think LCD monitors are great however, they're in the majority as far as screen sales go but remember that the majority of monitors out there are only 1024x768 or 1280x1024 so boosting font size to get multi pixel thick lines isn't an option even if most users could work out how to do it or even realise it was possible. >Also, just out of curiosity, what resolution do you run the 22" monitor at? 1600x1200 or 2048x1536 >and a darn good one, despite our differences on type >style Actually I'm an electrical engineer, I user to work in R&D modelling magnetic and electric fields for general electric. The design side started when my fellow mathmeticians didn't know what to do to market the software we'd written. I still don't think of myself as a 'designer' more of a 'web page synthesist' or 'average plagiarist'. Our designer (who originated the idea) is a different story. He's lectured in branding and design and top German universities, created websites for NatWest, Yahoo and HM the Queen and now is a design director for Ornge Communications. I won't turn the compliment down though (and we're getting along niceley this time :-) Tim From tim at pollenation.net Wed Oct 15 04:24:43 2003 From: tim at pollenation.net (Tim Parkin) Date: Wed Oct 15 04:24:43 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message-ID: <008001c392f5$cf706bc0$0a00a8c0@JASPER> Michael: >> From: Tim Parkin >> Verdana is actually a bigger font than arial, to this effect, I've >> modified the font sizing to reflect this. >> http://pollenation.net/assets/public/python-fonts-arialverdana.gif >Am I seeing things, or is the Verdana in that sample less tall than the >Arial? It looks like the widths are about the same, and Verdana is a wider >font than Arial, so it would make sense that it's less tall. No you're right.. I tried to get the fonts the same size (the size I would use if I used either one) and adjusted the line spacing to be the same so we could have an equal test of readability. I used the quantifier that the same amount of content should fit in the same area. This meant that verdana worked out smaller height. Obviously if I made the verdana lower case characters the same height as the arial lower cases, the verdana full character height would be substantially bigger than arial (by about 13%). >Both are too small for easy reading on my display--but of course they would >end up bigger when rendered at my 120 DPI setting. I understand that and promise I won't say "IT's AN IMAGE!!" ;-) Tim From roy at panix.com Wed Oct 15 07:56:36 2003 From: roy at panix.com (Roy Smith) Date: Wed Oct 15 07:56:41 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message-ID: On Wednesday, October 15, 2003, at 02:26 AM, Michael Geary wrote: >> http://hubel.sfasu.edu/research/AHNCUR.html > > OUCH! That paper really is painful to look at. Green on yellow? What > were > they thinking? They were thinking about their own data. They measured "Reaction Time" for various fonts and color combintations and found Green on Yellow to be the one that gave the fastest reaction times. I wonder about their experimental population, though. In the first paragraph of the paper, they point out that age and color-blindness are important factors, but they specifically excluded color-blind people from the cohort, as well as anybody with less than 20/20 corrected vision. They make no mention of the age distribution of the subjects they used, but if it's done in a university setting, I wouldn't be surprised if it was mostly 20-somethings (grad students hungry to make $50 for an hour of their time). Color blindness affects a significant portion of the population. According to http://www.hhmi.org/senses/b130.html, 7% of American males are red/green deficient. Their experimental technique was to present short (150 or so word) passages and ask the subject to find a given "shape" word (i.e. "square", "circle", "triangle", etc). I'm not convinced that scanning for a specific word is anything like reading for comprehension. On the other hand, for something like a reference manual, scanning for a given word may indeed be what you want to optimize. There is also another thing to consider. Even assuming that some case could be made that Green on Yellow increases reading comprehension, it is (IMHO) ugly. One of the goals of the web site is to be visually pleasing, and Green on Yellow doesn't meet that goal. From tim at pollenation.net Wed Oct 15 11:31:34 2003 From: tim at pollenation.net (Tim Parkin) Date: Wed Oct 15 11:31:33 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message-ID: <00b701c39331$70d4ca20$0a00a8c0@JASPER> >Color blindness affects a significant portion of the population. >According to http://www.hhmi.org/senses/b130.html, 7% of American males >are red/green deficient. Unfortunately when you have no other research, you try to re-evaluate the statistical evidence given in the research you do have. In this case, there was obviously a reason why they concluded that lower contrasts gave better readability results, what we have to do is say. Well there was either very little difference or there was a slight readability improvement for lower contrasts. >Their experimental technique was to present short (150 or so word) >passages and ask the subject to find a given "shape" word (i.e. >"square", "circle", "triangle", etc). I'm not convinced that scanning >for a specific word is anything like reading for comprehension. On the >other hand, for something like a reference manual, scanning for a given >word may indeed be what you want to optimize. I won't go into detail about how people read as there is an amazing amount of research out there but it's got a lot more to do with scanning word shapes than recognising letters. >There is also another thing to consider. Even assuming that some case >could be made that Green on Yellow increases reading comprehension, it >is (IMHO) ugly. One of the goals of the web site is to be visually >pleasing, and Green on Yellow doesn't meet that goal. Green and yellow is horrible as we know which is why I've not used it. However having done a little more research about scotopic sensitivity or Meares Irlen Syndrome, I've found that this supposedly affects a significant proportion of the population (between 4% and 12% depending on where you look) This isn't a subset of dyslexia and can appear on it's own (although between 4% and 10% for dyslexia). There is a also a strong link between Aspergers/Autism and with autism and aspergers rising rapidly and aspergers itself being a very common condition among programmers (geeks) I think maybe it's worth considering as long as it doesn't affect any other large group of people. I've yet to have anyone say they have difficulty reading the 80% contrast text. Maybe a large survey would be good? I'll look into it some more and maybe do some user testing when possible. Tim Tim _______________________________________________ Pydotorg-redesign mailing list Pydotorg-redesign@python.org http://mail.python.org/mailman/listinfo/pydotorg-redesign From roy at panix.com Wed Oct 15 11:48:58 2003 From: roy at panix.com (Roy Smith) Date: Wed Oct 15 11:49:05 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <00b701c39331$70d4ca20$0a00a8c0@JASPER> Message-ID: <16DCDEAE-FF27-11D7-8535-0050E405C35A@panix.com> On Wednesday, October 15, 2003, at 11:31 AM, Tim Parkin wrote: > I've yet to have anyone say they have difficulty reading the 80% > contrast text. Did you not notice these two messages? http://mail.python.org/pipermail/pydotorg-redesign/2003-October/ 000595.html http://mail.python.org/pipermail/pydotorg-redesign/2003-October/ 000600.html From tim at pollenation.net Wed Oct 15 12:00:54 2003 From: tim at pollenation.net (Tim Parkin) Date: Wed Oct 15 12:00:52 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <16DCDEAE-FF27-11D7-8535-0050E405C35A@panix.com> Message-ID: <00c701c39335$8a32f150$0a00a8c0@JASPER> Roy Smith: >On Wednesday, October 15, 2003, at 11:31 AM, Tim Parkin wrote: >> I've yet to have anyone say they have difficulty reading the 80% >> contrast text. > >Did you not notice these two messages? Yes and they didn't say that had difficulty reading the 80% contrast, they said they thought it was easier to read the 100% contrast. I think th other person ditto'd. I find cooking beans on toast easier than cooking a fry up. Doesn't mean I find fry ups difficult. I find it easier to walk than it is to run, again running isn't difficult. My point is exactly that people aren't finding it difficult to read at 80% wheras some people DO find it difficult to read at 100%. Tim From roy at panix.com Wed Oct 15 12:13:34 2003 From: roy at panix.com (Roy Smith) Date: Wed Oct 15 12:13:42 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <00c701c39335$8a32f150$0a00a8c0@JASPER> Message-ID: <86B51C86-FF2A-11D7-8535-0050E405C35A@panix.com> OK, let me be more clear. I find it difficult to read the 80% text. If you would like to conclude that a small enough number of people said they find the 80% text difficult to read that you're going to use it anyway, OK, I can live with that. But please don't dismiss my statement as having not been said because it doesn't fit with your conclusion. On Wednesday, October 15, 2003, at 12:00 PM, Tim Parkin wrote: > Roy Smith: >> On Wednesday, October 15, 2003, at 11:31 AM, Tim Parkin wrote: >>> I've yet to have anyone say they have difficulty reading the 80% >>> contrast text. >> >> Did you not notice these two messages? > Yes and they didn't say that had difficulty reading the 80% contrast, > they said they thought it was easier to read the 100% contrast. I think > th other person ditto'd. I find cooking beans on toast easier than > cooking a fry up. Doesn't mean I find fry ups difficult. I find it > easier to walk than it is to run, again running isn't difficult. My > point is exactly that people aren't finding it difficult to read at 80% > wheras some people DO find it difficult to read at 100%. > > Tim > > From tim at pollenation.net Wed Oct 15 13:00:57 2003 From: tim at pollenation.net (Tim Parkin) Date: Wed Oct 15 13:01:34 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <86B51C86-FF2A-11D7-8535-0050E405C35A@panix.com> Message-ID: <00de01c3933d$ede74270$0a00a8c0@JASPER> Roy: >OK, let me be more clear. I find it difficult to read the 80% text. > >If you would like to conclude that a small enough number of people said >they find the 80% text difficult to read that you're going to use it >anyway, OK, I can live with that. But please don't dismiss my >statement as having not been said because it doesn't fit with your >conclusion. I didn't dismiss your statement as not having been said and don't know how you think I did. I said that nobody had mentioned they had difficulty with the 80% contrast text and they hadn't. The reason I find it difficult to believe that a significant portion of the python population would have difficulty reading the 80% text is that a huge amount of the current python site is rendered at 63% contrast and some very important parts at 43% contrast. In fact I would have to assume that, if you feel it is difficult to read 80% contrast text then the whole of the web would be a pain for you to use. This is getting a little silly. I'm trying to build a website that works for the majority of people, I can honestly say that nearly every website in the world used a significant amount of content at less than 70% contrast (including the rnib, the oldie, uk government pension guides). I'll be making sure that there will be an unstyled css option that you can choose if you have serious problems reading 80% contrast text. I don't feel that this is the general problem you feel it to be. Please show me some empirical evidence that a significant proportion of the population will have problems with 80% contrast and then I can add it to the large body of evidence I've used to work out what the optimum contrast for screen readability is. I think we've stated enough opinion for to benefit the mailing list so if we need to carry on, can we do so off list. (I'll even restate now that you're welcome to your opinion about the difficulties in reading 80% text and I respect that you have this affects you personally and so, if it becomes apparent that this afflicts a significant number of python users, current or future, and the adjustments nescessary would not be detrimental to a greater number of people in the similar way or a smaller number of people in a greater way, then I'd agree that the changes would be worth making) Tim From tim at pollenation.net Wed Oct 15 13:38:37 2003 From: tim at pollenation.net (Tim Parkin) Date: Wed Oct 15 13:38:35 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Message-ID: <00f101c39343$308f1080$0a00a8c0@JASPER> Here are the last test cases for people to work out what they like the most, please post me off list with your opinions and I'll compile them :- http://pollenation.net/assets/public/arial80.gif http://pollenation.net/assets/public/arial100.gif http://pollenation.net/assets/public/verdana80.gif http://pollenation.net/assets/public/verdana100.gif Tim From tim at pollenation.net Fri Oct 17 05:54:49 2003 From: tim at pollenation.net (Tim Parkin) Date: Fri Oct 17 05:54:44 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <00f101c39343$308f1080$0a00a8c0@JASPER> Message-ID: <006a01c39494$ba50bd30$0a00a8c0@JASPER> Hi all, After a *huge* discussion about contrasts and fonts, we've come to some conclusions and some queries. Contrast wise the voting has been 50/50 between people liking 80% and 100%. A surprising number of people responded with different contrasts depending on the font. A sample demographic split 1) designers preferred 80% 2) oldies slightly preferred 100% 3) youngsters preferred 80% 4) the balance was split between people professing difficulty/tiredness reading 80% and 100% Overall I think providing an 80% (or maybe 85% as this seemed to be a demarcation point for some people) and allowing people to choose an unstyled version would be appropriate at this point. This decision is by no means set in stone as it would be trivial to change at any point in the future. As for fonts, although a lot of people liked verdana, almost as many preferred arial. We extended slightly to include various other common fonts as follows Tahoma Trebuchet MS Lucida Sans Bitstream Vera Sans Helvetica MS Sans Serif Tahoma, Trebuchet, MS Sans Serif and Helvetica were awful. This left Lucida Sans and Bitstream Vera Sans. Out of these Bitstream Vera Sans won hands down. We had a surprising discovery. On closer inspection we discovered that Bitstream Vera Sana was antialiasing at smaller sizes (which no other windows fonts we looked at did). This in combination with the quality of the font (and it's license) means we would recommend using the following order of fonts for the website "Bitstream Vera Sans", Verdana, "Lucida Sans", Geneva, Helvetica, sans-serif And I'd even go further to suggest that users of the Python site download the bitstream vera font if they want to get high quality body text. A sample of the results are here :- http://pollenation.net/assets/public/fonts/bitstream-vera-sans.png http://pollenation.net/assets/public/fonts/verdana.png http://pollenation.net/assets/public/fonts/lucida.png http://pollenation.net/assets/public/fonts/arial.png Cheers Tim From revanna at mn.rr.com Fri Oct 17 08:35:59 2003 From: revanna at mn.rr.com (Anna Ravenscroft) Date: Fri Oct 17 09:34:06 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <006a01c39494$ba50bd30$0a00a8c0@JASPER> References: <006a01c39494$ba50bd30$0a00a8c0@JASPER> Message-ID: <200310170735.59181.revanna@mn.rr.com> On Friday 17 October 2003 04:54, Tim Parkin wrote: > Hi all, > > After a *huge* discussion about contrasts and fonts, we've come to some > conclusions and some queries. > Tahoma, Trebuchet, MS Sans Serif and Helvetica were awful. This left > Lucida Sans and Bitstream Vera Sans. Out of these Bitstream Vera Sans > won hands down. We had a surprising discovery. On closer inspection we > discovered that Bitstream Vera Sana was antialiasing at smaller sizes > (which no other windows fonts we looked at did). This in combination > with the quality of the font (and it's license) means we would recommend > using the following order of fonts for the website > > "Bitstream Vera Sans", Verdana, "Lucida Sans", Geneva, Helvetica, > sans-serif > > And I'd even go further to suggest that users of the Python site > download the bitstream vera font if they want to get high quality body > text. You've done a great job Tim and I'm really impressed by your responsiveness to the community. Thank you! Anna Ravenscroft From guido at python.org Fri Oct 17 10:44:24 2003 From: guido at python.org (Guido van Rossum) Date: Fri Oct 17 10:44:32 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Your message of "Fri, 17 Oct 2003 10:54:49 BST." <006a01c39494$ba50bd30$0a00a8c0@JASPER> References: <006a01c39494$ba50bd30$0a00a8c0@JASPER> Message-ID: <200310171444.h9HEiPE06265@12-236-54-216.client.attbi.com> > As for fonts, although a lot of people liked verdana, almost as many > preferred arial. I do most of my browsing on a Linux box (Red Hat 7.3), and so do many other existing and potential Python users. Those fonts don't exist there. Therefore I'm not sure that picking fonts should be too much of an issue at this point. --Guido van Rossum (home page: http://www.python.org/~guido/) From matt at pollenation.net Fri Oct 17 11:29:02 2003 From: matt at pollenation.net (Matt Goodall) Date: Fri Oct 17 11:26:40 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310171444.h9HEiPE06265@12-236-54-216.client.attbi.com> References: <006a01c39494$ba50bd30$0a00a8c0@JASPER> <200310171444.h9HEiPE06265@12-236-54-216.client.attbi.com> Message-ID: <3F900ABE.8060500@pollenation.net> Guido van Rossum wrote: >>As for fonts, although a lot of people liked verdana, almost as many >>preferred arial. >> >> > >I do most of my browsing on a Linux box (Red Hat 7.3), and so do many >other existing and potential Python users. Those fonts don't exist >there. Therefore I'm not sure that picking fonts should be too much >of an issue at this point. > Actually, both Verdana and Arial are available for X aslong as you can use TrueType fonts. I don't know about RH7.3 specifically. http://www.gnome.org/fonts/ http://corefonts.sourceforge.net/ I work on a Debian testing/unstable box and I have many of the fonts Tim mentioned installed. They're much nicer to work with that the standard X bitmap fonts too. In any case, a bit further down that message, Tim suggested the following font order: "Bitstream Vera Sans", Verdana, "Lucida Sans", Geneva, Helvetica, sans-serif. Lucida (not Lucida Sans) is a standard X11 font, Bitstream and Verdana can be installed; Verdana and Lucida Sans are standard Windows fonts, Bitstream can be installed; Geneva is a standard Mac font; Helvetica is available on everything but Windows although I'm sure it's available. There's the sans-serif fall back at then end anyway. That list of fonts covers a lot of OSs although fonts and font sizes are a right pain on the web and it's quite difficult to cover all bases effectively. Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenationinternet.com e: matt@pollenation.net From tim at pollenation.net Fri Oct 17 12:03:37 2003 From: tim at pollenation.net (Tim Parkin) Date: Fri Oct 17 12:03:33 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310171444.h9HEiPE06265@12-236-54-216.client.attbi.com> Message-ID: <009401c394c8$3d310a60$0a00a8c0@JASPER> Guido: >> As for fonts, although a lot of people liked verdana, almost as many >> preferred arial. > >I do most of my browsing on a Linux box (Red Hat 7.3), and so do many >other existing and potential Python users. Those fonts don't exist >there. Therefore I'm not sure that picking fonts should be too much >of an issue at this point. The linux platform core fonts don't really provide a choice that people can have strong opinions about. Lucida on X11 is awful leaving only Helvetica. Other than this, many people install extra fonts on their system and, in doing so, install the windows core fonts or the bitstream vera fonts. The reason for the conversation was that these fonts present quite diverse ranges of condensed/expanded, x-heights and densities. Arial and verdana represent the extremes of both of these and are the most common fonts available to Python users (over 70% of users on Windows systems, 18% on Linux and 1% on Mac). It may seem anal but a little feedback can have a siginificant affect, if only for those users who have issues with reading. Tim From guido at python.org Fri Oct 17 12:13:45 2003 From: guido at python.org (Guido van Rossum) Date: Fri Oct 17 12:14:00 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Your message of "Fri, 17 Oct 2003 17:03:37 BST." <009401c394c8$3d310a60$0a00a8c0@JASPER> References: <009401c394c8$3d310a60$0a00a8c0@JASPER> Message-ID: <200310171613.h9HGDjG06459@12-236-54-216.client.attbi.com> > The linux platform core fonts don't really provide a choice that people > can have strong opinions about. Lucida on X11 is awful leaving only > Helvetica. Other than this, many people install extra fonts on their > system and, in doing so, install the windows core fonts or the bitstream > vera fonts. I don't believe that "many people install extra fonts." The reality is that if it's not on the dominant vendor's CD, it's not going to be on most boxes. > The reason for the conversation was that these fonts present quite > diverse ranges of condensed/expanded, x-heights and densities. Arial and > verdana represent the extremes of both of these and are the most common > fonts available to Python users (over 70% of users on Windows systems, > 18% on Linux and 1% on Mac). Are these Python stats or font availability stats? Where did you get them? > It may seem anal but a little feedback can have a siginificant > affect, if only for those users who have issues with reading. Yes, I'm glad you care about those people too. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim at pollenation.net Fri Oct 17 12:27:18 2003 From: tim at pollenation.net (Tim Parkin) Date: Fri Oct 17 12:27:13 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310171613.h9HGDjG06459@12-236-54-216.client.attbi.com> Message-ID: <009601c394cb$8f29a950$0a00a8c0@JASPER> Guido: >> The linux platform core fonts don't really provide a choice that people >> can have strong opinions about. Lucida on X11 is awful leaving only >> Helvetica. Other than this, many people install extra fonts on their >> system and, in doing so, install the windows core fonts or the >> bitstream vera fonts. >I don't believe that "many people install extra fonts." The reality >is that if it's not on the dominant vendor's CD, it's not going to be >on most boxes. Just from a survey on http://www.codestyle.org/css/font-family/sampler-UnixResults.shtml all the people I know who use unix have the windows fonts installed, most also have the bitstream fonts. This cross section is mostly programmers but a few designers and a couple of desktop office users although like many 'friend surveys' will have it's own demographic tilt. As an aside, it is intended that KDE would use Bitstream Vera range as part of it's core standard fonts. Other distributions would include Freetype, XFT2 and X Render extensions of the XFree86 project, Pango, KDE and Trolltechs QT >> The reason for the conversation was that these fonts present quite >> diverse ranges of condensed/expanded, x-heights and densities. Arial >> and verdana represent the extremes of both of these and are the most >> common fonts available to Python users (over 70% of users on Windows >> systems, 18% on Linux and 1% on Mac). >Are these Python stats or font availability stats? Where did you get >them? These are stats for september 2003 from www.python.org/wwwstats Tim From guido at python.org Fri Oct 17 12:37:13 2003 From: guido at python.org (Guido van Rossum) Date: Fri Oct 17 12:37:26 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Your message of "Fri, 17 Oct 2003 17:27:18 BST." <009601c394cb$8f29a950$0a00a8c0@JASPER> References: <009601c394cb$8f29a950$0a00a8c0@JASPER> Message-ID: <200310171637.h9HGbDv06546@12-236-54-216.client.attbi.com> > >I don't believe that "many people install extra fonts." The reality > >is that if it's not on the dominant vendor's CD, it's not going to be > >on most boxes. > > Just from a survey on > > http://www.codestyle.org/css/font-family/sampler-UnixResults.shtml > > all the people I know who use unix have the windows fonts installed, > most also have the bitstream fonts. This cross section is mostly > programmers but a few designers and a couple of desktop office users > although like many 'friend surveys' will have it's own demographic tilt. Trust me on this one. We're geeks. Inevitably, our friends are mostly geeks. This is *not* a representative survey. :-) > As an aside, it is intended that KDE would use Bitstream Vera range as > part of it's core standard fonts. Other distributions would include > Freetype, XFT2 and X Render extensions of the XFree86 project, Pango, > KDE and Trolltechs QT For most of my colleagues here at Elemental Security, it won't exist until it comes from a Red Hat CD. The same is true for our enterprise customers. > >> The reason for the conversation was that these fonts present quite > >> diverse ranges of condensed/expanded, x-heights and densities. Arial > >> and verdana represent the extremes of both of these and are the most > >> common fonts available to Python users (over 70% of users on Windows > >> systems, 18% on Linux and 1% on Mac). > >Are these Python stats or font availability stats? Where did you get > >them? > > These are stats for september 2003 from www.python.org/wwwstats I was afraid so. That's 70% Windows *downloads*, not *users*. Since Python is pre-installed on *all* Linux distros (not just Red Hat :-), Linux users don't have to download anythign in order to use Python. (The same will be true for Mac OS X Panther, but that's not out yet.) --Guido van Rossum (home page: http://www.python.org/~guido/) From skip at pobox.com Fri Oct 17 12:52:49 2003 From: skip at pobox.com (Skip Montanaro) Date: Fri Oct 17 12:53:06 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310171637.h9HGbDv06546@12-236-54-216.client.attbi.com> References: <009601c394cb$8f29a950$0a00a8c0@JASPER> <200310171637.h9HGbDv06546@12-236-54-216.client.attbi.com> Message-ID: <16272.7777.708131.314119@montanaro.dyndns.org> Guido> (The same will be true for Mac OS X Panther, but that's not out Guido> yet.) Actually, it's also true of Mac OS X Jaguar (10.2). /usr/bin/python is 2.2. Skip From guido at python.org Fri Oct 17 12:59:14 2003 From: guido at python.org (Guido van Rossum) Date: Fri Oct 17 12:59:25 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Your message of "Fri, 17 Oct 2003 11:52:49 CDT." <16272.7777.708131.314119@montanaro.dyndns.org> References: <009601c394cb$8f29a950$0a00a8c0@JASPER> <200310171637.h9HGbDv06546@12-236-54-216.client.attbi.com> <16272.7777.708131.314119@montanaro.dyndns.org> Message-ID: <200310171659.h9HGxEo06628@12-236-54-216.client.attbi.com> > Guido> (The same will be true for Mac OS X Panther, but that's not out > Guido> yet.) > > Actually, it's also true of Mac OS X Jaguar (10.2). /usr/bin/python is 2.2. Yes, but that's not a framework build (or something -- it's not quite as complete as what Panther will have; Jack and Just know the details). --Guido van Rossum (home page: http://www.python.org/~guido/) From tim at pollenation.net Fri Oct 17 13:09:25 2003 From: tim at pollenation.net (Tim Parkin) Date: Fri Oct 17 13:09:15 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <200310171637.h9HGbDv06546@12-236-54-216.client.attbi.com> Message-ID: <009f01c394d1$6e91a3e0$0a00a8c0@JASPER> Guido: >> Just from a survey on >> http://www.codestyle.org/css/font-family/sampler-UnixResults.shtml >trust me on this one. We're geeks. Inevitably, our friends are >mostly geeks. This is *not* a representative survey. :-) Almost all my Python using friends are geeks too, proudly so. My old boss wasn't a geek but he kept complaining that his linux pc wouldn't show websites like his laptop did so we installed ttf windows fonts. I would imagine a lot of Python users would be geeks too, whether or not they'd like to be called that is a different matter :-) The survey I used, though flawed, does seem to be good enough to show general trends and does reflect the experience of myself and that of a few of my colleagues. Some environments have strict guidelines on platform setup (we weren't allowed to install new fonts at a dot com I worked for, explaining I was designing for a client who wouldn't like us to change there logo finally got round that one). >> >Are these Python stats or font availability stats? Where did you get >> >them? >> >> These are stats for september 2003 from www.python.org/wwwstats > >I was afraid so. That's 70% Windows *downloads*, not *users*. Since >Python is pre-installed on *all* Linux distros (not just Red Hat :-), >Linux users don't have to download anythign in order to use Python. >(The same will be true for Mac OS X Panther, but that's not out yet.) The stats I picked of the site weren't for downloads, they were for general browsing. I was presuming that this would be the best source of information about what the balance of browser/operating system support for the new site would be. I'd love to know if there are any other stats available, actually that raises a question I was going to ask a while back. Can I get access to the raw 'combined' logs for the python server. I know they'd be huge but I've got some excellent data mining software that I could use to get some good information on usage. I think the conversation about fonts was pretty much over anyway, any further feedback was coming directly back to me, the last post was just a summary of findings. We could always move back to logos and straplines ;-) Tim From roy at panix.com Fri Oct 17 13:16:56 2003 From: roy at panix.com (Roy Smith) Date: Fri Oct 17 13:17:03 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: <009601c394cb$8f29a950$0a00a8c0@JASPER> Message-ID: On Friday, October 17, 2003, at 12:27 PM, Tim Parkin wrote: > all the people I know who use unix have the windows fonts installed, > most also have the bitstream fonts. Just another data point... At home I've got Mac/OSX and RedHat 8.0. At work I've got a variety of Linux and Solaris systems. Heck, I've even got a windows laptop. None of the above have any special fonts installed (unless they got installed by default along with an application). I install stuff I need to do my work. Databases, new versions of python or gcc, etc. But, fonts are just something I expect to be there. At this point in my life (remember, I'm the guy with the 40-something eyeballs :-)), when it comes to computers, I want a tool, not a hobby. For what it's worth, I checked my two home boxes. OSX comes with Verdana and Ariel, RedHat 8.0 doesn't. From guido at python.org Fri Oct 17 13:19:14 2003 From: guido at python.org (Guido van Rossum) Date: Fri Oct 17 13:19:21 2003 Subject: [Pydotorg-redesign] Draft HTML for redesign proposal In-Reply-To: Your message of "Fri, 17 Oct 2003 18:09:25 BST." <009f01c394d1$6e91a3e0$0a00a8c0@JASPER> References: <009f01c394d1$6e91a3e0$0a00a8c0@JASPER> Message-ID: <200310171719.h9HHJEg06701@12-236-54-216.client.attbi.com> > Almost all my Python using friends are geeks too, proudly so. My old > boss wasn't a geek but he kept complaining that his linux pc wouldn't > show websites like his laptop did so we installed ttf windows fonts. I > would imagine a lot of Python users would be geeks too, whether or not > they'd like to be called that is a different matter :-) > > The survey I used, though flawed, does seem to be good enough to show > general trends and does reflect the experience of myself and that of a > few of my colleagues. Some environments have strict guidelines on > platform setup (we weren't allowed to install new fonts at a dot com I > worked for, explaining I was designing for a client who wouldn't like us > to change there logo finally got round that one). Well that argument definitely won't fly for the casual visitors of python.org whome we want to please (if I recall the "goals" discussion on the marketing list correctly). > >> >Are these Python stats or font availability stats? Where did you > get > >> >them? > >> > >> These are stats for september 2003 from www.python.org/wwwstats > > > >I was afraid so. That's 70% Windows *downloads*, not *users*. Since > >Python is pre-installed on *all* Linux distros (not just Red Hat :-), > >Linux users don't have to download anythign in order to use Python. > >(The same will be true for Mac OS X Panther, but that's not out yet.) > > The stats I picked of the site weren't for downloads, they were for > general browsing. I was presuming that this would be the best source of > information about what the balance of browser/operating system support > for the new site would be. Yes, probably. (Interesting that the stats match the 70% download stats for Windows.) > I'd love to know if there are any other stats > available, actually that raises a question I was going to ask a while > back. Can I get access to the raw 'combined' logs for the python server. > I know they'd be huge but I've got some excellent data mining software > that I could use to get some good information on usage. I suggest you write to Thomas Wouters (thomas at xs4all.net). --Guido van Rossum (home page: http://www.python.org/~guido/) From skip at pobox.com Thu Oct 23 15:37:01 2003 From: skip at pobox.com (Skip Montanaro) Date: Thu Oct 23 15:37:24 2003 Subject: [Pydotorg-redesign] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Doc python-docs.txt, 1.2, 1.3 In-Reply-To: <16280.9038.338759.771647@grendel.zope.com> References: <16279.60447.29714.759275@montanaro.dyndns.org> <16280.9038.338759.771647@grendel.zope.com> Message-ID: <16280.11741.740064.72268@montanaro.dyndns.org> [... regarding all the "what is this python crap on my new computer?" questions which pour into (webmaster|python-help|docs)@python.org ...] >> And I thought only webmaster@python.org got asked that question all >> the time. Does it get asked at other addresses as well? I don't >> recall ever seeing it on python-list. Fred> I wouldn't expect to see it on python-list. Aren't the people who Fred> ask generally people who *aren't* in the Python community? Sure enough. Fred> They're going to look for the easiest ways to ask, so that Fred> generally means googling for "Python" and using whatever contact Fred> address is on one of the first pages they find. The first two Fred> Google's showing me now are: Fred> http://www.python.org/ ( webmaster at python.org ) Fred> http://www.python.org/doc/ ( docs at python.org ) Yes, but that doesn't quite explain why python-help gets so many of these questions, as Raymond indicated in his post. I think they'd most frequently get to http://www.python.org/community/lists.html then ignore several other mailing lists (python-list, python-dev, python-checkins, patches, marketing-python and tutor) before deciding that python-help was what they wanted. I can understand how intelligent people would skip all those lists, but I would also expect the other lists to all get some posts. If they decide python-help is the place to be, they should be slightly discouraged from posting by this text: Using it is much preferred to sending mail directly to Guido or some other individual, but less preferable than posting to comp.lang.python. Then again, maybe not. Python-help does appear near the top of http://www.python.org/Help.html (which is reachable via the "Help" link at the top of the home page) and there are no discouraging words there to direct people other places. Oh well, it was more out of curiosity than anything else that I asked. I suppose it implies something about the way the site is structured, and is thus a more appropriate topic for the pydotorg-redesign list (to which I've cc'd this - and removed python-dev). Skip From skip at pobox.com Mon Oct 27 12:53:54 2003 From: skip at pobox.com (Skip Montanaro) Date: Mon Oct 27 12:54:01 2003 Subject: [Pydotorg-redesign] user control Message-ID: <16285.23474.269840.40195@montanaro.dyndns.org> (now a bit out-of-date - originally sent 10/16) With all this discussion about font sizes and fg/bg contrast I wanted to make sure I wasn't missing something. Will I still be able to control font size to some degree with my browser (e.g., grow/shrink the displayed fonts using Cmd +/- on Safari)? Skip From fdrake at acm.org Mon Oct 27 13:18:25 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Oct 27 13:18:36 2003 Subject: [Pydotorg-redesign] user control In-Reply-To: <16285.23474.269840.40195@montanaro.dyndns.org> References: <16285.23474.269840.40195@montanaro.dyndns.org> Message-ID: <16285.24945.527589.197268@grendel.zope.com> Skip Montanaro writes: > With all this discussion about font sizes and fg/bg contrast I wanted to > make sure I wasn't missing something. Will I still be able to control font > size to some degree with my browser (e.g., grow/shrink the displayed fonts > using Cmd +/- on Safari)? If not, that should be considered a bug in the site. All font size manipulation by the site should be done using relative font sizes, so your browser should be able to resize however it wants to. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From matt at pollenation.net Mon Oct 27 14:13:57 2003 From: matt at pollenation.net (Matt Goodall) Date: Mon Oct 27 14:11:39 2003 Subject: [Pydotorg-redesign] user control In-Reply-To: <16285.24945.527589.197268@grendel.zope.com> References: <16285.23474.269840.40195@montanaro.dyndns.org> <16285.24945.527589.197268@grendel.zope.com> Message-ID: <3F9D6E75.7080603@pollenation.net> Fred L. Drake, Jr. wrote: >Skip Montanaro writes: > > With all this discussion about font sizes and fg/bg contrast I wanted to > > make sure I wasn't missing something. Will I still be able to control font > > size to some degree with my browser (e.g., grow/shrink the displayed fonts > > using Cmd +/- on Safari)? > >If not, that should be considered a bug in the site. All font size >manipulation by the site should be done using relative font sizes, so >your browser should be able to resize however it wants to. > Have no fear, I would never allow Tim to produce such an atrocity ;-). I use Mozilla (on Linux) configured to use my preferred font and font size and to ignore document specified fonts. http://pollenation.net/assets/public/draft-oct14.html, which I think is still the latest HTML mockup/demo, works wonderfully. Both the navigation and body text is rendered in my font and Ctrl +/- works very well. When I allow the page to override my font settings Ctrl +/- works just as well, only it uses the page specified fonts and sizes to start with. However, please try with Safari and other browsers. If it doesn't work correctly then post a bug report here. IIRC, Tim was also planning on providing a selection of stylesheets for different types of user. In fact, he's already done a couple to prove the concept. If your browser allows you to select an alternative stylesheet (View/Use Style on Mozilla) there are "Basic Page Style" and "large text" options. Also, you must check out the printed version of that page - it's fantastic! - note the complete removal of all navigation and the magical appearance of the "module" URL where the normal page contains a link. Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt@pollenation.net From skip at pobox.com Mon Oct 27 14:20:50 2003 From: skip at pobox.com (Skip Montanaro) Date: Mon Oct 27 14:21:09 2003 Subject: [Pydotorg-redesign] user control In-Reply-To: <3F9D6E75.7080603@pollenation.net> References: <16285.23474.269840.40195@montanaro.dyndns.org> <16285.24945.527589.197268@grendel.zope.com> <3F9D6E75.7080603@pollenation.net> Message-ID: <16285.28690.933655.683011@montanaro.dyndns.org> Matt> http://pollenation.net/assets/public/draft-oct14.html Matt> works wonderfully [with mozilla]. Matt> However, please try with Safari and other browsers. Works there as well. In addition Cmd- and Cmd+ resize the Google and Python logos. Skip From tim at pollenation.net Wed Oct 29 04:20:03 2003 From: tim at pollenation.net (Tim Parkin) Date: Wed Oct 29 04:20:09 2003 Subject: [Pydotorg-redesign] user control In-Reply-To: <16285.28690.933655.683011@montanaro.dyndns.org> References: <16285.23474.269840.40195@montanaro.dyndns.org> <16285.24945.527589.197268@grendel.zope.com> <3F9D6E75.7080603@pollenation.net> <16285.28690.933655.683011@montanaro.dyndns.org> Message-ID: <3F9F8643.2080006@pollenation.net> Skip Montanaro wrote: > Matt> http://pollenation.net/assets/public/draft-oct14.html > Matt> works wonderfully [with mozilla]. > Matt> However, please try with Safari and other browsers. > >Works there as well. In addition Cmd- and Cmd+ resize the Google and Python >logos. > > I've gone through quite a bit of pain to ensure that the site will resize intelligently up to a realistic point (beyond a certain point, headers start to overlap, lhs menu takes over the page, etc). On top of this, I've only recently gone through an extensive debug session with David Mertz who highlighted that setting a min font size of 16 (in fact any min font size above 13) was making the lhs menu's pop out of their boxes. (see bottom for reasons and solution After rejigging the site, it also now works for most realistic min font sizes . In addition, there will be a few alternate stylesheets, see the following for an example http://pollenation.net/assets/public/collapsetest/ These stylesheets currently work to make the font bigger and/or hide the menu (hiding menu will propbably be a tool only available at the document level and from the document sub-menu). oh.. the latest version including the fixes for min font size is... http://pollenation.net/assets/public/draft-oct23.html I've been working on the design for the home page which so far is going quite well. However, we're now very very busy at work and with no let up til the start of december. At this point I'll be getting married and going away on honeymoon for two weeks and won't be back until dec 24th. As you can imagine this doesn't leave much time for working on the Python redesign. I will be getting back to it over the christmas period however and will probably have a completed proposal by mid-end Jan. In the meantime, I'll leave you with a sneak preview of the home page. Excuse the rough edges as this is only a proof of concept for the 'stretchy images. http://pollenation.net/assets/public/draft-oct19.html Cheers all.... Tim PROBLEM & SOLUTION --------------------------- The problem was Mozilla's parent divs not inheriting the adjusted font sizes if the parent was normally an inline element (an a tag in this case). The solution was to add extra widths in. This raised another problem in that mozilla bases it's em widths on the base font size for whatever div you are working on. This is ok until a min font size is set. eg if you had two divs #div1 { width:60em; font-size:100%; } #div2 { width:100em; font-size:60%; } although both of these would be the same width normally, only the bottom one would get scaled if you set a minimum font size.