Day 15: Web Design Best Practices

Do you know the “best prac­tices” in web design and devel­op­ment? I fig­ure since this is very indi­vid­ual, it would be inter­est­ing to do some research on it to see what peo­ple con­sider to be best practices.

This is post 15/30 for #30daysofcreativity.

Cod­ing standards

Let’s start with cod­ing stan­dards. There are many dif­fer­ent ways to write code and a lot of peo­ple do it very dif­fer­ently. I’m talk­ing about what cod­ing style they use—how their code looks and how they struc­ture their web­site or application.

First of all, some­thing that is quite obvi­ous to most devel­op­ers these days, the best prac­tice is to sep­a­rate pre­sen­ta­tion from con­tent and behav­ior. The code should be writ­ten as seman­ti­cally as pos­si­ble to be easy to understand.

Third on the list on this web­site is pro­gres­sive enhance­ment and the way I see it, there are two types of pro­gres­sive enhancement—styling and Javascript. Start by apply­ing styles that work in every browser and when it looks at least accept­able cross-browser, start adding any nec­es­sary CSS3 you may want to use.

As for Javascript, start out by devel­op­ing the site with­out it. Once the site works well with­out Javascript, you can start pro­gres­sively adding it. Note that any Javascript code you use should ide­ally enhance the usabil­ity of the site. “Com­mu­ni­cate, don’t decorate.”

Read­abil­ity

As for inden­ta­tion, the above men­tioned web­site sug­gests using four soft-spaces but I per­son­ally don’t agree. My pref­er­ence is like the Dru­pal cod­ing stan­dard two soft-spaces since four is just too wide for my view­ing pleasure.

But any­way, whether you use two or four spaces doesn’t really mat­ter as long as you don’t use a reg­u­lar tab. The tab messes with how the code is dis­played across dif­fer­ent OS’s and editors.

Then we have Javascript, HTML and CSS com­pres­sion. I agree with the pre­vi­ously linked to site that read­abil­ity should be pri­or­i­tized over file-size. When needed, com­pres­sion can be applied with server-side meth­ods instead of for­mat­ting the text. Of course, using many com­ments is a plus.

HTML

As we men­tioned before, the markup should be kept as seman­tic as pos­si­ble. Now that the XHTML 2 spec­i­fi­ca­tion is dis­con­tin­ued in favor of HTML5, I’d sug­gest using either HTML 4.01 Strict or jump right ahead to HTML5. You can add Javascript to make HTML5 ele­ments work in older browsers so long as the user has Javascript enabled.

Ide­ally the markup should of course be valid, checked with the W3C val­ida­tor. How­ever, using some CMS’s this may some­times be dif­fi­cult to achieve. While I man­aged to get Dru­pal to val­i­date as HTML 4.01 Strict, some­times peo­ple choose to sac­ri­fice val­i­da­tion for, as the men­tioned site says, “cross-browser experience.”

As for meta tags, we should spec­ify that the markup is served as UTF-8. You spec­ify this a bit dif­fer­ent depend­ing on what ver­sion of HTML you are using. Another use­ful meta tag that should always be spec­i­fied in my opin­ion is the meta descrip­tion. Since this is what shows up in the Google search results, it’s a huge sell­ing point.

Google them­selves have said some time ago that the meta key­words are no longer used to rank web­sites. It’s pos­si­ble that some other search engines still use it but since 98% of my vis­i­tors use Google, I feel that I can safely ignore it. It’s just a few unnec­es­sary bytes of band­width being wasted.

I shouldn’t have to men­tion that today it’s cus­tom­ary to use CSS lay­outs on your site and use tables only for pre­sen­ta­tion of data—never build table-based layouts.

CSS

This is also basic stuff that we should all know. Don’t use inline styles—keep your code well orga­nized in exter­nal files. Make sure your code val­i­dates. Try as hard as you can to avoid using con­di­tional com­ments or IE “hacks” to keep the code easy to maintain.

It’s rec­om­mended by many to use short­hand CSS to keep the code tidy. Pix­els ver­sus Em’s is a much debated sub­ject and the opin­ions about this dif­fers. You’ll have to make up your own mind but what I can say is that all mod­ern browsers do allow zoom­ing text sizes spec­i­fied in either of the two options these days and Safari for exam­ple lets you choose your min­i­mal font size.

Again ref­er­enc­ing Molecular.com which matches my own opin­ion, CSS sprites are pre­ferred above the use of sep­a­rate back­ground images. The biggest advan­tage as far as I can see is the improved load­ing time and your images will no longer flicker on hover before the image is saved in cache.

The last thing I’ll men­tion for CSS is the use of a CSS reset file. It’s rec­om­mended to reset the browser’s default CSS with a CSS reset file and prefer­ably cus­tomize it for your own needs. I usu­ally start out with Eric Meyer’s CSS reset but check out this Site­Point Forums thread and you’ll see there’s a whole bunch of options.

Javascript

As with CSS, keep your Javascript well orga­nized and in exter­nal files instead of inline, and sep­a­rate styling from behav­ior. You should most often use CSS classes instead of chang­ing the style of con­tent from within your Javascript file.

This page on Opera.com describes many Javascript best prac­tices. To name a few, we have the pre­vi­ously men­tioned pro­gres­sive enhance­ment with grace­ful degra­da­tion, val­i­date any user input before using it, and avoid­ing global variables—try cre­at­ing your own name­spaces to keep the global scope uncluttered.

