There are multiple problems with using analogies based on buzzwords.

One of these problems is that you don't want to be like the man who says, "Our program is like this buzzword I heard today." He doesn't fully understand the buzzword, so he's likely to make an invalid comparison to it. And if he's using it incorrectly, he's being deceptive about whatever it is he's comparing to the buzzword.

Another problem is that buzzwords are fleeting. What's widely popular today may not be so in six, 12, or 18 months, let alone years. Using buzzwords in your analogies gives your analogies an uncertain shelf life. While you should be regularly updating your site, there's no sense in using content that has to be changed because it was poorly constructed in the first place.

A third problem with using buzzwords is that your target audience may know less about it than you do. If your analogies depend on an understanding of some jargon, you may not communicate your point.

For these reasons, among others, you should avoid using fad jargon in analogies on your Web site. The use of them will make you seem less authentic.

Parody is alive and well in our society. From Saturday Night Live to The Capitol Steps, we have made parody a popular form of art. Its popularity makes it a very tempting avenue for getting your message across.

However, I believe that its popularity dulls its edge for any thoughtful or professional message. You see, in our society, parody is so often linked with comedy that visitors to your site may have trouble keeping a straight face when you use it to discuss something that needs to be taken seriously. And comedy is not generally a good way to be seen as professional.

Good parody is clever, and clever can be very effective, but it can also get you into trouble more easily than being straightforward about your message.

So, how do you recognize that you are using parody? Here are some examples: the Intel-esque logo stating "Jesus Inside"; the many other messages hidden in a visually similar logo to a popular commercial product; and skits featuring parodied politicians or celebrities.

I know that you may be thinking now, 'Well, what's wrong with that?' ... nothing wrong, perhaps; It's all very cute, and there's a possibility that parodied logos will get people talking about spiritual things, though likely at first in an adversarial tone: "What's the deal with your T-shirt?"

But is cute what you want for your organization's message? Is it any better to marry your message to a corporate image than to be straightforward with it? Is using a company's name recognition any better than using common acronyms, as I mentioned in part one of this article, and is it authentic to do so? Is the parody likely to be seen as creative, since parody is so widely used?

The biggest problem with parody, I think, is not the appropriation of someone else's name recognition (thought that would seem to be questionable in light of John 17 (questionable, not forbidden)); It is the cuteness of it. By using a cute method, you may be telling visitors not to take you or your message seriously. That is the danger with cute and clever.

It is worth noting that I am limiting these comments to parody. Allegory, parable, and satire (which are different) should be considered on their own and have value if done correctly. I may some time write an article about them, but for now, know that they are different.

Why are gimmicks dangerous to authenticity? The reasons stem from the fundamental purposes of gimmicks, as well as their history. I won't go into the history of gimmicks, but I will talk about their purposes. You may even think that you have no tendency to use gimmicks in your publicity or messages, but please read on.

Think for a moment about the images you have connected with the word gimmick. Your images are likely connected to used car salesmen and late-night infomercials, and there is good reason behind that. Those groups often use gimmicks, and for a specific purpose. The gimmick is like a fishing lure: it is supposed to occupy your mind with its cleverness and amusing confusion so you won't see the hooks until it's too late. Is this really what you want to use on your business or church Web site?

Often, we resort to gimmicks not out of a desire to deceive or capture but out of a desire to be clever, witty, or cool.

The problem is that clever, witty, and cool are moving targets. Cool is based on whatever is or appears to be fashionable at any given moment, while clever and witty are only truly effective for those who are on the leading edge of a witticism. Put another way, your clever remark was only clever the first time or two; copying someone else's cleverness only validates them and makes you look less original and less authentic; and that thing you put on your Web site because it was cool is 'so last year' (as, by the way, is saying things are so last year. I shrug and use it anyway to make a point).

You see, we need to realize that our pride should be swallowed when we are tempted to try to be witty. We should rather simply say what we need to say and let the cleverness just happen, because as Solomon points out, "there is no new thing under the sun." Bear with me while we look at a couple of gimmicks I've been seeing a fair... or rather, an unfair... amount recently.

If there is one thing our jet-set society loves, it is acronyms. We love acronyms so much, we even make a similar construction of letter soup that doesn't even form a word, leading to a proliferation of TLAs and the slightly longer FLAs and SLAs (for those who don't know, they signify Three (or four or five or six or seven) Letter Abbreviations (or Acronyms... even though many of them are not acronyms; an acronym forms a pronounceable word, such as PIN for Personal Identification Number, but I digress).

The gimmick here that should be avoided is re-purposing acronyms and abbreviations for use by your organization. While you may think it is clever to come up with a program name based on common abbreviations and acronyms like GPS, CIA, LIFE, or NAT, they will likely do you more harm than good.

First, you're likely to confuse people who know the pre-existing meaning, because they'll hear people talking about, for example, a GPS meeting, and be quite annoyed when they show up and learn it never had anything to do with geocaching. Second, because of this confusion, people will have their expectations frustrated. Third, your visitors will likely think you are being what I have heard people here in the South call "too clever by half." Fourth, people will see what you're trying to do for what it is: trying to use the memetic credit someone else has built in a word or jargon term, and they are likely to look unfavorably on your memetic identity theft.

So, the lesson here is simple. If you must use an acronym for your group or program or event, come up with your own, and do your research to make sure you aren't using a term that is in wide use elsewhere.

You remember the drawbacks, right? Broken navigation, liability to copyright infringement, harm to your reputation, inaccessibility, etc.

In spite of their failure to deliver on any of their perceived benefits, frame remain somewhat popular with people who don't know much about computers, and this is understandable. Frames do tend to look pretty nifty.

They appear at first glance to keep the navigation right on the screen, and the header stays at the top. Although there are problems with this (e.g., if the visitor comes into a subpage from a search engine), and having a static navigation might lead to buttons visitors can't reach, but with care, you can have a layout that is similar to frames with a little bit of CSS.

Of course, you'll still be using the same amount of file space, but the result will never leave your visitors with nothing to look at but "Aren't we neat? We have frames. You don't, so our content is hidden. Get a new browser."

There are a couple of ways to achieve a pseudoframes layout:

The first way is to have a content div (always a good idea, but required for this). Using CSS, you style your content div to sit on one side (or in the center) of your layout, stretching from top to bottom, and scrolling when the content overflows it. To prevent visitor confusion, you'll disable scrolling on the body element so only the content box has a scrollbar. Here's the CSS code:

