Thoughts on Design

A List Apart: Articles: They Shoot Browsers, Don't They?

This is gobsmackingly audacious. Imagine a new version of Word that behaves exactly like the old version of Word unless the document it is processing contains a hidden instruction to unlock any new features. That's what Microsoft is demanding that web developers implement. Unless you explicitly say otherwise, IE8 (and IE9 and IE10, ad infinitum) will behave exactly like IE7.

I've been following rumors about this feature for awhile. I thought they were going to turn out to be incorrect. It seems too audacious even for Microsoft. Forcing designers to use proprietary code in order or IE to work correctly? I can't see how this won't blow up in their faces in some way. It's sure not going to earn them any good will.

456 Berea Street is linking to a great discussion on accessibility.

But I am going to take this opportunity to re-inforce what I believe is the nature of our professionalism. We should make an effort to create accessible content, because it's part of our job. And frankly, it doesn't take much effort; it's not difficult. - John "brothercake" Edwards

Nicely written, and to the point. Accessibility is the job. A lot of our clients and employers can miss the point. We aren't making these sites for them. They know the content, they don't need the site for that. We're making the site for their clients, for whom accessibility may be an issue. When we worry about accessibility, we aren't being picky, we're doing our job.

We've all done it. You right click to correct the spelling of a word, and you add the misspelled word to your dictionary rather than correct it. Firefox makes it easy to add new words, but they don't make it easy to remove them. Here's how to do it.

I've started using a great functional accessibility evaluator lately. A superb tool for testing and fixing accessibility issues on websites. A very powerful tool. Register for a free account and it gets even better.

The restructuring of the VTTI website is complete. They didn't want a redesign in the traditional sense, they wanted to update and improve what they had. I've updated the colors and textures, as well as improving the quality of HTML and CSS. The end result is a site with a simpler color palette, and improved overall functionality. The load time is down, and the design is now consistent across browsers and platforms. As a side benefit, it's also much easier to maintain and expand.

As you can see, it ended up looking a somewhat like the Alumni Association site, but that's not a big surprise. The goal with VTTI, like the Alumni Association, was to put together a site that met the University's requirements, without using their templates. They both wanted a site that was identifiably Virginia Tech, but was a little unique as well. Variations on a theme, rather than an exact match.

A List Apart has a great article on How to Size Text in CSS

.

In this article, we will reconcile the designer's requirement for accuracy with the user's need to resize text on demand, arriving at a best practice that satisfies designers and users and works across browsers and platforms.

How can you ask for anything more than that?

What type of image should I use online, JPG, GIF, or PNG? Simple question, but the obvious reply is another question. How are you going to use the image? One of my favorite quotations is Horatio Greenough's "form follows function". The function of an image should control the image's file type. A few things to consider:

• Is it a large image?
• Is it a photograph, logo, line drawing, or simple graphic?
• Are there file size requirements?
• What color profile is required?
• Do you need to match image colors with any other object on the site?
• Are there subtle gradations of color?
• Are there large blocks of a single solid color
• Is transparency required?

Once these questions are answered, the file type required is much easier to determine. Some tasks can be accomplished by all three common web image file types, others by only one or two. The need for subtle color transitions for instance would rule out GIFs, while the need for transparency would rule out JPG. If you need both of those things together, a PNG file is the only real option. Look at the function required, and use that to control the file type choice. JPG files are the best web solution for photographs, images with subtle variations of color, and images with large blocks of a single solid color. They also compress well, allowing for larger images to still have reasonable load times. They do not however, allow for transparency. This format also uses lossy compression, which means compression of the file causes loss of detail. The more compression, the more loss. GIF files are very good for logos, allow transparency, and use a non-lossy form of compression. They also allow for animation of images. The downside of this is that they only allow for 256 colors, so color matching can be awkward. Due to the color limitations, GIFs also do not reflect subtle gradations of color well. PNG files are a nice compromise between the two. They allow transparency, and can use up to 24-bit color. This allows them to use both the subtle color range of of the JPG, and the transparency of the GIF. In practice, I've actually had more luck with using PNGs for transparency than GIFs. Just as PNGs are better at subtle color gradations than GIFs, they also seem to be better at subtle gradations of transparency. The key here is to look at the purpose of the image. File type follows function. 

Someone has posted an image of what HTML code should look like. Well done. h/t Photoshop, Illustrator, and Web Design Resources.

Derek Powazek has posted an article about How to Shoot Events. Very nice. I've done a fair bit of photography, enough to know how well his suggestions work at least. I've seen the most benefit myself from number 3, "Be Confident". A confident photographer, who looks even vaguely professional, can go just about anywhere. Everyone assumes that you belong.

POSH - Plain Old Semantic HTML

POSH, in case you haven't heard of it already, is short for "Plain Old Semantic HTML", and is obviously much quicker and easier to say than "valid, semantic, accessible, well-structured HTML". Unfortunately POSH -semantic markup - is also something most people building websites or creating content for the Web have yet to discover.

It's nice to hear that I'm not the only one that sees quality semantic HTML as a viable web design solution. There are flashier solutions, but well written HTML with good CSS is hard to beat from a reliability point of view. When it comes to web solutions that are 508 compliant, there's nothing better. I love trying new things, using new technology, but there are places for that. For instance, newer technology can be incorporated into an otherwise POSH site. It's not necessary to completely throw your site into the every new technology that comes along. One trend in recent years has been to make all Flash sites. Nothing wrong with Flash, it has some impressive potential, but a lot of the flash sites I see have very low usability. They're pretty, they're creative, some of them I'd consider works of art. They're not however, a viable alternative to most of the work I do. Usability and 508 compliance may not be exciting, but when a client or employer wants it, the best course of action is to make it POSH.