» HTML

Are Template Clubs Losing The Plot?

Dan Luton — Wed, 19 Jan 2011 16:30:31 +0000

I've long been a fan of the cutting-edge design work produced by many of the top template clubs.

Rich, unique designs are being published every month for keen club members to download and deploy for their own web projects, making it easy to get an amazing looking website up-and-running in relatively little time.

However, what I'm not a fan of is the way many templates are built these days.

A good poke around under the hood is enough to make anyone who works with HTML/PHP/CSS frown at what's going on – yes, the code is normally nicely structured, but what is rendered in the browser needs to be carefully considered before using a commercial theme.

Framework = More Work?

The trend these days is to use a proprietary theme framework – these are produced by the clubs and normally the core is shared under a GPL license. All of the club template releases are built on this framework, which offers a bewildering amount of flexibility in layout and features. Often they come complete with an entire management system which is used to configure how everything works. This management can even stretch beyond the template and start managing core features of the CMS itself.

However, the learning curve tends to be steep, with the frameworks being massively complex in their implementation, and core changes to the code are far more difficult than they would be for a more traditionally constructed theme.

Many aspects of the layout can be adjusted within the theme's setup options, so in a lot of cases, code intervention isn't really needed – but what if you need to break free of the framework for something? You have to commit to learning how everything works within the framework, and often even small adjustments are hugely complex given the more rigid nature of the frameworks (which are normally based on a CSS grid system).

More Features = Less Performance

Ah, HTTP requests. A real hog of performance, and something you want to really keep to a minimum. By using clever techniques such as CSS sprites, JS and CSS combining, you can massively reduce the number of requests thus speeding things up – a win for your users, a win for your host, and a win for the performance of the site.

Now, I understand the requirement to separate elements up in order to give flexibility to a theme – but at what cost? Dozens of individual CSS and Javascript files cannot be a good thing.

Take a nice, lean CMS like WordPress for example. I recently was asked to investigate why the breadcrumb trail wasn't working (turns out the theme's breadcrumbs file was pretty much useless) and was horrified at the source output that I saw. Take a look at these stats:

section (a 'normal' site would be around 20-100 lines) including:

233 lines of code for the section (a ‘normal’ site would be around 20-100 lines) including:
46 lines of embedded CSS
16 separate CSS files
12 separate Javascript files
2 Javascript libraries
Almost 1400 lines of code for the home page

Which all add up to the following:

308 total objects
287 images
300Kb of scripts
A 2,700Kb total page size

Of course, I understand that sites will vary in content, plus there were a couple of extra plug-ins installed in this case – but a quick look at the relevant demo sites paints a pretty similar picture. When you consider that template clubs usually run on some pretty beefy server hardware, they can give a false impression of how the template might perform. Once deployed to a more common shared hosting platform, performance will undoubtedly suffer.

What can we do about it?

Template clubs and their projects are obviously a great way for novice developers and webmasters to get started, but many will be oblivious to what goes on under the surface of a theme, blinded by the fancy design and effects.

It's a shame in some ways, as the popularity of these clubs means that a high percentage of CMS websites will be using them, which could portray the whole platform in a negative light if the performance of a platform is judged on these sites.

My advice: take a look at what's going on under the hood when using a club template, you might be surprised at what you see. All those features aren't really free, and are costing you dearly in terms of performance. Also, to get some real stats on your site, run it through a performance checker like http://websiteoptimization.com/services/analyze/ to see how your own projects perform.

Of course, not all theme providers can be tarred with the same brush – know of a club producing more streamlined templates without all the fluff? Let us know in the comments!

Anatomy of a Newsletter

Dan Luton — Mon, 04 Jan 2010 11:12:59 +0000

Newsletter crafting can be pretty straightforward but cumbersome at times due to the way they must be constructed in order to retain the original designs – even more so if the designs are quite complex and laden with images.

Getting Started

First off, work from a design so you know how the final construction will look. This can be a full-blown Photoshop mock-up, or a wireframe…however you make it, just make sure it's designed as you'd like the final newsletter to appear.

Once your design is ready, you will need to create the framework of the newsletter, using HTML tables and a combination of carefully defined table-cells. You can save some time here by using a visual (WYSIWYG) editor such as Dreamweaver to visually create the layout; this will save a significant amount of time over hand-coding the table layout. In fact, you can use a visual editor to create the whole thing – but I personally prefer to see exactly what's going on, so tend to hand-code once the basic structure is defined.

Note that the table I've used here is quite narrow (600px) and centered – you can use your own dimensions and alignment here, but this arrangement seems to work best for most email clients and display resolutions.

I've also left the border active (border="1") which will help when I add content to the layout. You can disable this later if you do not wish the borders to be displayed in the final newsletter.

Adding Content

Once you have your basic structure in place, you're ready to start adding content (text and images) to the newsletter. For now, don't worry about the styling; just add the bulk of the text and any images you have to the layout.

If you don't have final images, use exact-sized placeholders until the graphics are ready. This will help to get the layout exactly right, and show where any fine adjustments to the table layout is needed.

Images should be added using the absolute path to the server where they are stored:

…this will ensure the images load correctly into the document. Note that many email clients will require user approval before they fully display embedded images – it is not possible to override this.

Adding the Style

This is where most of the time is consumed – actually adding the inline CSS to the layout in order to get the look to match the design you've made. Inline styling offers the best and most widely compatible method to add styling to the newsletter. If you're comfortable with hand-coding the styles, this is the best way – but of course you can always use a visual editor…just keep an eye on the way the styling is added to the document – some editors (such as Dreamweaver) may define styles in a stylesheet format which won't work for the newsletter.

The styles must be applied to each and every element that needs to be altered from the default. You can of course apply a global style to the whole container (the main table definition) to set a standard font size/colour/style to start you off:

This will give you your text style for any text that does not have it's own definition. Much of the styling information will be applied to things like headers and links:

Here's My Title

Check out the following link:

My Link

It is necessary to add all styling information in this way. You should also refrain from using shorthand CSS as some email clients will ignore this method of styling, such as:

This is my paragraph.

Viewing the Newsletter in Other Formats

If your mass-mail system supports a plain-text version of the newsletter, you should take the time to create this alongside your HTML version so that users who cannot view mail in HTML format can still read the email.

If this is not practical or possible, provide a link to the HTML document on your server at the top of the email, this way readers who cannot properly view the newsletter will at least have the option to view the newsletter in their browser, which has a good chance of being rendered as you intended it.

The finished example (click to view the actual document in your browser)