From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1Eexct-00046k-Sf for garchives@archives.gentoo.org; Wed, 23 Nov 2005 16:37:44 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jANGbO4p005311; Wed, 23 Nov 2005 16:37:24 GMT Received: from callisto.cs.kun.nl (callisto.cs.kun.nl [131.174.33.75]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jANGbOUr015742 for ; Wed, 23 Nov 2005 16:37:24 GMT Received: from localhost (localhost [127.0.0.1]) by callisto.cs.kun.nl (Postfix) with ESMTP id 73F532E8216 for ; Wed, 23 Nov 2005 17:37:59 +0100 (CET) From: Paul de Vrieze To: www-redesign@lists.gentoo.org Subject: Re: [www-redesign] Update of http://wwwredesign.gentoo.org Date: Wed, 23 Nov 2005 17:37:52 +0100 User-Agent: KMail/1.8.92 References: <001701c5f03b$a9ea52d0$6402a8c0@vega> In-Reply-To: <001701c5f03b$a9ea52d0$6402a8c0@vega> X-Face: #Lb+'V@sGJ;ptgo5}V"W+5OCoo{LZv;bh,s,`WKLi/J)ed1_$0;6X<=?utf-8?q?700LVV/=3BLqPhiDP=5E=0A=09=27f=5Dfnv?=@%6M8\'HR1t=aFx;ePfp{ZQoBe+e)JOQ8T5*(_;mHY+cltLGq<;@$Y,=?utf-8?q?O=5C=24=0A=09Tm=23G6M?=,g![Q62J{na*S9d;R[^8pc%u\aiLqU@`kJtYl"^6pxdW Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: www-redesign@gentoo.org Reply-to: www-redesign@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4721641.7Ahz1tJ7af"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200511231737.58986.pauldv@gentoo.org> X-Archives-Salt: 9b282f21-0ab4-4352-bb42-152f052a4c9b X-Archives-Hash: 11a79b2a736bc8944c13384388790da7 --nextPart4721641.7Ahz1tJ7af Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 23 November 2005 15:39, Aaron Shi wrote: > > I should have said that the last update was not complete as > > far as design was concerned. I was mainly looking for > > accessibility and rendering issues on as many browsers/OS's > > as possible. I got that feedback and fixed the issues that > > came up. I also implemented the rest of the design so it > > should now be more visually appealing and better match Aarons > > reference design. I took into consideration all of the > > suggestions that were submitted and now ask for additional > > feedback to ensure that my changes didn't introduce any > > additional rendering/accessibility bugs and that the design > > is acceptable to as many people as possible. > > > > If there are no more outstanding issues reported I will > > submit this current layout for approval. > > Sorry, but this looks worse. The colors (other than what's in the > original graphics) are way off. I'm going make a wild guess that an > uncalibrated LCD is being used to view the site. Many panels are not > capable of the full 16.7 million range and uses dithering techniques to > emulate the other colors. So in reality, the colors when viewed on > proper LCD and CRTs are slightly off (but all the "off-ness" in colors > adds up and the combined effect is quite obvious). I agree, the reference still looks better. And indeed an LCD is not really= =20 a good judge of colors. > > > Any issues with the > > infinity symbol should have been addressed a year ago. > > Amen. Could you anyway make a version where the infinity symbol is made by=20 clipping two "oh"'s together. I would like to see how they visually=20 compare. I find the infinity symbol to be dissonant towards the "gent"=20 letters. > The reference I made, after listening to comments on the forums, etc., > is what I believe an improvement to the original submission. However, > the live site right now, while the backend is perhaps implemented with > improvements, the frontend (the design) is a deterioration. I > understand there are technical limitations to what's possible. I've > worked with CMS's and combining backend with frontend etc., but it's > about injecting data into the design; not the other way around. This > is usually done after reference templates are done and "locked," and > the final output of the injection effort is usually very close to the > references templates. The Gentoo templating system seems to be such a > way that everyone working on this project, Curtis and myself included, > have to work contrary to normal processes in order to force things to > work. At the time, the design was approved understanding that it would be a=20 guide towards the final looks. Not an absolute this and nothing else.=20 =46urther the designer (Aaron) was encouraged to participate in=20 implementing his design. Partly to make small improvements, and to fill=20 in the design where it was missing. As such I fully believe that the new=20 reference could be used as basis. > If you look at all of the professionally designed sites on the > Internet, I bet they're using a font size similar to what's in the > reference templates. The reality is, most people are _not_ on 1600x1200 > resolutions and the font used in the live site is just plain huge. I'm > using 1280x1024 and it's still gigantic! (All of my browsers' font zoom > is default.) Even mozilla.org's fonts are about half the size of what > we're using. Looking at other "modern" open source sites, freebsd > (nice facelift), fedora, etc. none of them are using fonts as large as > ours, not even close. The browser's zoom capability is really a > double-edged sword... > > That said, all the "reading/content" fonts are controlled using 1 value > in global.css, change font-size in body and the whole site will change. > The "reading" font I'm referring to is specified for the real > substance on the page that people want to read, i.e. the content. The > philosophy is that content "reading" fonts can be larger or flexible > (hence I put in the font-size adjuster so people can increase/decrease > the content font size and have that remembered in a cookie). However, > fonts that are an inherent part of design should be congruent with the > design itself. I agree, I think that the main text size should be taken from the browser=20 settings. Those are normally reasonable (smaller than wwwredesign) AND=20 what the user prefers. The text zoom function is just a kludge around=20 sites that have been wrongly designed. The font size of menu items could=20 be set, but body size shouldn't. > > Green vs. yellow: > http://www.aaronshi.com/gentoo/problems/greenvsyellow.png > > Pea Green (top) vs. Live Site Green (bottom): > http://www.aaronshi.com/gentoo/problems/greentest.png The bottom one > hurts doesn't it? Yes it does. > > > The "Locator" would require rewrites of not only the XSL but also the > > actual xml files and is outside the scope of this project. > > Touching any > > xml content file is strictly off limits, all existing xml should be > > backwards compatible with the new design. This point is not > > debatable. > > Use of a database would make this task easier while allowing > > backwards > > compatibility but it will have to wait for a future update to > > the site > > to be implemented. > > Fair enough. I think the design should be made to include a locator when given in the=20 page. I would think something like adding an optional "" tag to=20 the DTD. The DTD would then query the parent for it's parent=20 (recursively) and display that parent, and then this one. (Creating the=20 path). It would be compatible with existing pages, while still allowing=20 forward progress. I see no reason why it would be impossible to change=20 the DTD as long as current pages are still supported. > > > The contents of the uppermost menu are to sites that are outside the > > www.gentoo.org website. They will stay in this location. They > > are green > > to contrast with the purple background to ensure that colorblind and > > other visually impaired people can see it. Green is the compliment to > > purple so I am baffled that people think the combination is not > > attractive. In Aarons preview the light purple color of these > > links is > > not visible to color blind individuals thus it is unacceptable. This > > color will not change. > > The contrast between the purples should be enough, the lighter purple > is roughly 2x brighter than the darker purple. The green makes it > standout too much, especially the live site green. It's distracting.=20 > Originally, this element was intended as an indicator (to complement > the locator) of the Gentoo network site a user is on. If we come back > to asking the fundamental questions, by looking at any given page do I > know where I am? After browsing around, am I still on the same sub > site? Or have I gone from main to planet to bugs to ...? I understand > this is a lost cause, but it's good to know that a "locator" of some > sort is being considered for the future. Breadcrumbs have been a rather > standard feature since the late 90s. And I see no reason to not implement them (as above). > > Graphics should be implemented in the CSS as much as possible to aid > > future maintenance (the xsl templates are huge and not easy > > to maintain. > > The least amount of editing of these files as possible is one of the > > major goals). In text browsers that can handle graphics but don't > > support CSS the upper left logo (which is a background image > > so it can > > be put in the css) will not appear but will leave space for > > the missing > > background image. I can't figure out a way around this. If you have a > > suggestion I would appreciate it. > > I tried to do everything in CSS, which is why having a printable > version of the site > (http://www.aaronshi.com/gentoo/guidepageprint.html) is easy. Nothing > is changed. No CSS files are changed. The _only_ difference is that > the print CSS file is added to the end of the cascade, so that the > print CSS rules overrides certain elements we want to redefine for > print. Basically, with the logically structured HTML, we can change the > design a whole lot without touching the HTML simply by manipulating the > CSS. I.e. I had in mind different themes and elements for xmas, > halloween, etc. and only an extra CSS file is required to add the > changes (without touching the existing CSS files). Besides the fact that I agree with this, it is also the way that things=20 will go in the future as propagated by the W3C. And indeed, css should be=20 used predominantly for the design. > > > Horizontal scrolling of the entire page when a code listing is wider > > than the page only happens in IE. All other browsers > > understand the CSS > > scroll:auto tag and will only scroll the actual code listing. > > The same > > applies to inline images within the page contents. IE is broken but I > > did everything I could to make it behave the same as other browsers. > > This is one issue that IE is simply broken on and there is > > nothing I can > > do to fix that. Javascript fixes are available but the use of > > Javascript > > is strictly forbidden. Javascript is not debatable. > > I think this problem was fixed in my reference page, some googling > uncovered the solution (http://www.aaronshi.com/gentoo/guidepage.html). > If in IE, scale down the window, the scroll bars will automatically > appear on the code listing when necessary. It behaves identically as > in Firefox etc. I'm not too sure what you mean by the inline image > problem, can you explain (maybe a demo is easier)? > I see no reason why javascript could not be used to circumvent the=20 behaviour of certain (enumerated) broken browsers. Normally working=20 browsers do not use the javascript and would look exactly the same with=20 or without javascript enabled. The broken browser looks properly (or as=20 proper as possible with the broken behaviour) though. > > The site is not XHTML it is HTML-4.01 Transitional and it > > passes the w3c > > validator. Manually overriding HTML-4.01 Transitional in the w3c > > validator is not required and any errors that it reports if > > you do this > > will not be addressed. If you can come up with a good > > technical reason > > why doing this would benefit anyone I will address it. Why not implement either html-4.01 strict, xhtml-1.0 (transitional or=20 strict) or even xhtml-1.1. All are compatible with browsers that=20 understand 4.01 transitional. If possible xhtml-1.1 would encertain that=20 the layout and structure of the pages are properly separated. > > The differences between the two specs (at least HTML 4.01 vs. XHTML > 1.0; -- 1.1+ is another story) are not really that significant. I > don't see why we can't switch to XHTML unless there are inherent coding > in the system that we can't mess with. I don't see it either. I also don't see why transitional is needed when we= =20 have such a tightly controlled source language. None of the pages=20 actually contains actual html, so having the stylesheet support xhtml-1.1=20 (has no transitional version) should be straightforward. > > > Navigation and useability studies are beyond my scope. These issues > > should have been addressed a year ago. > > I tried to address those issues (with pages of explainations etc.), but > my suggestions were completely ignored. Hence, I won't say anymore > about this. Please still give your suggestions. I think it is important they are=20 properly performed. > > > The left hand navigation column is dead. No amount of beating > > this dead > > horse will resurrect it. The jumppads will remain at the bottom and > > appear on all non-documentation pages so that those links are > > accessible > > as much as possible. Don't be so thickheaded. > > We can also make additional jump pads if necessary. I only did 3 for > the sample. > > > In Aarons preview the search box and the ads column are placed with a > > Position:absolute and has it's size set. At resolutions below 800x600 > > this makes the ads overlap the content and the search box overlap the > > box to the left on every browser. When content is scarce the > > ads overlap > > the footer. This is not fixable given the current state of > > css support > > in the various browsers. After many many many long hours of > > research and > > experimentation I decided that we would have to resort to a table for > > the ads column and include the search (now donate) box within the div > > that contains the four purple boxes with a % width to fix > > this issue. I > > lowered the % width of the donate box and increased the > > others to bring > > it more inline with Aarons original design. It's not perfect but it's > > close enough. > > It looks fine at 700x500. Even smaller at 640x480, it's still ok.=20 > This is because there's a min-width rule specified for the content > area. Modern browsers should respect this rule (IE doesn't, but > Firefox, etc. and Opera are fine). Actually it is easy to even make IE do such a thing by introducing a=20 "strut" and having a proper overflow behaviour. A strut is an invisible=20 element that has the minimum with required and as such forces that this=20 is the minimum. > http://www.aaronshi.com/gentoo/problems/700x500ref.png > > Speaking of lower resolutions, the author credits takes up the entire > screen (http://www.aaronshi.com/gentoo/problems/700x500live.png). I > originally thought about doing it this way, but after trying with that > same author list it didn't seem right. Hence the design was reworked > to use the side bar, as old Gentoo site does, for author listings. It > seems to work better. Probably right. I think that some flexibility is good. > The side bar overlapping the footer when there is minimal content is a > known issue. It's not as if we have the handbook in the footer. ;)=20 > The alternative is to have the footer block the bottom of the side bar, > but the implementation is much more convoluted that it's not worth it.=20 > On the other hand, the side bar in the live site stops abruptly if the > content is long. If content is the main focus, does it make sense to > show a whole page's worth of white space just so the sidebar can > display entirely? > > > Accessibilty guidelines say that all text links should be > > underlined. I > > made an exception for the grey menu bar for aesthetic > > purposes but will > > not make an exception for any other links. > > My thoughts exactly, although the author list is missing the > underlines. I think that the browser preference should be used. Most browsers=20 underline by default. But if users prefer links not to be underlined, why=20 not respect those users. > In my own site logs, Netscape 4 still out numbers IE5 for Mac (go > figure). It's a simple cost/benefit analysis and in the end is it worth > it to support such non-standard-compliant browsers? What message are > we sending? --- we try to accommodate a few at the cost of the > majority? That's why one should use javascript to enable hacks to work around such=20 broken browsers. Most users get the full behaviour, and the broken=20 browser gets slightly degraded, but controlled behaviour. > > Background should remain white, it's much easier to work with. To make > it easier on the eyes, just lighten up the text a little (i.e. so it's > not black on white which is high contrast but high contrast also > strains the eyes after prolonged reading). I used #515151, which is > 81% gray. The other point for not having colored backgrounds is that > it looks particularly bad on laptops running on battery. When the > screen dims when it's not on AC, it's all over. Also I find that the purple background on the live site makes the site too= =20 purple. > > *all extraneous information and decorative news headers were removed > > from the front page to help readability and to bring focus to the > > information. This includes the cow image and text. > > Overwhelming amounts > > of information on the front page should no longer be a problem. This > > also brings the jumppads closer to the top so new users will > > be better > > able to spot them. > > If decoration is used sparingly, it's great. If we want to be purely > information based, and ignore appearance and marketing, we could go > text only. > I agree, we should use the decoration where not superfluous and where=20 there is space. If the decoration causes space issues, it can be=20 reconsidered. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart4721641.7Ahz1tJ7af Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) iD8DBQBDhJrmbKx5DBjWFdsRAtIvAJ9DRFY+zY3t/a/5JfVeZIypN1IeZwCg04bk qF0RIHY2HNbHTNnVZJRY13A= =h/Jd -----END PGP SIGNATURE----- --nextPart4721641.7Ahz1tJ7af-- -- www-redesign@gentoo.org mailing list