Talvin Muircastle creates assistive technologies for users with disabilities, for the virtual world of Second Life. The text below is adapted from (with permission) and you can read the entirety of his original post at his blog The ScriptAble Project.
You walk into a casino and put some money in the slot machine. You pull the handle. Odds are, you aren’t going to get anything the first time. Probably not the second, or the third. But casinos know that there is a window of opportunity for them: if you don’t see something line up in front of you, if you don’t hear the ring of coins or chips dropping into the till within a certain span of time, you are going to walk away. They set the odds, therefore, such that within that window of opportunity you probably will get a payout of some amount.
Probably not the Jackpot.
More than likely, not even as much as you have put in.
Still, you have to get some measure of satisfaction and gratification from it, or eventually even the Gambling Addicts are going to walk away–or at least try a different game. The level of payout required is determined, not via any intellectual mathematics, but through a sort of emotional calculus that varies person-to-person.
The same theory applies to developing technology for the End-User: if the User starts using your tech and doesn’t get some sense of satisfaction from it fairly quickly, they will decide it is not worth their valuable time. They will view it as “broken”, and they will describe it as such to others. Given that word-of-mouth is still the most potent form of advertising, this can make or break you.
Microsoft learned this the hard way with Windows Vista. They thought that people not only would not, but could not go back to XP. They did, in droves. Apple recognized this when they released Snow Leopard: while Snow Leopard contains some important stuff for the future of Macs, it’s all under the hood. The average user isn’t going to see much of a “payout”, so they priced it really low: $29.
Now add the challenges of Assistive Technology. Most Software Development (sadly) assumes the hypothetical “Normal Person” as the audience. This person doesn’t really exist, of course. We are too diverse. Perhaps we need to reconsider that whole concept, but that is a post for another time, and probably another blog.
My audience is almost never going to fit the “Normal Person” characteristics. The End-User may not use their eyes. They may not use–or even have!–hands. They may have a high level of intelligence yet have difficulty communicating with me effectively due to dysfunction in one part of their brain. They may have a disability “just like” someone else’s, and yet live their lives and deal with the world in a totally different way. It is my job to create technology that will give them a “payout” in their first hour using it. Sometimes, I even succeed.
The moral of this story? IT students should be sure to get a good liberal arts education. OK, seriously: the code you write may look elegant, efficient, and useful–to another scripter. How does it work for the End-User? If they don’t start getting some coins in their till pretty quickly, they are going to stop pulling the handle, and you wasted a lot of time on a work of modern art.
(Eric Jordan did an update to his first “Webmaster” vignette, and I’m posting it here for collective enjoyment. Thanks, Eric!)
Web Master 1.1
(I had enough fun with the first one, I decided to upgrade!)
The Programmer approached the Web Master in his cubicle once again. “Web Master, please help me. I am trying to select graphics for this new page. I want it to look cool.”
The Web Master quickly clicked over to his Photos directory, and brought up a picture of a winter storm, a polar bear, and a refrigerator.
The Programmer twitched in his chair, slightly. “No, Web Master, you do not understand. I want this page to look radical.”
The Web Master nodded, and brought up pictures of Che Guevara and rioting students.
“Forgive me, Web Master, but I have not been clear. I want to draw lots of visitors to this page.”
The Web Master ahhed softly, and turned to the Web Browser. He found a porn site.
Seeing the expression on the Programmer’s face, the Web Master said, “It is you who must forgive me, for I have erred. First, I should have asked: who is your audience?”
And the Programmer was Enlightened.
It’s pretty easy to explain to people why their web sites need certain kinds of standards; take, for example, Section 508, which is essentially the ADA for web sites. Section 508 says that any organization receiving federal funds (hmm…bailout companies, take note) must have an accessible web site. “Accessible” is further defined by specific criteria, but it mostly comes down to making web sites that can be used by the physically impaired.* People understand needing to modify something so everyone can use it equally, without unfair impediments.
However, it can be more difficult to explain why web sites should also be using coding standards. For example, how many people realize that HTML is actually deprecated (i.e., dead**)? HTML was replaced by XHTML and CSS. The last valid version of HTML was released in 1999–10 years ago! And, even if your site is using more current technologies, is it actually validated as standards-compliant? Just using XHTML/CSS is not the same as using valid XHTML/CSS. It’s the difference between having my dad poke at your engine and bringing the car to a certified mechanic.
If your library’s site is still using HTML or non-validated XHTML/CSS, it’s not just a matter of being a technological left-behind. Your site actually has some major issues you may not even be aware of. Here’s just a few:
- Older (non-standard) code can be a real obstacle for visitors using mobile devices. What’s the point of designing a cool iPhone app for your library if the entire library’s web site isn’t usable on the same device?
- Internet browsers come in all sizes, shapes, and levels of annoyance. Each browser has slightly different rules about how it chooses to render a site. If you look at your library’s site in Internet Explorer and then Firefox, chances are high they don’t look the same. Being standards-compliant can minimize these differences. Keep in mind also that sites often render differently in different versions of browsers. Try looking at your site in Internet Explorer 6 and then Internet 7. Make sure you’re sitting down first.
- You may actually be sucking up your visitors’ bandwidth. Standards-compliant sites tend to be cleaner and more compact, without gobbeldygook code soup on the back end. This means they tend to run faster. Don’t have broadband in most homes in your service area? Your library’s site on dial-up might be a nightmare for your patrons.
- Generally, you can’t have a site that’s accessible to people with disabilities without it also being code standard-compliant (although, alas, you can have the reverse). If you aren’t using standard code, rest assured that your site is not good for people using adaptive software like voice readers.
- Non-standard code actually hurts your search engine rankings. Sites that are standards-compliant are more friendly to those little Google robot spiders crawling through your site to index it.
What does this mean to me, Laura?
- If your site is running on HTML, it’s waaaay past time to bring it into the 21st century. <plug type=”shameless’>Contact us at OPLIN to find out how you can get on the waiting list for the Dynamic Website Kits, which are totally standards-compliant.</plug>
- If you’re planning a re-design of your library’s site soon, it’s critical that you take standards into consideration. The footloose-and-fancy-free “do whatever works” mentality won’t cut it anymore. To do otherwise can end up making sure that people using alternative browsers (e.g. Opera, Firefox), mobile devices or adaptive software don’t visit your library’s web site.
- You can use automatic online and free validators from the W3C (World Wide Web Consortium–they make the international standards for web stuff): Here is the XHTML validator and here is the CSS one.
__________________________________________________________
*Yes, I know this is a very simple explanation. Want more?
**Yes, I also know that W3C is working on the HTML 5 spec. But I am not holding my breath for a quick release and, if you are, I might have a bridge to sell you.
Ah, Twitter is a wonderful thing. I asked members of the Twitterverse to catalog the problems of library web sites, and my followers (as friends on Twitter are called) did not disappoint. I got responses not only from both library and non-library folks, but even a bit of international participation with a comment or two from Australia.
Here’s a sample of much of what I received:
- “Nonsensical links to products by name. Bookletters, EBSCO, iBistro.”
- “Branch hours/locations not easy to find from the library home page.”
- Having to…”scroll waaay down to bottom to find search box and then was Title(not keyword).”
- “Animated gifs and blinking text.”
- “Focus on library materials and facilities, rather than how people use our materials and facilities.”
- “Acronyms.”
- “No site search. C’mon, time to leave 1998.”
- “Hiding your staff and/or hiding ways (or not providing them at all) to contact staff through the web site.”
- “Library jargon: what the heck is a ‘electronic reference database’ to the layperson?”
I saw at least one major theme here: many libraries don’t have sites that are intended for the end user. Too many library sites are designed around the perceived needs of library staff, rather than for their patrons. I encourage every library to take a good, hard look at their public-facing web site(s) and ask the question “Who is this really for?”
Here’s some additional sins I’ll add to the list:
- Can’t find the address and/or phone number for at least the main branch on the front page.
- Too much text on the front page. Don’t put the whole 3-paragraph story there; just a teaser. People scan the web; they don’t read. When I see too much text, I’m outta there.
What other problems with library web sites do you commonly see? Share’em in the comments!
![[Bloglines]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/bloglines.png)
![[del.icio.us]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/digg.png)
![[Facebook]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/facebook.png)
![[Fark]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/fark.png)
![[Furl]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/furl.png)
![[Google]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/google.png)
![[MySpace]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/myspace.png)
![[Reddit]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/reddit.png)
![[StumbleUpon]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/stumbleupon.png)
![[Technorati]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/technorati.png)
![[Twitter]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/twitter.png)
![[Windows Live]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/windowslive.png)
![[Yahoo!]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/yahoo.png)
![[Email]](http://www.oplin.org/meanlaura/wp-content/plugins/bookmarkify/email.png)