Hi Alan Interesting that they justify layout tables on the basis that some users may have IE5, yet have a slow, graphics-heavy site which will take forever to load without a broadband connection. How many users I wonder have a screen width of more than 1024px plus IE5 plus broadband?
Elizabeth Spiegel Web editing 0409 986 158 GPO Box 729, Hobart TAS 7001 www.spiegelweb.com.au From: [email protected] [mailto:[email protected]] On Behalf Of Alan Berman Sent: Monday, 19 January 2009 12:29 PM To: [email protected] Subject: Re: [WSG] Examples of great high-school websites? Educational Networks has been courted our administration (for El Camino Real High School in southern California) for the last couple of years. I finally let them come to show me their stuff, intending to show them what I had put together for my school site as a discussion starter; they are not used to talking to people who have done this sort of work--content management is the magic wand they offer to the schools, so when there's something that's already set up that way they have a tough time getting past a solution that isn't theirs: http://ecr.lausd.k12.ca.us <http://ecr.lausd.k12.ca.us/> (Please note that the Student Info page, linked from the navbar, is entirely designed by and controlled by a former student--it is rife with errors and designed without any regard to consistency with the overall site design. I know about it and have no time to do anything about it except ask for forgiveness at present.) I welcome comments, of course, but that's not the reason I'm sending this message. Most of the site is content-managed (I did the PHP myself, no use of any sort of CMS framework or engine--for better or worse) and I have used Mike Cherim's contact form (although I styled it to fold in with the site, I think). The rep they sent wasn't really very conversant on the technology, but did write down all of my issues, including these points: 1. All their sites (and they have done MANY) look exactly the same if you squint: fixed-width, scrolling banners, etc. 2. All their sites load slowly. 3. All their sites are invalid for HTML and CSS 4. All of their sites fare unfavorably against any accessibility guidelines 5. All of their sites weren't as good (IMHO) as what I had already made etc. When the rep went back to EN with her tail betwixt her legs, she must have talked to some tech people, then sent back a note with her signature; this is an excerpt from her note. Perhaps this will help clarify their position, at least as of last year. And one would think that, regarding the last comment about accessibility, if they can do it as a "tech support" request, why not just build it into ALL their sites? It's all part of the deep structure of the CMS, right? Well, it should be. . . *** EXCERPT FROM EN'S RESPONSE*** 4) CSS vs. Tables. This is a vary valid discussion and here are the considerations in making a decision as to what approach to take: - All our sites use CSS for a lot of centralization in terms of backgrounds, fonts, styles, it is efficient, works robustly and beautifully. - Most of the tables are not handled through CSS because CSS is not reliable across various browsers the way each renders HTML. We design our sites to be correctly visible from IE 5, Firefox, even on Mac's with IE 5 (which is no longer supported by Microsoft). Our public sites should operate properly even on exotic OS's or old browsers as in many communities people have old computers with old browsers. When tables are implemented one can also correctly handle more complex tables. CSS is fine with simple "listing tables" such as a 1 X N matrixes (like one can see on the homepage of ECR), but imagine a 3X3 matrix where the requirement would be to merge the first two cells starting from the most left column for only on the top row. This would be a nightmare to handle through CSS, thus the correct choice would be to use the Table approach. - The sites we built are portals with unified navigational structures. The header, footer, left nav bar (if there is one) would come from "includes" using a proprietary technology (a bit like portlets) which also works most efficiently with tables, rather than CSS. http://en.wikipedia.org/wiki/Liquid_web_design#Liquid_versus_fixed_layouts <http://en.wikipedia.org/wiki/Liquid_web_design> has an excellent discussion about "Table vs. CSS". At Educational Networks we do follow closely all new technologies and implement them as they become widely available and have proven track records of being robust and mainstream. A good example would be RSS enabling most dynamic sections and ICAL compatibility of our calendars. There are numerous Web 2.0 technologies with lots of eye candy and we constantly evaluate them before reliably implementing them. For example, last year we AJAX enabled several applications of the CMS in the back-end such as "Food Menu" and "Events Calendar", and "Settings" as it was the appropriate thing to do for ease of use. But with each novelty there is the risk of making the systems sluggish or not compatible with older computers/browsers and sometimes this is too high of a price to pay for eye candy and thus in many instances we choose to err on the conservative side. 5) Liquid vs. Fixed Pixel: Same issue, of course sites can be designed with liquid considerations in mind, yet, graphic design is also very important for schools and is one of the most important parameters in generating traffic. People like attractive designs. Fixed pixel designs are in general significantly more precise as each pixel is counted, rather than resizing the design based on the size of monitor/browser. The main issue with liquid design is that content would never stretch perfectly as the site is stretched horizontally which would look less than attractive. For example, ECR site viewed on a 24 inch full screen browser would have its announcements sections with huge one line sentences, not even a paragraph which is very difficult to read and is also aesthetically problematic. At the same time, the top nav-bar would remain all the way on the left while all other content areas to the right would be stretched that nav-bar would remain the same. Still, it is for us not a technological challenge to create a liquid design, yet it would look less attractive. At a school like Brooklyn Tech we know that 99% of visitors are at 1024 pixels wide, thus www.bths.edu <http://www.bths.edu/> is designed with a width of 900 pixels ensuring no horizontal scroll bars. There is also the possibility of having some design elements extend beyond the fixed length which gives a feeling of liquidity which can be seen at www.marshallmiddle.org <http://www.marshallmiddle.org/> . A liquid site would be mostly text based with minimal amount of graphics. This is really no problem for us, but in the extreme example, a school site that looks like Craigslist.com <http://craigslist.com/> would be less attractive to the communities than something that looks like www.fallbrookhs.org <http://www.fallbrookhs.org/> . 6) Handicap accessibility: When our customers request we can make the sites compatible with federal accessibility requirements. It is a tech support request, not a problem. ***END OF EXCERPT FROM EN'S RESPONSE*** ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [email protected] ******************************************************************* ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [email protected] *******************************************************************
<<attachment: winmail.dat>>
