Design can be a very subjective matter. All of us have our personal likes and dislikes when it comes to the appearance of the products, tools and websites we use, but it’s important for both the designer and client to set those aside when you’re working on a web design project.

Websites are designed for their audience, for the users that the owner is hoping will visit and complete some transaction or task. As part of the user-centred design process, we research the users; create personas and use-cases for them, so that we can better understand how to tailor the site to their needs. And yet it’s very common for feedback to come in from members of the project team (on both sides) that involve personal opinion. For example, “I don’t really like the use of green in the sidebar”, or “Perhaps the product image should be a little larger”.

We need to remember that we’re not designing for ourselves, we’re designing for our users and so we need to set aside our opinions and think in terms of evidence. On what basis were these design choices made, and is there evidence to suggest that a different approach would be better?

Andy Clark of Stuff & Nonsense spoke about his approach to this subject on the Boagworld podcast offering the suggestion that if the person persists in pushing their opinion then you could offer a compromise:

“We’ll look at both versions, your version and my version; we’ll launch with my version and then we’ll test yours separately and see if it’s better.”

This puts weight in the designer’s approach, based on their experience and training, whilst exploring the suggestion and incorporating it at a later date if it proves itself through testing.

At OCC we have been using Microsoft’s web application framework ASP.Net MVC on a number of our projects and products for a couple of years now and really enjoy the flexibility, power and transparency it offers. But it’s still relatively young and new features are added frequently so we’re keen to learn as much as we can from others that have been working with it.

With that in mind, last week James and I attended a NxtGenUG meeting with a talk from Richard Costall covering useful tips and tricks for those using ASP.NET MVC 3.0, based on his first five months of working with it on a new project. Richard demonstrated a simple site created using the new Razor view engine.

His main points were:

• Creating a ViewModel for each View is generally good practice. This allows data of relevance to the View only (e.g. page title) to be decoupled from core entity data.
• If @Html.EditorFor() is passed a collection, it will render an editor view for each member of the collection automatically – no need to write looping code.
• Mixed collections of inherited entities (for example, a shopping basket containing different sorts of product) are very easy to display and edit using MVC. Just create a View to display each inherited type. The MVC plumbing will automatically work out which View to use based on the type of each object in the collection. Ensuring that the correct ViewModel is bound on processing of posted data is a little trickier – if necessary, you can override the default ModelBinder implementation.
• The Post-Redirect-Get pattern can save writing a lot of ViewModel rebuild code when submitted data is rejected due to a validation failure. Add the ModelStateToTempData attribute (from MvcContrib) to the HttpGet action to override the default ViewModel data with the user’s previous inputs. This pattern also avoids the “resend previously submitted information” warning displayed by the browser when F5 is pressed after a POST.
• Use Html Extension Helpers to implement non-standard editor controls such as sliders.

There was some lively discussion in the group concerning the relative merits of MVC and WebForms technologies for commercial development. The general view was that MVC was the better technology to use – it produces elegant and compact HTML (no nasty viewstates), plays well with jQuery, enables finer control of rendering and is more easily testable and reusable. However, some thought the lack of rapid prototyping support may make it a hard sell in time-pressed commercial environments; perhaps there is room for some innovation there.

Thanks to NxtGenUG and Richard for an interesting and informative evening!

“The Cloud” is a term that we use to describe a way of hosting and running websites and applications where we ship off our files and databases to whomever we choose and have all the worries of managing the details of hardware, operating systems, networks and datacentres managed for us by them. This way, the specialists at the cloud provider can focus on providing a high quality, scalable platform, and the customer can focus on developing and deploying their website or application.

There are many cloud providers and today we will look at the recently-refreshed Windows Azure from Microsoft.

Windows Azure

Azure is Microsoft’s cloud platform and runs on their datacentres all around the world. As a Microsoft product many web developers might shy away from Azure as an option with concerns it might not support non-Microsoft technologies or frameworks such as PHP, Node.js, Python, or Java – actually Azure supports all these and more; any operating system and any language.

