Skip to main content

Evaluating Web Sites

What makes a Web site readable?

As the Internet moved from the ASCII texts of the USENET and FTP repositories towards HTML, no one really cared about appearance. The notion was that content was everything — and most content files were journal articles and scientific research. The early notion of specifying fonts on the World Wide Web was a major shift from the original notion of the Web. You can look at changes from HTML pre-1.0 to our current standards and the shift towards visual content is obvious.

The reality is that there was no stopping the drift towards a visual medium.

Given basic HTML 2.0, designers resorted to complex tables-within-tables to mimim familiar print designs. From the earliest handwritten manuscripts, artists have known how words are placed on a page (or screen) affects how they are read. No one was about to settle for no control over a Web site's appearance.

Temptation to experiment can lead to innovation, but on the Web it also helps to keep a design simple.
I don't surf the Web much. Like most people, I have destinations I have bookmarked and seldom explore beyond those now. My "start page" is Google News because it is simple, mostly white, and easy to read. The two-column design is easy enough to read on my screen, especially if I can enlarge the text.

Designers want the control they are accustomed to, but some choices they think important for aesthetics make a Web site useless for me. Too many Web sites rely on specific fonts, even locking sizes so those of us needing larger type cannot use the pages. Google never makes this mistake. Most news sites do, though — so I stop visiting them.

I'd actually be okay with a return to the past. Give me text. Let me select the scale of the fonts on my screen. Allow me more control as the reader so I'm not locked out of a site by my blurry vision or inability to focus on some colors.

The past isn't going to return though. My own Web sites are visual. I have spent days and even weeks altering colors and typefaces. I tweak the smallest elements of the pages, trying to make them as visually appealing as I can while still allowing users to magnify the text. (That's not always possible, but I definitely do my best to make sites accessible.)

I often wish Web designers would study why people use Wikipedia and Google. They are simple, fast, and easy to read. Don't add sounds (I prefer my iTunes music), don't force me to watch videos, and don't use wild color schemes that are trendy for a week.

Even what some designer thinks is simple can be a mess. Yahoo is a good example of too much at the top level of a site. Microsoft and AOL are even worse. No wonder most of us use Google!

Comments

Popular posts from this blog

MarsEdit and Blogging

MarsEdit (Photo credit: Wikipedia ) Mailing posts to blogs, a practice I adopted in 2005, allows a blogger like me to store copies of draft posts within email. If Blogger , WordPress, or the blogging platform of the moment crashes or for some other reason eats my posts, at least I have the original drafts of most entries. I find having such a nicely organized archive convenient — much easier than remembering to archive posts from Blogger or WordPress to my computer. With this post, I am testing MarsEdit from Red Sweater Software based on recent reviews, including an overview on 9to5Mac . Composing posts an email offers a fast way to prepare draft blogs, but the email does not always work well if you want to include basic formatting, images, and links to online resources. Submitting to Blogger via Apple Mail often produced complex HTML with unnecessary font and paragraph formatting styles. Problems with rich text led me to convert blog entries to plaintext in Apple Mail

Learning to Program

Late last night I installed the update to Apple's OS X programming tool suite, Xcode 4. This summer, in my "free" time I intend to work my way through my old copy of Teach Yourself C and the several Objective-C books I own. While I do play with various languages and tools, from AppleScript to PHP, I've never managed to master Objective-C — which is something I want to do. As I've written several times, knowing simple coding techniques is a practical skill and one that helps learn problem solving strategies. Even my use of AppleScript and Visual Basic for Applications (VBA) on a regular basis helps remind me to tackle problems in distinct steps, with clear objectives from step to step. There are many free programming tools that students should be encouraged to try. On OS X, the first two tools I suggest to non-technical students are Automator and AppleScript. These tools allow you to automate tasks on OS X, similar to the batch files of DOS or the macros of Wor

Learning to Code: Comments Count

I like comments in computer programming source code. I've never been the programmer to claim, "My code doesn't need comments." Maybe it is because I've always worked on so many projects that I need comments  to remind me what I was thinking when I entered the source code into the text editor. Most programmers end up in a similar situation. They look at a function and wonder, "Why did I do it this way?" Tangent : I also like comments in my "human" writing projects. One of the sad consequences of moving to digital media is that we might lose all the little marginalia authors and editors leave on manuscript drafts. That thought, the desire to preserve my notes, is worthy of its own blog post — so watch for a post on writing software and notes. Here are my rules for comments: Source code files should begin with identifying comments and an update log. Functions, subroutines, and blocks of code should have at least one descriptive comment.