5530 E Northern Lights Blvd
Anchorage, Alaska 99504-3135
907-742-4000
This section is specifically about designing your web pages; the "do"s, "don't"s and "should"s related directly to how your page is going to appear in a web browser. There is also a set of policy-related guidelines that you need to read.
The first two questions to answer when you're building a website are "Who's the audience?" and "What is the purpose of the site?". If you haven't answered those questions, do that before you do anymore coding. Those two questions will drive the design of your site. On the ASD website, the answers will vary some, but by and large, we can assume a few things.
Parents of students, students, staff, and people hoping to become one of those are the main people that will be using our site. We also get traffic from the media and other school districts. That gives a huge base of people with a wide variety of needs and expectations.
We're fortunate in Anchorage to have a higher than average number of homes with computers and Internet access, but we must not assume that all of those computers are new or that they have the latest and greatest software. As one example, millions of people access the Internet through AOL on slow modems and older computers. Some may have computers only a year or two old, but if they've never upgraded their software, they could be using a browser that doesn't meet the current HTML specification. Others may access the Internet using special software that reads web pages, or they may have difficulty using a keyboard (which become an issue when designing your navigation.)
Basically, we have to assume a pretty low common denominator, technologically speaking. This doesn't mean that we're stuck building simple sites or that we can't use the newest technology. It just means that we have to build our sites carefully and with our entire audience in mind.
One word. Information. We can get into all sorts of discussions about what kind of information and how it should be presented and distributed, but it comes down to that one word: Information.
Peope come to the ASD website to find out something about the district. If we can provide something BEYOND that, so much the better, but if people come to the ASD site to find something and they can't because our design has gotten in the way, then we've done a disservice to that person and to ourselves.
The Internet and WWW have matured to a point that the circle has come back around -- the info is the key. Long downloads and superfluous page geegaws are distracting and although we're not "competing for eyeballs" the way a commercial site has to (like the battle between Amazon and Barnes & Noble, for example), making our website difficult to use or navigate is counter-productive.
Accessibility is currently a big issue for web developers. In a nutshell, it means making accommodations for people who are vision impaired or blind, people who are hearing impaired or deaf, and people with motor impairments. It's important to ASD's web presence in two ways.
First and foremost, we are a publicly-funded institution and it's our responsibility to make sure that if somebody comes looking for information, that information is available, no matter what kind of computer or browser the user has. We want people to use our web site, so it just makes sense to make sure that anyone can.
Additionally, there are some possible legal issues. As of August of 2000, all federal government web sites were required to comply with the Americans with Disabilities Act. How does that relate to the ASD? Well, let's look at the Childrens Internet Protection Act (Senate Bill 97) as a possible example. Introduced in 1999, S. 97 would require any school district or public library that gets discounted Internet access from the government to filter Internet content or lose their discounted access. (There is some debate about further results, but one common opinion is that those institutions that do not comply with the new law would be required to reimburse the government for past years of discounted access.) Would the government try something similar to make all federally funded sites accessible? Maybe. There isn't really anyway of knowing, but it can't hurt to prepare, can it?
[As a side note, S. 97 is currently on the Congressional calendar awaiting action. That action could be debate or a vote. We'll probably see some movement on it after the elections in November.]
The links below give some insight into making pages accessible.
I strongly recommend that you take some time to read this information, especially if you already have a site up or if you are getting ready to build a site for the first time.
Bobby
http://www.cast.org/bobby/
Bobby is a program set up by the Center for Applied Special Technology. They
have a web page validator that will tell you what kind of accessibility problems
your page may have. You can use it on their web site or download a stand-alone
version. They also have lots of good information about building accessible
pages.
Web Accessibility Initiative
http://www.w3.org/wai/
A project of the World Wide Web Consortium, the standards body for the web.
Pretty dense reading, but this group's recommendations will probably set the
tone for any legal standardization of web accessibility.
Accessibility -- More than the Right Thing to Do
http://www.evolt.org/article/Accessibility_more_than_the_right_thing_to_do/4090/381/index.html
A very well-written piece that covers basics of the law and the changes you
might need to make to existing sites and even provides a handy checklist.
Accessibility -- The Clock is Ticking
http://www.alistapart.com/stories/ticking/
Another article that covers some of the legal issues, but also addresses accessibility
issues in general. From A List Apart.
As with anything, if you develop good habits to begin with, you don't have to break them later.
If you've looked at even one tutorial about building web pages, you've probably run into this already. If you haven't, there are links on the last page of this article that can explain it, sometimes in great detail, sometimes not. The good news is that you don't really need to understand it in great detail, mostly because as the Internet has matured, the software to create web pages has started taking that palette into account.
"Degrading" is an industry term for backwards compatibility, which
means ideally, any browser should be able to look at your page and get
the information that's on it. The <noframes> tag described
in Part 4 is a good example. Another example
is JavaScript. If you use JavaScript for a function on your page, make
sure that a browser that doesn't support JavaScript won't be left out
in the cold when they don't get that function. For example, if you use
JavaScript to make a button look like it's being pressed down (called
a rollover by most WYSIWYG HTML editors), an older browser will still
see the original button, but not the pressed one. That's probably okay,
because it doesn't limit the functionality of the button, just the coolness
of the animation. HOWEVER, if you use JavaScript to make a navigation
menu and that's the only way to get around your site, then you've just
locked out a measurable percentage of browsers. So that leaves you two
options -- don't use the menu at all, or (better) provide a text menu
somewhere on the page.
This is an option when you just have to do something on your site that isn't supported by some browsers or assistive technologies. A text-only site addresses all of the issues above, but can create more work. It's usually not necessary to create a complete mirror site if you code your main pages correctly.
I can't stress this enough. Before you post your site (or even just a new page), make sure it's going to work! At a minimum, you should check it on a Mac and a PC, in both Navigator and Explorer! If you've done anything tricky, make sure it displays correctly. Ideally, you should check it with a text-only browser like Lynx or MacLynx. It can also be enlightening to view your pages in Navigator or Explorer without loading the images.
The two biggest surprises for people who design on one platform and have never browsed on the other are the differences in the way fonts and colors look. Windows tends to darken things (dark blue becomes black, dark red becomes brown) and Microsoft uses larger default text sizes, so that page so carefully crafted on a Macintosh with all the line breaks in the pixel-defined table goes kerblooie on Win98.
It's also a good idea to run a code validator on your pages, especially if you're using a WYSIWYG page editor like Adobe Pagemill or Claris HomePage, particularly the older versions of these. Almost all WYSIWYG editors older than a year or two create non-standard code that can be problematic. I'll write more about that later.
You should also test your site for accessibility. The best site that I've found for this is Bobby (http://www.cast.org/bobby/). Not only does Bobby tell you where potential problems are, it gives you suggestions for fixing them.
These are the places in web design that it's easiest to make bad decisions. Please understand that I am not trying to tell you what you can and can't do. That's not my job and I certainly don't want to stifle anybody's creativity. The items listed below have been gray areas since the beginning of web design, but they have attained a new level of importance in light of the issues in Part 2 of this article.
Anything that makes the text on a page harder to read is probably bad for the site. Using color photographs or complicated tiles as a background image or pattern can lower the contrast between the background and text and make it difficult to read, even for people with good vision. Would you read a book or magazine that had yellow text on a green background for more than a few sentences? Probably not. So why should we expect people to read difficult pages on the web?
Animation can add some life to a page, but it can also be tremendously annoying if the animation is stuck in your peripheral vision. (As a side note, many of the public domain animated GIFs that were created two or three years ago run waaaaay too fast on newer systems.) Looping animations can also make viewing difficult for some people with certain learning disabilities.
This goes back to assuming the low common demoninator and a basically informational site. People shouldn't have to download a plug-in just to view the information on your page. As long as the animation or movie is an extra or there is an alternative, then you only have to deal with the issue of download time.
There are a few useful things that frames can make easier, but it's
also easy to misuse them, especially where full accessibility is an issue.
If you use frames, either provide a non-framed version of your site/page
or use the <noframes> tag. If you don't know what
the <noframes> tag is, look at one of the articles
below or consult your HTML guide.
Personally, I haven't used frames in years for anything intended for a wide audience because I think their problems outweigh their benefits.
If you want to use frames, look at these articles for some pointers about making them work for everybody.
Frames Without Tears
http://www.alistapart.com/stories/frames/
from A List Apart
Some Caveats with Using Frames
http://www.evolt.org/article/Some_Caveats_with_Using_Frames/22/293/index.html
from evolt
Don't Forget the Non-Frames Folks
http://www.hotwired.com/webmonkey/96/33/index2a.html?tw=authoring
from Webmonkey
The new standard for HTML 4.0 has the best support for CSS yet, but unfortunately, the browser companies haven't caught up with them. This is a big issue, and once we get CSS-compliant browsers (next year? maybe?) CSS will make it much easier to design good, accessible sites. That's very good news.
The problem is that if you go too crazy with CSS on a site, older browsers will choke on the page, especially with things like layers and absolute positioning.
There are ways to use CSS that don't inflict damage on your site, and there are ways not to. Here are a some articles to get you started.
Mulder's Stylesheets Tutorial
http://www.hotwired.com/webmonkey/authoring/stylesheets/tutorials/tutorial1.html
A good overview of using CSS and the current shortcomings from Webmonkey
Fear of Stylesheets
http://www.alistapart.com/stories/fear/fear1.html
Practical application of CSS from A List Apart
There are some things that just shouldn't be done. It's a short list, but an important one.
Microsoft and Netscape, in their zeal to make the Web cooler, added
some tags to their browsers outside the HTML specification. These include <blink> (Netscape)
and <marquee> (Microsoft). There are significant problems
with both of these tags, especially if your page design depends on their
correct display. The <blink> tag in particular can
make large blocks of text extremely difficult to read. They have also
caused seizures in people with autism. They may be snazzy, but they're
not that snazzy. Some of the tags have been incorporated into the HTML
4.0 specification, but aren't supported by one browser or the other.
Here's a complete list of proprietary tags.
(This list was cribbed from Web Design in a Nutshell by Jennifer Niederst,
published by O'Reilly. I can make an unqualified recommendation that you get
this book.)
That's not a very long list, is it?
So that's it. Not too much, and all of it's common sense.
One final thought: If you create pages on a regular basis, learn something about HTML. Even if you use a WYSIWYG editor, there are going to be times that you'll want to stray from their limited creativity. And as mentioned elsewhere in this article, some of these editors create faulty code, and if you don't know anything about HTML, you won't be able to go in and fix it. When all of the browsers and all of the editors finally adhere to one set of standards, knowing how to code by hand will not be nearly as important, but that day is at least a couple of years away.
If you have any questions, contact us and we'll figure out an answer.
Kathy Griffith, Webmaster
griffith_kathy@asdk12.org
742-4193
David McCreath, Web Development Programmer
mccreath_david@asdk12.org
742-4647
Webmonkey-- Lots of good stuff for beginners and experienced
coders alike. Of special interest to this article are the Authoring and
Design sections.
http://www.hotwired.com/webmonkey/
Builder.com-- A large, commercial site that has a large section
for beginners.
http://www.builder.com/
evolt.org-- A volunteer organization of web professionals that
banded together to share knowledge. The information ranges from the simple
to the arcane. And there aren't any ads! If you're looking for difficult
answer, try searching the Tip Harvester Archive.
http://www.evolt.org/
A List Apart-- Another site by developers for developers, somewhere
between Webmonkey and evolt. Updated weekly.
http://www.alistapart.com/
If you don't have the time or skill to create the images you want for your site, take a look at one of these sites.
Media Builder -- A highly commercialized site, but well worth
the visit for the graphically impaired. This site has free fonts, free
images, free animated GIFs (careful with those!), free backgrounds, and
even an online GIF editor.
http://www.mediabuilder.com/
Mega Web Tools -- This is more of a collection of links than
a cohesive site, so sometimes the quality control isn't there. It's still
an excellent resource.
http://www.megawebtools.com
| Privacy
Policy
| Copyright © 2000-2007 |
|
Anchorage School District 5530 E Northern Lights Blvd Anchorage, Alaska 99504-3135 907-742-4000 |