Tim Benniks, Front-end Engineer - Blogpost

A mobile development strategy

2011-02-02T19:18:21+01:00

Things to keep in mind when developing for mobile

If you build a mobile website, you could re-use the templates that are used for the regular website and just change the CSS. So, downscale images, downscale the grid, hide certain assets, and maybe put the menu on the top of the page.

I used the tricks above on my own website and wrote about them here. I used media queries and a fluid grid to make my website accessible to all the devices I liked. Developing in this particular way is fine for websites that do not have a specific mobile concept. It just makes them easier to navigate on an iPad or HTC phone. But you should not do this for a project that has it’s main focus on mobile.

If you are developing a specific website or app for a mobile device, there are some considerations to keep in mind. Remember that you usually have a strict policy on Internet use and that you only have a 3G or GPRS connection. Even if you hide the slide show or the background images, the browser will still download them. The same goes for resizing images with CSS. You uploaded a big image for your desktop users, but you scale it down for mobile users. It turns out that the mobile browser actually downloads the big image and then scales it down.

For me this is a total “no-go”. Why load stuff you can’t even see or scale down? It just slows down the experience and drives up your Internet costs.

Some companies advertise that they allow flash to work on their device. That sounds promising, but I have not seen any workable and performing sites yet. The flash drivers on those devices are not optimized for a mobile and slow down or crash the browser. A definite “no-go” again.

Context baby!

When you develop for mobile, in what context users view your site is very important. On a mobile you are usually more hands-on and more goal-focused. Imagine running for the train and you forgot from what lane your train is departing. You grab your mobile, squeeze your bagel somewhere and browse to the train company website to check the departures. How frustrated would you be if you had to browse through 5 pages and scroll along media players that show the company’s history and such? You just want to get to these departure lanes...

I propose a set of simple templates that already know that the website is being viewed on some sort of mobile / touch device. In this template you can leave out all the fancy slide shows and high-res images. Instead, just focus on the most important information.

I personally think that if you design a website, you should start with the mobile version. It let’s you and your client focus on the most important piece of information on the entire website. After that, scale up and design the fancy stuff. If you organize your process this way, hopefully all your team members get a sort of group conscience that you are working on a design that has to be very adaptable to the users context. Everything should be flexible and fast. It’s the wobbly web people, not a magazine... Nothing is fixed anymore, not even pixels (check the iPhone 4 screen).

Device classes

Because you can never develop for all devices in the world, it’s handy to classify the most used resolutions and devices into some groups. You can target your design and development to each of these groups.

Each of these device classes has a unique:

context (chill mode on the couch, desk use, running);
input method (touch events, mouse etc);
average display size.

Luke Wroblowski wrote a great piece about this.

Responsive design and fluid stuff

Responsive design is a relatively new term, but actually it’s as old as the Internet. Remember all these old school websites that would fill your whole screen? These designs where percentage based and would scale down if you had a smaller screen.

Responsive design means that you design something that is able to respond to change. The design is adaptive to the context it’s used in. For example: resolution, landscape or portrait, JavaScript support, CSS3 support, touch or mouse oriented. So it’s not just a fluid grid.

Stuff you can use when developing a responsive design

Progressive enhancement

This is a much discussed topic for years. Any respectable web developer should know about this by now. It is even more important to use it for mobile development. There are loads of devices with many different browsers and versions. Feature detecting is a key element in responsive design. This is a nice article about progressive enhancement.

Fluid “em-based” or “%-based” grids

Using a fluid grid can help you a lot in mobile development. As there are a lot of different screen resolutions it’s not manageable to design a fixed grid for every device. Just design for an average screen that has been classified in the device classes mentioned above.

If your design is fluid you can still pull of resolutions that fit in the classification but are a little different then the one you initially designed for.

Fluid images and client side adaptive image replacement

Fluid images is a very sexy technique which Ethan Marcotte helped make famous. It basically means that even your images scale according to the resolution of the device.

There is a drawback to this technique. To be able to scale the images you need to use the biggest one possible to match all your design stages. A stretched image on a website is horrible. A nice solution is “client side adaptive image replacement”. Read more about about it here.

Media queries

Media queries are hot! The spec is not entirely finished but they are very usable nowadays. Media queries let you add CSS rules according to a query that you specify. For example “orientation: landscape”, or “screen”, or “max-device-width: 768px”. Picture the strength of these when you build one interface for let’s say two devices classes. When you get below a screen width of 320px, move the menu to the top and when you hit 240px remove that new column and make the typography a little bigger. Try resizing this website, look at the Media query magic!

Conclusion

If you put all of this together, mobile development is in desperate need of “adaptive” design and development. It’s hard to predict how many devices are yet to come, and what their capabilities and resolutions will be. If your design is adaptive and feature detecting you can be almost sure it will service old and new devices. This is a pretty bold statement so let’s hope browsers keep implementing web standards the correct way.

If we developers and (especially designers) keep it about web-standards, we can show our team-leads and project managers that they do not have to buy insanely expensive packages like net biscuits. It would be awesome if designs become a little more web-oriented so that developers and designers can work together more closely. This not only prevents extra overhead in your project, but also helps creating a great standards-based web app that works on a large range of mobile devices.

Sources:

Non-blocking JavaScript roundup

2011-01-10T20:49:42+01:00

About blocking

In my opinion JavaScript plays an important role in the perceived speed of a website. While JavaScript is executed, nothing can happen on your page. Most browsers have only one thread for the UI and the JavaScript and because of this they can only do one thing at a time. The longer the JavaScript takes to load and parse, the longer it takes the browser to be able to do something with user input. The very existence of a script tag in your page is enough to make the page wait.

In this article I will outline some techniques to handle this issue in a pragmatic way. The blocking issue is important because speed and responsiveness is vital for a website. The faster a user perceives your website, the sweeter the experience is to them. The Yahoo! developer blog has a lot of data on this.

A reason why

There is a reason why browsers block page loading when they encounter a script tag. Blocking is a necessary part of the page life cycle because the script may make changes to the page while executing. An example is document.write which is often used by banners. The browser can never know what that document.write does with the current DOM. So it stops rendering and lets the script execute. Once that is done, the browser resumes building your page. This also goes for external scripts. Keep in mind that page rendering and user interaction can not happen during the execution of javascript.

Position

Back in the day when separation of structure, logic and styling became a best practise, it was advised to put all the external stuff in the head of the page. This would be an ideal example of that:

<html>
<head>
	<title>2003</title>
	<script type="text/javascript" src="prototype.js"></script>	
	<script type="text/javascript" src="effects.js"></script>
	<script type="text/javascript" src="common.js"></script>

	<link type="text/css" rel="stylesheet" href="style.css" />
</head>
<body>
	<h1>Meh.</h1>
</body>
</html>

In this 'once' excellent code we can see a major performance issue. Because there are three script tags in the header the browser has to parse them first before she starts to render the rest of the page. Let's say each file is big and takes about 100ms to download and parse. The perceived performance will suffer horribly because you have to wait about 300ms of blank page before you see something. A nice example is http://www.schiphol.nl. They have a stunning 28 JavaScript files loaded in the head of their homepage. Try to load this website with an empty cache and see the nasty stuff happen. For fun try the same from Italy. The experience is very slow and I would not like to come back to check the departure times again.

A simple solution for this would be to put the script tags just above the body end tag. Now the browser will render all the sweet stuff first and then blocks near the end to download and parse the JavaScript. If it blocks the UI in the end, it's a lot less harmful.

Combining

Now that your script tags are placed at the bottom, you still have multiple HTTP requests. An HTTP request generates overhead and is therefore harmful for the responsiveness en perceived speed of your website. A general rule of thumb that we have learned from Yahoo! is to combine your scripts. Three requests of 20kb take much longer than one request of 60kb.

Combining can be an automated process, so you don't have to bother putting all those files together yourself. The cool thing is that because of this automation you can still have separate files when developing. When the website is on a production server all JavaScript files get combined so there are as little requests as possible.