You can learn all about what Windows Azure offers on their “What is Windows Azure?” page, so I won’t go into detail here. Instead, we’ll look at a specific example, getting a WordPress website (build in PHP and usually run on Apache with MySQL) up and running on Windows Azure.

The first step is to set up an account on Azure, you’ll need a phone number and a credit/debit card (which will not be charged) to validate your account. They currently have a 3-month free trial, after that their prices seem very reasonable and like most cloud providers you only pay for what you use.

WordPress on Azure

Once you’re logged in, click on the “Manage” option in the navigation at the top of the screen and you’ll be taken to the page shown below.

From here, click on the “Sign in to the Management Portal” link on the left and you’ll be taken to the shiny, new Azure management app.

The first time you access it you’ll get a little tour, but eventually you’ll get to your dashboard, which will be empty and look something like this:

Just a side note: When I registered there was a short wait before the “web sites” option (which we will be using below) was available to me; just a couple of hours.

Choose the “web sites” option on the left and click “create a web site”.

Choose the “from gallery” option, highlighted above, and then find the WordPress option in the list of apps available.

Click the “Next” arrow and choose your website’s URL; leave the database setting as “Create a new MySQL database”; and choose the region closest to you (or your audience).

Click the “Next” arrow again and confirm your new MySQL database settings, then click the final “Next” icon to complete the process and Azure will begin deploying your new site.

A few moments later and it will inform you that the deployment is complete, and the site is up and running.

That’s it! Your WordPress site is now live and can be accessed at the URL you configured in the setup earlier; you can get there nice and quickly by clicking the “Browse” icon in the toolbar at the bottom of the Azure portal.

Configure WordPress

As this is WordPress, the first time you access it, it will ask you to complete the installation by making a few configuration choices.

Click the “Install WordPress” button at the bottom to complete the setup and WordPress will show you a “Success!” message with a “Log In” button that will take you to your new WordPress admin login area. Enter your chosen WordPress username and password and log in to see your blog Dashboard.

You’ll want to visit the Settings section using the menu bar on the left to tweak any final settings, but you’re all ready to go!

Configure Azure

With any hosted service you’re likely to want to be able to view usage statistics, configure FTP and publishing access, etc. So let’s switch back to Azure.

Set up FTP access

Click on the name of your new site in the Web Sites list and you’ll see a one-off startup page welcoming you and giving you some options for how to proceed.

First off, let’s set up FTP access so that you can begin customising WordPress further with custom themes and plugins. Click on “Set up deployment credentials” under the “Publish your app” heading (if you’ve dismissed the welcome screen you can access this through the “Reset deployment credentials” option under the “quick glance” heading on the dashboard).

Choose your username and password, click the tick to confirm and you’ll be sent back to the welcome screen with a success message.

Click the “Dashboard” option at the top of the Welcome screen and you’ll see your Azure website dashboard (you can get back to the welcome screen by clicking the cloud with a lightning bolt icon on the left of the dashboard option).

Here you can see a wealth of usage information, as well as plenty of further configuration options. If you scroll down a little, you’ll find your FTP address on the right, under the “FTP hostname” heading. Use this along with the credentials you just set up and you can begin uploading to, and editing your, WordPress installation.

Publishing alternatives

If you use git as your source control you can configure Azure to have its own git repository for your website, which you can push updates to and it’ll build and deploy your changes automatically. Click the “Set up Git publishing” option to be guided through that.

You also have the option of linking your site to TFS (Team Foundation Server) for publishing via that code-base, or you can download a publishing profile to load into Visual Studio to allow direct publishing from there.

To Conclude…

I’m really impressed with Microsoft’s cloud platform; Azure is beautifully designed with lots of thoughtful options and a clear user experience. Hopefully you’ll agree that setting up WordPress is a breeze, and it’s not the only option, Azure also has off-the-shelf installations of Drupal, Joomla and Umbraco in its gallery and I’m sure the list will continue to grow.

In the future I’ll be writing about deploying a custom .Net web application to Azure so keep an eye out for that!

