Rob Huddleston's Blog - Web Design

Ems versus Percents

Thu, 19 Mar 2009 14:53:00 -0600

Recently, a post came through on the Yahoo! Dreamweaver list about ems versus percents for sizing in CSS. Basically, the question was whether or not there was actually a difference between them and whether or not it mattered which one you use. This comes up quite a bit, and I can completely understand how it can be confusing, so I thought I'd share my thoughts on the issue. I want to start with an explanation of what, exactly, an "em" is. An em is a unit of measurement defined as the height of the given font; specifically, it is (at least in theory) the height of a capital "M" in the font. In practice, that means that one em = the font size, so if you have your font size set to 16 pixels, 1em = 16px. If your font is set to 12 points, then 1em = 12pt. However, in 16px text, 100% is, obviously, 16 pixels. If your font is at 12 points, then 100% is 12pt. And that's the root of the question: if 1em = the size of the font, and 100% = the size of the font, then what's the difference? The answer is that when dealing just with font sizes, there isn't a difference. If you have your body's font set to the browser default (16px for most browsers), then there is no difference at all between setting your h1 to 120% or to 1.2em. They are identical. Box sizes, though, are a different creature altogether. Percentage widths on a box refer not to the size of the font, but to the browser window. So if I say that I want my "mainContent" div to have a width of 80%, I'm saying that I want it to span 80% of the browser window, however big that may be. But it's also legal to say that I want my "mainContent" div to be set in ems. So I might decide to set the div to, say, 48em. And here's where the power of ems comes in. Assuming that I'm using that browser-default 16px, then a box with a width of 48em would be 768 pixels wide. But ... and here's the trick behind using ems ... if you then resize your *text*, the box will also resize. Why, one might ask, would you want to do that? Quite simply, for accessibility. It's not about YOU, the designer, resizing text. Rather, it's about tying your design to the browser's resize text functionality - an important accessibility tool. You can actually see this in action. Using Firefox*, visit both cnn.com and yahoo.com. On CNN, resize your text (View -> Zoom -> Zoom Text Only, then View -> Zoom -> Zoom In or ctrl-+)**. Then do the same thing on Yahoo's homepage. What you'll see is that CNN's layout breaks pretty quickly, since their layout is pixel-based, but Yahoo's does not - their boxes expand with the text. *You need to use Firefox for the above example because IE's text resizing feature only allows for resizing if the font size on the page is set in percents or ems, and CNN's is not, so the text will not resize. ** Until very recently, Firefox defaulted to only "zooming" text when using ctrl-+ and ctrl--. I'm not precisely sure when they switched to zooming the whole page (including graphics), which IE has been doing since version 7 was released, but I know that it was very recent - one of the dot releases since 3. I'm personally not a fan of zooming the whole page. If I'm on one of those blogs designed by a moron who is using 3 point text and I need to make the text bigger to read it, I don't want the whole page to expand to the point that I have to scroll left and right and to the point that the images pixellate, but the browser designers forgot to ask my opinion before they changed the feature. So I hope that helps explain things a bit. By the way, in DW CS3 and CS4, the starter pages contain a bunch of layouts called "elastic" that size their boxes using ems for exactly this reason, so you might try playing with them to see what happens. For example, change the font size in the CSS for one of the sidebars and watch what happens to its width. The book "Mastering CSS Using Dreamweaver CS3" (or the CS4 version) has a chapter on using these layouts. (Stephanie Sullivan, one of the co-authors of the book, actually created all of those starter pages, so she knows of what she speaks.)

The two biggest mistakes made by designers with hyperlinks

Fri, 06 Mar 2009 18:00:00 -0600

The web was originally developed, at least in part, to provide a means by which documents can be linked together. Hyperlinking is one of the very first things you learn when you get started in web design. Yet, as with a lot of other things, a lot of people consistently get it wrong when working with links.

I'm going to cover two basic, but common hyperlinking mistakes here. The first is used to be much more common than it is today, but it still exists: not using logical text for the hyperlink. "Click here" was perhaps the first cliche of the web - a sure sign that a designer wasn't really thinking through their pages. I hesitate to go right out and call it lazy design, but ...

One of the blogs I follow every day is scottkelby.com. Scott, in case you're not familiar with him, is the President of the National Association of Photoshop Professionals. He's also the best-selling computer book author out there. More important, at least in my eyes, is that Scott is also the grand-poobah when it comes to Photoshop knowledge. If you use Photoshop at any level and want to get better, you owe it to yourself to so as I have done and add his blog to your daily read list. I have nothing but complete respect for Scott, but that said, there is one thing that I wish Scott would change: his approach to links. Take a look at the screen shot below, taken from Scott's blog today (March 6, 2009):

See what he's doing there? He's not using the words "click here", but he might as well be with that "Here's the link" at the end. What purpose does that serve?

There are several problems with the "click here" or "here's the link" approach. To begin with, it's a bit insulting to your reader, if you think about it. They know they're supposed to click; they know it's a link. So why tell them. It's kind of like giving someone directions to a store in the mall by saying, "OK, so you need to go out in the mall, turn right, and then go downstairs. Oh, and by the way. That big hole in our wall? That's the door. You need to go through it to get started."

Instead, wouldn't it make a lot more sense to just link the relevant phrase in your text to the page in question? Take the second paragraph from scottkelby.com above: instead of the useless "Here's the link" stuff, why not just link the words "check out the work of photographer Loretta Lux."

That approach is also a lot cleaner. It reads better. It's more accessible: a screen reader will often present all of the links on a page to the user separately. Often, a blind user on Scott's page would be presented with a list of links that all said "Here's the link", and have no way of knowing which one belongs to what text. Oh, and one more key element: search engines like Google do a lot of their indexing based on the text provided by links. Having a site as prominent as Kelby's link to yours would be a big boon for search engine rankings, but unfortunately for Ms. Lux, most of that boon is lost because Google is going to index the words "here's the link" with her page, not the much more important words like her name or the fact that she's a photographer.

So please, take a moment to think about your link text. I'm going to go so far as to say that there is never, ever a time when you need meaningless "click here" text. If you think you have an example where it's simply impossible to word the text differently to get rid of it, let me know in the comments. I'm willing to bet that I can come up with a rewording that will make more sense.

The second problem I want to mention here, and the one that actually inspired this post, is much newer, and unfortunately becoming much more prominent these days. Ironically, in many ways, it's an offshoot of fixing the problem above. If you are going to have words in the middle of a sentence serve as your link, please make sure that the text is obviously different! Here's the example that made me decide I needed to write this post:

There are two links in that paragraph. Can you find them? If you were to visit the actual page from which the screen shot was taken, you could of course hover over each word with your mouse, waiting for it to change into the hand and let you know there's a link. This is in fact exactly what I had to do when I visited the site: I could tell from the context that there should be a link in there somewhere, but I certainly couldn't see anything, so I had to start mousing over stuff. Seriously? In what design school, exactly, is it being taught that you should make your links into some sort of Easter egg hunt?