Of course, you don't have to use these dimensions, but you do need to set the height, at least, of the content box, or it will just render the whole division, possibly letting your content run off of the visible page into no-visitors land. The height property tells the browser how much you want to show before it starts using the scrollbar. The overflow:scroll will put scrollbars in place, but they'll only become activated when there is overflow.

You can also try to thumb tack your navigation and header to the page using static or fixed, but MSIE doesn't tend to like that. Here's the code:

...and here is what you can feed MSIE (using IECC or server-based browser-dependent stylesheet selection) to get it to render this properly:#header { _position: absolute; } /* _position: absolute; is a hack for MSIE */
#ie6 #header { position: static; left: 0; top: 0; float: left; }

The first line is pretty straightforward: it's a hack, so theoretically, you could garbage up your main stylesheet with it, but I like to keep MSIE-specific nonsense in a CSS file labeled "4ie". The second line need some explanation. In my HTML, I have a conditional comment that tells IE6 and lower that there's a div with the id=ie6. This way, I only have to target it once in the HTML, and I can use the CSS id tag to target it in the stylesheets. In this case, IE6 responds to static, but in my experience, you have to float whatever you want static.

As you can see, this is much more complicated (and therefore probably less reliable) than the scrolling box. I should also note that you must repeat these steps for your navigation (this was for the header), and if you have a navigation bar stuck on the side of the screen with fixed or static, you need to have a padding or margin on the left side of your content division that is at least as big as your navigation bar. But in spite of its added complexity, it does look a little better than the scrolling box, and is more widely used. Now that you've seen both, you can make your own decision.

In our society, a person with a voice that is carried on the radio or television can gain quite a bit of clout and respect. We place a high value on people whose words have a broad reach. Even if the person is not on a mass-media outlet, we tend to pay attention to people of prominence or official position.

In this age of mega-churches and mass-media ministries, we find two great mistakes in how churches handle leaders and preachers on their Web sites: the Star Pastor, and the Pastor Incognito.

The Star Pastor is usually the leader of a vibrant and popular ministry, but he doesn't have to be. You can recognize a Web site that has this problem because the minister's face is prominently displayed. The copy exhorts people to come hear the preacher by name. There may even be pull quotes from the pastor on the front page. This is more common in mega-churches, but it can be found in some very small churches, as well.

The problem with a Star Pastor is that, no matter what your congregational or denominational structure, the pastor is not supposed to be the head of the church body. Jesus is supposed to be the head, the leader, the focus of the congregation.

Paul wrote to the Corinthians that we should not be followers of this preacher or that teacher, not of Paul or Apollos, but followers of Christ1.

But while placing too much emphasis on the preacher or other leader is bad, the other extreme is no better.

The Preacher Incognito might not be on the Web site at all, but if he is, the Web site refers to him as Brother Jim, or Pastor Mike. This may seem to convey friendliness and informality, and that's not a bad thing, but if that is all the information visitors have about the local leader, it can come across as unreliable and possibly even secretive.

Strike a good balance with the information about your leaders. Make sure the focus of the site, like that of the congregation, is on Jesus the Christ, but don't leave your visitors wondering who your pastor really is. Here are some points to ponder:

• Does your Web site display, somewhere sensible, the full name and (church) physical mailing address of your pastor, minister, priest, preacher, head elder, or other leader? It should.
• Does your Web site include the local leader in the header graphic? It shouldn't.
• Does your Web site make clear to visitors where and to whom correspondence should be sent? It should.
• Does your Web site's/ministry's name include the leader's name more prominently than "Original Ministry Name with John Smith"? It shouldn't.
• If a visitor wishes to call the pastor for prayer or a visit, does your Web site have this information in an easily accessible location? It should.

With a little forethought, your Web site can be friendly, informative, and properly balanced with regard to your ministry leader's place in the church.

You might not think C.S. Lewis would have much to say about Web design, having died about two decades before the development of the World Wide Web, but it turns out he said quite a bit on the topic of this article just in the preface of one of his books. Every area of our lives is covered in the Bible, and that's much older than Mr. Lewis's writings, so the age of the material usually gives no indication of its applicability.

I mention C.S. Lewis because he not only wrote what I want to convey, he did it in better words than I imagine I would come up with. Plus, he's a respected figure in many Christian circles, so that doesn't hurt. I will not be merely quoting his words. I will, of course, attempt to help you in applying them to the art and science of Web design.

The book is Mere Christianity, and the preface is a great read. In it, Lewis wrote that the book was not about an alternative creed or communion. The Christianity Lewis described, he wrote, "is more like a hall out of which doors open into several rooms" (xv). His aim, he wrote, was to bring people into the hall, that is, into the universal Church of Christ Jesus. The rooms are the various congregations, fellowships, and denominations within the Body of Christ. Lewis wrote, "But it is in the rooms, not in the hall, that there are fires and chairs and meals. The hall is a place to wait in, a place from which to try the various doors, not a place to live in" (xv) That, he wrote, is the purpose of the rooms.

I agree. And just as the purpose of the book he wrote was to tell people about the unified belief in Jesus Christ, so is the purpose of each church to lead people to Jesus and help them to become faithful disciples living to the full the abundant life available in Christ Jesus. But what does this have to do with our Web sites?

Our Web sites should do this and avoid causing people to stumble. You may recall that I said a few weeks ago that we should develop a sense of the apropos, that we should not add any stumbling-blocks to the Gospel beyond the Stone the builders rejected? I turn again to Lewis for a concise explanation of my point:

"Ever since I became a Christian I have thought that the best, perhaps the only, service I could do for my unbelieving neighbors was to explain and defend the belief that has been common to nearly all Christians at all times" (viii). Lewis explains that he felt the questions of distinction between the different denominations or Christian individuals should be expounded upon by experts only, but what I think is more important is the next reason he lists: "And secondly, I think we must admit that the discussion of these disputed points has no tendency at all to bring outsiders into the Christian fold. So long as we write and talk about them we are much more likely to deter him from entering any Christian communion than to draw him into our own" (viii). Now, I want to be clear that I am not saying a church should not post on its Web site the tenets its members believe. I am not talking here about a simple listing of the congregational or denominational beliefs. I am rather talking about things more on the lines of dissertations on why this is right and other groups believe the wrong thing. Lewis writes, "Our divisions should never be discussed except in the presence of those who have already come to believe that there is one God and that Jesus Christ is His only Son" (viii-ix).

