EvoBloggito

Part 5, Why Bad Websites Happen to Good Companies: Having a “Splash” Page

Author: Ray Gulick; Published: Jan 12, 2009; Category: Accessibility, Bad Websites/Good Companies, Design/Development, Marketing; Tags: Information Architecture, Splash Page, Usability; 4 Comments

Splash pages represent a fundamental misunderstanding of the online medium. Often, they come from a print perspective ("books should have a cover"), or sometimes from a broadcast perspective ("a show should have an intro"). In user surveys, splash pages consistently rank as one of the most annoying things on the internet, but there are still splash pages out there, and most are attached to company websites (or print designer portfolio websites). A simple Google search reveals the many problems with splash pages, so we won’t address that here.

If the problems with splash pages are well known, why do they still exist, and in fact, continue to show up on new or redesigned sites?

• Ego, part one: the designer wants to show off his/her creativity or flash/illustration skills.
• Ego, part deux: the CEO or marketing exec is under the mistaken belief that a "cool" splash page is…um… "cool."
• Money: the designer can charge extra for the splash page flash or illustration, and maybe more for the "concept."

Websites with splash pages are inherently brochure sites (has anyone ever seen a splash page on a website that engages its audience?). The underlying assumption with splash pages is that "the market" wants/needs to see/hear the company’s "big message." That, my friends, is so "brochure."

Designers who push splash pages either misunderstand the web medium (perhaps they’re primarily print designers who only design an occasional website and don’t understand the differences?), or they’re making design decisions based on what’s best for them rather than what’s best for their clients.

Clients who insist on splash pages (I’ve had one of those in 9 years) are either uninformed, or they don’t care about their users ("it’s our website, not our customers’ website"). If they still insist on a splash page after you attempt to educate them, take their money if you need to, but realize that you are on the "brochure website" path on that website.

For more posts in this series, see the “Bad Websites/Good Companies” category at right.

Intro: Why Bad Websites Happen to Good Companies

Author: Ray Gulick; Published: Dec 21, 2008; Category: Accessibility, Bad Websites/Good Companies, Design/Development, Marketing; Tags: Design/Development, Marketing; No Comments

You’ve seen them: surprisingly bad websites representing good companies or organizations. Websites with Flash intro screens, incomprehensible menus, bad links, and no discernible message. Websites that drop you off unexpectedly in the middle of nowhere with no clear indication how to get back without hitting your browser’s back button. Websites with so little traffic that you cause a spike in the unique visitors graph just by visiting the homepage. Websites that haven’t changed or been updated since the dotcom bubble burst. Websites that make you cringe if they belong to your company.

In a series of posts over the next several weeks, we’ll look at how and why bad websites happen, what you can do to avoid having them happen, and if they’ve already happened, what you can do to fix them. You may recognize your website falls short of what you’d like it to be, and that’s good! Before you can fix the problem(s), you have to be aware they exist.

We’re going to start with this premise: websites require your attention, effort, time, and willingness to engage your market to have any value to your business. The days of online brochures are long past. Having a brochure site is like going to a party, but standing in the darkest corner of the coat closet. If nobody notices you, and you’re not willing to engage in conversation, there’s not much sense in going to the party. Or having a website.

For more posts in this series, see the "Bad Websites/Good Companies" category at right.

Determining Usable Window Space at Different Resolutions

Author: Ray Gulick; Published: Dec 21, 2008; Category: Accessibility, CSS, Design/Development; Tags: Browsers, Design/Development, Monitor Resolution; No Comments

A certain amount of confusion exists about designing for different screen resolutions. Many web designers assume that 800×600 resolution gives them 800 pixels in screen width, and 600 pixels of depth that can be considered "above-the-fold." However, this is far from the case. All browser windows have scrollbars and toolbars that must be accounted for, and of course, there is no consistency across browsers in how much screen real estate they use.

For the sake of demonstration, I’ve created a couple of images for 800×600 and 1024×768 screen resolution, using the Windows Internet Explorer browser templates provided by Joel Laumans (thanks, Joel). He’s used the assumption that an 800×600-pixel screen allows the browser window to be sized at 800×600 pixels, which is usually true, but not always, due to monitor differences. We’re going with that assumption also, to simplify the issues. Some of the numbers below will be different with diferent browsers.