There is another great benefit from automating the combination of files. The combined file can also be compressed! This way you loose white space, comments and variable names get shortened. The smaller your file, the faster the download, the sweeter the experience becomes for you users.

Nonblocking

Nowadays it's a best practise to practise the techniques mentioned above. Next to this it is advisable to keep the amount of code small. Less code means a faster site because there is not much to download and parse. But, if we look at this best practise with realistic eyes, it's not going to work out. Our applications are bigger and fancier then ever before.

If you combine all files and put that file at the bottom, you still end up with one big file that holds off the document.ready event when downloading and parsing. The trick is to load the JavaScript after the page is finished loading. So after the window.load event.

Defer

There are a couple of techniques you can use to accomplish this. There is the defer attribute that you can place in your script tag. The fact that you pace the defer attribute on the script tag means that you tell the browser that the script will not change the DOM and it is safe to load the script after the page has been rendered. The downfall to this technique is that it is only supported by Internet Explorer and Firefox 3.5+.

Dynamic script elements

The DOM allows you to dynamically add and remove elements to it. Things like a link tag and a script tag are also DOM elements. You can change, add or remove them in any way you like with some basic DOM manipulation functions profited by JavaScript.

var scriptTag = document.createElement("script");
scriptTag.src = "file.js";
document.getElementsByTagName("head")[0].appendChild(scriptTag);

The newly generated script tag wil load file.js. The fancy thing about this technique is that the JavaScript file is loaded and executed without blocking the page while loading. It does not even matter where the script tag is placed.

When a file is downloaded this way it is automatically executed. This could potentially lead to some trouble with script dependencies. You have to find a way to know when the script is loaded, and ready to be executed. Most browsers fire a "load" event when the script source has been downloaded. You can add this to your function:

scriptTag.onLoad = function() {
	alert("I am loaded");
}

Of course Internet Explorer has a different implementation. They have implemented 5 ready states. The most important are "loaded" and "complete". Internet Explorer uses them inconsistently so it is wise to check for both ready states.

scriptTag.onreadystatechange = function() {
	if(scriptTag.onreadystatechange == "loaded" 
	|| scriptTag.onreadystatechange == "complete") {
		scriptTag.onreadystatechange = null;
		alert("I am loaded");
	}
}

If you combine everything you could write something like this:

function loadScript(url, callback) {
	var scriptTag = document.createElement("script");

	// check for IE
	if(scriptTag.readyState) {
		scriptTag.onreadystatechange = function() {
			if(scriptTag.readyState == "loaded" 
			|| scriptTag.readyState == "complete") {
				scriptTag.onreadystatechange = null;
				callback();
			}
		}	
	} else {
		scriptTag.onLoad = function() {
			callback();
		}
	}
	
	scriptTag.src = url;
	document.getElementsByTagName("head")[0].appendChild(scriptTag);	
}

With this fancy piece of code you can load script asynchronously across browsers. And with the callback attribute you can make sure that your scripts are loaded in the correct order:

loadScript("jquery.js", function() {
	loadScript("validate.js", function() {
		loadScript("common.js", function() {
			yourApplicationNameSpace.init();
		});
	});
});

For the most optimal speed, just inline this function just before the body ends. For the fastest possible load time, use a tool like YUI compressor to make the script as small as possible.

That wraps it up, I hope it helps! Let's make sure we all use these kind of techniques so we can enjoy a faster web!

Progressive enhancement: you have to do it together to make it work

2010-12-02T09:37:18+01:00

A project like this is usually filled with red tape and politics about specs and money. Front-end developers have to negotiate these hazards and advise their clients (and team) about using proper techniques. These techniques are critical for a fast, accessible and responsive website. A site that has little need for support and rework is cheap and without countless rework issues for IE6 we have more time on our hands to develop for the future.

By now we all know that the answer to these problems is 'Progressive Enhancement'. But, lets face reality, most of the time progressive enhancement is a bit of a utopian ideal. Let's say your client has 95% IE7 users but still wants to show off with shadows, gradients and transitions. Obviously there are ways to still use our beloved techniques, but it gets a lot harder when you have to explain to the client that the project will be expensive and time consuming.

Crossroads

In these projects we often get to a crossroad where we have to make a decision. Are we going to develop for the future or are we optimizing for the fading past of 2001? Both ways are valid as long as the choice is made wisely. Most of the time this choice is not made by (or known to) the whole team. Then the trouble starts. Who is responsible for the design decisions when it is unclear who knows what techniques are used while developing? What will happen to your credibility if you present the final templates to an unhappy client that expected gradients in IE? At that moment it's probably not so cool to tell them that -ms-filters suck right?

Tickets start to appear in the issue-tracker because the client's tester (who has the visual designs as a baseline) spots loads of bugs in IE6. I could go on and on with more situations like these. I guess at one point in time we have all been in them. You are in big fat trouble if the vision on front-end development was not chosen on time. It is vital for the project that all stakeholders are involved when this vision is spread out.

I've noticed (and I've also heard this from other developers) that many visual designers have a bit of trouble with progressively enhancing their design. In their eyes it looks more like tearing down the design to make it work in less capable browsers. Their work has obviously been done with vision and according to them, it should look the same everywhere.

Lets work together

It is our responsibility as web developers to teach everybody around us about the browser differences and the solutions that progressive enhancement can offer us to make projects ready for the future.

I think we can solve some of the issues I mentioned above by working together as a tight team. Obviously the whole team needs to be committed to their jobs and it also helps if everybody in the team knows a little bit about what their teammates do. A front-end developer for example needs to know his typography, but to be able to build templates he also needs to understand the back-end technology.

The same goes for visual design. They are 'web' designers right? So, try to understand what browsers do and why some stuff is hard and most stuff is easy. Try to crawl into the mind of a developer and look at the abstract methods that are used to build a website. Use a design tool that is component based so you can generate five pages with different content blocks on the fly. In my opinion Photoshop is for pixel nerds and generates loads of overhead when prototyping.

Think more like a web developer and work together. The front-end developer could use the designed components to recreate them in the browser. To go even further, the developer could use these components as includes in his development environment. As long as you use the correct naming conventions everything is synced up nicely.

When you know a bit more about what your teammates do, it becomes a much easier to communicate. The faster the communication is, the more time you have to document and keep everybody up to date. It is vital that you create a group consciousness that you are working on a web project. On the web everything is dynamic, the web has loads of users that browse on different devices, browsers and connections.

Think in responsive design, nothing is fixed anymore. Maybe the interface that you are building appears on someones fridge door in 2014? I'm not saying that we have to 'over' design and think of every aspect possible. It's just about being agile in your thinking process.

All team members know different things. Where one is really into making fast websites, the other might be into accessibility. The best thing to do is combine these skills and get the correct group of people together before you start a project. It is also very important to incorporate your client into the project team, make sure you work with your client and not for them. This way the project becomes nice and agile and the client will understand the choices that are made in the process.

Conclusion

As I have said before, it is vital for your project to work together closely. I think the 'scrum' method suits this nicely. Knowing a bit more about your teammates and getting the client involved are also important parts.

Next to this is the vision on front-end development. As this is such an important part of the project, this vision needs to be shared with all stakeholders. The vision needs to be written down and understood by everybody and could even be part of a pitch. To write this down, you need to know a lot about what the goals of your client are. For example; What is the target audience for this project and what are the goals of these people? In what context are they looking at the site? On a mobile in the train, or on the toilet with an iPad? Maybe they check the website on the 15" CRT in the nurses station (yes, hospitals are shabby when it comes to this :-)).

This article reflects my idea on how to handle projects. Please share your opinions because this is an ever changing subject and we could all use some fresh ideas.

In my next article I am going to try to explain something about progressive enhancement and it's background. For now read the masterpiece 'Hardboiled webdesign' by Andy Clark to get more information about the general use of progressive enhancement. Andy also writes a bunch about the mindset that you need to be a hardboiled web developer and use progressive enhancement in real-life projects.

My new fluffy CSS3 layout

2010-11-10T23:20:02+01:00

I attended a great presentation by Vasilis van Gemert that inspired me to use the new layout techniques offered by CSS3. Vasilis talked about the transition of fixed websites into scalable (fluffy) websites that are very flexible and work on multiple devices and resolutions.

I realized that there is great power in using @media-queries and a percentage based layout. Try resizing your browser window right now, and see what happens. Note that IE6/7/8 cannot handle this nifty stuff so switch browsers if you have to.

When you buy a new (desktop) computer nowadays, you usually get a nice big screen. So, next to making this website work on small screens, I also wanted to give people a full-window experience. The bigger your screen, the more wide and fancy the website.

For now the maximum width is 1900px. I used HTML5 markup for the layout and outline. The columns are styled using "inline-block". This was a sweet find because I didn't have to worry about float and clearfix problems anymore! In this case it's just bad luck for old IE users. This is my personal site and I want to be able to experiment with innovative technologies.

Is this the perfect solution?

You hear loads of people that say that @media-queries solve 'all' our problems. With this new magic niftiness we can build 'one' website that works on all screen sizes and devices.

But what happens when we use this technology is that we actually add more code in order to optimize for small, mobile devices. That's a little weird don't you think? Especially when we all know that speed matters a lot on mobiles.

I read a great article on fluid images by the Ethan Marcotte. In this website I used a small bit of the techniques described by the Ethan. Every image scales when you resize the browser. This very fancy stuff on one side. But on the other side it's a bad practice. Why load big images that get scaled down when you visit the website on an iPad or HTC device?

Why did I use fluid images?

Because I did not design a dedicated mobile site. I made a site that looks good on most screen resolutions. This way my visitors do not have to zoom in. I actually use 'display:none' for images when you visit this site on a mobile device with a screen-width of 280px.

If you think about that, it really is against the 'speed matters' rule for mobile websites. Luckily this is a very simple layout with hardly any images and it's backend system is the fastest I've ever seen (Zotonic). So, no problems in the speed- and data usage departments.

A final tought

I have one final thought on just using @media-queries to transform your site into a mobile website. This is also mentioned in several articles on the wobbly web and by developers around me.

You should show different content on a mobile device then on a desktop screen. The mobile context is way more hands-on and goal focused. For example when you want to check the train times when you are running towards the station with a coffee in you hand. At that moment you do not want the corporate history of the train company in a slideshow on the homepage. You need those frakking departure times!

@media-queries are a great aspect of the responsive design movement out there. I love the fact that we design for multiple devices and think about the future. I hope to see more examples of experiments like mine and would love to see some best practices on responsive design of websites.

The future of web development is a bright one and I love to being a part of it!

Mediafonds updated

2010-10-05T13:20:24+02:00

To simplify the design Mannschaft redesigned the navigation and made sure that new content is easier to find. This is why they added the "Acitiviteiten" link. The Etalage is still the main area of the site. It shows the ever growing productions that Mediafonds funds.

Other things that have been renewed are: the calendar overview, the "activiteiten" pages and there is a possibility to add a slideshow to a page.

See the new site here: http://www.mediafonds.nl.

jQuery notice featured on papermashup.com

2010-10-09T01:08:55+02:00

The intro of the original article

Last week I signed up Gravity a new site setup by a few guys that used to work at MySpace. As I was using the site I noticed these great little notifications popping up in my browser, Mac users will be familiar with this as they work in the same way as Growl notifications. I thought it was interesting that this technique of displaying live information to users could be presented in this way, so I went on the hunt for a similar jQuery plugin and found a number of results however the one that caught my eye was the jQuery Notice plugin by Tim Benniks.

See Ashley's post or my own project page about the "Growl-like"notification Plugin.

About jQuery and performance

2010-12-14T20:35:06+01:00

Once upon a time, all we needed to worry about was reducing Bytes and Requests and playing around with load order to make things faster. Nowadays, we are increasingly impacting one more major component in performance — CPU utilization. Using jQuery and other frameworks that make selecting nodes and DOM manipulation easy can have adverse affects if you’re not careful and follow some simple practices for reducing the work the browser has to do.

How to make a simple contact form in Zotonic

2010-04-17T13:16:08+02:00

This article originally comes from zotonic.com and is written by Arjan Scherpenisse.

Making a simple contact form might seem difficult, but with the smart application of different Zotonic techniques you'll see that it's actually very easy.

Create the contact page URL dispatcher and template
Create the contact form
Create the contact-form handler Erlang file.

Create the contact page URL dispatcher and template

The URL dispatcher is placed in priv/sites/default/dispatch/dispatch. Add this line:

{contact_url, ["contact"], resource_template, [ {template, "contact.tpl"} ]},

This says that the page at "/contact" will use the "contact.tpl" template. Let's create this template, at priv/sites/default/templates/contact.tpl:

{% extends "base.tpl" %}

{% block content %}
<h1>Contact page</h1>
{% endblock %}

Now we have this, let's try to see if it loads. Flush the Zotonic cache (to refresh the URL dispatchers) by going to "modules" -> "rescan modules" in the admin. Now, point your browser to http://127.0.0.1/contact. This should show the contact page with the template you just made.

Create the contact form

Now you should write the acual contact form. You should decide what fields you want in the form, so for now, just put a name, e-mail and comment field:

{% wire id="contact-form" type="submit" postback={contact} delegate="resource_default_contact" %}
<form id="contact-form" method="post" action="postback">

 <label for="name">Name</label>
 <input type="text" name="name" id="name" />

 <label for="email">E-mail</label>
 <input type="text" name="mail" id="mail" />
 {% validate id="mail" type={presence} type={email} %}

 <label for="message">Message</label>
 <textarea name="message" id="message" cols="60" rows="8"></textarea>
 {% validate id="message" type={presence} %}

 <input type="submit" value="Send" />
</form>

This template has 3 fields, of which the message and the e-mail are required, and the e-mail input has to contain a valid e-mail address. The name field is optional.

Create the contact-form handler Erlang file.

As you see in the wire statement in the contact form, the delegate argument is set to resource_default_contact, which is the name of an erlang module which we still have to create. When the form submits, this module's event/2 function gets called.Create a file priv/sites/default/resources/resource_default_contact.erl with the following contents:

-module(resource_default_contact).
-export([event/2]).

-include_lib("zotonic.hrl").

event({submit, {contact, []}, _TriggerId, _TargetId}, Context) ->
  ?DEBUG(z_context:get_q_all(Context)),
  Context.

This is the most simple version of a Zotonic form-handling function: it just dumps all form input it gets to the Zotonic console (using the ?DEBUG macro). To compile this Erlang module, enter the following on the zotonic console:

z:m().

You'll see a notice that the file is recompiled, which should end with a "ok" message to indicate the success. This compiling is actually very important: Whenever you change the .erl file, you'll need to recompile it using this command.

Using mod_emailer to e-mail the contents of the contact form to somebody

Using Zotonic's mod_emailer modules, you can very easily send somebody an e-mail. Let's create a simple template to send the contents of the form to the site administrator.

Create the file priv/sites/default/templates/_email_contact.tpl:

<html>
  <head>
    <title>Contact form</title>
  </head>
  <body>
    <p>Hello, the contact form of the site has been submitted.</p>
    <p>Name: {{ name|escape }}</p>
    <p>E-mail: {{ mail|escape }}</p>
    <p>The contents of the message was this:</p>
    <pre>{{ message|escape }}</pre>
    <p>Regards, your website.</p>
  </body>
</html>

This template will function as the message body that will be sent. Note: this template gets scanned for the <title> tag, which will double as the e-mail's subject, so be sure to include it!

Now we have to change our event/2 function to render this template and e-mail it using mod_emailer. Change the event function to the following:

event({submit, {contact, []}, _TriggerId, _TargetId}, Context) ->
  Vars = [{mail, z_context:get_q("mail", Context)},
          {name, z_context:get_q("name", Context)},
          {message, z_context:get_q("message", Context)}],
  z_email:send_render(z_email:get_admin_email(Context), "_email_contact.tpl", Vars, Context),
  z_render:update("contact-form", "<p>The form has been submitted! Thank you, we'll get in touch soon.</p>", Context).