In other words, I am saying that you should follow the example of another famous writer, Paul of Tarsus: "For I determined not to know any thing among you, save Jesus Christ, and him crucified" (ICor 2:2). That is, focus on the core of Christianity when your words are highly visible, lest the unsaved mistake your disagreement for disunity. The Body of Christ is unified in faith. Therefore, let your Web site reflect that the Body is in unity where the matter is of necessity and freedom where the matter is of conviction or preference. Let the latter be discussed within the Body, not on the public forum, for it is infinitely more important that one be brought to some acceptance of Christ than that one understand Christ fully yet reject Him because of disunity.

I have chosen to discuss this topic in the context of doctrine, but it has wider applications. You should not post on your Web site the discussions and disagreements your governing body has. It is understandable that your members will not always agree with each other, but you are not being a good witness if you post the details of those disagreements on your Web site. Rather, discuss in private, reach agreements, and post those, if they are something your visitors will find useful or interesting, on your Web site. The Body is unified in the Spirit. Let your actions and your Web site content reflect that. The private discussion is for the purpose of reaching that unity on a particular issue. The Web site is for the purpose of displaying where your congregation stands in the end.

Let me be clear, however, that this is not about hiding problems that exist in your congregation. It is about glorifying God on your Web site. Where problems exist, you should fix them and be silent about them on your Web site until they are resolved. Do not simply put up messages of "all is well" if that is not the case. People want authenticity. Make sure your church is giving it to them. Make sure you are unified, make sure you fix problems where they exist, and then go forward with your Web project.

Your Web site should glorify God, but it can only do that if it is an accurate reflection of a church that is performing its role in the Church. It can only glorify God if you are glorifying God. So, if your church is having a problem, it is probably best if you scale back your Web site to just a page with your address and telephone number, along with worship times, until you get your church to where it needs to be. A great Web site isn't going to fix a broken church, and a broken church isn't going to glorify God among the nations. So, let your church be unified, then let your Web site reflect that, and let your Web site be unified with the rest of the Body of Christ, for apologetics are only useful for the members of the Body. Arguments do not win souls, because as Paul wrote, the Gospel does not win on the merits of its wisdom of words, for it is foolishness to the lost (ICor 1:17-29).

It is natural to want to go one step beyond just being friendly and welcoming and assert that "there's a place for you here at Fifth Street Church" or "your place is here".

This demonstrates a myth among some churches on the Web. This myth is that the church has a place for everyone. While this is true of the Church universal, it is not true of your congregation. No matter how big or small, nor how welcoming your congregation is, not everyone will fit in there, because not everyone fits there in God's plans.

God's worldwide family of believers has a place for everyone — rich or poor, young or old, trusting or skeptical, weak or strong, confident or timid, hungry or full. But it simply does not apply the same way to your local congregation.

Whether your church is small or mega-sized, whether your church's worship style is traditional or cutting edge, whether your church is led by a single person following Christ or by a consensus of all the members, no church congregation can be the right place for everyone.

For starters, not everyone's place in the will of God is in Crestview, Florida. By reason of locality, not everyone's place is 'here'.

Secondly, not everyone can use their giftings 'here', because 'here' already has a music minister, or a preacher, or enough Sunday-school teachers, or something that at least one of the visitors to your Web site is going to have. By reason of facility, not everyone's place is 'here'.

Thirdly, not everyone shares the same tastes and preferences. I am speaking here of deep tendencies, not daily whims or superficial enjoyment. And while these are not quite as important as the callings and gifts of God through the Holy Spirit, neither are they unimportant. I believe God loves variety; look how many different creatures God created. I believe the same is true of worship styles. I believe God enjoys them all, but I do not. Some prefer quiet tunes and thoughtful lyrics, feeling worship in the mind of God, while others prefer a service with energetic music and simplified lyrics, feeling worship in the passion of God's love. But it's not about the music style. Some prefer less music and more individual prayer, or more preaching, or more hearing of the concerns of the body, or more testimony, and while the worship is all about God, God means for worship to also meet the needs of the believers for encouragement, edification, joy, peace, comfort, and release of the individual worship tendencies they have. By reason of partiality, not everyone's place is 'here'.

But what is the big deal with this? Perhaps all of this seems excessive as a response to one statement that isn't even on all church Web sites. To be blunt, the big deal about this is honesty and authenticity, or more pointedly, our witness. And it goes beyond this one statement, but this statement can illustrate an attitude that is more wide-reaching. So, to consider this statement: We know, by the reasons I've just enumerated, among others, that not everyone who reads our church Web site will find the place God has for them in our specific congregation. And we know that one of the major stumbling blocks people have with the Church is hypocrisy — some of it real and some of it only imagined — within the body. And since we know these things, it is a bad witness for the Gospel of Christ Jesus to post something we know is not true, or is true only in a certain, unusual light. Now, this statement may seem trivial, but the reality is that the statement is trite, and partly because it is inauthentic.

It is vitally important that you have the understanding and the attitude that the Church universal of God's love in Jesus Christ is authentic. Because the Church itself is authentic, your church should find it offensive to your mind, and abomination to you, to knowingly put forth something that is not authentic. Let your music, regardless of its style or tempo, be authentic. Let your sermons, regardless of their length or structure, be authentic. Let your lives, living sacrifices in a multitude of professions and ministries, be authentic. And by the way, don't forget to make sure your Web site, in addition to being accessible and well designed, is authentic in its content. Authenticity of content is the point of this article, not just the do or don't of one statement.

But on the subject of the statement, let me reiterate:

You should not advertise on your Web site that there's a place for everyone in your congregation. That simply isn't true, for reasons of preference, temperament, and God's sovereign will. Instead, you should mention specific things about your church's service styles, programs, and general atmosphere. Don't worry that not everyone will like it there. The Body of Christ has many members, and they're not supposed to be alike. Neither are church congregations.

You should focus on telling the people who would be happy in your congregation what you offer and work together with other area churches to help those who aren't a good fit find the church that does meet their needs. Remember Peter's reply to the beggar in the temple. He basically said, I don't have what you want from me, but I have what you need. We should be like Peter and help people find what they need. After all, it's not important that every person goes to your church, just that they go to a church that follows Jesus. And it may help the Gospel for people to see churches working more closely with each other.

Work together, focus on meeting needs you can (and especially do)

And in place of "your place" on the Web site? Maybe something like, "There's a place for you in God's family. Let us help you find it." Or, "We are a friendly, welcoming church." And then live up to your words.