In the original design of HTML, links were to be blue and underlined. Blue was chosen most likely because it is the darkest color that is most obviously not black, while underlining links made sense because no real designer would use underlining for anything else. But both were there because it was understood that it's important that links stand out: that there be contrast between them and the surrounding text.

Link many designers, I'm not a huge fan of underlining links on things that are obviously navigation: look at the sidebar to the right of this article, and you'll see that the link's aren't underlined. That's because I believe that it's obvious from the context that those are links, and because in every case, the entirety of the text in question is a link.

The body of a document in a difference story, however. Assuming that you read and took to heart the whole first portion of this post, you know by now that your links should be embedded seamlessly within your text. However, they still need to stand out. So I will always underline the text of the links in the body of a page when I create it from scratch, as well as making them an obviously different color. Rob Sommers, however, pointed out (correctly) that this blog actually contradicts that, since as you can clearly see links in the body on this page are not, in fact, underlined. So the correct statement would be simpler: just make sure that the links are the page are nice and obvious. Underlining is probably best; making the text bold I think works well, too (although if you disagree - if you think that the links within the text are hard to find - please let me know in the comments.)

So there you have it. Rule #1 for linking: link meaningful text, instead of garbage like "click here" or "here's the link." And rule #2: Never make your users have to search for that link within the text.

New Features in Photoshop CS4

Thu, 15 Jan 2009 23:54:00 -0600

So I have to admit that I may have been a tiny bit wrong about Photoshop CS4. OK, I was very wrong. I've been telling a lot of people recently that there are a ton of reasons to consider upgrading to CS4 ... if you use Dreamweaver, Flash, Fireworks, or Illustrator. But if you're a Photoshop user, well, I hadn't really seen much to be impressed with.

Well, I was wrong. It turns out that there are a ton of really great enhancements in Photoshop. The problem, I think, is that none of them are terribly flashy. But that doesn't make them any less impressive.

Something that's been fairly frustrating for me throughout the whole transition to CS4 is that most of the things that are new in all of the programs are things that require me to rethink my workflow. Dreamweaver's Live View, Live Code and Related Files features, for instance, have saved me more time than I can count, but it took some time to get it stuck in my head, because in order to use them, I had to change the way I do things. The new animation model in Flash and the Motion Editor have likewise forced me to rethink my entire approach to creating animation. And I'll admit that I still don't think of Fireworks first when I need to wireframe a web site, but I'm trying to get there.

Photoshop's new features fall into the same category. I haven't really discovered them because I've been trying to use Photoshop the way I always used it in the past. But now I need to take a new approach to a lot of things, and that's going to take some getting used to. But it will be worth it. Just as I can't count the hours I've saved thanks to my new workflows in Dreamweaver and Flash, I know now that forcing myself to relearn how I edit images in Photoshop will be worth the effort.

Okay, now I know you're sitting there, screaming at your screen, "JUST TELL ME THE FREAKING FEATURES ALREADY!" Well, you really shouldn't yell at your screen. I can't hear you, and it will hurt your monitor's feelings. Besides, I have no intention of telling you what the features are. I know, it's mean. It's partially because it's a little bit late, and I really want to go watch Grissom's final episode of CSI, but mostly it's because I don't have to. Instead, I'm going to let Scott Kelby do it. Enjoy!

P.S.: Here's the link to the second and third parts of the series. As of when I'm writing this, he hasn't posted the fourth part yet.

Edit: They have now posted part four.

Creating a Paginated Photo Album in PHP

Tue, 30 Dec 2008 12:39:00 -0600

A recent question on the Yahoo! Dreamweaver group asked about creating a photo album using PHP. In particular, the member who posted the question wanted the ability to add navigation to the bottom of the page reading something like "Page 1 of 75", "Page 2 of 75", "Page 3 of 75. "

The member mentioned that he had tried using PHP for this, but had not been successful. He didn't say why the original PHP solution didn't work, but a server-side language is definitely the solution here. While many of you know that PHP isn't really my language of choice, since the original question specifically mentioned PHP I'm going to give the answer in that language.

Step 1: The Database

First off, we need a database. I know, the mere mention of "database" is enough to send many folks screaming from the room, but bear with me. This is the simplest database you're ever going to need to create. Again, because we're talking PHP here, we'll go with MySQL - although in this case I'll have to admit I'd use MySQL even if I was using some other language instead. All you need in this case is a single table, which to be really creative we'll call "Photos" for the sake of this tutorial. The table needs to only contain two fields: a primary key of some kind and a field to hold the path to the image. (If you don't know what a primary key is, click the link on the word in the last sentence. Or just trust me that you need it and don't worry about what it really is. Either way works.) Let's call them photoID and photoPath.

