Navigation Jump

Print This Post/Page

KIXE Redesign: Frontpage and the Anal Coder July 30, 2006

Posted by ptvGuy. Comments: 7 comments
icon for podpress  KIXE Redesign: Frontpage and the Anal Coder [5:24m]: | Download (4497)

…many of my projects will be coming as new web content…

I apologize to everyone for having been too busy to post anything here for the last month, but many of my projects will be coming your way as new station web content very soon. However, to get back into the swing of things, I bring you the KIXE redesign. I have maintained the KIXE website (such as it is) for several years now with a complete redesign always pending but never approved. It's horrible design and coding has always been a thorn in my side and, with the launch of their new logo and look, I've finally gotten the go-ahead.

KIXE Broadcast AreaKIXE is a small-market station based in Redding, California and serving an incredibly huge geographic area covering most of the northern end of the state–ten counties in all. This area runs the gamut from rural to mountainous to desert to farmland to just plain sparsely populated. Many of the people served by this station live in small towns and isolated communities, and home-schooling is quite common. If ever there was a place that could benefit from all of the incredible content (especially educational resources) that a PBS station website can bring, this is it.

Piefecta is a beautiful piece of coding and highly adaptable…

There are a number of challenges to be met in getting KIXE's site up to standards. There's the usual content rescue wherein I have to find all of the actually useful content and extract it from the coding nightmare that it's currently buried in. There's the fact that it's hosted on a Windows 2003 server with a number of other sites, and I don't have the usual server control that I've been getting so spoiled on. There's the addition of an online auction and an eGuide that will require initial setup and long-term maintenance–probably with Microsoft Access interaction. However, the greatest challenge here–and I'm gritting my teeth and going forward anyway–is the absolute reliance on Microsoft Frontpage.

I'm not a Microsoft basher, so if you were hoping for a tirade on that subject, you'll have to look elsewhere. The web is full of them; they're not hard to find.

That kind of stuff always reminds me of those guys that see you putting a tiny nail in the wall with a little utility hammer and start in making derisive comments about what they call "housewife hammers." You have to cut off people like that before they start telling you how many ounces their "real hammer" is and let them know that the point is the job and not the tool. Best answer for that kind of stuff: "I could do it with a rock; I'm sorry that it requires so much more for you to accomplish the same thing."

…reworked it to cover one, two, and three column layout from a single CSS file…

So, how does one go about creating an accessible, standards-based, cross-browser compatible, dynamic website with a tool like Frontpage? Frankly, you cheat. You do as much as possible directly in the code, and you start with a standards-based design and rework it to fit your job. KIXE wants a site based on the PBS Be More Station Website Prototype which varies between differing static pages having one- to three-column rigid layouts and a header and footer. Therefore, I've decided to adapt the Piefecta layout to the prototype to achieve a standards-based, rigid-column design. [Thank you John and Holly.]

Piefecta is a beautiful piece of coding and highly adaptable. I've reworked it to cover one-, two-, and three-column layout from a single CSS file and even added in support for the three faux columns found in the center column of the homepage. If you'd like to see where this is at right now, then visit the KIXE test page. There are still a lot of internal styles to work in, but the primary layout is there and waiting to be filled.

…added in support for the three faux columns found in the center…

If you look closely, then you'll see that I've actually used a few proprietary Frontpage extensions for server side includes. This makes up for the fact that I don't have the .htaccess control of an Apache server here to hide my server processing in a plain HTML file. I don't want to create a site laid out with all the files having SHTML or ASP extensions as those tend to confuse people, so I will be making use of what the server offers me. I will be using both standard and timed Frontpage includes to run basic server preprocessing from a plain HTML file.

Keep checking back here as I update you not only on the progress of this redesign, but also on some great new tools that you'll be wanting to add to your station website soon.

Thank you all, code well, and good night.

Print This Post/Page

Accessibility: Web Design for the Mobility-Impaired May 17, 2006

Posted by ptvGuy. Comments: 2 comments
icon for podpress  Accessibility: Web Design for the Mobility-Impaired [4:46m]: | Download (4844)

…Accessibility is about making the page useful to everyone…

Mobility impairment isn't always as obvious as you might think it is. You don't have to imagine extremes of disability like paralysis or missing limbs. Try imagining a simple fall or other accident that results in both hands in a cast and unable to use a mouse. Now, with that in mind, open your website in your browser, put an unsharpened pencil in your mouth, and try to use the eraser to push the TAB key till you get all the way to the main content of your page. With a properly placed "skipnav", one TAB key click gets you to the link, and a click on the ENTER key gets you to the main content. That's accessibility. It's the web equivalent of an entry ramp.