This loads the relevant values from the form, puts them in the Vars variable, and then calls the z_email module to mail the given template to the e-mail address of the site admin (which is defined in your site's config file). For more information on sending mails from Zotonic, please see the mod_emailer documentation.

Finally, this contact-form handler replaces the contact form with a <p> tag with a success message, using the z_render:update function.

Zotonic's speed, A benchmark by Floris Benniks

2010-10-03T01:37:49+02:00

Zotonic's crew claims their framework is faster then the competition (Django, RoR, Wordpress, Drupal, Jooma!, etc). Any reasonably able developer does not just buy that. A simple benchmark could show a bit more of Zotonic's potential. As Floris had both his php site and his Zotonic site running on the same machine, it was the perfect environment for a comparison.

For the benchmark the "about" page of his site was used. The apache benchmark tool has been used for all testing.

ab -n 1000 -c 100 http://127.0.0.1:8000/about/

This command sends 1000 requests with 100 requests at the same time.

Specs

Zotonic uses postgreSQL 8.4 and Erlang R1304B.
The php site uses PHP 5.2.1 and MySQL 5.1.3.
The test computer is a Q6600 @3.1ghz (quadcode), 8gb ram, Vertex ssd

Requests per second

PHP: 167.62 [#/sec]
Zotonic: 1795.91 [#/sec]

Zotonic is 10.71x faster then the PHP site.

Transfer rate

PHP: 1023.23 [kb/sec]
Zotonic: 8130.70 [kb/sec]

Zotonic is 7.94x faster then the PHP site.

Conclusion

As It turns out, Zotonic is indeed faster then his PHP website. Of course there are many ways of testing and this is just one of them. Let's not see these numbers as final yet.

At least my mission has been accomplished. Floris is going to build all his websites in Zotonic from now on.

Check out the original Dutch article on florisbenniks.nl

Step by step guide to install Zotonic on OSX

2010-05-19T20:56:22+02:00

First things first

You guys and gals need to download some software bundles to be able to start using Zotonic. You will need:

Xcode (OSX development bundle)
ImageMagick
Erlang (preferably R13B04)
PostgreSQL (preferably 8.4 or higher)
The Zotonic source code

ImageMagick

ImageMagick has loads of dependencies and extra bundles. Because of that, it's a pain to install. But luckily MacPorts comes to the rescue. The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading command-line stuff on OSX.

MacPorts will do all the dependency checks and installs them. Great stuff! First download MacPorts and install (don't worry, it's just a .pkg file).

After that type:

sudo port install ImageMagick

Erlang

To install Erlang you could use MacPorts again. To be honest I wouldn't do that. It takes ages to check al the dependencies and it does not install the latest version. Just download this one.

Let the fun stuff begin and become a real command-line wizard! After you've downloaded Erlang, just unpack it. Open terminal, type cd and drag Erlang's folder into the terminal. You will see something like this appear:

cd /Users/tim/Downloads/otp_src_R13B04/

Hit enter. Now that you are in, type the following commands to configure, compile and install Erlang. Note that each of them takes some time. Don't put them in the same time, just one after another. Have some coffee / beer. This takes a while :-)

./configure
make
sudo make install

PostgreSQL

PostgreSQL has an excellent installer. Just install the package. It could be that there are some issues with the memory management your Mac has and that PostgreSQL requires. If that is the case, just pm me on @timbenniks. If this starts to happen to more people, I will write up the solution here.

The Zotonic source code

You can just download the package from: http://code.google.com/p/zotonic/. If you are using Mercurial you can get Zotonic's tip like this:

hg clone https://zotonic.googlecode.com/hg/ zotonic

Now the good stuff!

After all this downloading and compiling, we need to get to business with Zotonic. Here's a list of what we need to do to make all of this happen.

Database crap
"Make" zotonic
Zotonic's configuration

Database crap

Open pgadmin. Just do cmd+space and type pgadmin, your Mac will find it for you.

In the sidebar you will see a tree structure with just "Servers(1)" and then a PostgreSQL item under it. It should have a red cross. Double click that and type in the root password that you gave while installing PostgreSQL.

Afte this, click on the Databases item in the sidebar. The Postgres database will appear in the tree structure. Click on it and then click on the SQL button in the top bar.

Now a new window opens and we can query away! Note: remove the default text that is in the window. We need to make a new user, a new database and grant the new user access to the new database. Please do these queries one at the time. Just paste in and press the little green play button in the top bar.

CREATE USER zotonic WITH PASSWORD 'yourdbpassword';
CREATE DATABASE zotonic WITH OWNER = zotonic ENCODING = 'UTF8';
GRANT ALL ON DATABASE zotonic TO zotonic;
\c zotonic
CREATE LANGUAGE "plpgsql";

Make Zotonic

I would suggest that you put the Zotonic folder in the "Sites" directory that lives in your home folder. Please note that the root folder of Zotonic needs to be named zotonic at all times. Sorry for this, we are working on it :-P

No open terminal and "cd" into this folder. Obviously my name should be swapped with your username.

cd /Users/tim/Sites/zotonic
make

Zotonic's configuration

If you open the Zotonic folder you find a "priv" folder. Your projects will live in there. For now we will use Zotonic's default site. We need to rename the config for it to be read by Zotonic.

cp priv/sites/default/config.in priv/sites/default/config

Then, edit that file and change the values of dbpassword, sign_key_simple and sign_key:

% Configuration of the default site.
[
% This site is enabled or not.
{enabled, true},
 
% Atomic hostname, MUST be equal to the directory name of this site.
{host, default},
 
% Hostname for virtual host support
{hostname, "127.0.0.1:8000"},
{hostalias, "localhost:8000"},
% PostgreSQL database connection
{dbhost, "127.0.0.1"},
{dbport, 5432},
{dbuser, "zotonic"},
{dbpassword, "yourdbpassword"},
{dbdatabase, "zotonic"},

% Admin password, used during installation. You can change it later
{adminpassword, "admin"},

% Key used for signing image urls with image manipulations (crop, rotate, resize, etc.)
% A new key will force regenerating images, which takes cpu time and will fill your hard disk.
{sign_key_simple, <<"--change-me--">>},

% Key used for signing postbacks - this _must_ be a hard to guess key, otherwise your system is insecure.
% When not defined, then zotonic will generate a new key on every restart.
% When a new key is generated then all postbacks from old html pages will fail.
{sign_key, <<"--change-me--">>}
].

Make sure that the directory "priv/sites/default/files" and all its subdirectories are readable and writeable for the current user (Which is the user zotonic will run under).

chmod -R +rw /Users/tim/Sites/zotonic/priv/sites/default/files

Now start up Zotonic! Go to Zotonic root folder and type:

./start.sh

You see zotonic starting up, lots of messages pass by, and zotonic will install the initial database. When something goes wrong here, then it is almost always a problem with the database connection. Check your database configuration in the config file.

Point your browser to http://localhost:8000/ or logon as admin (the default password is 'admin') at: http://localhost:8000/admin/

When all done, then you can stop the Erlang shell with:

q().

That's all folks. Good luck messing around with Zotonic. The next post will be about setting up a new project and about the basics of dispatch rules and templates.

The myth of the page fold

2010-05-21T11:22:38+02:00

As web professionals, we all know that the concept of the page fold being an impenetrable barrier for users is a myth. Over the last 6 years cxpartners have watched over 800 user testing sessions and only 3 on occasions they have seen the page fold as a barrier to users getting to the content they want.

timbenniks.nl featured at 1stwebdesigner.com

2010-03-13T20:30:32+01:00

Thanks Andy, for including me into your sweet blogpost!

Read it here: http://www.1stwebdesigner.com/inspiration/ultra-modern-websites-html5/

Cross-browser @font-face support

2010-05-21T12:21:08+02:00

Read the rest of this great post on themeforest.com

Zotonic destroys WordPress and rethinks the CMS with Erlang

2010-03-09T21:45:26+01:00

Chad DePue took a minute from getting ready for his talk at Erlang Factory (and working on the day job) to talk with Marc Worrell, Lead Architect of Zotonic – a new Content Management System written entirely in Erlang. This is a brief overview of the system focused on the ‘why’ – the technical details are well covered on their site, but he wanted to understand the motivations behind a company taking on a project like this.

Read the interview here: http://erlanginside.com/zotonic-destroys-wordpress-and-rethinks-the-cms-with-erlang-149

How to effectively communicate with developers.

2010-03-08T16:26:59+01:00

If you have ever worked with a developer or a development team, this article will probably strike close to home. As designers, we work with dozens of developers across the globe each year. Some of us are fortunate enough to find a gem; a developer that just gets it. A developer that you feel is on your same wavelength in terms of what needs to be accomplished with the user interface, and what it needs to happen. Most often, however, we find developers that we generally don’t see eye to eye with.

jQuery “growl–like” notification plugin.

2010-05-05T22:26:46+02:00

What! Another one?

There are more growl-like notification plugins out there, and I hear you thinking: why yet another one!? Well. The other plugins out there are not written in a style that I like. I needed my notifications more flexible and lightweight. The project is hosted on the jQuery plugins repository and on google code.

How it works

This plugin extends jQuery. That means that you can call it like this: jQuery.noticeAdd() or jQuery.noticeRemove(). The fact that it is not bound to an html object makes this plugin very easy to use. It is callable or removable from any function. For example: it could be initiated as callback from a function or on a success or failure after an Ajax request. More info here.

About the Atatonic CSS Framework.

2010-05-05T22:00:28+02:00

What! Another one?

Lately there are more and more CSS frameworks popping out of ground. My issue with most of them is that they mainly focus on the grid. All the other options are added in later. This framework has its main focus on typography. Vertical rhythm is one of the most important things in design, so why not start your perspective from that angle?

To make my life easier as a developer I added grid support in the Atatonic CSS Framework. Its works like any other grid system, but with only about 10 lines of css.

The main goal of this project is to provide a solid base to start with every project. I do not want to bloat this framework with features. That is what you do in the project specific styles. The combined file is only 5kb. Deflate of gzip it and you are down to 3kb.

Incremental development

The Atatonic CSS Framework is still very young. It is a basic set-up of typography and grid tools. Changes will be made and things will be added in the process. I aim to keep the core small and voerviewable. So extra features will be added as plugins. Like a stylesheet for forms or something that adds extra typographical features.

Check it out.

Hands on rules for a fast website.

2010-12-14T20:34:40+01:00

Yahoo! did some great research on this subject and came up with 14 rules. In a series of posts I will talk about the rules that I think are the most important. I will give some background information and explain how to implement them by examples of my own code.

The 80/20 performance rule

This rule is commonly referred to as the Pareto principle (also known as the 80-20 rule), which states for any phenomenon, 80% of the consequences come from 20% of the causes.

We see this phenomenon in software engineering or designing where 80% of the time is spent in only 20% of the code or details in the design. When we optimize our applications, we know to focus on that 20% of the code. This same technique should also be applied when optimizing web pages.

Most performance optimization today are made on the parts that generate the HTML document (apache, databases, template engines, etc.), but those parts only contribute to about 10-20% of the user’s response time. It is better to focus on optimizing the parts that contribute to the other 80-90%.

Reduce your http requests!

Every external file you include has to be processed and loaded after the html has been loaded. The more you include, the more http request the browser has to handle. The impact of having many components in the page is exacerbated by the fact that browsers download only two or sometimes four components in parallel per hostname, depending on the HTTP version of the response and the user's browser. Yahoo!'s research shows that reducing the number of HTTP requests has the biggest impact on reducing response time and is often the easiest performance improvement to make.

When you cache these external files in the user's browser, you can have remarkable speed improvements. More on that in the next post.

Ways of reducing http requests

One way to reduce the number of components in the page is to simplify the page's design. But is there a way to build pages with richer content while also achieving fast response times? Here are some techniques for reducing the number of HTTP requests, while still supporting rich page designs.

Combine files

This way you reduce the number of HTTP requests by combining all scripts into a single script and combining all CSS into a single stylesheet. Combining files is more challenging when the scripts and stylesheets vary from page to page, but making this part of your release process improves response times.

This is a simplified example of my library.php code. In future posts I will use this code and add caching, gzip and different ways of compressing to it.

/**
 * library.php
 * Controller to fetch css or js script files.
 *
 * @package     timbenniks.com    
 * @author      Tim Benniks - tim@timbenniks.com
 * @copyright   2009 timbenniks.com
 * @version     $Id: library.php 63 2009-01-16 09:24:18Z timbenniks $
 */

// create variables from $_GET['files']
$string 	 = explode('.', $_GET['files']);
$files	 	 = $string[0];
$extention 	 = $string[1];
$all_files	 = explode(',', $files);

$cached_file = './cache/'.urlencode($files).'.'.$extention;

// set the right content type
if($extention == 'css')
{
	header('Content-type: text/css');
}
elseif($extention == 'js')
{
	header('Content-type: text/javascript');
}

// If the file is not cached, create it. 
if(!file_exists($cached_file))
{	
	for($i = 0; $i < count($all_files); $i++)
	{
		if(is_file($extention.'/'.$all_files[$i].'.'.$extention))
		{
			$put_contents = true;
			$join_files   = file($extention.'/'.$all_files[$i].'.'.$extention);
			$all_in_one   = join('', $join_files);
		}
		else
		{
			$put_contents = false;
			header("HTTP/1.0 404 Not Found");
		}	
	}

	if($put_contents)
	{
		file_put_contents($cached_file, $all_in_one);
		echo $all_in_one;
	}
}
else
{
	echo file_get_contents($cached_file);
}

CSS Sprites

This is the preferred method for reducing the number of image requests. Only one! For multiple images. Combine your background images into a single image and use the CSS background-image and background-position properties to display the desired image segment.

Conclusion

Reducing the number of HTTP requests in your page is the place to start. This is the most important guideline for improving performance for first time visitors. Most of the time 40-60% of daily visitors to your site come in with an empty cache. Making your page fast for these first time visitors is key to a better user experience.

Composing with web typography.

2010-05-21T12:24:03+02:00

This article has quotations from 24ways and A List apart.

Just as regular use of time provides rhythm in music, regular use of space provides rhythm in typography. Without rhythm the listener or the reader becomes disorientated, lost or totally bored.

On the Web, vertical rhythm (the spacing and arrangement of text as the reader descends the page) is contributed to by three factors: font size, line height and margin. All of these factors must calculated with care in order that the rhythm is maintained.

The basic unit of vertical space is line height. Establishing a suitable line height that can be applied to all text on the page is the key to a solid dependable vertical rhythm which will engage and guide the reader down the page.

Establishing a suitable line height

Before we start you have to know that the default setting of a browser (yep, all of them!) is 96dpi with a basic font size of 16px. So 1em would be 16px. The easiest place to begin determining a basic line height unit is with the font size of the body.

I almost always go for 12px. That is because the table of 12 is divisible by 1, 2, 3, 4 and 6. So it is easy to switch to 24, 36 or even 18. To ensure readability the body text will almost certainly need some leading, that is to say spacing between the lines. A line-height of 1.5 times 12 would give 6px spacing between the lines of the body text. This will create a total line height of 18px, which becomes our basic unit.

Here’s the CSS to get us to this point:

body {
	font-size: 75%; 
}

html>body {
	font-size: 12px;
	line-height: 18px;
}

There are many ways to size text in CSS and the above approach provides and accessible method of achieving the pixel-precision solid typography requires. The first font-size in the example reduces the body text from the 16px default down to the 12px we require.

This rule is primarily there for Internet Explorer 6 and below on Windows: the percentage value means that the text will scale predictably should a user bump the text size up or down. The second font-size sets the text size specifically and is ignored by IE6, but used by Firefox, Safari, IE7, Opera and other modern browsers which allow users to resize text sized in pixels.

As you can see I have used pixels as measurement here. Further down below I explain why.

Spacing between paragraphs

With our rhythmic unit set at 18px we need to ensure that it is maintained throughout the body. A common place to lose the rhythm is the gaps set between margins. The default treatment by web browsers of paragraphs is to insert a bottom-margin of 1em. In our case this would give a spacing between the paragraphs of 12px and hence throw the text out of rhythm.

If the rhythm of the page is to be maintained, the spacing of paragraphs should be related to the basic line height unit. This is achieved simply by setting bottom-margins equal to the line height.

p {
	font-size: 12px;
	line-height: 18px;
	margin: 0 0 18px 0;
}

Don't fear the pixel!

As you can see I code in pixels. Let me explain this before you guys hit me! At Mediamatic Lab we mainly build websites that are designed around and by typography. After many attempts we came to the conclusion that building a website that is based on typography gets easier using pixels. When designing a practical system like this, it’s important that it’s relatively easy (for yourself and others) to use and maintain.

With pixels, I can set one base line height for the entire document and I don’t have to recalculate it whenever I use a smaller or bigger font size. If you wanted to make your font a bit bigger, just up it one pixel and leave your line height the same.

An easy example to show the difference between relative sizes and pixels:

p {
	font-size: 14px;
	line-height: 18px;
	margin: 0 0 18px 0;
}

p {
	font-size: 1.1667em;
	line-height: 1.286;
	margin: 0 0 1.286em 0;
}

You can use relative sizes, but it quickly becomes a lot more difficult to maintain as the math becomes more complicated. As you can see in the example, the line height had to be recalculated to make sure it would still be 18px with a font of 14px. If I would have kept it 1.5 like you would want, it becomes 1.5 times 14 which becomes: 21 instead of 18. If you have a big page with a lot of elements and you make a small miscalculation, your whole rhythm could be gone and predicting how browsers are going to round your values makes it hard to be exact.

In the end, it's a tradeoff

Most browsers will scale pixel-based line-heights proportionally along with the text. Of course, the margins don't scale, and neither do the images. But is it worth making the system more complicated just to make the margins scale if the images don't?

Consider the amount of people that use ie6 is becoming less and less. And for that percentage of the ie6 users, how many scale websites? If they really need bigger fonts, they need that on their whole computer and they have probably set their screen to 120dpi.

There you have two other reasons then technique to just use pixels.

At some point as designers we have to strike a balance between creating pixel-perfect layouts and infinitely flexible ones. When you get down to it, resizable text is primarily an accessibility feature, not a design feature. Ideally it’s something that should be provided by the browser, no matter how the page is built, and in modern browsers it is. As long as all your content is readable and accessible at all sizes, it’s not necessarily true that the design must maintain integrity as you scale.

The basics of web typography.

2010-05-19T09:44:12+02:00

If you ever made a nice risotto, you know that this recipe takes a lot of care and effort to make it taste just right. Put to much water to quickly and it becomes blobby, put to little to late and it turns out dry and tastes like cardboard. The same go's for typography. Apart from content, typography can make or break your website.

Typography for the web has come a long way since web 0.1. In these old days typography for the web was not an important thing. Today things are different. Not only do we have modern browsers that support images (yeah!), but we have the opportunity to make our pages come to life through great typography.

Contrast

Pale pink text on a pale blue background, is very cool for an old school t-shirt, but it doesn’t read well. Text is there to be read. Make sure that it contrasts enough with the background to achieve that. If you’re ever unsure about contrast, then take a screen dump of your page, open up your image editing software and reduce the image to grey-scale. You’ll soon see if you have enough contrast. Robert Bringhurst, a very cool typographer writes: "...typography exists to honor content". Are we honoring the content if we design our pages in such a way that the content is difficult to read?

Personally I dislike to read long stretches of reversed out text (e.g. white text on a dark or black background). It may well be appropriate for shorter stretches of text on-screen, but I find it very tiring to read for any length of time.

Size

This one is easy. Don’t set body text below 11px and, if possible, make it bigger. Remember, what’s legible on your 65" High Definition Plasma monitor, might not be so on a 15" MacBook. If in doubt, make it bigger!

Hierarchy

Varying type size is one of the best ways to differentiate content. Colors and pretty boxes might help, but different sizes of type throughout your pages will show your readers the importance of your pages. If you have readers that are in a hurry, they can quickly pick out the important bits and might stay longer and read on.

Hierarchy can be achieved in other ways too. I've just mentioned using different sizes of type to achieve it, but you can also use different styles. For example all-caps or using italic for sub-headings. Serif and sans serif faces can also be mixed to good effect.

Space

Let your type breathe. Don't be afraid to leave blank spaces in your pages. This white space will help focus attention on the text. Next, remember line-height. A good rule of thumb is line-spacing that’s at least 150% of your text size. (e.d. 12px font-size and 18px line-heigt). Good type designers put a whole lot of effort into the micro white space that sits inside type. They spend countless hours attempting to achieve a balance (vertical rhythm) between the lines of text. Likewise, we should take time to consider the macro white space, the 'voids' that shape our blocks of text.

Conclusion

Remember, these are not rules, but rather guidelines. However, follow them and your site will have that thing that makes user like you website very much instead of just a nice one.

The next post will be about the research I did on what CSS technique to use. It will show some different approaches with their pro's and con's.

This post is inspired by a great blogpost on the website iLoveTypography.

Cross-browser rounded corners.

2011-01-31T14:39:05+01:00

Every element in HTML is square. You can apply a background image to an element to make it look round, but the element itself is still square.

CSS3 comes with a heaven-sent solution: border-radius. It allows you to apply a rounded corner or border to an element without the use of extra markup or Javascript. Unfortunately, only Gecko (Firefox's rendering engine) and Webkit (Safari, Chrome) support it, with prefixed equivalents -webkit-border-radius and -moz-border-radius, because their support is still experimental.

Webkit and Gecko have a market share of 20% and 7%. What to do with the other 73%, mainly Internet Explorer 6 and 7? We don't want to serve the majority square corners, while only a minority sees the beautiful round corners, right?

And what about Opera? Wasn't that browser pretty modern? Well, Opera supported -o-border-radius in 2006 in version 9 of their browser, but they removed the support in 9.1 for unknown reasons. So we need a cross-browser solution. Fortunately, there are a few:

Adding markup

The most straight-forward solution to create rounded corners on a box is by adding extra markup (html) to the box to apply corner backgrounds to. With a fixed width and height, you only need one element to show four rounded corners. With a fixed width and dynamic height, you need at least two elements. With a dynamic width and dynamic height, you need four.

In most cases, you won't need extra elements for types 1 and 2. For example, when you have markup that already looks like this:

Title
Text

If only the height is dynamic, the complete top (with the top-left and top-right rounded corners) can be applied to the h3, which overlaps the div. The div itself has a very tall background image positioned from the bottom, with the bottom-left and bottom-right corners and the filling for the middle.

With a dynamic height and dynamic width and using the same markup, you don't have enough elements to apply a corner to. The div can contain the top-left corner and the filling, the h3 can have the top-right corner, but then we're still two elements short, so we'll need to add two more elements to show the bottom corners. Our new markup:

Title
Text

Now we can add the bottom background images to the spans, but our beautiful clean html is cluttered.

Making it dynamic

To keep our markup clean, we could add a little Javascript. Let's take our first markup snippet again, and add a class to it:

Title
Text

We could now tell Javascript to add four span's to all elements with the class "rounded". We want to get this result:

Title
Text

This transformation only takes a few simple lines of code, especially when using jQuery. With our Javascript-generated corner spans, we have enough elements to apply corners to, and we could generate general styles using the classes which are the same for every rounded box. A small note: if the background below the div has a pattern or gradient, you need even more elements so they aren't overlapping eachother. Also, use caution using this method with existing sites. If you have any scripts that don't expect your site's markup to be modified by another script, it may break stuff.

Making it super-dynamic

Until now, our solutions were depending on using a background image. So for every combination of border-radius, foreground color and background color, you'll need a seperate image. It would be a lot easier if this was done completely automagic. You could write a back-end script, creating the images dynamically, but that would cost a lot of time.

Fortunately, there are cross-browser solutions that don't need any images to work. In this area we find two free Javascript libraries: CurvyCorners and ShadedBorder. They work by dynamically creating hundreds of tiny divs in each corner. Together, these divs form an anti-aliased rounded corner.

The effect is super, and both CurvyCorners and ShadedBorder are easy to setup and configure. There's a major cause for concern, however. If you want a box to have four rounded corners with a border-radius of 20 pixels and a border of 3 pixels, CurvyCorners creates 424 extra div's, each with their own position, background-color and transparency. With 5 rounded boxes, that's 2120 extra div's. That could cause serious performance issues with page buildup, scripts and scrollspeed, especially in older browsers.

The solution

$.fn.rounded_corners = function()
{
	return this.each(function()
	{
		$(this).css({position: 'relative'});

		$('')
			.css({ // this will only accept numeric border widths
				marginTop:   '-' + (parseInt($(this).css('border-top-width))   || 0),
				marginRight: '-' + (parseInt($(this).css('border-right-width')) || 0),
				marginBottom:'-' + (parseInt($(this).css('border-bottom-width'))|| 0),
				marginLeft:  '-' + (parseInt($(this).css('border-left-width'))  || 0)
			})
			.appendTo(this);

			if($.browser.msie && $.browser.version < 7)
			{
				$(this).each(function()
				{   
					
				var h = $(this).height();
				var w = $(this).width();
	
				if(h%2)
				{ 
					$('.cnr_sw', this).css({bottom: '-1px'});
					$('.cnr_se', this).css({bottom: '-1px'}); 
				}
	
				if(w%2)
				{	 
					$('.cnr_ne', this).css({right: '-1px'});
					$('.cnr_se', this).css({right: '-1px'}); 
				}
			});
		}
	});
}    

if($.browser.msie)
{
	$('.selector1, .selector2, #selector3').rounded_corners();            
}

.cnrs {
	background: transparent url(/image/corners_white.png) no-repeat;
	border: none !important;
	overflow: hidden;
	position: absolute;
	height: 6px;
	width: 6px;
	font-size: 1px !important;
	z-index: 9999;
	right: 0;
	top: 0;
}

.cnr_ne {
	background-position: right top;
}

.cnr_nw {
	background-position: left top;
}

.cnr_sw {
	background-position: left bottom;
}

.cnr_se {
	background-position: right bottom;
}

How to enhance your websites SEO

2010-05-05T22:00:26+02:00

Tools you can use

Create a sitemap.xml file

A sitemap.xml file is a listing of the pages on your website in a format that is friendly to the search engines. You might be more familiar with a site map that is intended for humans to use. It's the same concept, but the XML format is in the language that the search engine crawlers read.

There are a variety of tools out there to generate site maps for your website:

If you have a website that is static HTML pages, then you can use the free sitemap generator at XML-Sitemaps.com to generate one. If you use something like Wordpress I recommend using a great plug-in that I found called Google (XML) Sitemaps Generator for WordPress. It will generate and update a sitemap automatically for you.

Create a robots.txt file

A robots.txt file is a set of instructions that tells the visiting search engine crawlers what they can and can't index on your website.

For example, you can give instructions to tell certain search engines not to crawl your website, or that all engines shouldn't crawl a particular directory on your website. The most basic instructions tell all search engines that they can crawl all directories on your website.

When you subscribe to Google's free Webmaster Tools, there is a tool that will create a robots.txt file for you. Once you create it, make sure that it goes in the root directory of your website.

Submit your URL

This one should be obvious, but it's worth mentioning anyways. Submitting your URL to the search engines helps them find your website quicker - although sometimes it will still take some time after you submit it before the engines crawl your website.

At the bare minimum, you should submit your URL to the three major search engines. You can do that at these spots: submit a URL to Google, to Yahoo or to MSN

Submit your sitemap

The same benefit as telling the search engines what your URL is applies to your sitemap as well it will just help them find your website and content easier. From personal experience, Google makes it very easy to do. There is a tool within their webmaster tools that lets you do that.

Tips for Page SEO

Title tags

A page's title tag is the first thing search engines look at when determining what a particular page is about. Title tags are also what potential visitors see and read when they're looking at a search results page.

Most websites include the company name in the title tag, although there is still a good deal of debate about whether the name should be at the beginning or end of the title tag.

The most important thing to do with your title tags is make them relevant to what the page is about. It's important to include one or two keywords in it as well, but don't stuff your title tag full of keywords - that will just make your website look bad, and there are limits for the number of characters that can appear.

Header tags

From the standpoints of usability, accessibility, and SEO, there are arguably fewer things that are more important than using your header tags properly. Not only do they visually break up your content on the page, but they also give users who are glancing through the page an idea of what is being written about.

How you use header tags

H1 tags are used for your main page title, to show what the page is about and H2, H3, H4, H5, H6 tags are used to break up your page copy, but also to show the search engines what the topics are on a page so that it can index your website properly.

ALT and TITLE attributes

These two attributes don't usually play a prominent role in the average user's experience with a website, but they're still important and shouldn't be overlooked. There are also some small SEO benefits that can be gained from using them.

The ALT attribute is used when coding an image onto a page; think of it as some alternate text that appears should an image not load on a page. This attribute is important from an accessibility perspective because the screen readers used by blind people won't show them what the image is, but if there is some descriptive text in the ALT attribute, they will pick up on that.

From an SEO perspective, the ALT attribute is another opportunity to get some code onto your page that the search engines will be able to read. Making it as relevant as possible to what the page is about can help contribute to stronger search engine rankings.

The TITLE attribute is usually used on links, and is often one of the small touches that a great website has. You've all seen the TITLE attribute in action even if you don't realize what it is; if you hover over a link and a little tool tip appears, that's the TITLE attribute in action.

From an SEO perspective, it's again all about relevance, so be sure that what you're putting in the TITLE attribute relates to where the link takes someone. Doing so will also help from a usability standpoint, which is just another added bonus.

Use META tags

Contained within the header of every page's source code are what are called META tags. They are invisible to a website's visitors, but are there because search engine spiders read them.

The two META tags that you need to concern yourself with the most when it comes to SEO are the description and keyword tags.

The description tag is especially important because it is listed in your search result. It's what users read when a link comes up and what makes them decide whether to click on the link or not. A well-written description should read like a sentence and should be a succinct summary of the page and what someone can find when on it. You don't want to include as many keywords as possible, but be sure to write the description with a focus on the keywords that are relevant to that page.

The keyword tag is still worth focusing some attention on, so be sure that you include at least a few relevant keywords in there - but again, don't go overboard. Back in the early days of search, people used to stuff the keyword tags with anything and everything to improve their search engine results, and as a result, many search engines now just disregard the keyword tag.

Content is king!

Want to know the most important aspect of SEO on a website? It's the content. It always has been, and it always will be. You could use all of the tips mentioned above, but unless they are all relevant to the content on the page, then you're just wasting time.

Yes, it's true that most people will not read your content - but that doesn't mean you should ignore it, because the search engine crawlers do read it and weigh it highly in their algorithms. The tricky part is that you also can't write content that is entirely for the search engines, because real people need to read it and make a connection to it. There needs to be a balance between the two.

Here are some tips to help you write SEO-friendly content:

Focus the content around a few keywords only -- don't try to include as many as possible
Make sure that it reads well and makes sense from a human point of view
Just write naturally and explain the information in terms most people will understand
Keep it relevant to what people would expect to read on that page

SEO-practitioners often forget that the search engines are not the end unto themselves - they are only a tool that real people use to help them find what they're looking for. So even if they can get the search engines to think that a page is great, it's only as great as its ability to either keep people on the website, or to get them to make a purchase or complete a transaction of some sorts.

And in an interesting twist, yet another thing that the search engines factor into their algorithms is how quickly someone leaves your website from the search engine results that brought them there. This is just further proof that SEO can be summed up in one word, which I've already used repeatedly: relevance.

(Almost) never add a reset button to a form.

2010-05-21T12:35:43+02:00

There was a time when many, many, forms on the web had a reset button. Thankfully, reset buttons are not quite as common these days, but there are enough of them out there to cause users lots of frustration.

Zotonic—A pragmatic and modern CMS.

2010-05-21T12:31:10+02:00

This post is a copy from Marc Worrell's post on whatwebwhat.com

Zotonic enables hosting very popular sites on simple hardware.

I will write a couple of articles highlighting aspects of Zotonic. Today I focus on the reason we built a new CMS and on performance aspects. In other articles I will highlight the general design of Zotonic, the template system, modules, screen components, form handling, and adding logic (actions) to the templates.

Why?

Yet another CMS? Why? Because the current crop of open source content management systems don’t do what we want them to do. What do we want to do? We have a simple list of requirements:

Flexible and easy to learn template system;
Separation of logic, viewer and data store (MVC);
Rich data model, easy to add knowledge to the data;
Easy to make highly interactive web sites;
High performance from a single machine for simple hosting;
Future proof, easy to integrate with XMPP and other services;
Easily extensible with modules;
Able to handle push notifications with Comet;
Easy and fun to program the back end.

The Open Source building blocks of Zotonic

Zotonic would not be possible without the contributions of many open source projects:

Django like template engine (an adapted version of ErlyDTL);
HTTP protocol handler and abstraction with Webmachine;
Event driven user interface based on Nitrogen;
The best scalable open source database around: PostgreSQL;
A sweet and small CSS framework: Atatonic;
jQuery for the user interface.
epgsql For connecting to the database; and
esmtp For sending e-mail.

Zotonic is written in the programming language Erlang. In the next section I explain why we use this programming language.

What is a web site anyway? Or why we choose Erlang

Once upon a time a website was a collection of manually edited HTML pages and some images. All was fine.

Then search was added to the site, necessitating extra programs running on the server on behalf of a web site visitor.

Then those pages started to be filled with content from a database, nothing changed much except that editing and searching got a lot easier.

And then we started to let the visitor react, interact and upload information to the server. Not only the visitor was allowed to interact, also machines got their own interface to talk to the server. Web 2.0 with APIs and user generated content took off.

Nowadays a web site is talking in many different ways to humans and machines. It is collecting information from multiple sources and actively submitting new articles to other sites or machines. The web server gives the visitor more and more ways to access the stored information. People are using RSS readers, widgets, desktop applications, other web sites and so on.

The web server evolved from a simple machine serving some pages to a complex switchboard connected to many different servers and services. The web server constantly sifts through information and storing it on behalf of its users. It constantly generates different representations of its own stored information, let is be as HTML pages, RDF documents, Atom entries, XMPP messages or API result sets.

This new web server is an always on machine. Not a simple server reacting to requests from a web browser.

This new web server is way more dynamic than yesterdays database based HTML generator. It needs to stay connected with other servers, it needs to have all those connections open and active at all times. It even needs to push information to the web browsers of visitors.

This new web server needs a different approach and programming model which becomes more and more like a information switchboard with thousands of open connections to other machines and web browsers.

Erlang was created to program telephone switches. Its programming model and features are a natural match to this new kind of web/information server. Besides its natural match to the problem domain it was also created to make very robust systems that are always on. No need to reboot an Erlang system for a program update.

That is why we choose Erlang. To create a robust web server that can be like a spider in the web of information. And one that is still easy to program and extend.

Performance: Scale up? Scale out? Scale in!

The current generation of computers are so fast that we can play multi user video games on a single machine, whilst surfing the web, checking our mail and what not. Why should we be happy with generating a couple of web pages per second from a machine that is so capable? How green is that?

We have quite a lot of experience building content management systems and web sites in general. What did we learn? For one thing: when you want high performance and flexibility and less machines, then you are in a lot of trouble.

Usage scenario

Our usage scenario is:

A fairly popular web site experiencing periodic surges of visitors;
The web site uses modern technologies like Ajax and Comet; and
Multiple web sites on a single server.

So we are not targeting the new Flickr or similar sites. They need custom built software, not an off the shelf CMS. We are targeting the other 99 or so percent of the web sites.

PHP

PHP is the most popular language for building web sites.

For every request PHP wakes up and starts finding out where he is, where the code is, what the code is, where the database is, etc. etc. It does this again, and again, and again. Even when nothing is changed. This share nothing approach is nice when handling a single request, or when scaling out (adding more machines). It is not nice when you want to handle lots of requests from a single machine.

Ruby on Rails and Django

Other scaling problems arise with Python (Django) and Ruby (on Rails). Typically they are single threaded, that is they use only one thread of those 32 or more hardware threads that are available on modern hardware. That is solved by having more independent processes, each handling requests one by one. Those processes need to communicate with each other, adding more processes and complexity for caching systems etc.

Zotonic

Thanks to Erlang, Zotonic is completely multi threaded and scales linearly when adding more cores. All information about the web site is kept in memory and easily shared between requests. When two requests need the same html fragment then that fragment can be only rendered once. Note that this is not caching, which Zotonic handles as well, but a simple prevention for doing the same thing twice at the same time.

Zotonic typically serves 100 to 500 dynamic pages per second on normal of the shelf hardware. Which is enough for the fast majority of web sites.

Zotonic can serve a complete page before a Joomla/Drupal/WordPress site has even loaded its PHP code. With a Zotonic server you can serve either many more sites, or many more visitors per site.

Later more about the architecture of Zotonic and how to use Zotonic.

Zotonic, a quick overview.

2010-09-02T16:15:22+02:00

This post is a copy from Marc Worrell's post on whatwebwhat.com

Modules, the basic building block

A Zotonic web site is made of different functional parts:

Controllers, in fact Webmachine resources.
Templates, all what you see. Templates can include other templates.
Screen components, scomps, those are templates with their own little controller.
Actions, everything that you can do with buttons, forms, jQuery effects etc.
Validators, used to check submitted input elements.
Css, Javascript, static images. Those are all put in lib directories.
Dispatch rules. They map a request url to the correct controller.
And a bunch of supporting Erlang code to make it all work.

A module contains one or more of the above items. All templates, actions, validations, css, javascript, dispatch rules and scomps are contained in modules. Modules have a priority and can overrule components of modules with lower priority.

Modules are directories with at least one Erlang module implementing a gen_server that manages the module. Subdirectories in the module contain all the templates, Webmachine resources, dispatch rules, actions etc.

Modules communicate with each other using notifications. Modules can be activated or deactivated using the admin interface (which is implemented using multiple modules).

Data Model

The data model is inspired by semantic web triple stores. But then adapted to make it work with a relational database and usual CMS interfaces and methods.

All (ok, most) data in Zotonic is a resource. Resources are connected with edges, creating a directed graph of information. Every edge has also a predicate. The predicate defines the meaning of the edge. For example author, as in the author of an article.

For example, a news article is a resource. The image of the news article is another resource, connected to the article with an edge, and so is the author of the article, the place the article is happening etc.

You could say that Zotonic has only two tables. A resource table and an edge table.

Resources are typed using a hierarchical category system. Some predefined resource categories are: text, news, image, video, sound, person, group, predicate, category and other.

A Data Resource

A resource has some fixed fields and can have any additional fields. The fixed fields are:

Id, an unique integer.
Title.
Slug. Used to make understandable uris
Introduction, a short abstract used in lists.
Body, the textual body of a resource. A body contains HTML.
Unique name, used by the system to find resources by name instead of id.
Featured flag, to show things at important places on your site.
Published flag.
Publication period. From when till when a resource is published.
Uri. The originating uri of the resource when it is imported from another site.
Authoritative flag. Defines if the resource is imported or created locally.
Category, defines what the resource represents. For example a person, article, event, image or video.
Group. Editors work together in groups, all content belonging to a group can be edited by editors in that group.
Visibility level. Defines if the resource is viewable by the group, community or the world.

All textual fields (except name and uri) can be multilingual. Any resource can have multiple extra data fields. Think of a date range, name or address.

In the next article I will show a bit of a template.