Check out the above linked to site or Drupal’s Javascript cod­ing stan­dards for a lot more rec­om­men­da­tions on how to build your Javascript.

Per­for­mance

As for per­for­mance, Molecular.com men­tions Yahoo! Per­for­mance Guide­lines which is a very nice ref­er­ence point for build­ing effi­cient sites. The YSlow Fire­fox plu­gin will mea­sure the per­for­mance of your site and grade you on sev­eral areas, show­ing you where there’s room for improvement.

When vis­it­ing Kings of Code 2009, I attended the pre­sen­ta­tion “Rich And Snappy Apps, No Scal­ing Required” by Thomas Fuchs and Amy Hoy, two great Javascript experts. They rec­om­mend using a tool called SmushIt to opti­mize images for the web, which works very nicely.

Another rec­om­men­da­tion I agree with is to use a frame­work instead of going through the has­sle of writ­ing your Javascript from scratch—it will save you some time and make cod­ing a lot more fun. While Amy and Thomas are Pro­to­type users, I’m per­son­ally a big fan of jQuery.

Finally, they rec­om­mended another tool called Sprock­ets, which is a Ruby library that will give you cleaner and more effi­cient Javascript.

See Molecular.com for more recommendations.

Search Engine Opti­miza­tion (SEO)

SEO is a very fuzzy sub­ject and if I’m cor­rect, Google is try­ing to get rid of the con­cept of opti­miz­ing for their search engine since it’s means to rank results very organ­i­cally and it may be hard when peo­ple are try­ing to fool the indexing.

But still, there are a few things I would say are best prac­tices that should be con­sid­ered dur­ing every project. The first one is to sim­ply have a nice struc­ture of headings—ideally one h1 ele­ment that is the most impor­tant piece of con­tent on the site, and the sec­ond most impor­tant are h2 ele­ments and so on.

As we men­tioned ear­lier, grace­ful degra­da­tion of Javascript is pre­ferred. Assume search engine bots do not have Javascript. If the user needs to take a spe­cific action via Javascript to access cer­tain con­tent, or you have a func­tion instead of a URL in an anchor href attribute, the search engine may not be able to index it.

Some argue that URL’s should be kept “clean” and con­tain tar­get key­words to rank well in search engines. While this may be true for other search engines, I’m not sure, it’s becom­ing less and less impor­tant when opti­miz­ing for Google. How­ever, remem­ber that com­plex URL’s are less hard for users to mem­o­rize, and they’re less readable.

For more on SEO you can check out Google’s Search Engine Opti­miza­tion Starter Guide.

Cross-browser test­ing

You know how it works—you need to check the web­site in all major and some­times less major browsers. I per­son­ally dis­cuss with my client to deter­mine if IE6 com­pat­i­bil­ity is nec­es­sary for the par­tic­u­lar project I’m work­ing on. If you know the quirks and use best prac­tices, your page should work in most, if not all, browsers.

IE 6–8 I test on two dif­fer­ent Win­dows XP vir­tual machines, and Chrome and Fire­fox is what I test with most fre­quently in MacOS X. Since Safari is using WebKit, like Chrome, I test my sites in that one less often. Opera is another one that needs to be tested for.

If you don’t have access to dif­fer­ent plat­forms via vir­tual machines, dual boot or dif­fer­ent com­put­ers, you can always use online ser­vices to test in dif­fer­ent browsers on dif­fer­ent OS’s. This is some­thing I do reg­u­larly when devel­op­ing email tem­plates, and my favorite ser­vice which I dearly rec­om­mend is Lit­musApp.

Lit­mus works very well for test­ing in email clients as well as mobile and desk­top browsers. Some­times it can be a bit slow but I still believe it’s the best soft­ware of its kind.

Con­clu­sion

My con­clu­sion after look­ing into this for a while is that these so called “best prac­tices” are highly sub­jec­tive and there are a lot of dif­fer­ent ones. I would say they fall into two dif­fer­ent categories—the best prac­tices of “cur­rent cod­ing stan­dards” and the guide­lines that a com­pany sets up for its employees.

I’ve sprin­kled this post with some ref­er­ence links that I rec­om­mend you have a look at. Most of all, I sug­gest you make up your own mind about what your per­sonal pref­er­ence regard­ing these best prac­tices are instead of blindly fol­low­ing some­one else’s lead.

Tomor­row we’ll go through some of the so called best prac­tices for free­lanc­ing and start­ing your own stu­dio, so stay tuned.

  •  
  • <a href=“http://www.facebook.com/share.php?v=4&src=bm&u=http://www.mrnordstrom.com/2010/06/15/day-15-web-design-best-practices/&t=Day+15%3A+Web+Design+Best+Practices” rel=”” title=“Share this on Face­book” onclick=“javascript:pageTracker._trackPageview(‘/outbound/article/www.facebook.com’); window.open(this.href,“sharer’,‘toolbar=0,status=0,width=626,height=436′); return false;”> 
  •  
  •  
  •  

One response to “Day 15: Web Design Best Practices”

  1. Day 30: #30daysofcreativity, Twentynine Highlights

    […] June 15th by me Web Design Best Practices […]

Leave a Reply