First, let’s look at width. Beyond this mention, we’re going to ignore the fact that it’s possible to open a list of favorites on the left of many browser windows. We are, however, going to allow for the scrollbar and right border, which carve out 22 pixels. Next, allow for the left border, which takes another 6 pixels. Then, to be safe, we’ll allow another 4 pixels on each side, for an 8-pixel "safety margin." Let’s do the math: 800 – 22 – 6 – 8 = 764 pixels of usable width.

Next, let’s look at depth. Obviously, web pages can be very long. What we’re concerned with is trying to identify the above-the-fold depth: the part of the screen that shows without the need to scroll down. We’ll never be able to be certain of this depth, not only because of browser differences, but because of the broad range of choices that individual users make with toolbars, tabs, status bars, etc. All we can do is try to find a reasonable depth that accommodates most users. We’ll use 170 pixels as our assumption about how much room we have to leave for toolbars and tabs (I’ve seen more than that, but those folks have "embraced" scrolling as "just something you do" on all webpages). We allow 26 pixels for the status bar at the bottom of the browser window, and another 4 pixels for safety margin. The math: 600 – 170 – 26 – 4 = 400 pixels of above-the-fold depth.

The examples: 800×600 |1024×768

Why Online Language Translation Applications Are a Bad Idea

Author: Ray Gulick; Published: Dec 20, 2008; Category: Accessibility, Marketing; Tags: Translation, Web-based Applications; No Comments

One of the blogs I follow recently recommended an online translation application. For some reason, I was not able to submit a comment on the post, so I’ll air my comment here. The service suggested was Nice Translator. My wife, Angela, is a professional translator, which gives me some insight into translation issues.

First, most translation applications do a reasonably good job of translating individual words, provided the words have only one meaning. It gets a bit more difficult when a word can be both a verb and a noun (i.e., I will ride to the store, vs. I need a ride to the store). The better applications (Google Translation, for instance) differentiate between usages of a word and give you several options. This is good, but you may have no way of knowing which of the options is suitable, which is a problem.

Beyond single words—sentences and paragraphs—all translation applications fall far short of delivering usable translation. Even relatively simple sentences are routinely mangled. Sometimes (if you’re lucky) the translation will just be awkward. If you’re not so lucky, the meaning can be completely changed. Why? Software is unable to understand the context of the words, and as a result is unable to make decisions about rephrasing or selecting other words that more accurately express an idea.

Assuming your motivation for using a translation application is a need to communicate to a non-english speaking audience, the app is going to let you down. In fact, the awkward sentence structure and confusing words amplify your inability to communicate with your non-english speaking audience. Maybe you’ll provide them with a good laugh, and they’ll give you points for trying. But they won’t be fooled into thinking you understand them.

If you need to communicate with a non-english speaking audience, work with a good human translator with experience in the subject matter. It will cost you some money, but you will also communicate with your audience (and you won’t have to worry about looking blöd).

10 jQuery Plugins We Really, Really Like

Author: Ray Gulick; Published: Dec 15, 2008; Category: Accessibility, CSS, Design/Development, jQuery; Tags: Accessibility, CSS, Design/Development, jQuery; No Comments

It wasn’t that long ago that javascript was considered a "kiddie" programming language, used mostly to inflict annoying browser behavior on website visitors. Then, AJAX came along, using javascript to process client-side requests. Suddenly, javascript was useful. jQuery has been described as "javascript that has grown up." Following are our current favorite plugins.

Thickbox – accommodates images (singly or in galleries), Flash, text, iframes, and AJAX, making it perhaps the most versatile of existing modal window scripts. Recently, there’s a Dreamweaver extension to further simplify implementation.

PrettyPhoto – another modal window that’s almost as versatile as Thickbox; we also like it because it’s so… pretty!

Watermark Input – unobtrusively allows hints in form fields that disappear when the user puts his cursor into the field.

jTabber – tabbed boxes that allow you to display hidden content on request, without reloading the page.

Superfish Menu – based on the suckerfish menu, this is a highly configurable menu system that supports IE6 and is accessible.

Scrollable HTML Table – like good little developers, we only use tables for displaying tabular data these days: this plugin allows you to fit a very long table into a short depth, scrolling it from top to bottom.

Colorize – another table plugin, this one for alternate coloring of rows and changing the color as you hover over each row.

jCarousel Lite – scrolls through images, highly configurable; we used this plugin for our portfolio presentation.

jqZoom – we haven’t had an opportunity to use this one yet, but it’s very cool; lets you "magnify" areas of an image.

s3Slider – another plugin we’re dying to use; maybe the coolest slide show effect ever.