hi i got a few mails from people who checked the rc1. a few of the issues we knew already. please find enclosed a digested feeback text file which at least discusses some issues i think we should/could look at when the next version rolls out (:-)). really they are not ISSUES, but more NICETOHAVES, maybe we can have such a file at perl.apache.org/NICETOHAVES ?
./allan
[Tom snipped] Those are among the most attractive web pages I've ever seen. Nice work. I have noted (and appreciate) the rules which guided your work. I subscribe to the exact same rules, as it happens. As far as fonts, I question the rationale in specifying a size of 1em for the body. Wouldn't browsers assume that? And personally, I wouldn't suggest named fonts at all. My Helvetica, for example, is a PostScript version which renders web pages very poorly. I would prefer that my browser's default sans-serif font be used instead. Many of your visitors will be using Lynx, I expect. (I, for one, am always using Lynx when I am configuring a server and need to consult the documentation.) You might want to direct some effort into making the pages look a little prettier for them. [end Tom snipped] ************************ [Terje double snipped] That's ok. If you are getting ready for release, now is a good time to start tentative planning for the next major overhaul. I'll make my comments in that light. 1) Please, *please*, reconsider the design decision that put the navigation(-ish) boxes on the left side of the page! > by navigation(-ish) boxes, do you mean the prev|up|next currently on >the > righthand side of the screen? I mean the "Slashbox"-style boxes down the left edge of the page. They simply eat up too much of the valuable left margin of the page. The margin in print/layout works because it's _empty_ space; it creates some air on the left of the main body text. When you put "stuff" there you create a distraction which intereferes when you try to read the main body text. Placing those boxes on the right side takes care of this problem as well as degrading more gracefully when printed or viewed on low-resolution screens. > we want to produce a seperate print style sheet, that hopefully will take > care of what you describe above Separate stylesheets for different media are a good idea, yes. I would prefer to move those boxes for on-screen presentation too though, for the reasons above. If you feel very strongly about keeping those boxes where they are, you may consider providing an alternate stylesheet that puts the boxes on the right (Mozilla-based browsers lets you choose which of several alternate stylesheets to use from a menu). 2) Disregard Netscape 4.x *completely* as it'll only give you false ideas of what "works" and what doesn't. Hide *all* CSS from it with <style>@import foo.css</style> or some such trick and make sure only the _content_ gets through even if it's ugly as all hell. 3) State explicitly somewhere that it is _acceptable_ if the _presentation_ is less then perfect in non-conforming browsers so long as the _content_ is always available. It will save a lot of pain later if you explicitly state, as part of your design goals and criteria, that it's _ok_ to have some small display glitches in less then perfect CSS implementations as long as the content comes through allright. Graphic designers tend to scream bloody murder at such glitches (because they really are bloody ugly, and badly ruins the aestetics), but the big mistake is to then try to fix them with wide-reaching workarounds that lowers the overall technical quality of the code. If it's been decided before-hand that these are acceptable, people tend to have a more realistic attitude to what constitutes acceptable tradeoffs between technical purity and practical hackery. For instance, your choice of the Transitional DOCTYPE is probably due to a percieved need for "Quirks" mode in browsers to work around poor standards support in other browsers. I've found that by setting the goals realistically, I can dispense with such hackery and use a Strict DOCTYPE and still achieve good results. I'd point to <URL:http://validator.w3.org:8001/> as an example, but I fear I'm too little skilled as a graphic designer to be able to impress any such with my work. :-) The site should however be sufficient to indicate that it _is_ possible to find a marriage of the two opposites that satisfies both if only you find the right balance in your compromises. A skilled graphic designer would have been able to improve those aspects of the site rather much and still allow me my fanatical adherence to standards and good practices. 4) Perform a WCAG review of the site! This *will* show you major problems. I can almost guarantee you that you will want to stick your head in the sand, mutter "nahnahnahnahICan'tHearYou!nahnahnah", and pretend they do not exist. Please don't. Accesibility is important and the only reason you're in trouble now is because you didn't take this into account from the start. Try <URL:http://valet.webthing.com/access/> for example. The form defaults to only performing Normalization of the code. You need to select a test suite before it will give you any results. Try checking your pages with "WCAG-AAA" selected. It will turn up a *lot* of issues. Fixing some of them will be a pain, and some can't be fixed without major restructuring on your part. Don't let that discourage you, however. Start off by picking the low-hanging fruit; as a little accessability is better then no attention to accessibility. Once you get started it's also possible to ask for volunteers to do a review and help you with improving you accessability. Give me a holler and I'll give you a few pointers; or work your way from <URL:http://www.w3.org/WAI/>. 5) You use a "<link>" element to refer to the "bookmark icon", but ignore the navigation ("top", "next", "previous", "toc", etc.) <link>s that lets Mozilla and other modern browsers provide the navigation. > i dont get you, exactly what is wrong with that ? <link rev="start" href="/"> <link rev="next" href="chapther2.html"> <link rev="glossary" href="glossary.html"> These let you define logical relationships between the various pages on the site -- especially for logical collections of pages such as the manual -- that will allow smart browsers to provide an UI for moving between those parts. Read up on the Mozilla "Links Toolbar", or the similar feature in iCab. Search engines can also take advantage of this sort of markup. You may also want to look into using "Dublin Core Metadata" to add information about modification times, author, copyright, etc. etc. to the pages. This is also good for automated processing -- be it by search engines or by browsers -- of the pages. IOW, this isn't really about the "navigation links" as they appear in the page as shown on screen. This is about structural metadata in the <head> section of the document. Please don't think that I'm slagging your design! It's just that it's very hard to "critique" something without also "critisizing" it. Hopefully I've managed to avoid the worst pitfalls and gotten through that I'm suggesting ways to be "even better", not trashing you for not doing better in the first place (which would imply that your work wasn't very good). As I wrote, the work you've done _is_ very good. What I'm "critiquing" isn't so much the work as the decisions made when you hammered out your goals and success criteria up front. [end Terje double snipped]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