A skipnav is a link placed at the very beginning of the page (before any other page content) that allows a user to skip all the top-bar and sidebar navigation links and go straight to the main content. It's generally a simple text link placed either in the beginning of the header or in a separate DIV prior to the header. It's one of the very few pieces of page content considered acceptable for cloaking (matching text color to the background color or using CSS to size it or slide it off-screen to make it invisible to the user.) Like most accessibility options, it exists primarily for disabled users and doesn't have to be visible to be useful. (On a side note, the PBS Station Prototype Website provides an already named landing point for such a link, but it was placed there for the CSS.)

…anything that might make a user's hands uncooperative…

Web design for limited mobility also includes checking your scripts to see if your behaviors are mouse-centric. Without touching your mouse, try to get around your site. There aren't perfect keyboard equivalents of all mouse events, but the major ones are pretty basic. If you have a CLICK event, add the same KEYPRESS event. If you have a MOUSEOVER event, add the same FOCUS event. If you have a MOUSEOUT event, add the same BLUR event. Accessibility is about making the page useful to everyone no matter how they get to it or have to get around it.

The ACCESSKEY value of the anchor tag is another good and far underused feature to add to your navigation system. Even though it's not currently supported in some browsers and browser versions, it's one of those things that doesn't hurt your page by being there. Browsers that don't support it just ignore it. Users hold the ALT key (the CONTROL key for Mac users) and press the specified, single alphanumeric character to either set focus on or activate a link depending on the browser. It allows you to set keyboard shortcuts for primary site navigation.

…it's about making it easier and more intuitive. That's usability…

Other aspects of mobility impairment related to computer usage may not occur to you initially. These include slowed reflexes, lack of coordination, tremors, ticks, palsy, arthritis, and anything else that might make a user's hands uncooperative. I, for one, have a hard time double-clicking fast enough (due to nerve damage) for the computer to register it as such. Therefore, avoid page design that relies on a site visitor's speed and eye/hand coordination–unless, of course, you want your page to feel like a video game. Avoid single character or single digit hyperlinks on a page or image maps with tiny hot spots. (I know, scripted image maps are a whole other issue.)

You would not believe the number of web pages I've been to that use words like "I" or the number "1" as important content links. Try to hit that after six cups of coffee. Our goal isn't to make it harder for site visitors to use our sites; it's about making it easier and more intuitive. That's usability. It's the web equivalent of a well-ordered office directory posted clearly on the wall with neatly labeled signs on every door.

I know that these things will require a little extra time and effort, but they're worth it. It's just not that hard to imagine yourself in need of them.

Print This Post/Page

Time, Money, and Accessibility May 9, 2006

Posted by ptvGuy. Comments: add a comment
icon for podpress  Time, Money, and Accessibility [2:41m]: | Download (2154)

When the government mandated that buildings and other facilities should be accessible to people with disabilities, they knew that most business and property owners could never afford to do the kind of work necessary to make that happen. Therefore, they set aside large sums of money to offset some of these expenses. When the government mandated that all government websites be made accessible, they made sure that there was some funding available to do this.

…no one has set aside any money for it…

No one has mandated accessibility for public television station websites, and, unless you know something I don't, no one has set aside any money for it. You might think that station personnel would be more involved with this (or at least interested.) After all, Descriptive Video Service was created by a public television station, WGBH in Boston, and PBS aired the very first accessible television program, The French Chef (also from WGBH), in 1971 with "open" captions. Still, most stations have no understanding of why extra time (and therefore money) should be devoted to the web equivalent of this.

…we can accomplish this important task within our very limited budgets and time constraints…

Therefore, the onus of providing such accessibility to the station website rests solely on the station web developer. Why would we do this without any requirement (or extra money) in place? We do it for the same reason we provide cross-browser compatibility; we want to provide the best possible user experience for as many of our users as we can.

I won't attempt a comprehensive accessibility guide here, but there are some basics that I want to cover over the course of the next few posts. There are different aspects of accessibility that have to do with the limitations involved in the underlying disabilities themselves. Many of them have to do with sight and mobility issues while using a computer. However, the majority of web design accessibility issues have to do with basic site design and usability.

I hope you'll join me in discussing how we can accomplish this important task within our very limited budgets and time constraints. Why should your station's web presence be "site-impaired?"

Addendum: I just found a great podcast interview with Paul Boag on web accessibility over on the CreativeXpert website hosted by Alan Houser.