Archive for the ‘Best Practices’ Category
SEO Rules vs. SEO Concepts
Friday, July 18th, 2008Often times, web development blog posts recite easy to understand, step-by-step instructions on how to optimize XHTML code for SEO. Generally, I think this is good. The fact is, web users have low attention spans, and usually the best way to get a message across is to state it simply in point form. But in order for developers and internet marketers to enhance their abilities over the long haul, more is necessary, as we’ll discuss. With this article I’ll show how online writers and readers alike can become part of a long-term commitment to making the web a better place to surf.
Why lists of “rules” can often fail in the long run
It is often said that behind every rule there is an underlying principle. Let’s illustrate this with an example. When a blog post tells a user to use H1 tags for headings instead of something clunky like
<div class=”header_main”>My Example Heading</div>
then the whole reason behind the necessity of the H1 may become lost on the reader, especially a reader that is new to web development, or is picking it up simply as a hobby. In such a case, the reader needs to understand why such an approach to markup is necessary — not just that it is necessary. Simply stated, websites are more findable, search engine friendly, and faster loading when the markup is semantic. Now, I’m not going to go into the details of defining “semantic markup” here. That is a topic for another post. But I’m emphasizing that the rules can easily be forgotten over the long run if the readers are not understanding the reasons behind certain SEO techniques, best practice coding, and other standards-based ideas.
Online writers and readers both play a role
So writers should be more aware of the effect their content will have on the future of web development, SEO, and the internet in general. We as writers should strive to teach others based on strong foundations and concepts that are clearly understood. Likewise, we as readers need to strive to read and learn from others based on strong foundations and concepts that are clearly explained. Both sides have a significant role to play in what the web will be like down the road.
Readers and writers, aim for a stronger foundation of learning
Therefore, in conclusion, while the typical bulleted lists and point-form rule-sets have their place and can be very useful, the more important “reasons behind the rules” are what will truly enhance a reader’s development as a web site professional, and will, by extension, make the web a better place for all.
Tips for Better CSS Files
Thursday, July 3rd, 2008While working on medium to fairly large websites, I’ve recently found it helpful to apply certain coding practices in my CSS files to help readability, and to ensure that any future developers (including me) will have little difficulty editing the CSS code. Since my main CSS files nowadays often end up being anywhere from 1000 to 2000 lines long, here are some quick tips that I think help CSS code to be more readable and web developer-friendly:
1. Indent CSS using the same structure as the HTML
I don’t know why this isn’t more prevalent (at least it’s not written about a lot online), but I recently started doing this after viewing an online video from a fairly popular CSS developer and blogger. Having the Web Developer Tool Bar in Firefox helps track down CSS fairly quickly, I find the indenting actually assists the development of the site itself. It’s much easier to read the CSS and see what the code is doing, even as you type. Especially is this important if the project spans many weeks or months, as the structure of the HTML and how it relates to the CSS styles can easily go forgotten. So, indent your CSS in a hierarchical manner so you can easily match a nested section of HTML to its CSS counterpart.
2. Use lots of spacing and comments
The comments are generally a no-brainer. All good code is commented. But the spacing is simply for readability. I know, the more white space you have, the more bandwidth it’ll cost you, but you can always remove the white space towards the end of the project, if necessary. And spacing should not just include that which occurs as entire lines between ID and Class groupings — I personally like to see white space in between all the selectors and colons as well as between grouped styles that are organized all on one line (as opposed to one on each line within the group, as seems to be most common). So do this:
#example_section {
float: left;
width: 300px;
height: 400px;
background: url(../images/example_image.jpg) no-repeat 0 0;
}.example_section_2 {
color: #fff;
line-height: 14px;
}
Not this:
#example_section{
float:left;
width:300px;
height:400px;
background:url(../images/example_image.jpg) no-repeat 0 0;
}
.example_section_2{
color:#fff;
l ine-height: 14px;
}
The difference is subtle in this short example, but the first example is much easier to read when applied to a 1000+ line CSS file.
3. Always use external files to hold your CSS code
This is a basic tip, and all good developers should do this. If your main CSS file applies to dozens, or even hundreds, of content pages, then your pages will load faster with an external file because all subsequent page loads will get the CSS code from your browser’s cache. Thus the CSS will only load once, saving bandwidth and improving user wait times. And of course, the other benefit is that the CSS stays separate from the HTML, the same way the JavaScript should, keeping the 3 layers of front end web development clean and separate.
4. Keep default styles and link styles near the top
For me, this one is a bit of a personal preference. I like to know that all my default styles (CSS reset code, heading styles, unordered list styles, hyperlink styles) are easily accesible near the top of the CSS document. After all, those styles are not always part of the HTML hierarchy, and often won’t fit well with the DIVs, custom paragraph tags and the like. So when I do a high-speed scroll through my CSS code, I know that when I get to a certain section near the top (in my case the section that styles all hyper links on the page), then I know that all my default styles have ended and the hierarchical section begins. And with some effective commenting, the rest of the document can be just as easy to scroll through and find a particular section.
5. Use shorthand notation
This will improve your CSS code immensely, as well as save a few kilobytes in bandwidth. Basically it means putting related CSS styles on one line instead of declaring them all using separate selectors. So for example, here is a long-winded example of applying a background image to a DIV tag:
#my_example {
background-image: url(../example_image.jpg);
background-image: background-color: transparent;
background-image: background-repeat: no-repeat;
background-image: background-position: 0 0;
}
And here is the better shorthand version of the above code:
#my_example {
background-image: url(../example_image.jpg) transparent no-repeat 0 0;
}
Much easier to read, easier to maintain, and the order of the values doesn’t matter, so you can make the reference to the JPEG image the last value if you prefer.
Benefits while you develop as well as in the future
The benefits reaped from these tips will not only help developers working on the site in the future, but will help you during the process of developing the site. Often, client requests and other project details interrupt the workflow. That can put a damper on your mental ability to stay focused on how you’ve organized your code. To ensure that your code doesn’t become an unintelligible mess, keep things neat and organized and you’ll see the benefits now as well as in the future.
Must-use Methods to Spam-Proof Your Email Address
Wednesday, June 25th, 2008Working for a busy web development & hosting company exposes me to the sad fact that well over 90% of website owners today do virtually nothing to protect themselves from email spam. Spam filters are good, and they’ve come a long way, but they are not the perfect solution — far from it. Even with a close to perfect spam filtering system in place (which never happens), users will still be inclined to waste time sifting through junk mail just to ensure that nothing was incorrectly filtered.
In this post, I’ll describe a few solid methods to ensure that your email address will not be harvested by “bots” or other automated programs that harvest emails from naive website owners.
The best junk mail folder is no junk mail folder
Okay, that sub-heading is a little misleading, since I don’t honestly believe it’s possible to eliminate the junk mail folder — even if the methods outlined below are used. But with good solid spam-proofing methods carefully followed, I believe that the junk mail folder can be empty 99% of the time, if not more.
1. Don’t use predictable user names for your email addresses
This is one of the methods that I haven’t really seen promoted much, and I’m listing it first because it really gets to the root of the issue. When I registered a domain name last year, I started out using a very typical email address: info@mydomain.com. Guess what? Within days, even though that email address was not listed on my site, I started getting spam in my inbox and junk mail folder regularly. Spammers know that as soon as a domain is registered, and a site goes up on the web, the “info”, “admin” and “sales” email accounts are likely used first. But don’t fall for this all too common mistake.
It is absolutely not true that potential customers are going to “guess” your email address using one of the “common” email prefixes (info, admin, support, etc). That is quite ridiculous. People don’t guess phone numbers, or bricks and mortar addresses; they look them up. The same applies to email. If they want to know your email address, they’ll look it up on your contact page, or else they’ll ask you directly, if that is an option.
So, choose an email address that is unique and cannot be “guessed”, but is still memorable and is associated with your product or service and the related company department. For example, instead of sales@yourdomain.com, use sales-dept@yourdomain.com. Or instead of support@yourdomain.com, use techsupport@yourdomain.com.
2. Do not display your email address on your web site
This is a tougher one, but it can be done, while still allowing users to send you email. There are tons of Javascript methods available online to “cloak” your email address, and many of them are easy to implement. If you are a novice web developer and aren’t familiar with any of these methods, then take the time to become familiar with them. One good one will do, and it will pay off in the end for your own sites, and for any client sites you work on.
There are also similar, simpler methods that involve replacing characters in the email string with HTML character codes. For example, this code & #64; (without the space after the ampersand) is equivalent to the @ symbol. You can also replace the entire email address, or parts of the email address with this kind of code, and so it is less likely that an email harvesting program or spider-like bot will find your address. I personally like to mix up regular letters with HTML character codes to keep it inconsistent, just in case the bot is programmed to sniff out the character codes and interpret them. But the JavaScript methods are much more secure, from my experience.
Also, be sure that the clickable link that appears for the user to see on the page does not contain your actual email address. Instead use a “call to action” phrase inside the anchor tag. For example:
This ensures that the bots will not be able to find your email address in the code or in the web page’s text. Definitely a safer way to go.
3. Use a contact form instead of an email address
This is a simple one, and is probably the only guaranteed method. The fact is, although the methods above work quite well, a human can still find your email address – it just takes more effort. So, if you want to completely avoid all spam, then I would suggest using a simple contact form. Don’t forget to validate the fields using JavaScript and a server side language, to ensure the fields are filled out correctly, thus reducing form submission spam.
4. Use a separate email address for subscriptions, forums, etc.
I have a hotmail address that I’ve been using for about 7 years, and I have never received a single spam message in it. I have never given out that address to anyone except close friends. But for newsletters, subscriptions, forum registrations, online purchases, etc., I have a completely separate email account. I expect junk in that one, so it’s no big deal. So take the time to register a separate “subscription only” email address that you don’t mind being public. That way, the email you use for business communications will not be made public – except where it appears on your website in the protected manner I’ve listed above.
What about using an image, or spaces, or the word “AT”?
I personally don’t like methods like making your email address an image, or putting spaces in between the characters in your email address, or using the word “AT” in place of the @ symbol. I think those are amateurish solutions, and don’t belong on professionally developed websites.
What does this have to do with front end web development?
Although much of the information I’ve presented here is fairly well known to experienced web developers, I feel it hasn’t been taken seriously as “best practices” in web development. I don’t think web developers should wait for the client to suggest methods to secure their public email addresses. They probably will never suggest such a thing; they probably don’t even know it’s possible.
It’s the webdeveloper’s job to offer the client the best possible web site solution, and this includes taking measures to ensure the client’s email addresses are protected from, or at the very least, minimally affected by, unsolicited email.
Do You Comment Your DIVs?
Sunday, May 25th, 2008
A little background
Since I started working for my current employer, I’ve built a number of sites from scratch using CSS layouts. I’ve also had to work on older web sites built using older HTML methods. The good thing is, many of these sites have CSS-based layouts. The annoying part is that some of them suffer from divitis (i.e. too many nested <DIV> tags, in the same style as table layouts). In my view, if developers are going to use this style of layout, then they might as well use tables.
The problem is…
But getting to the purpose of this post – what I find tedious at times is when I need to wade through dozens of nested DIV tags, and there are no comments to guide me along. I might have to delete or alter one particular DIV. Or I might even have to add another DIV to the already existing mess, as it may not be in the budget to rework the whole section. But I can’t tell just from glancing at the code which DIV is the one I need to edit.
Dreamweaver offers some help
Fortunately, there’s a simple feature in Dreamweaver that allows you to right-click on any opening tag and choose “edit tag”. This highlights the entire tag, including closing tag, so you can see where it ends. But that method is not always easy, since the opening and closing tags may be in different files (because of server-side includes), and the closing tag may even be well off the screen, and so the whole section is not completely visible. Thus, you still have to do a little poking around just to ensure you’re deleting/editing the correct tag.
My recommended solution
My solution to this problem is to put a comment at the end of every single DIV in my HTML. Here is an example:
I know, it adds to the file size, and it can be pointless at times (for example when the closing DIV tag is on the next line with nothing nested). But commenting ensures that anyone who needs to look at the code will be able to read it easily, and most importantly, be able to discern almost immediately which section of code he will have to edit.
I think this is a good, clean, and universal solution to many code reading issues, and I find that it should be considered a “best practice” — especially in complex CSS layouts.
One caution about using this method: Including multiple comments in a CSS layout can trigger the IE6 ghost text bug. But the simple solution is to put the comment just inside the closing div tag. It’s not as clean looking, but it’s an acceptable workaround.