I’m sure you’ve come across IE7′s warning “This page contains both secure and nonsecure items. Do you want to display the nonsecure items?” Or IE’s more recent warning “Do you want to view only the page content that was delivered securely?” Other browsers have similar messages, which will rightly unnerve cautious internet users.

These warnings are the result of the page being secured, delivered over HTTPS, but some of the page’s resources being delivered using HTTP. It’s a simple thing to overlook if you have a site that has both secure and unsecured areas, but share master pages, or other code that might link to JavaScript, CSS, and image files.

Thankfully there are a couple of really simple solutions:

Use relative paths

In your link to the resource, be it an src attribute in HTML or a url in CSS, you can use a relative path, which will automatically take on the same protocol as the current page.

For example, if you were linking to a background image from your CSS, you could use background-image: url(images/bg.png); which would look for an images directory in the same folder as your CSS file and find bg.png in there.

Omit the protocol

Technically this is simply another type of relative path, only this time you leave off just the http or https from the beginning of the path.

For example, if you were linking to Google’s Content Delivery Network to get your copy of jQuery then you could use <script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script> and the browser will fetch the script using whatever protocol the page is using.

There are plenty of WordPress plugins out there that promise to improve your page speed in various ways, but the truth is you can do a great deal without resorting to them and just making a few simple but effective changes to your Apache configuration. In fact, this article applies equally to any Apache website, not just WordPress.

As we know, keeping our page load times nice and snappy is the key to happy visitors and one of the important factors in SEO. Whilst it’s something to take seriously, it’s not too hard to understand with some pointers. This post will take you though the easy wins that are often overlooked when setting up a new WordPress site:

• Leverage Browser Caching
• Enable Compression
• Disable ETags

We’ll be using Google Page Speed and Yahoo’s YSlow browser plugins as a way of measuring the improvements in our page speed and getting tips for where to focus our efforts.

Leverage Browser Caching

Browser caching is when the server tells your browser how long to cache copies of your site’s files; the HTML, CSS, JavaScript, images, etc. The server does this using “HTTP headers” it attaches to the files it sends to the browser, in this case specifically the cache-control header, which specifies the number of seconds the browser should keep hold of the file before it should ask for a new copy.

If you open up Firebug and switch to the “Net” tab, or the alternative if you’re using developer tools in another browser, you should see a list of all the resources your page is sending to the browser (you might need to refresh the page to get this).

Without browser caching we can see that all the page's resources are being downloaded from the server

The “Status” column shows us that all our page’s resources are being delivered by the server – this is what the “200 OK” status means. We want to change this so that the browser gets the resources from its cache, which is far quicker.

To do this we will use the Apache mod_expires module, which will allow us to define how long the server will tell the browser to cache the various types of resource.

First you’ll need to endure that mod_expires is enabled on your server, so open up your Apache httpd.conf file and search for the line LoadModule expires_module modules/mod_expires.so it’s commented-out by default so uncomment it or add it in as necessary.

Next, add in the configuration. Just like for compression, above, this can be added to the http.conf or .htaccess files.

For our site, we use the following configuration:

# Content expiration headers
<IfModule mod_expires.c>
    ExpiresActive On

    ExpiresDefault "access"

    ExpiresByType text/html "access"
    ExpiresByType text/xml "access"
    ExpiresByType application/xml "access"
    ExpiresByType application/xhtml+xml "access"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType text/javascript "access plus 1 month"
    ExpiresByType text/x-javascript "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType application/x-javascript "access plus 1 month"
    ExpiresByType image/gif "access plus 1 month"
    ExpiresByType image/jpg "access plus 1 month"
    ExpiresByType image/jpeg "access plus 1 month"
    ExpiresByType image/png "access plus 1 month"
    ExpiresByType application/pdf "access plus 1 month"
    ExpiresByType application/x-shockwave-flash "access plus 1 month"
    ExpiresByType image/ico "access plus 1 year"
    ExpiresByType image/icon "access plus 1 year"
    ExpiresByType image/x-icon "access plus 1 year"

    # Need to register the icon mime type
    AddType image/vnd.microsoft.icon .ico
    ExpiresByType image/vnd.microsoft.icon "access plus 1 year"