Are you viewing this column from its own page, on your LiveJournal friends list, or using the RSS feed?

Next Friday: What your church believes is important. Some discussion of how to properly talk about your beliefs on your Web site.

There are many benefits to putting your organization's best foot forward. You will make a good first impression, you'll increase the likelihood that visitors will return, you'll be less likely to alienate your visitors, and you'll be more likely to get them to make a decision in your organization's direction, whether it's buying or donating, committing to publicly support your organization, or taking a step of faith into the family of God.

When your organization is a church, putting your best foot forward is even more important, because unlike many other organizations, the Church has some powerful enemies in the culture of today's western society. Individuals, groups, and the forces of the Accuser set themselves in array against the Church of the Almighty. The Bible warns us not to give Satan a foothold, and whether you believe that Satan is an actual entity or a personification of the sin nature, the need to not give people any minor legitimate excuse to turn away from our message is very important.

So, knowing that the message we wish to put forward has opposition, churches should examine well their ways and ensure that the only stumbling block visitors to a church Web site have to face is the stone the builders rejected, not any of these things:

• grammatical or spelling errors
• internal squabbles
• questionable content
• outdated, inaccurate, or incomplete information
• disunity with the Body of Christ
• inauthenticity

These things have the potential to lower the reputation of your congregation, or worse, the Gospel itself.

As the virtual feet of those who bring good news, your church Web site needs to be the answer of yes to the wider question. Beyond the need to best represent your congregation, there is the wider question of witness. Jesus calls his disciples to be witnesses of what God is doing in the world, so everything your church does should be able to answer yes to the question, "Are we being good witnesses to the love and work of God in this dark and broken world?"

Shed the light of truth in your congregation and on the World Wide Web. Be a good witness. Have beautiful feet.

How do you like the new format? Please leave a comment.

Next Friday: Every congregation should be welcoming to every one who seeks God, but should you say this on your Web site? Read next week. The answer may surprise you.

For the content portion of this article, I will talk a little bit about content, because content on a Web site is king. You'll never make your visitors content with your site until they are content with your content. It doesn't matter how pretty the layout is, how friendly the navigation is, or how efficient your code is, if the content is not what visitors want to find. Conversely, while a bad layout is likely to cause people to leave your site, content that is good enough (and not available somewhere else) can draw return visitors to a site with a poor layout and difficult navigation.

This does not, of course, relieve you of the responsibility to make sure your site has good navigation and design. It merely puts content in its proper perspective.

To put this into a historical perspective, think back to what you experienced (or, if you are young, to what you were told), or just visit some of the oldest pages on the Web(many sites simply seem to never die). When the World Wide Web was first developed, pages were all about content. There was little to no presentation. In fact, information available on the Internet was mainly just text in the beginning. You may recall hearing about or using a protocol called Gopher. This protocol gained some popularity near the early days of the Web, and it is still available today. And it is still pretty much what it used to be: simple hypertext (of a sort) focused on content to the near-exclusion of layout. The important thing here is that, even though it was eventually overshadowed by http (with its more versatile HTML), gopher did gain significant popularity back then.

The reason it became popular was its ability to transfer information. Your visitors (unless you are the owner of Zombo.com) come to your site for your content. For some sites, that content is your games or your artwork, but for most sites, that sort of thing, along with layout, will be secondary, or even tertiary, behind the content and possibly other things.

Since content is the most important thing on your site, it is important to understand what good content is and what sorts of content should not be on your Web site. This could easily be described by saying that good content is content your visitors either expect to find based on their seeking out your site or will be pleased to find even though they didn't expect it.

However, this description is not adequate as a guide to help you determine what your site should not be without and what your site should avoid being with.

Because every Web site served a unique organization with unique needs, I cannot tell you everything that should and should not be on your site. To answer the questions of what should be on your site, you need to develop a sense of the apropos.

To help you with this, I plan to focus on these questions in my articles over the coming weeks. Since I focus in my business on churches, I will focus in my articles on the specific needs of churches, but you should be able to glean some understanding from these articles that will be applicable to your situation in business or in social or polemic situations that warrant a Web site, as well.

Is there a topic within this umbrella of content you'd like to see me make the focus of part or all of an article?

Is there a word of advice you'd like to give or a story about the results of putting particular content on your organization's site you'd like to share?

Do you have a specific question relating to content?

Post a comment, and I'll probably write about it or make it available to the other readers.

Next Friday's article: Beautiful feet, putting the best foot forward, being a good witness.

Since this is a topic that has been covered by others years ago, I didn't think I would need to write an article about it.

Unfortunately, I found it on a couple of Web sites I visited yesterday, so some people are still using frames, and not for the right reasons.

I'll start off by saying that frames, or better yet iframes, have their place. They can be useful for long documents in which having the table of contents always in place can be useful. However, that could be accomplished with a static or absolute div, but that's a matter for another time. They can also be useful for a monolithic process, which must be completed in order and holds no point in returning to or bookmarking some intermediate step.

Unfortunately, these are not the uses to which I see frames put. No, they're being used for layout, and like tables (which I may discuss at another time), frames are not suitable for use in layout.

When you come down to it, a frameset is just a more rigid table, but while it has some perceived benefits, it has some overwhelming drawbacks.

Perceived benefits:
1. Navigation in one file; no duplication
2. Navigation always in place, no matter how far the page scrolls
3. Less bandwidth, because navigation, header, and/or footer are in files that don't get reloaded.

All of that sounds very nice, but the static navigation can be done easily with CSS, and we'll see in a moment that it's not a true benefit when taken together with the rest of the picture.

Beyond not truly delivering on its perceived benefits, the frameset has a number of drawbacks that make its use by any organization outside of a meta-page model (like that mentioned above, or like a 'comment on this article' page) simply wrong.