If you're completely new to databases and I've already lost you, don't worry. All you need to do is log onto your web hosting account and rummage around until you find the utility that they've provided to allow you to administer your database. When you open that up, there's a 99.999% chance that they're using something called phpMyAdmin, which for reasons I can't fathom a lot of people love. In there, click the link to "Databases", and you'll see a link to "Create New Database." Click it. (This would, admitedly, be a lot easier if the people who designed phpMyAdmin had ever taken usability or design into account for even a second. I should mention in the interest of fairness that there are many other, better, easier to use admin tools for MySQL, but that's a much longer topic than I'm willing to get into here.) Give your database a name, something like "PhotoDB". Once it's created, the page (should) refresh and you (should) see the new database over on the left side of the screen, in that hideous greyish-blue bar. Click the database, and you'll see a text field to create a new table. Type a name (try "Photos". Honest - try it. You'll love it.), say you want 2 fields, and then click Go. (It's way the hell over on the other side of the screen, instead of being anywhere that might make sense.) In the first column, type the name of the first field (photoID). Set the data type to INT. (It means integer, but you don't have to actually worry about that.) Ignore the next few oh-so-confusing choices, and click the drop-down box next to "Extra", from which you'll select auto_increment. In the second column, type a name (photoPath), and just leave the rest of the fields as-is. Once again, hunt around on the screen for the well-hidden "Go" button (again, way to the right), click it, and you're done. That wasn't so bad, was it?

Oh, in all of the steps above, when you're naming things like tables and fields, don't use spaces.

[More]

CS4 Now Shipping

Wed, 15 Oct 2008 13:48:00 -0600

Adobe announced that the CS4 products are now shipping, so get your copy today!

CS4

Tue, 23 Sep 2008 11:40:00 -0600

This morning, Adobe officially announced the CS4 product line. There's a ton of information online about it, but I'm going to try to coalesce the most important bits here.

First off, the actual editions. Just as with CS3, there are six packages of CS4 you can get: Design Premium & Standard, Web Premium & Standard, Production Premium, and Master Collection. Design Premium (the one that I suspect the majority of folks will want) includes InDesign, Photoshop Extended, Illustrator, Flash, Dreamweaver, Fireworks, and Acrobat 9. The Standard edition includes only the regular version of Photoshop, InDesign, Illustrator, and Acrobat. Web Premium contains the new versions of Photoshop Extended, Illustrator, Acrobat 9, Flash, Dreamweaver, Fireworks, Contribute, and (in a change from CS3) Soundbooth. Web Standard is basically the old Macromedia suite: Dreamweaver, Flash, Fireworks and Contribute. Production Premium has Photoshop Extended, Illustrator, Flash, After Effects, Premiere, Soundbooth, OnLocation, and Encore. And the Master Collection has everything. All of the suites also include Bridge and Device Central, and all except the Production Premium include Version Cue.

Pricing seems similar to CS3: Design Premium is $1,799, Web Premium and Production Premium are $1,699 each, and Master Collection is $2,499. (All of the above are US prices. Yes, overseas prices are higher. No, I don't want to get into why.) Adobe is introducing a new two-tier upgrade policy, whereby it will be cheaper to upgrade from CS3 than from older versions. Also, they have a three-versions-back policy, so if you have Illustrator CS, CS2, or CS3 you can upgrade, but if yours is older than that, you can't. You can upgrade from your Mac edition to a Windows edition if you've switched since your last purchase and you can switch to another language if you need to. You can upgrade to Dreamweaver CS4 from GoLive, Illustrator from Freehand, and InDesign from PageMaker. And yes, the educational pricing is still available. Oh, and yes, there is a policy in place that will provide a free upgrade to CS4 if you have recently purchased CS3, but unfortunately the page that details that policy doesn't state the exact date after which you have to have purchase CS3 in order to qualify. I'm trying to get that date from my Adobe contacts and will post a note here when I do.

As for details of the new features ... they are for the most part huge. Over the next few months, I will be doing a series of demos and user group meetings and possibly even video trainings of what's new in the products about which I'm most familiar (Dreamweaver, Flash and Photoshop will be first up), so stay tuned. You can of course visit the individual product pages (simply go to www.adobe.com/go/product_name) to see a list of some of the key features.

And then the last question I know everyone has: when can you get your hands on these? Adobe is mum as to an exact release date - all they are saying now is "mid-October." And trail versions should be out about a month later, so around mid-November.

Adobe to announce CS4 on Sept. 23

Wed, 03 Sep 2008 12:41:00 -0600

Adobe is going to official unveil CS4 on Sept. 23. Specific details - including things such as which products exactly will be included in CS4 and when exactly it will be released - are still not available, and are in fact exactly what will be announced on the 23rd.

If you live in the San Francisco Bay area, you can attend a special joint meeting of the bay area Adobe user groups on Sept. 30 to get your fill of CS4 goodness. Stay tuned here for more details on that.

My user group in the Sacramento area will also be holding a CS4 announcement event the following day - Oct. 1. Again, check back here or take a look at our website for details in the coming weeks.

If you aren't in either of those areas, then I'd urge you to find a local user group. Most user groups around the world will be holding events in the week or so following the 23rd, so don't miss out!

The difference between and

Wed, 03 Sep 2008 11:08:00 -0600

The question came up on one of the Yahoo! groups I frequent as to when you should use to make text bold and when you should use . In particular, it was asking when the latter exists at all. So here's my explanation.

The difference between and is that simply tells the browser to make the text bold, without telling the browser why the text is bold, whereas tells the browser that the text is bold because it is being strongly emphasized.

The theory here is that if you use or or any other markup that focuses solely on what things look like, you are not building any logic into your page as to why things look that way. In particular, you are not considering the needs of those who may not be able to see your page, such as blind users who rely on a screen reader (or Google, for that matter - the largest "blind" user on the web.)

There are several reasons why text on a page might be in bold. One is for purely visual effect - you want the company name to stand out a bit, for example. The other is for emphasis.

Consider this example. You have a sentence where you want the company name to be bold - just because - and then a word in the sentence to be bold for emphasis. You could just use :


Here at Some Company, we take pride is serving your needs.

Or you could use logical, semantic markup:


Here at Some Company, we take pride is serving your needs.

Of course, when rendered in the browser, the two are identical (assuming that your style sheet sets the companyName text to be bold (.companyName{font-weight:bold;}).

Here's the first sentence, using :
Here at Some Company, we take pride is serving your needs.

Here's the second, using the styles and :
Here at Some Company, we take pride is serving your needs.

So they look the same, but are in fact very different. If you read the sentence out loud, you wouldn't read the company name that happened to be in bold any differently than the surrounding text, but you would read the word "your" differently - you would emphasize it. That's because as a sighted user, you can see that one is bold for visual effect, and the other is bold for emphasis. But a screen reader is just a piece of dumb software - it can only do what you tell it. If both are marked up with , a screen reader has no way to telling one from the other, and it will in fact emphasize the company name, causing the sentence to sound strange when read. Instead, if you use the semantic markup of the second example, the screen reader will simply ignore the style sheet, and read the company name normally, while it will know that the word "your" should be emphasized.

Does that make sense?

There's another reason why the second example is better than the first. Later on, when the boss comes along and says that she wants the company name to be both bold and a different color, all you have to do is update the style sheet if you're using the second method. Because every use of the company name already has the span and the class around it, you can instantly add the color or any other formatting to the company name text - globally throughout your site - without having to dig into the code to find them. If you took the "easy" way out at first and simply wrapped the tag around it, then not only do you have to add the style, you also have to go in and find each instance of the company name in the text and wrap the span and class around them, hoping you don't miss one. Then when you show the boss the site again and she decides that she actually doesn't like the bold, you once again have to go in and find each instance of the name and remove the if you're using the first method. Again, if you had started with the styles, you can simply edit the style sheet and be done.

Sierra Adobe User Group Present: Dreamweaver CS4 Preview

Mon, 04 Aug 2008 11:37:00 -0600

This Wednesday night (Aug. 6), the Sierra Adobe User Group is going to be having a preview of the next version of Dreamweaver, presented by yours truly.

The meeting is scheduled to start at 6:30 PM Pacific time. We will be broadcasting the meeting online, so everyone anywhere is welcome to join us. You can get details, RSVP, and find a link to the online meeting room at our website, www.sierrammug.org.

Hope to see everyone there!

Setting up a local email testing server

Sun, 27 Jul 2008 19:37:00 -0600

If you do any sort of web development, you are likely going to run into situations where you need to have your web application send email. While the process of setting up your server-side script to send the email isn't difficult, testing it can be. In the past, I have always simply uploaded the script(s) to my web host and tested it live. While that worked fine for my development projects (although it was always a hassle), it didn't work so well in classes.

I finally decided that the topic was important enough to do a little research and see if there was a way that I could set something up on a local machine to test sending email, and it turns out that it was almost ridiculously simple. A quick Google search for "free SMTP program" brought up a bunch of results; I'll be using a program called, strangely enough, Free SMTP Server. I think it was the first or second hit on Google, but I found something that worked for what I needed so I didn't bother investigating any further.

Once you have the program downloaded and installed, you're pretty much done. Go into the configuration settings for your language of choice. If you use ColdFusion, open up the ColdFusion Administrator and go to the Mail page. If you're a PHP person, open up php.ini. Either way, simply make sure that the mail server is set to "localhost" and the port is 25.

That's it. (Well, if you use PHP, you need to restart your web server.) For ColdFusion, simply create a cfmail tag:



#form.body#

In PHP, it'll be as easy:


$to = $_POST['email'];
$subject = $_POST['subject'];
$body = $_POST['body'];
mail($to, $subject, $body);

Note that while this is a great solution, it only sends the email - it doesn't receive it. That's because SMTP is only for sending mail. Receiving it requires an POP server, and that's a whole different ballgame. However, as long as you use a real, valid email account in the "to" field, you should be able to test this with no problems.

Extremely cool piece of web history

Tue, 15 Jul 2008 01:41:00 -0600

This is pretty cool: a phenomenal piece of the history of the web. On February 25, 1993, Marc Andreesen, then still merely a part of the software development group at the National Center for Superconducting Applications, posted this message on the WWW-talk chat group proposing a "new optional HTML tag: IMG". Yup, here it is - the introduction of that which would truly set the web apart from Gopher and the other applications of the internet.

(Oh, and can I just say that I was also shocked when I looked up Andreesen on Wikipedia for the link above and discovered that he's only just over two months older than me?)

Dreamweaver CS4 Preview - Change of plans

Mon, 14 Jul 2008 13:56:00 -0600

I had planned on doing a series of posts here on detailing the new features you'll find in the Dreamweaver CS4 beta. The original goal was to do one main feature per week or so. But those of you reading along here may have noticed that that hasn't been happening. It didn't happen in large part because I have ended up needing to spend a lot of time over the last week preparing for my upcoming presentation at the Creative Transitions Conference in Milwaukee, where I will be speaking on ... Dreamweaver CS4. (I'll also be giving my "good form design" presentation that I did at TODCon and that I'll be doing again at MAX.)

So the best way to find out about what's new in CS4 would be to come to the conference. You can head over to the conference website to register. In addition to the 1 hour presentation, I'll also be doing a 3-hours hands-on demo of CS4 on the last day of the conference, so you'll not want to miss that.

If travelling to Milwaukee won't work for you, there are two other ways you can get the information. One is to sign up with my Adobe User Group and then attend our meeting on August 6, during which I'm going to be giving this presentation (sort of a dress rehearsal for the conference.) Don't worry if you're not local - you can attend the meeting online (details are on the site.)

You can also wait until just after the conference, when I'll be posting the presentation assets here on my site. I'll post here when those are online and provide a link to them.

Dreamweaver CS4 Preview - Feature #2

Mon, 23 Jun 2008 21:37:00 -0600

It's taken me a bit longer than planned to get back to previewing Dreamweaver CS4. I'm going to try to keep these coming about once a week, although no promises there...

The second new feature I want to preview isn't really a new feature, but rather a vast improvement on a long-time staple of Dreamweaver: the Property Inspector. Originally, the Property Inspector enabled users to quickly apply formatting to text (among other things.) However, the advent of CSS formatting - and more correctly, Dreamweaver's overdue switch to CSS-based formatting with the MX2004 release - posed a challenge. Unfortunately, the traditional approach to formatting presented on the Property Inspector didn't mesh well with CSS, leading many folks (such as yours truly) to actually begin recommending that it not be used for formatting text at all. You can easily tell a page creating using the fundamentally-flawed Property Inspector present in the last several versions, thanks to the overabundance of poorly named classes: .style1, .style2, .style357, etc.

Fortunately, those problems are a thing of the past with CS4. The Property Inspector has now been split into two sections: HTML and CSS. The HTML tab presents the options familiar to long-time Dreamweaver users: you can make text into a heading, apply an ID, make text bold or italic, or create a link.

A click of the CSS button on the right shows off how much work the Dreamweaver team put into not just re-engineering this, but really in thinking it through. You now have a "Targeted Rule" drop-down to make sure that you apply styles to exactly the element you need. You can click Edit Rule to to modify an existing rule or create a new one. And best of all, when you try to simply apply a style directly to text by changing the font or applying a color, a dialog box opens that prompts you to apply an appropriate name to the style.

This new approach will definitely take some getting used to, and will be more difficult for brand-new users who do not really understand CSS to get started with, but I for one think that's a more than acceptable pay-off if it means that everyone will end up with better pages in the end.

I do have one beef with the new Property Inspector, and in my eyes it's a huge over-sight on the part of the team that I think is going to lead to a ton of headaches over the next few years while we wait for the next version after CS4, but nobody's perfect, right? The issue is that the new Property Inspector defaults to the CSS tab rather than HTML. The beta of CS4 has only been out for a month, and I have already lost count of the number of folks who think that they've lost the ability to add links to text directly from the Property Inspector. It's not at all obvious that the HTML section exists, particularly because the buttons to switch between the two modes don't look at all like buttons unless you mouse over them. I can already foresee the need to have a little snippet on my desktop that I can just paste into forums to answer folks when they ask how they can add links now. I sincerely hope that the Dreamweaver team looks at this, sees all of the confusion it's causing, and decides to change the default before the final release of the program.

Still, that problem doesn't negate the fact that the Property Inspector is a huge improvement over past versions.

Dreamweaver CS4 Preview

Tue, 10 Jun 2008 13:23:00 -0600

A few weeks ago, Adobe posted a public beta of the next version of Dreamweaver to their labs site. I think that it represents the most significant changes to the program in many years - probably since Dreamweaver MX. Over the next few weeks, I'm going to do a series of posts on what I feel are the most significant new features in CS4 in the hopes of getting folks ready for the release.

First, though, I did want to anticipate a question that I know is going to come up: no, I do not have any knowledge as to when CS4 is going to be released. Adobe, as with other software companies, is very tight-lipped when it comes to release dates for software. There was a recent dust up online when a reported claimed to have heard that the CS4 release would be in October of this year, but Adobe has flatly denied that. To be honest, I think that an October or November release is probably what they are aiming for. I can base this guess on two things: 1) Adobe has traditionally released new versions of Creative Suite software every 18 months or so, and 18 months after the April 2007 release of CS3 would be in the October/November range; and 2) with CS3, they released a public beta of Photoshop roughly 6 months before the final release, so it would make sense that this cycle's public betas - Dreamweaver and Fireworks this time - would be released about 6 months out, so that again puts it in October or November. But I want to stress that these are merely educated guesses on my part. I have no "insider" knowledge of the release dates for these products, and it is entirely possible that things could happen to get them out the door sooner or later than that.

OK, now that the disclaimer is out of the way, let's start with the first new feature of CS4: the interface. Photoshop, Illustrator, InDesign and Flash all got an interface make-over with CS3, but Dreamweaver and Fireworks did not, so this time around, both of them are rejoining the family, so to speak, with the overhaul. (I will be posting a separate series on new Fireworks features, by the way.)

At first glance, the new interface may be a bit intimidating, as it is the biggest refresh of the IDE since MX. After you play around with it a big, though, I think you'll find that it isn't so radically different that it's hard to use, particularly if you use any of the other applications in the Suite. The two most obvious changes at first glance are that there's no title bar in the application anymore and that the Insert panel has gone over to join the other panels on the right.

The lack of a title bar across the top of the screen is a big change visually, but not something that I think will effect anyone's workflow. If anything, it probably helps since it gives us another 20 or so pixels of actual work area. The insert panel is a bigger issue, as in my opinion in becomes much more difficult to use when it's living over with the other panels, but the good news is that you can "fix" this: simply grab the Insert panel by its tab and drag it to the top of the screen. When you release the mouse, not only will it pop into place where it should be, but it will also switch to the tabbed view that we're all used to.

The rest of the panel set over there has another new feature that I think is of questionable value in Dreamweaver, but I'll share it anyway. If you look in the extreme right corner of the panel set, you'll see a little double-arrow. Click there and the panel group will collapse down to a set of icons and labels. Now, drag the left edge of the group to the right, and they will collapse further so that they are just icons. This so-called "iconic" mode (I don't particularly like that word, by the way, since it sounds silly) saves a ton of space. You can click on the icon of any of the panels to it pop out so that you can use it. As soon as you click away, the panel will disappear again.

I guarantee that when CS4 ships, Adobe is going to make a big deal about this feature. While I can see its value in programs like Fireworks and Photoshop, I honestly don't like it in Dreamweaver. The problem is that in Photoshop, for example, I only need to use the Layers panel every now and then, so being able to collapse it out of the way helps. But in Dreamweaver, I can constantly needing to reference the Files and CSS panels, so having the extra clicks to activate them and having them cover a portion of the document while they are open is more of a hindrance. So while I am excited about the "iconic" panels in the graphics programs, I doubt I'll ever use it in Dreamweaver.

Another interface change is the addition of a bunch of new workspaces. Up in the top right corner of the screen, you'll see a drop-down that will by default by set to DESIGNER, but contains a set of pre-built workspaces. These are nothing more than panel arrangements, but several of them are pretty helpful. The Designer workspace gives you the Insert, Files, CSS and Property Inspector panel groups, which are all that many designers need. The App Developer, on the other hand, drops the CSS, Insert and PI panels and just gives you the Files and Application panel groups. For some reason, the Dreamweaver team has always felt that "developers" or "coders" prefer to use left-hand panels, so they are over there. Whatever. I suspect that most folks will probably settle on a single workspace, but for those that wear many hats, this might be useful. As before, you can also create your own workspace. Oh, and there is a "Classic" workspace that automatically docks the Insert panel at the top of the screen for those of us adverse to change.

The last new interface feature to point out here is the new Vertical Split. Lots of folks like and use the Split feature in Dreamweaver, which divides the screen between Code and Design view. Personally, I'm not a big fan, but I can see why some would be. Well, after years of being asked for it, the Dreamweaver team has finally given us the choice to split the screen vertically as well as horizontally. Simply go into Split view, then click View -> Split Vertically. This is a "sticky" option, so if you go back to Design view, for instance, and then return to Split, the vertical split will still be there. The other thing that they have done at last that should make folks happy is the ability to choose whether you want the Design view to be on the top (or left) of the split or the bottom (or right), which should again please a lot of folks.

That's all for today's preview. I'll be back soon with a look at another new feature. In the meantime, why don't you do ahead and download the beta and start exploring on your own?

Top Ten(ish) Mistakes Made by Beginning Web Designers

Wed, 04 Jun 2008 19:24:00 -0600

I spend a good deal of my time on several Yahoo forums related to Dreamweaver - both "newbies" and general users - and HTML. I see a lot of the same questions come up on the forums; in fact, one of my motivations for starting this blog was to have a central place where I can post common answers to common questions. But I also see a lot of the same mistakes coming up over and over on sites, so I wanted to take a moment here, climb up on a soap-box, and present a list of the Big Mistakes I see beginning designers make, and offer some ideas as to how to avoid them. Before I start, I want to say thanks for Steph for giving me some more ideas of mistakes to post here. As usual, you rock.

Not using heading tags

The default display of headings is way too big. No one can deny that. But guess what - the tiniest bit of CSS allows you to resize headings. You only need to write one line of CSS, in fact (or no lines if you use Dreamweaver's CSS panel.) And here's a news flash - CSS has been around for ten years. Yes, you read that right - ten years. For almost 60% of the life span of the web, we've had the ability to resize headings with CSS. So why in the heck aren't you using them?

There are so many advantages to using headings that I could almost do an entire post just on them, but let me just hit a few key ones. First, they make your site more readable. Did you know that the majority of people do not read web pages, but rather just scan them? (You actually did know that, because I bet you scanned this page to get an idea as to what the "top ten things" were before you started reading.) There's pretty much nothing you can do that will help readers scan your page and get the information they need quickly that is more important and easier to implement than the proper use of headings. Headings say, "Yo! Over here! I got some nice information, right here! Come on, you know this is what you want to read ... come on ... that's right ... over here ..." OK, so maybe headings aren't exactly like pushy drug dealers, but you get the point.

Second, headings improve your search rankings. Google and other modern search engines read through the content on your page and catalog it, but they need some way to figure out what your page is really about. One easy way for them to do that is to look for headings. The next time the good ole' Googlebot hits this site, it will know that robhuddleston.com should come up on a search for "mistakes" and "web designers" because that text is in a heading up there. The fact that it's in a heading 1 means that it's really important - more important, for example, then "not using heading tags", although that text, marked up as heading 2, is more important than this text that's just in a paragraph.

Third, headings just make your page look better. Instead of some disorganized mass of text, you present some nice, easy-to-read, well-thought-out content.

So use headings. But also, use headings correctly. The most important line on your page - the line that says "this page is about ..." should always be marked up with heading 1. The subtopics of heading 1 should be heading 2, while its subtopics will be heading 3, and so forth. You should never place a heading 3 directly under a heading 1 without a corresponding heading 2 between them, and of course you'd never place a heading 3 on the page by itself, right? Right?

Bad Spelling and Grammar

Whenever you think of a stereotype of a less intelligent person, what's the first thing that comes to mind? Probably, an inability to speak or write clearly. So then why do you have a page riddled with spelling errors? Worse, why is some of the text on your page almost incoherent because of bad grammar and incorrect punctuation? The web is primarily a form of written communication, and it should be treated as such. You wouldn't turn in a major proposal to your boss without carefully proofing it, would you? So do the same on every page. Reread the page - the whole page - and make sure you have spelled things correctly. Yes, you can use a built-in spell checker, but you shouldn't rely on it, because we all know that it's possible to misspell something to the point of it being properly spelled as a different word.

While you're at it, check your grammar. Grammar is as important, and in fact almost more important, than spelling. Our brains have an amazing ability to interpret the meaning of misspelled words and figure them out anyway, but bad grammar is a lot harder to figure out. If you're not good with grammar yourself, then find someone who is to proof your documents in the short term, and learn it in the long term. There is nothing that you will do in your life where a good understanding of grammar will be considered a bad thing.

Finally, please, oh please check your punctuation. Don't overuse commas. Do use periods. And please learn the correct usage of an apostrophe. "It's" is a contraction for "it is"; the possessive is "its". On the other hand, you rarely need to use an apostrophe when you are pluralizing a word, so the correct form is "web page editors", not "web page editor's". The latter one means that something belongs to a web page editor, not that there are more than one of them. "We received a lot of resumes", not "we received a lot of resume's". And by the way, it's "we sell CDs" and "we sell DVDs", not "we sell CD's" and "we sell DVD's". The apostrophe is only correct when you say "The DVD's content was subpar".

Let's pause for a moment for a quick joke. I love this one, but it only works in print.

A panda walks into a café. He orders a sandwich, eats it, then draws a gun and proceeds to fire it at the other patrons.

"Why?" asks the confused, surviving waiter amidst the carnage, as the panda makes towards the exit. The panda produces a badly punctuated wildlife manual and tosses it over his shoulder.

"Well, I'm a panda," he says, at the door. "Look it up."

The waiter turns to the relevant entry in the manual and, sure enough, finds an explanation. "Panda. Large black-and-white bear-like mammal, native to China. Eats, shoots and leaves."

The joke is actually where the title of the best book on punctuation you'll ever read comes from. It's Eats, Shoots and Leaves: The Zero Tolerance Approach to Punctuation by Lynne Truss. If you spend any part of your time writing - and I assume that you wouldn't be reading this if you didn't, since writing is a big part of our jobs as web designers, then you owe it to yourself to go buy that book and read it. The good news is that it isn't the extremely boring grammar book you may remember not reading in school. When I first heard about this book, I was listening to an interview with the author, and as soon as she referenced the chapter called "The sexy history of the hyphen", I knew it was something I needed to read. I can absolutely promise that reading this book will make you, overnight, a better writer, and as I already mentioned, that can only be considered a good thing.

Oh, and while I'm at it: "there" is a location - "it's over there"; "their" is the possessive plural - "their SUVs waste gas"; "they're" is a contraction for "they are" - "they're reading a blog about how to be better web designers".

Using Images in Place of Text

The web is primarily a visual medium, and as such images are important, but you should never use an image in place of a block of text in your content. Why? Because images load slower, they are less accessible, they make your site less search friendly, they make your site less usable on alternate displays such as cell phones, they are harder to edit ... I could go on and on, but let me ask a question instead. If you were preparing a report for work in Microsoft Word, would you go into Photoshop, type a big block of text, save the image, and then insert that image into Word in lieu of just entering the text? Of course not! That'd just be silly. But then why do you think that's the right way to go with your content on a web page?

Now, I know what you're thinking: "but Rob", you are saying (and you really shouldn't talk to your computer like that ... I can't hear you ...) "in Word, I can use Comic Sans for my font, whereas on the web I have to use Arial or Times New Roman! Eww!" Yes, that's true. You are in fact very limited in your font choices on the web. But guess what? There are two types of people in the world: those who care about fonts, and then the other 6.7 billion. I promise that no one has ever left a well-written, immensely usable, informative site because the content was in Arial or Times New Roman.

All of the above applies to your navigation bar, too. With plain text and CSS, you can create navigation bars that are every bit as attractive and functional as your image-based nav bars are now, but with the added bonuses mentioned above: they are easier to maintain, load faster, and are more searchable. Also, you can create rollover effects for your text-based navigation using nothing but CSS - no JavaScript required.

The one and only exception to this is a logo. If you have a company that's been around since the dark ages (and by dark ages, I mean pre-1990 when the web was invented), then it was most likely designed without the web in mind, so it may use some special font that isn't widely supported on the web. In that case, go ahead and display the logo as an image. Make sure you provide meaningful alternate text for it, but otherwise, it's okay. What I'm referring to here is having the main content on your page in an image, not specialty items like logos.

Placing Content-Important Images as CSS Background Images

I see a lot of confusion out there around when you should use CSS to place a background image and when you should insert the image via the HTML <img> tag. It's really quite simple, though: if the image matters for your content, then it should be inserted via HTML; if it's only there for visual presentation, then use CSS.

Before you do anything else, in fact even before you finish reading this, go get Chris Pederick's Web Developer toolbar for Firefox. (I'm just assuming that you already have Firefox and already use it as your primary browser. If not, then start by downloading and installing Firefox.) Once the toolbar is installed, load your page in the browser, and from the toolbar click Images -> Hide Background Images. This will turn off all of your background images, leaving you with just the important stuff - your content. When you hid images, did something important disappear, like your company's logo or the image that you are using to illustrate the main concept on the page? If so, then you messed up: those images should have been inserted via HTML. The opposite is true here, as well: if you hide the images and you still see that cool little flair that's setting off your headings, then you messed up there as well, since that should have been a CSS background image.

Just today, I saw a page that violated both this rule and the one about not using images for content. When I hid the background images on the page, what I got was a blank page. Guess who can't use that page? Anyone with disabilities such as visual impairment. Anyone who may be browsing the web with styles turned off. And how about the fact that no content = no Google page rank. That's not saying that you'll have a bad page rank - you won't be indexed on Google at all.

Resizing images with width and height attributes instead of a graphics program

Let's face it. Browsers are stupid. Really, really stupid. We all know it, so then why do we continue to want to pretend that they aren't? Most modern designers are aware of the fact that browsers continually choke on what seem like even simple stuff, and yet lots of folks still insist on resizing images through the width and height attributes of the HTML <img> tag. Why? When you do that, you are not affecting the image itself - it is still the size it was. All you're doing is asking this really dumb browser to go ahead and stretch it out when it displays, and then you wonder why the image looks like crap. Instead, use the right tool for the job (you're going to hear more on that in a bit). If you have an image that isn't the right size, use an image editor to resize it. It doesn't matter too much which editor you use, just so long as it's a program designed to edit graphics. Open the image in there, use its tools to resize the thing, and then insert it into your web page. You should still specify the width and height in the <img> tag, but you should only provide the correct values.

Using "click here" for Links

Thanks. I'm not sure I could have figured out that I was supposed to actually click on that hyperlink. I almost thought that this might be a special link that I could just think about really hard and magically activate.

Please don't insult my intelligence. Please do give me something useful for the description of the link.

Why say click here to view our products when view our products is more concise, more informative, and in general reads better. I can absolutely promise that there is not a single instance where you simply have to use "click here" for a link. Just spend a second thinking about it, and I guarantee that you can come up with a way to word it so that you don't need to say that. Don't believe me? Give me an example in the comments, and if I can't come up with a way to reword your link to get rid of "click here" and be descriptive, I'll send you a free, autographed copy of my new book. I'm making a realistic promise here (and one I will fulfill, by the way), but I could just as easily say that I'll turn over the title to my house because I am absolutely, 100% certain that no one can come up with a case where "click here" is really needed.

By the way, not using "click here" will also improve our search rankings.

Disabling Right-click

If you place content on the web, someone who wants to keep a copy for themselves is going to do it. There are about a million ways to defeat a no-right-click script, the easiest of which is of course to simply disable JavaScript (which can be done with a single click from that Web Developer toolbar I mentioned above.) But you need to keep in mind that "Save image" isn't the only thing on a right-click menu, and there are a ton of reasons as to why someone might be right-clicking that have nothing at all to do with stealing your content.

Here's something else to consider: have you ever been to a store where they basically treat you like a criminal? There are plenty of them out there, and we know which ones they are. I'm not talking about the Targets that have security cameras every ten feet on the ceiling. That's fairly unobtrusive. Rather, I'm talking about the stores that station an employee near the exit to check that the stuff in your bag matches the stuff on your receipt. How does it make you feel to know that you went to this store and spent your hard-earned money there, and all they can do to thank you is to assume that you must be there to steal stuff? Not so great? So then why do you want to treat your web users the same way? In my eyes the no-right-click script is more like a store that has a security guard actually follow you everywhere in the store, constantly making sure you aren't trying to steal anything and then actively getting in your way when you try to do perfectly legitimate things in the store.

So just don't do it. If you really think that your content is that special and you really think that everyone is going to try to steal it, then don't put it on the web.

Noise

When I'm on my computer, I do one of two things with my speakers: either turn them off entirely (as when I have my laptop running while I teach), or playing music. That's music of my choosing (currently, it's the soundtrack to Battlestar Galactica: Season 3. Don't laugh. Bear McCreary's scores to seasons 1-3 are some of the most incredible music I've heard. I can't get enough of them, and while I'm totally bummed that the series will be over after this year, I can't wait for the release of the season 4 soundtrack. If you like symphonic music at all, you owe it to yourself to pick these up.)

Anyway, where was I? Oh, yeah - listening to the music I want. Few things anger me more than some damned web site that feeling that their noise is more important than mine. Again, I'll use a real-world analogy: let's say you go into a store and you're on the phone or talking to the person you went to the store with or listening to your iPod, and as soon as you enter an employee rushes up and starts shouting in your ear. Do you really like going to those restaurants that blast their music so loudly that you can't hear anything else? Not too pleasant, is it? So why do you think it's okay for your site to do the same thing? Let me tell you: it isn't okay. If you have a video you want to play, fine - play it - but by default, turn off the sound. If I choose to want to listen to the sound, I'll turn it on, thank you very much. And there is never a situation where it's okay to have music playing in the background of a site by default. Again, if you want to have the music there, fine, but you'd better let me decide when and if I want to play it.

The penalty for violating this rule is simple: I will not be returning to your site. And I know for a fact that I'm not alone. It took a long time and a lot of very angry customers before sites figured out that pop-up ads only drove customers away. I hope that it will not take as long for sites to figure out that the same is true for noise.

Splash Screens

Repeat after me: the web is not print. Your web page does not need a title page. Just take me to the content I asked for, please. Honestly, splash screens weren't cool when they first started to appear ten years ago, and unlike wine, they haven't improved with age.

The web is not print. When I visit your page, I want to see your page, not some idiotic splash screen where your logo spins around like it's on crack. Just show me your content.

The web is not print.

Using Tags, Setting Absolute Sizes on Text, and Not Letting Font Information Inherit

I'm combining three out of the four big mistakes about text (the fourth being not using images in place of text) here because they are all so closely related.

The first is using the tag. Just don't do it. CSS has been around since 1996. The Clinton administration. That's when Java was introduced, IBM's Deep Blue defeated Garry Kasparov in chess, the Menendez brothers were convicted, and Whoopi Goldberg hosted the Oscars in which "Braveheart" (truly, one of the worst films to ever win) won Best Picture. Internet Explorer and Netscape were still in version 3.0 and Opera was in version 2.1. It would be seven more years before we saw Safari, and almost eight before Firefox hit the scene. Ancient history, so why are you still relying on a tag from back then? There is nothing - absolutely, positively nothing that can be done with the tag that cannot be done better, faster, and easier with CSS. So don't use it. Period. In fact, let's go one step further: raise your right hand. No, seriously. Come on, raise it. Okay, now repeat after me: "I do solemnly swear (or affirm, if you'd prefer) that I will never again in my life time use a font tag. I further swear (or affirm) that I will stop thinking of the web as print, and that I will immediately go buy each of Rob's books." (Sorry, I couldn't resist that last one.)

Next up: using absolute sizes for text. CSS allows you to use inches, points, picas, centimeters, millimeters, pixels, ems, exes, and percents for text. The first five - the "real world" units of inches, points (a point is 1/72 of an inch), picas (1/6 of an inch), centimeters and millimeters just do not make any sense on a computer screen. (Remember, you just got done swearing that you wouldn't think of the web as print, and that includes not using print units like points.) Pixels are "real" on a computer, but unfortunately, browsers are supposed to have an important accessibility feature that allows users to resize text so that they can make it bigger and thus readable to those with bad eyesight. IE gets it wrong and only allows users to resize text if the designer set the text size using what IE deems as a "relative" unit - meaning ems, exes, and percents. So stick to those three at all times. (Remember, for all intents and purposes, 1 em = 100%, so you can use whichever makes more sense to you.)

The third point up there is not letting text inherit, but in a way this is really just an extension of the point I just made. If you set your heading 1 to, say, 18px, and your heading 2 to 14px, and your paragraphs to 10px, you'll have a nice, (sort of) predictable page. But what happens when the boss/client/whomever wants all of the text on the site to be just a little bigger. Well, then you've made a whole lot of extra work for yourself. Now, you have to go back to your style sheet and change every one of those. If instead, you set the font size on the <body> to 100% (which is of course the default, but it makes things a bit clearer if you go ahead and set it anyway), and then say that you want your h1 to be 115%, your h2 to be 105%, and your paragraphs to be 90%, then you've really leveraged the power of CSS and inheritance, because all of your sizes are now based on that body size. Want all of your text to be a bit larger? Simply change the rule for the body to 110%, and automagically the rest of the text - the headings and paragraphs and anything else you set - will get 10% bigger. That's all there is to it.

Along the same lines, why do you want to go through and create rules that say that each level of heading and all of your paragraphs and the lists and whatever else should be Arial, when one simple rule setting the font-family on the body element will do the trick with less code? Remember: less code equals less work.

Needless JavaScript for stupid effects

JavaScript is a great language, and when used appropriately, it can greatly enhance a site. I use it all the time to validate forms and include Ajax support, particularly now that Dreamweaver has Spry. But as with many technologies, with the good comes a whole lot of bad. No one needs little hearts to follow their mouse around the screen. Having my monitor shake because there's a pretend earthquake was funny ... once ... when I decided I wanted to see it. Today, all these effects do is scream "I'm an amateur designer!!!!"

Focusing on One Browser

I see this a lot: "When I created my page, it looked fine on my computer with IE, but then the client said it looked horrible on his machine which is running Firefox so ... help!"

While there may be some day in the future when we have world peace, no longer care about the price of gas because all of our cars have Flux capacitors and run on banana peels, left over beer and beer cans (just don't hit 88mph!), and all browsers display pages the same way, we have to live in the here and now and that means testing your pages in as many browsers as you can get your hands on. That means that if you use Windows, you will want to have installed on your computer IE (not that you have a choice there), the current build of Firefox and the latest version of Safari. If you want, you can also install Opera. If your IT department balks at these, point out that they are simply necessary to do your job. They don't tell Accounting that that can't have Excel, so they can't tell you that you can't have Firefox. And besides, the software you need is free.

Mac users will already have Safari, so go get Firefox. Then install Parallels or whatever other emulator you want to use and install Windows so that you can have IE as well.

(The big problem you'll run into is trying to test on more than one version IE at a time. The ideal solution would be for Microsoft to get over themselves and just let us install more than one version at once, but that's as likely as the world peace and Flux capacitor stuff, so until then you can either chance hacking your registry to install other versions or use the "official" method of a build of Virtual PC with the other version of IE. It's up to you.)

Then, as you build your pages, test on one of the standards-based browsers such as Firefox. When the page is working correctly, go ahead and preview in IE and then fix the problems you see. You will find that it's much easier to build your page to Firefox first, and then modify as needed for IE, rather than the other way around.

There are really two things to keep in mind here. The first is something you really should have learned in kindergarten, but way too many people tend to forget: not everybody thinks the same way you do, not everybody believes the same things you do, and not everybody uses the same browser as you do. Okay, you might not have learned the bit about the browser in kindergarten (although my daughter, whose last day of kindergarten in on Thursday, is scary-good on the computer already), but the reality is that you need to remember that as you build your pages. The second thing to keep in mind is that the web is not print. In the print world, you can design that page once in InDesign and then know that every time it is printed, it will look the same. But since the web is not print, the same isn't true on the web, and you need to account for that from the very beginning of the design process.

Designing Only for Your Screen Size and Resolution

Have I mentioned yet that the web is not print? I think I may have once or twice. You know that the gal in the corner office has a bit bigger monitor than you do and has a bit nicer graphics card that lets her set her resolution really, really high so that she can view even long pages (like this one) in a single screen (not that it is readable to most mortals because the resolution is so high that the text is tiny). So if you know that ... why are you still designing your page so that it looks great on your screen but awful on hers?

Here's a radical concept for you: design your pages so that they look good on every size screen at every resolution. That does not mean that you always need to use liquid or elastic designs for your pages. Fixed-width designs will work, too, so long as you take into consideration what will happen in all that empty space on those high resolutions.

And what about really small screens and low resolutions? What about the folks out there that surf your pages on cell phones? Or your aunt who still can't figure out how to make the little window-thing "big" on her computer, no matter how many times you show her? Does your page still look good - is it still readable - on smaller resolutions? If not, then you still have more work to do on your site.

Using the Wrong Tool for the Job

Let's say you decide you need to major house work done, so you go out and hire a contractor. How much confidence would you have in him if he went to pound nails into the wall and used a screwdriver for the job? Would you really consider him to be a "professional" if he didn't even know which tool was right for the particular job at hand? Of course not. And yet there are many out there who call themselves "professional" web designers who consistently use the wrong tools for the job.

This isn't going to be a visual editor vs. code editor debate. While I happen to be a fan of visual editors, I don't consider a pure-code editor to be the "wrong" tool for the job. What I'm referring to are those who use the "Save as HTML" "feature" in Word or Excel or, even worse, PowerPoint to create pages. Along the same lines are those who use those same "features" in Photoshop or Fireworks*. Word is an awesome tool - really, it is. Since I started writing the books, I use Word almost every day, and it really does rock. Excel is likewise awesome for spreadsheets and doing math; nothing rivals PowerPoint for preparing presentations. My expensive digital camera would be worthless if I didn't have Photoshop. Every one of those tools is great - when used for its intended purpose.

But not one of those tools is designed for creating web pages, and none of them should be used for that. There's nothing wrong with creating a comp layout of your site in Photoshop or Fireworks, but then please do not export the site as HTML and call it a day. All you get is a completely unusable, unmanageable, unsearchable, and unupdatable page. Instead, pick out the pieces of that comp that should remain as images and export them to the appropriate format. But build the page in a tool designed for the job. Use Dreamweaver or Expression Web if you like the visual editing environment; use your coding tool of choice if you prefer that approach, but either way, build your site in a program that was built for that purpose, not one that was built for creating print documents or for doing complex math or for manipulating images. You wouldn't (I hope) think of creating the company's annual report in Dreamweaver, so you shouldn't be thinking of creating the company's web site in Word.

* The one caveat to this may be Fireworks CS4. While I have not yet installed the beta, I did see a tutorial by Alan Musselman, the Application Architect for Fireworks, on exporting from CS4 where is certainly appears that the program now takes a standards-based approach and, for instance, keeps text as text when you export. So the line between Fireworks and Dreamweaver may be blurring a bit. I'll have more to say on this when I have to chance to install Fireworks this weekend and give Allan a hard time about that shirt. (Alan's tutorial is on Adobe TV. There seems to be some problem with the site right now so that it's not letting me get the exact link, but if you go to the site and just search for "Fireworks", you see it - it's called "Fireworks Tips and Tricks - Fireworks CS4 Beta Announced".

Summary

So there you have it. My ten ... uh, I mean fourteen things that beginning web designers get wrong. Feel free to comment on anything you think I'm wrong about, and any other points you think I might have missed.