Archive for the 'Web Design' Category

Dec102005What Page Dimensions Should I Design To?

When I teach Web design classes, students always want to know how wide and tall their web pages should be. This is an easy enough question to answer when you’re dealing with printed designs like brochures and magazines: the size of the paper you’re printing on…duh! But with the Web, the size of our “canvas” is not for us to decide. It’s based on the hardware and viewing habits of our sites’ visitors—from 15 inch to 23 inch (and above) monitors and resolutions ranging from 640×480 pixels to 2560 x 1600 (and up). And since not everyone maximizes their browser window to fill their monitor, we’re not even entirely sure if a browser is using the entire area of the monitor.

Know Your Audience

Determining how to approach your Web page design is, like most interactive design, largely dependent upon your audience. The more tech-invested your audience the more likely they’ll have powerful computers, the latest Web browsers, and larger than average monitors. But how do you really know?

There are a few approaches involving JavaScript and some server-side code that can let you track not only your visitors’ monitor sizes, but also what size they’ve opened their browser windows to. I’m not going to show you how to do it: you can find information on that all over the web (like here and here.)

For an easy, out of the box (and a little out-of-the-pocket) approach you can also try the basic site stats package Mint. This php/mysql/javascript stats tracking setup provides a few add-ons that let you track both the resolution of your visitors’ monitors, and the width of their browsers.

No one has yet viewed this site (at least since I’ve started tracking it) with a monitor that’s less than 800×600 pixels; in addition, over 97% of my visitors have their browsers expanded enough to display 760 pixels (wide) of page content.

A starting point

If you’re not going to do the research—after all, it is a bit of a bother to set up the JavaScript code to do this, especially if you’ve got a well established site with lots of pages—you can safely assume that the vast majority (if not all) of the people visiting your site have monitors that are at least 800×600 pixels.

It might also be safe to assume that even if they don’t have their browser windows maximized, they’d at least be willing to expand the window to see the entire width of your site’s pages. In that case it’s pretty safe to design to a maximum width of 760 pixels. This accounts for any browser “chrome” like a scroll bar that would nibble into that 800 pixel total. In addition, if you’re really concerned about the total visible height of a page—often referred to as the area “above the fold” (as in a newspaper)—then a cautious estimate is 410 pixels, giving you about 760×410 pixels to work with (height is pretty tricky as I discuss below.)

A quick look around the web showed that fixed width designs aimed at 800×600 monitors range in width from 705-760 pixels. This site, for example, is designed to 760 pixels wide.

Editor’s Note: April, 13, 2007.Since this article was written, I’ve redesigned the site. It now is designed to 890 pixels wide.

If you want to bite the bullet, like a few sites such as A List Apart have, you can even design for the next larger monitor resolution: 1024×768. This affords around 955×600 pixels of breathing room. A List Apart is set to 960 pixels, while The Onion opts for 957.

Don’t design for height

It’s pretty hard to design a page whose height will always fit a visitor’s browser window. There are a lot of elements that can potentially eat away at the amount of vertical space a browser can display: location bar, status bar, bookmarks bar, menu, tabbed browsing, the Taskbar on Windows, and the Dock on Macs. The safest assumption is that the top few hundred pixels (up to about 410) will be visible to any one visitor. So make sure that anything someone HAS to see fits within that space: so don’t hide your incredible, must-have, offers below this region, or visitors may quickly pass them over. What’s worse is a page proclaiming the virtues of being a member of the Web site, but hiding the “Sign up to be a member” link below the visible part of the page, so users have to scroll just to join. Most won’t.

If you want to get a rough (very rough) approximation of what your site looks like in different size Web browsers try this online tool.

Nov122005Don’t miss these podcasts!

If you weren’t fortunate enough to get down to Sydney,Australia for the 2005 Web Essentials conference, you can still tap into its collective wisdom via podcast. Web Essentials included presentations and workshops from some of the most influential thinkers, writers and practitioners of standards-based Web design (I guess my speaker invitation must have been lost in the mail.)

The WE2005 organizers and presenters were generous enough to let the world listen in on the thoughts of these great speakers. You can download the podcasts at http://we05.com/podcast/. In addition, many of the presentation materials and slides are available from the site.

It’s like having a $2000 conference right in your living room!

Oct122005The versatile <label> tag

The <label> tag is a useful addition to your web-form toolkit. It’s intended to provide a text label for a form element—for example, “First Name” next to a text field used to collect a visitor’s name. The <label> tag associates the text with a form field, thus providing a clear description of the field’s purpose. This makes the form more accessible as well.

But as an added benefit, many Web browsers treat the <label> tag as an extension of the clickable area for checkboxes and radio buttons. In other words, you can click the label to select a radio button or checkbox. See for yourself:

(Sorry Safari users, this neat feature hasn’t been added to that browser, yet. Try it in Firefox.)