Drawbacks of frames
1. They break navigation – They prevent visitors from bookmarking a page in the frameset. The only way around this is the heavy use of JavaScript or a separate frameset for each possible combination of pages, which kills the point of having a frameset.
2. They can lead to copyright infringement – displaying someone else's content in your frames is usually a violation of their copyright, because it makes their content appear to be your content. Even if this is something you would never intentionally do, a small mistake in coding can cause it to happen.
3. They hurt your credibility – Because frames hide the actual location of the framed pages, your organization looks less honest to visitors. They may ask themselves why you're hiding where the content is being served. This is especially important if you want visitors to send you their contact information, buy something, or donate to your organization.
4. They are not accessible – One of the biggest problems with frameset sites is that many screen-reading browsers (and text-based browsers) cannot parse them in a meaningful way. Your visitors, even the ones who are using an older graphical browser, may be unable to get anything out of your Web site other than "This site was built using frames. Aren't we awesome? Get a frames-capable browser here." Now, I support the spread of Firefox and other good browsers, like Opera, but you have to wonder how a blind person, or someone who is accessing your site using Lynx over a secure shell connection is going to feel when you deny them access to your content.
5. They usually aren't crawled by search engine spiders – This is where you get your real drop in bandwidth consumption: fewer visitors coming from search engines. Because your frameset doesn't really link to other pages on your site in a meaningful way, search engines may not index your site at all. And if they do, they won't index it properly, as the next point explains...
6. They break when visitors come from search engines – "Hi, welcome to our site. Use the links on the left to navigate." Oops. Your visitor came from a search engine, and the search engine indexed the framed page, not the frameset. You can try a JavaScript force to make the page reload in the frameset, but that has a number of problems. First, your visitor may have scripting turned off. Second, this forces the user to load your page twice. Third, if your visitor didn't want your home page, they must now hunt for the page they did want with no clues about where it is. But more likely, they'll be scratching their heads and wondering what links you mean, since they don't see any links at all. Search engines also frown on these 'orphan' pages, and they give them lower rankings.
7. They eat valuable screen space – Visitors viewing your page from a small window (whether they like to multitask or have it maximized on a small screen (and just think of the horror if they're browsing from their mobile phone), 30%, 50%, or even more could be eaten up by your header, navigation, and footer.
8. They are not as usable – If they have scrollbars, they may confuse users about which scrollbar to use. If they don't have scrollbars, they may prevent users from viewing all the content in them.

You can easily see that the drawbacks outweigh the perceived benefits. The use of frames for layout rather than a semantically appropriate grouping is acerbic to your visitors; it leaves them with a sour taste for your organization.

Having the navigation only in one file is not such a great thing. While it may make maintenance a little easier, global search-and-replace applications or functions can make maintaining menus just as easy. And having all the links in one file will hurt your rankings in search engines, make your site less accessible, and possibly leave visitors with only one page to view.

There are better techniques for a frame-like layout with CSS and/or iframes.

In order to overcome the drawbacks of the frameset, you'll eat up more bandwidth and do more maintenance work than if you'd built your site without frames.

This is my tenth actual article in this online column, and I think it's a good point to make some changes to the style of the column. Next time, look for some changes in the way I put this together. I'll also be trying to tackle more subjects of a less technical nature. I hope you find these changes beneficial.

Looking back at the articles I've posted recently, I think I've gotten a little off track. I want these articles to be useful to everyone, not just those who are interested enough in their Web projects to try to do some of the coding themselves.

So, maybe you don't want to learn how to code HTML or XML, and maybe you have no interest in knowing what a stylesheet is, and maybe all these letter combinations are just so much Greek to you. Or maybe you understand Greek, and this stuff is like Farsi.

Well, if so, some of the things in this article are for you.

If not, this article is still for you, because this article was written to help you get the most out of the money you're paying your designer to build your Web site. It makes little sense to pay someone to design something if your actions are not helping that design to be done in the fastest and most cost-effective way possible. You want to be able to help the designer get things done so you can get on with enjoying the benefits of your new Web site.

The most important thing in working with a designer is to communicate your wishes. Partly, this is about knowing what you want, but even if you don't know when asked, you should try to answer the designer's questions as quickly as possible. The more you communicate with the designer and answer the questions he or she asks you, the less you'll have to say, "I don't know. Just try something and I'll see how I like it," because that may work well, but it's more likely to cost you more when you say, "No, I don't like that. What I really wanted was this other way," so try to figure out the answers to the questions you're asked, even if you don't know when the designer brings them up.

Remember. Doing things right the first time is good stewardship.

The best thing when doing a project involving design is to decide things early so that you and your designer know which way to go. If you can't decide before you start, it is easier to make changes in the preliminary stages than at the end.

However, while it is usually easier and cheaper to make changes at the start, multiple design changes are likely to irritate your designer, who wants clear direction from you. He or she can't meet your needs if you don't make them clear, so consistency refers back to the point about communication.

The other problem with multiple changes to the design is that if the designer is waiting for you to settle on a design, he or she probably isn't putting together the finished product, which can delay your launch date.

So, be consistent. Settle on a design and stick to it. Minor changes can be made at the end, although they are likely to be more expensive than at the stage when all that has to be changed is the template.

It is very important that you listen to what the designer tells you.

You probably hired this person because he or she has a better understanding of design than you do (If this is not the case, you need a different designer. If you know a lot about design, maybe you should just do it yourself using the other articles here). So, if your designer is more of a design guru than you are, listen!

After all, you hired this person for the insights more than for the labor, or at least, you should have. This person is a professional.

Listen when the designer tells you that animated spinning crosses are a bad idea (To paraphrase Dean Peters, you should only have one on your Web site if there's one on your church building). Listen when the designer tells you that red text on a green background is not appropriate, even during Advent (for those who don't know, it'll be unreadable to some people). Listen when the designer tells you that cursor tails are a Bad Thing (User: "Why doesn't the link do anything?"). Listen when the designer tells you that picture won't make a good background for your text (partial transparency is not uniformly supported in all browsers).

A good designer doesn't try to say no, but there are some things that simply aren't what a good designer wants attached to his or her name. So, when a Web designer tells you something is not a good idea, you should think about it long and hard before saying, "I still want it," and if they start taking their link off your pages, you'll know you've gone where angels fear to tread.

Listening is another part of communication

Here's some useful advice I found from other designers:

Remember that your screen and browser are not the same as everyone else's

Don't forget the "Pick Two" concept (fast, good, cheap)

If you get someone to do your site for two pizzas and soda, remember that you'll get what you pay for.

The image mockup is not days away from the finished site.

It'll probably cost twice what you think or take twice as long.

Web sites must be maintained.

There is no such thing as WYSIWYG on the Web.

Change your mind as often as you like, as long as you understand it won't be done on time, under budget, or be consistent.

Your designer can't (99% of the time) generate your content for you.

It may look easy, but it took your designer years to learn everything he or she knows.

Things happen in life, and sometimes those things keep us from meeting our goals. Be flexible with your designer, within reason. Be especially patient if they're late because they were waiting on you, even if that waiting was way early in the process.

Have a wonderful experience with your designer!

If you've spent much time on the World Wide Web, you've probably seen advertisements for fonts. Special fonts. Wild fonts. Fun fonts. 10,000 fonts. Wacky fonts. Nature fonts. And many, many more. With all of these fonts at your disposal, many of them free, it would be tempting to toss one or two or a dozen of them into your Web site.

This is a temptation you must resist.

You should especially resist putting more than two different font faces on a page, but you should also resist using a super gee-whiz neat font you downloaded into a Web site, for a very simple and practical reason.

What you see is not what your visitors will get.

Oh, there's the wild chance that some of your visitors will have found this magnificent font and installed it on their computers, but most people will not have done this.

For the majority of your visitors, you'll need to stick to the norm, the more widely accepted fonts. Using the most common fonts will ensure that what you design is very close to what your visitors see.

But how, you might ask, can I know which fonts my visitors will have? I have located a site that lists them1. These cover Windows and Mac fonts, but Linux users can get their distro's Webcore TTF package or the Libertine and/or Liberation font packages to replace them. This brings up the good point that there are no truly universal fonts, which is why it is critical that Web designers include a font family in their font declarations. Take special note on the referenced page of the footnotes, which mention some pitfalls. You can see how the Web core TTF fonts are supposed to look on the Optimal Use of Fonts on Linux page.

How this works is that the browser will use the font family to pick a font of the same basic type when it looks and can't find the font you used when designing the page. For example, let's say you make a page and want to use MS Comic Sans (though you shouldn't. Ever. Just, no.), and you use this as your font declaration:.badstyle { font-family: "Comic Sans MS", cursive; }The browser will ask the system for the font "Comic Sans MS" and, not finding it, it will substitute a cursive font, such as "Ambassador Script" or "Coffee Service", or something slightly cursive-like, such as "Chancery".

It is important to make sure your font-family cue (the last thing in the declaration) is of the same type as the specific font you've chosen. If you put a declaration like this:.mismatched { font-family: "Georgia", courier, sans-serif; }people are going to be very confused, because Georgia is a serif font, Courier, while serif also, is a monospaced font, and sans-serif will not display in something like Times but in a font like Helvetica or Geneva.

Of course, if you're creating an image, you can use whatever font you please. Just make sure you pick one that's readable. Nobody's going to care how pretty it is if they can't read it, and if it's not conveying information, it doesn't belong on your page. Remember, every mark has meaning.

By the way, don't make an image just so you can use a cool font. Images should be reserved for information that cannot be conveyed textually. Words in a pretty font are not image-worthy, unless the topic of the page is that font or multiple fonts. A picture that contains words (in an ordinary or pretty font) is worthy of being an image. Respect the bandwidth of your visitors, and don't waste your own resources transmitting unneeded graphics.

If you choose your fonts wisely, everyone's experience with your Web site will be improved.

One of the greatest challenges in Web design is the hoops designers have to jump through in order to make the same standards-compliant code render properly in the various browsers. Some of these browsers render according to the standards, and others render according to some outdated, agnostic, upside-down LSD trip of a document object model.

Now, one doesn't like to name names, but we can hardly have an honest discussion of this topic without pointing the finger, or, to be more accurate, let's call it what it is. The browser family that is unparalleled in its flagrant abuse and disregard for the W3C DOM and other widely accepted standards is the (for reasons passing human comprehension) ever-popular Microsoft(tm) Internet Explorer(tm).

A while back, someone put together a pie chart showing the portions of time spent on a Web design project that were devoted to various things, like making the site W3C compliant, hunting down a mistake in your JavaScript code that Firefox wouldn't swallow, swearing, actually designing, and a big slice almost half the size of the pie labeled, making it work in MSIE. I won't link to it, because it's more colorful than my description and therefore not safe for work, but if you want to see it anyway, remember the mantra: Search engines are your friend.

The MSIE browser family is probably the greatest contributor to the Internet community of the need for browser hacks in the CSS. What are hacks? A hack is a method of using the disparity in the way different user agents (browsers) parse the CSS code, particularly bugs, to feed different CSS to different browsers. In other words, it is a relatively controlled way of breaking the code so that certain user agents will recognize a style declaration, while others will ignore it as malformed or unmatched code. You see, CSS is only applied when it matches a particular element, class, or id. For example, the declaration "p { color: #f00; }" on its own line will match all paragraphs in the document, regardless of their level in the HTML hierarchy, class, or id, unless another declaration later in the stylesheet overrides it. This declaration, by the way, will turn the text red, so make sure no paragraph elements are on a red or similar background, or visitors will be unable to read the text.

Hacks work because browsers generally ignore what they can't parse or don't need to apply. For example, if you have a style declaration of ".nonexistentclass { display: block; color: #f00; }", but you don't have any markup with the attribute of class="nonexistentclass", the browser will simply ignore that line and render the document using the remaining style declarations before and after the missing one.

When Web authors want to target one particular browser with a declaration (usually some correction) to make it render things differently, they will often abuse the syntax in a way that most browsers ignore but some particular browser or family of browsers will apply.

This is a Very Bad Thing.

To start with, the hacks you use today may be corrected in future versions of the browser, and then all you have is messy code that doesn't render in any browser. For another thing, you have messy code, and that is to be avoided for many reasons, including download and render speed, possible jitter, resource costs, future maintainers, and the principle of the thing.

Fortunately, while the team at Redmond has not fixed their broken browser, they have given us an efficient way to apply fixes without garbaging our CSS for the other browsers. Unfortunately, we have to garbage our HTML, but not nearly as much.

This feature is called the conditional comment, or the Internet Explorer(tm) Conditional Comment, or IECC, as I call it (and on looking around, I see I'm not alone), mainly for its onomatopoetic satisfaction. I call it that because MSIE is the only family of browsers I know of that supports it. In a perfect world, of course, all browsers would recognize and properly render according to the standards, but short of that, it would be ideal if all browsers used conditional comments, because they each have their own little quirks, but we can thank the Lord and the programmers at Redmond for at least giving it to us for the browser that is the most riddled with big, show-stopping quirks... like making most of the page content disappear when certain things are floated in a certain relationship to other things that are statically positioned. So, as I said, we should count our blessings that this technique allows us to set apart code for the MSIE family.
How does this work?

You start with an ordinary HTML comment:<!-- Hi. I'm a comment. Nothing written in here will be rendered. -->

Comments are very useful for programmers. While the HTML spec says1 that comments have no special meaning, this does not prohibit meaningful content from comments. In fact, all comments have meaning (if a comment has no meaning, it should be deleted instead of commented out). The spec simply means that comments are not covered by the standard beyond being designated as something most user agents should not render. That is, while they have no meaning within the specification, they still have meaning.

Comments are useful for documenting code, as in telling the reasoning behind a line of JavaScript or telling template users what goes in a particular part of the template; for locating problem code or storing code that is meant to be rendered at a later date or temporarily removed from the page; for storing metainformation, such as the copyright notice for a script or other content, which may not be intended for rendering on the public page but is important for code maintainers and programmers borrowing from the page code; or for presenting Easter eggs for curious visitors to find if they look at the code, to name a few possible functions.

Conditional comments merely add another function to the comment element. To make the contents of a comment render conditionally in browsers that recognize them, namely, MSIE, you add a conditional in square brackets:<!--[if IE]><p>This paragraph is rendered in MSIE browsers</p><![endif]-->

I've included a paragraph here, but this is more commonly used for adding in a stylesheet: <!--[if IE]><link rel="stylesheet" type="text/css" href="ie-fixes.css" /><![endif]-->

Note that this stylesheet declaration must be after all your other stylesheets, or your carefully chosen fixes may be applied before the styling that needed fixes in the first place!

Using this extra stylesheet (which does NOT add an extra file request for all other browsers but CAN contain all your MSIE style fixes, even for different versions) allows you to feed IE the differentiated code it need to render properly around its bugs, such as the margin doubling bug, the peekaboo bug, and the EM-text-resizing bug. For standards-compliant browsers (and in the case of some bugs, IE7), the regular stylesheet sends, for example, ".thing { width: 75%; }", and the ie-fixes stylesheet contains a declaration that overrides it, such as ".thing { width: 67%; }" to make it render a visual more similar to the others, or at least not paste other elements over the content of this one.

I have encountered, in my wanderings around the Web, some discussion and disagreement on this technique. I'd like to take a moment here to state my logic regarding the comments I have seen.

First, I say that this is not a hack, nor does it make non-validating/not valid code. The spec I mentioned before clearly indicates that what is in comments has no particular meaning (within the specification). That one browser family assigns meaning to certain types of comments does not change the fact that other browsers ignore it completely, as they do all comments. This is as it should be. It has been suggested that to use IECCs to break the code in a way that authors find more convenient than forcing users to switch browsers at gunpoint is somehow against the precepts of proper coding. To that, I say, nonsense. It is the most elegant solution available, and the fact that other browsers ignore it makes it no more against proper programming than documenting your code in comments. It is a means of making the process of presenting information more efficient, more portable, and less annoying than simply posting notices that the site is "best viewed in Netscape Navigator". Such zealotry has no place in Web design. Meanwhile, IECCs allow Web designers of all skill levels to design pages that will properly render in standards-compliant browsers and allow fixes for the outlier without requiring high-level programming skills or access to the server's internal structure. I am well aware that many organizations use low-cost Web space that uses a common server daemon they don't have access to configure. And isn't delivering the content what programming, especially Web programming, is all about? It's about getting the job done and not making life harder for the people who have to maintain the code after you. IECCs, while not the perfect-world solution, are still the best thing available until MSIE joins the ranks of browsers that support the standards.

Second, I say that while individual Web designers should advocate for the exclusive use of standards-compliant user agents, the number of Web users using the MSIE family of browsers is too large to be simply ignored or browbeaten, and even if we do want to gently nudge them with our design choices, IECCs allow us to display such messages only to those who need them, and not to people who are already using a good browser.

Third, I say to those who think that building fixes for multiple browsers will lead to huge increases in overhead, not so. Using IECCs and judicious choices in classes, you can target each version of IE in one extra stylesheet, which only the browsers being fed the fixes have to download.

For more information on using the IECC technique, visit Quirksmode's page on Conditional Comments. Unfortunately, this page says, they only work under IE-Win.

A lot of people want to approach the Web as though it were an informal venue. After all, they think, it's the hip, new thing; All the cool kids are doing it; There's a new jargon of acronyms you need to learn to use it.

That simply is not true.

Yes, the social networking sites are very informal. Yes, the median age of World Wide Web (as distinguished from Internet) users is probably below 25. Yes, the jargon and acronyms change the dynamic on certain social interaction sites. Yes, there is quite a lot of buzz surrounding the Web, specifically, and the Internet, in general. And yes, there are places on this information superhighway where functional illiterates can be revered.

But your organization's Web site is probably not one of those special places. Okay, maybe your target audience will be users in an age range below 25, and maybe your organization is doing something with social networking. I understand that you want your site to generate a lot of discussion, and thereby, traffic. However, even in those instances, good design and good copywriting can make your site more successful and more likely to attract the coveted return visitors.

The idea that a lot of people have is that the World Wide Web is the stupid cousin of their brick-and-mortar storefront. Because of this, they think that visitors to their Web site will judge them less harshly than visitors to their physical office.

In fact, it is the opposite. In physical space, you have limits to what you can do with your office. The architect may have put a wall where you didn't want one, and the windows may not be adequate to keep potted plants alive. But on the Web, you are only limited by your imagination and your technical expertise.

Not only do your Web visitors expect, or at least want (some of them have become jaded and no longer expect it), professionalism, clean design, good colors, and useful information; but they also tend to be more technically savvy than the people who come through your physical doors. Because of this, many of them will judge your site based on the cleanness of the code... or at least by the loading time, which is a pretty good indication of code efficiency.

The idea of clean, efficient code, clean, solid design, and well-balanced colors may seem obvious to you, but a quick look at the state of the Web shows us that it is far from obvious to a lot of people. There are many organizations whose Web sites appear to have been put together by a 12-year-old.

Let me tell you that some of them were.

Now, the hip, fresh, new aura that people try to put on the Web does lend itself to the notion that kids are better able to understand this quickly-shifting landscape, but I don't believe that is true. For one thing, stability and agility come better by training than by natural ability. Remember the old adage about the baseball coach. He has two players who run from home plate to first in the same amount of time. One has good form, the other doesn't. The coach will pick the one with bad form, because with training he can outpace the one with good form.

Also, with age and experience comes better judgment. And with the wisdom of experience comes the understanding that not everything that is popular is profitable. Finally, professionalism tends to increase with age, as does understanding of logical consequences.

So, it's usually not a good idea to let a juvenile build your presence on the Web. Your Web presence needs to have the responsibility and gravitas that your organization has.

It needs to be factually accurate.

It needs to be respectful of your clientele, target audience, or membership.

It needs to spell things correctly.

It needs to use grammar effectively and correctly to communicate ideas well.

It needs to have good design and colors to make visitors feel comfortable.

It needs to use efficient code and current best practices so that your site isn't wasting bandwidth or being incorrectly rendered in browsers.

There is no place for sloppiness in your organization's Web presence. Your visitors are using it to decide how credible, authentic, and stable you and your organization are. Make sure it is making you look good.

Flash has become very popular on the World Wide Web, and Adobe claims that its player is installed on 99% of Web-enabled desktops in mature markets. In fact, Flash content has become so popular that other programmers have developed players to display Flash content in browsers and in stand-alone viewers.

Flash allows the inline display of video, graphics, dynamic applications, and other gee-whiz neat features.

So, it is tempting for Web designers to use it for all sorts of things.

But that temptation should be resisted. For one thing, developers tend to write for the latest version of Flash, which leaves out at least a tenth of users, according to Adobe's statistics. For comparison, in November of 2008, Microsoft(tm) Windows(tm) Vista(tm) had about 17% market penetration[1] (it passed 10% in March '08). For another, Flash files can cause the visitor's browser to use an inordinate number of CPU cycles to display a page. For another, Flash animations may prevent your navigation from working as expected (dynamic menus get tucked under a silly Flash video on many Web sites, preventing visitors from being able to use them). For another, Flash is not as understandable to search engines. Finally, using Flash, your information may not reach your visitors, as users with disabilities may find using Flash difficult or impossible, while other users may still have Flash installed but disabled because of security concerns or other factors.

In other words, Flash files can annoy your visitors or prevent them from seeing your content if used inappropriately — that is, in places where the content unnecessarily relies on the technology. But designers still want to be able to deliver some of those neat features to their visitors. Can this still be accomplished?

It can. First, let me say that Flash has its place. YouTube, for example, couldn't do what it does without it. And if your content requires extensive use of video or interactive games, Flash may be the best technology for your content — but it is a technology for video and interactive content, not for layout. Your layout should use (X)HTML+CSS or XML+XSLT+CSS. These standards offer the best in accessibility, visitor comfort and control, and search-engine friendliness.

And, as it happens, CSS offers you as a designer with an easy way to create neat effects that don't significantly increase page loading time.

In this article, I'm going to show you haw to create a graphical button that will change when your visitors hover over it and then when they click on it. Here's the HTML you'll need:
<div class="navigation">
<a href="page1.htm">These</a>
<a href="page2.htm">Are</a>
<a href="page3.htm">Navigation</a>
<a href="page4.htm">Links</a>
<a nohref="nohref" class="here">Current Page</a>
</div>

Not much to that, is there? Notice how the last link is different? I forgot to mention that I'm also going to show you how to show your visitors where they are.

It is an important rule of thumb in Web design to never show your visitors a link that doesn't do anything. If you link to the page users are on (except in a trail of breadcrumbs), your visitor may click on the link and wonder why nothing is happening (especially on a fast computer and a fast connection). The visitor may then start clicking madly on the link, confused about why the computer has suddenly become unresponsive. So, we're going to make a "You are Here" cue. Note that we've also removed the actual hyperlink reference (href) and put a placeholder there to ensure that the browser treats it properly.

Now that we have the HTML, let's see what goes in the stylesheet.
/* Stylesheet main.css */
.navigation a, .navigation a:link, .navigation a:visited { display: block; background: url('myimage.png'); height: 50px; padding: 5px; }
.navigation a:hover { background-position: 0px -50px; }
.navigation a:active { background-position: 0px -100px; }
.navigation a.here { background-position: 0px -150px; }


Notice a few things, here: The order of these style declarations is important. Style declarations cascade in the order they appear in the document, so the last statement on any particular attribute will be the one that the browser renders, and attributes that are not overridden will continue to render. This means that we don't have to re-declare the height, background URL, and padding of the navigation anchors in the above example, when we're declaring what style is applied to an anchor that the visitor's pointer is hovering over. I've put the "You are Here" one at the end, because I don't want it to change when the visitor hovers over it (notice that 'here' is a class and uses a period, not a pseudoclass like the others, which use colons). You could, if you wanted, make this behavior the same as the hover behavior, but I think that may confuse some visitors.

The real magic here is with the background position. By default, CSS specification says renderers should assume top left for background position; in other words, 0px 0px. We'll make the button's background shift by 50px when we hover over it. I've given my buttons a five pixel padding, which gives me two pixels of apparent padding and three pixels for border bevel or decoration on each button. Notice that I haven't given my buttons a width. This is because I prefer to use text on top of a generic background, so that I can easily change the button words (and with a little scripting, I could even show the buttons in the visitor's native language, but that's well beyond the scope of anything I'd write here).

This style of button will work well with vertically stacked buttons of fluid width, and that means the background image should be unreasonably wide and not have a bevel on the right edge. I prefer to make a button that either has no decorations on the sides or has decoration on only one side (usually on the left). This allows me to look good and be a little lazy, or efficient, if you'll allow my preferred term. ;)

One of the best things about this technique is that it allows you to style and 'animate' your navigation buttons using only one image. This is important because every image your visitors' browsers have to download requires connection overhead, so fewer connections to transmit the same amount of data means less bandwidth overall.

So, what do we do for the background image? Load up your favorite photo editor. I use The GIMP, but you can use Photoshop or even MS-Paint, if you really want to (I think it will save a GIF... just change the URL in the CSS so it points to your image). Create a new file that is whatever width you think is necessary and 200 pixels tall. I make mine 600 or 1300 pixels wide, depending on how likely I think it is that a button will exceed 600 pixels on someone's insanely wide screen. Usually, 600 is enough, especially if you're going to limit your navigation bar to less than 40% of the browser window. Mark (GIMP and Photoshop allow guide lines, in other editors, you may have to draw a line) every 50 pixels for the boundaries between button states.

Remember, the first 50 pixels will show normally, 51-100 when the visitor hovers the pointer over it, 101-150 when the user clicks or otherwise activates the link, and 151-200 when the link is described as being the current page.

Now, simply draw whatever you want your button background to be in each of the four states.

Save the file in the appropriate directory with the appropriate file type (in my example, myimage.png).

Take a look in your favorite browser. Enjoy.

Which of these would you like to see me post here regularly?

A better idea for a recurring feature, or notes on your selection above: