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
(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#Liquid_versus_fixed_layouts
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
<http://www.bths.edu/>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
<http://www.marshallmiddle.org/>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
<http://craigslist.com/>Craigslist.com would be less attractive to
the communities than something that looks like
<http://www.fallbrookhs.org/>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: memberh...@webstandardsgroup.org
*******************************************************************