In addition, other types of fields are given “focus” when their labels are clicked. For example, clicking a label for a text field, places the cursor into the text field—just as if you’d clicked in the field itself. Try it here:

Best of all adding labels, is a piece of cake. Dreamweaver 8, for example, can help with the process (you just need to make sure the “Form Objects” box is checked in the “Accessibility” category of the Preferences window.)

Adding the code by hand isn’t any trouble either. You can either wrap a <label> around a form element like this:

<label>Name:
<input type="text" name="textfield" />
</label>

Unfortunately, only Firefox reliably treats the label text as clickable using this method. A better approach is to use the <label> tag’s “for” attribute to associate the label with the form field. For this to work, you need to add an ID attribute to the form field, and then use that ID as the value of the label tag’s “for” attribute like this:

<input name="opt-in" id="optBox" type="checkbox" value="check" />
<label for="optBox">This whole label is clickable!</label>

Jul202005Search Engine Optimization Revisited

My last post talked about one of the key ingredients to high-placement in search engine results—in-bound links. The more sites that link to you, the more popular your site is, and the higher your SERP—search engine rank position. I also suggested that your Google Page Rank is a good determinant of that. Unfortunately, I appear to be wrong.

Last week I attended Web Visions 2005, a yearly conference dedicated to analysing, promoting and understanding the Web. One session, “Search Engine Optimization and Web Standards” presented by SEO expert Alan K’necht provided clear insight into how search engines work, and what you can do to make your sites more “search engine friendly.” First, apparently the Google Page Rank is neat and all, but has little relation to your placement in the search results.

However, he did make some very important points about what helps and what doesn’t help improve your search engine attraction factor. Here are a few rules of thumb (circa July 2005.)

What helps:

  • Words, words, words. Search engines eat them up, index them, and use them to judge the value of your site. In fact, the ratio of actual content to other coder fluff like CSS, JavaScript code and excessive HTML tags, is important. Search spiders don’t always index and entire page, so you need as much textual content available as possible. Ideally 40-50% of a page should be text.
  • The position of words. Words at the top of the page are given more weight than your concluding paragraphs.
  • Emphasized words. Believe it or not, adding bold or italics around a word, not only gives it more emphasis for your human readers, but it’s also important to search bots. But don’t over do it. You’ll be penalized if EVERYTHING is bold on a page.
  • Make the page title descriptive. Too often, a page’s title will be generic—a company’s name, for example —instead of descriptive of the page’s content—”How to build a sand castle.”
  • Use the <h1> tag. Use an <h1> tag, but ONLY one, on a page. Also place it very near the beginning of the page, and make sure it’s descriptive too. Using other headers too, like <h2> and <h3> to organize sections of your page is also a good idea.
  • Meta-tag: description. A description of your page is used when your page is listed in search engine results. But it’s also analyzed by search bots to get an understanding of the page. Keep it short and descriptive.
  • In-bound links. Obviously. You need other sites to link to your site.
  • Site architecture. Apparently, search engines put some value to directory and file names, so they should be descriptive of the content they contain. In addition avoid using more than 2 dashes in a file name.
  • Make links descriptive. Don’t use “click here” for link text. Use words that clearly indicate what the link leads to: for example, “directions to AAA Co.”

What doesn’t help

  • Flash. Search bots don’t index Flash movies. Some can crawl Flash movies and follow links within them, but they don’t read the words contained in the Flash movies.
  • Meta-tag: keywords. Keyword metatags were once used by search engines. But, saavy Web masters learned they could increase a page’s SERP, by adding words that weren’t even related to a page’s content inside the keyword meta-tag. Now most search engines ignore these.
  • Graphics. Search-engines can’t read text in a graphic (think navigation buttons), nor do they read the “alt” property either.
  • Deeply nested tables. If you’re still designing your site with lots and lots of tables within tables. It’s time to get on the CSS-tip and change how you layout your pages.
  • Lots of code. Any code you can place in an external file, like CSS stylesheets or JavaScript routines, should go in an external file.
  • Font tags. These just add code and get in the way. Switch to CSS now!
  • Cookies. If your site depends on cookies to function, a search bot may skip right by.
  • Forms. If you require people to fill out a form to access parts of your site, you’re guaranteeing that those areas of the site WON’T be indexed by search engines.
  • Too many parameters in a URL. If your web-site is all tricked out with the latest and greatest database-driven, server-side magic, be careful that it doesn’t produce URLs like www.example.com/?id=948578978129&name=bob&sessionID=84787837&this=that. Many search engines steer clear of this unfriendly URLs. There are solutions for unfriendly URLs.

These are a handful of the tips from Alan’s session. Keep in mind that Search Engine Optimization is an ever shifting target. The major search engines are always refining the algorithms they use to determine which sites should win the search wars, so these tips (good in July 2005), may be obsolete in 2006. For more information on SEO, you can find SEO resources on Alan’s site.

Categories

Archives

Buy them today!

Dreamweaver 8: The Missing ManualCSS: The Missing Manual