</IfModule>

Let’s break this down:

• ExpiresActive On switches on cache-control for all our resources.
• ExpiresDefault "access" sets the default cache expiry to be instant – as soon as the content is accessed.
• The following lines are all similar to ExpiresByType text/css "access plus 1 month" where we say what type of resource we are talking about (in this case CSS files) and how long they should be cached (in this case 1 month after they are accessed).
• Note that the HTML and XML types are all set to “access”, this means they won’t be cached by the browser. We chose to do this so the user is guaranteed to see the very latest content, but what you choose will depend on your site.
• The final couple of lines add in a non-standard type of image/vnd.microsoft.icon, which is used by favicons, and then adds an expiry for that type.

After making this change, restart your server and take another look at your page. The first time you look at it, it will still request all the resources from the server (as it hasn’t been told to cache them yet) but when you look at the headers of one of your files you’ll see the new cache-control header is in there.

Note the "Cache-Control" header is now present

The next time you refresh your page, your browser will know to get these resources from its cache rather than request them from the server, so your new page load should look more like the following:

With browser caching enabled we can see that all the page's resources are being fetched from the browser's cache

Much better! Now all our content is coming straight from the browser cache (denoted by the “304 Not Modified” statuses) and you can see the loading speeds are all significantly faster.

Enable Compression

When the server sends information to the browser it can be configured to compress the data in order to make the loading speeds quicker. To enable compression in Apache, first you will need to check that mod_deflate and mod_headers are enabled on your server, so open up your Apache httpd.conf file and search for the following lines, they are commented-out by default so uncomment them or add them in as necessary:

• LoadModule deflate_module modules/mod_deflate.so
• LoadModule headers_module modules/mod_headers.so

Next, add in the configuration. This can be added to any of the following locations:

• The base-level of the httpd.conf file so that it applies to all your server’s sites.
• Into one of the <location> sections so that it applies to just that location’s files.
• Into a .htaccess file so that it applies to just the files governed by that file.

For our site, we use the following configuration:

# Compress text, html, javascript, css, xml
<IfModule mod_deflate.c>
    # The list of mime types we want to compress
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE image/svg+xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/atom_xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE text/x-javascript

    DeflateCompressionLevel 9

    # Netscape 4.x has some problems...
    BrowserMatch ^Mozilla/4 gzip-only-text/html

    # Netscape 4.06-4.08 have some more problems
    BrowserMatch ^Mozilla/4\.0[678] no-gzip

    # MSIE masquerades as Netscape, but it is fine
    # BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

    <IfModule mod_headers.c>
        # Make sure proxies don't deliver the wrong content
        Header append Vary User-Agent env=!dont-vary
    </IfModule>
</IfModule>

Let’s break this down:

• There are a number of lines similar to AddOutputFilterByType DEFLATE text/html – these lines tell the server to compress specific types of file, in this example, HTML files. Here we list all the types of file we want to compress and anything we leave out will be sent normally. Note that images and PDFs are not included, it’s only text-based files.
• DeflateCompressionLevel 9 sets the compression level to its highest. This will take more processing power so adjust this according to your needs.
• There are a some lines that begin with BrowserMatch, these take care of compatability with some older browsers.
• Finally there is a section that ensures proxies work well with our compression.

Now that’s all set up Apache will compress all the content it can and, using Firebug, you’ll see both the size and load time of all the text-based resources drop nicely.

Disable ETags

A common complaint of YSlow is that “There are x components with misconfigured ETags” – because we have taken control of our browser caching, we don’t really need ETags any more (they are just another way for your browser to control its cache) so the simplest solution is to turn them off.

To do this you’ll need to have mod_headers enabled (as for enabling compression, above) and add the following to your httpd.conf or .htaccess file:

# Turn off ETags as we're manually managing our caching
<IfModule mod_headers.c>
    Header unset Etag
    FileETag none
</IfModule>

This removes the Etag HTTP header and YSlow will stop complaining and give you an A-grade for ETags.