The purpose of this unit is to learn Ruby, and a little about professional code construction.

The two books you will need are:

• The Well Grounded Rubyist, David A Black
• Clean Code, A handbook of Agile Software Craftsmanship, Robert C. Martin (Uncle Bob)

Read the books

Don’t worry about code at this point, begin by reading the books and working through the examples. Ensure at a minimum you read the following chapters:

• The Well Grounded Rubyist, every chapter
• Clean code, chapters 1 – 7 + 1o

Don’t be tempted to work through your own code at this point, just follow along with the examples. Don’t worry about committing everything to memory, or even understanding it all. This won’t be the last time you read these books, but will give you an overview and remind you where to look when you encounter problems these books can help with in the future.

Devise your sample code project

After reading the books, come up with a simple project that will test the code you’ve learnt, under the following constraints.

• It should be a command line app
• It should collect some input from the user
• It should process that input, perhaps along with some data collected from the web and stored in a flat file
• It should return some data back
• It should be simple enough to code within a day or so

Discuss the project with me at this point if you wish.

Implement the project, using the best practices you’ve learnt

• Create a new public github project to store the code in.
• Write the code using the best practices you’ve picked up from Clean Code, and the skills in the Ruby Book.
• Use git as you go, committing each change using the process learnt in unit 1. Stick to master for now.

Notify me when you are done, and I’ll review your code in git and set up a code review ready for you to move on to the next step.

Ensure you are on a Mac or Linux machine

None of this is going to work if you are using Windows, so the first step is to install Linux. Download the latest version of Ubuntu, and get it installed on your PC.

Setup a GitHub account

If you don’t have one, set up your GitHub account, where you can store your code and show it off!

Ensure you have set up your .ssh public/private keys, there is good documentation on GitHub.

Learn the basics of Git

Working through this tutorial will get you up and running, and handily, it focuses on Octopress as an example!

Use the Code School tutorial after for a second perspective if you wish.

Read the first chapter of The Well-Grounded Rubyist

It helps to have an understanding of where Ruby stores files to enable you to happily install Octopress and its dependencies, so reading the first chapter of our core course text – The Well Grounded Rubyist will give you that grounding.

Set up RVM

Next you need to set up RVM to manage your gemsets and ruby versions. First follow this tutorial which will explain why RVM is so useful and how to get started.

Install and setup Octopress

Octopress is blogging platform of choice for the cool kids. It lets you store all your posts in MarkDown and uses Git to keep them versioned. You can host it on Github Pages, Heroku or your own choice of platform.

• Follow the standard guides – don’t forget to use RVM to set your gemset location and Ruby version.
• Consider using POW if you haven’t already

Set up your plugins

I recommend (sign up for an account if you haven’t already) hooking into:

• Twitter
• Delicious
• Github

Get some content on them all first!

Write your first blog post and publish

Write your first post, on your starting point and current experience, and what your goals are after completing the course.

Write your second post on the process of setting up Octopress and RVM and your thoughts on the platforms so far.

To cut to the chase – Elastic Beanstalk wins, but as usual it depends on your situation.

Common features

All the below services feature:

• Deploy from the command line with git
• Full support for Ruby/Rails apps
• Gems installed and updated automatically on each push
• Comprehensive settings to handle db:migrate
• Integrated database support (no need to set up separate instance)

Note that none of these features came with Elastic Beanstalk when it first launched – its come a long way, so may be worth reconsidering if you’d previously disregarded it.

Heroku

Pros

• Heroku very easy to get started, you just install the toolkit and your away
• Documentation is simple and straightforward
• Heroku is the cheapest option for a low traffic site – you can run a site with a basic (less than 10k rows) database for free, although it will be quite slow if you have a lot of traffic
• You don’t have to add a credit card, so you will go up in price only as and when you choose to – no nasty shocks
• Backups are handled automatically
• A number of addons are provided, making it easier to integrate with systems such as NewRelic for monitoring and SendGrid for emails
• Database integration is simple with Postgres support out of the box

Cons

• Once you need to add power and handle more traffic the price goes up quickly
• You need to manually scale your application by adding dynos – a vague and somewhat confusing concept Heroku have come up with themselves - this gives you *some* control over price, but ultimately means your site won’t cope well with unexpected spikes in traffic
• Customer support is reported to be poor, but I haven’t needed to use it personally
• Heroku is owned by Sales Force, which means it could be sold at any point or deprioritised
• Unlike the others, you can’t log into your server via SSH
• After deploying an update the first hit to the server takes ages

We use Heroku for all our test applications, and for little pet projects that might grow. I wouldn’t use it for actual scaling though, its too expensive and you don’t get enough for your money.

EngineYard

Pros

• Scaling happens automatically, so you can handle that spike (although this can lead to a suprisingly large bill)
• You can SSH into the server and change things
• Backups are handled automatically
• A number of addons are provided, making it easier to integrate with systems such as NewRelic for monitoring and SendGrid for emails
• Database integration is simple with Postgres and MySQL support out of the box
• Support is excellent – I’ve had much first hand experience of this

Cons

• Its a little more work to deploy than heroku, but not much, and after the first live publish it takes no longer to update
• Its incredibly expensive, we once spent $100 on a month for a server without any traffic
• EngineYard applies a 20% surcharge on all of Amazons prices, as it uses Amazon for storage, IP Addresses and backup, so it will almost always be more expensive

I would recommend EngineYard for production products where money is no issue, and support and absolute minimal interaction with setting up addons is required.

Elastic Beanstalk

Pros

• New users can use Elastic Beanstalk free and underlying services up to a certain amount free for a year, making it competitive with Heroku, certainly for the first year
• A sample low traffic site on Elastic Beanstalk after the free period is $35 per month. To run that same site on EngineYard would cost at least $86
• Scaling happens automatically, so you can handle that spike (although this can lead to a suprisingly large bill)
• You can SSH into the server and change things
• Backups are handled automatically

Cons

• Its a little more work to set up and deploy for the first time than Heroku and even EngineYard (the toolkit needs installing manually, you can’t do it as a gem), but it only takes a few mins extra
• In order to use a database to get the same ease you would with Heroku and EngineYard you need to use Amazons RDS service (which provides a MySQL, Oracle or SQL Server database) which comes with variable additional charges
• Addons aren’t provided, so its a tiny tiny bit more complex to integrate with essential monitoring tool New Relic (although it is free for AWS users), and SendGrid. Its not much more work though.
• Its hard to work out how much you will pay, although it should always be cheaper than EngineYard since they use AWS and add on top. Elastic Beanstalk itself is free, but you pay for bandwidth, storage, database, backups etc.
• You don’t get as much feedback from the server when pushing as you do for Heroku and EngineYard

Elastic Beanstalk is where I would recommend hosting production products to get a balance of service and price. You could even start a pet project on there right away due to the free storage tier. There are more cons, but I feel these are offset by the price for many situations.

• HTTP Basic Access Authentication over SSL
• HTTP Digest

The answer, as usual, is it depends, but if you can force the server to use SSL, or are creating a private API, then its Basic.

HTTP Basic Access Authentication over SSL

HTTP Basic is a simple form of authentication where:

• STEP 1 – the client makes a request for information, sending a username and password to the server in plain text
• STEP 2 – the server responds with the desired information or an error

HTTP Basic doesn’t need to be implemented over SSL, but if you don’t, it isn’t secure at all. So I’m not even going to entertain the idea of using it without.

Pros

• Its simple to implement, so your client developers will have less work to do and take less time to deliver, so developers could be more likely to want to use your API 
• Unlike Digest, you can store the passwords on the server in whatever encryption method you like, such as bcrypt, making the passwords more secure
• Just one call to the server is needed to get the information, making the client slightly faster than more complex authentication methods might be

Cons

• SSL is slower to run than basic HTTP so this causes the clients to be slightly slower
• If you don’t have control of the clients, and can’t force the server to use SSL, a developer might not use SSL, causing a security risk

In summary – if you have control of the clients, or can ensure they use SSL, HTTP Basic is a good choice. The slowness of the SSL can be cancelled out by the speed of only making one request.

HTTP Digest Access Authentication

HTTP Digest access authentication is a more complex form of authentication that works as follows:

• STEP 1 – a client sends a request to a server
• STEP 2 -the server responds with a special code (called a nonce), another string representing the ‘realm’ and asks the client to authenticate
• STEP 3 - the client responds with this nonce and an encrypted version of the username, password and realm (a hash)
• STEP 4 - the server responds with the requested information if the client hash matches their own hash of the username, password and realm, or an error if not

Pros

• No usernames or passwords are sent to the server in plaintext, making a non-SSL connection more secure than an HTTP Basic request that isn’t sent over SSL. This means SSL isn’t required, which makes each call slightly faster

Cons

• For every call needed, the client must make 2, making the process slightly slower than HTTP Basic
• HTTP Digest is vulnerable to a man-in-the-middle security attack which basically means it could be hacked
• HTTP Digest prevents use of the strong password encryption, meaning the passwords stored on the server could be hacked

In summary, HTTP Digest is vulnerable to at least 2 methods of hacking, where a server using strong encryption for passwords with HTTP Basic over SSL is not.

If you don’t have control over your clients however they could attempt to perform Basic authentication without SSL, which is much less secure than Digest.

The answer – it depends, but probably HTTP Basic

Ideal:

• Use HTTP Basic with SSL, slower than non-SSL, but only one call needed per information request
• Store passwords on the server encrypted with a strong password hash such as bcrypt, making it harder for hackers to extract them from the server
• Force the server to serve the API over SSL

If you can’t force the server to server the API over SSL, and don’t have control over all the clients being built (i.e. you are creating a public API):

• Use HTTP digest

Why bother

A REST API follows standards, and these standards take into account many of the gotchas you would encounter if you just made up your own rules, as many choose to.

It is likely you will also be creating the clients (for example, you may be making mobile apps that the API supports), and the better the API, the easier it is to create those clients.

Following these standards means:

• Documentation will make more sense and so developers will understand your API quicker
• Developers who have used other REST API’s will already understand how to use yours
• Developers will therefore be able to integrate quicker and therefore deliver products faster and at lower cost
• The API will handle common issues out of the box so clients should contain less bugs
• Many of the principles will make your clients faster, improving product quality
• These principles help to ensure as much as possible is managed by the server, so you don’t have to repeat as much code in each client

Create a uniform interface by mapping HTTP methods to CRUD

CRUD = Create, Read, Update, Delete

HTTP methods = POST, GET, PUT, DELETE

• Create = POST
• Read = GET
• Update = PUT
• Delete = DELETE

So instead of API calls such as:

• Create – GET: /user/new?name=Mark
• Read – GET: /user/1
• Update – GET: /user/1/update?name=John
• Delete – GET: /user/1/delete

Simply:

• Create – POST: /user (with the variables in the entity-body)
• Read – GET: /user/1
• Update – PUT: /user/1 (with the variables in the entity-body)
• Delete – DELETE: /user/1

See IBM – RESTful Web Services: The Basics for more justifications on this.

Following this means everyone can understand how to use your API in a common way and keeps the API simple.

Understand the difference between a URI and a Resource

Consider the following:

• POST: http:/test.com/user
• GET: http:/test.com/user/1
• PUT: http:/test.com/user/1
• DELETE: http:/test.com/user/1

POST, GET, PUT, DELETE are the methods

http:/test.com/user, http:/test.com/user/1 are URI’s

user/1 is a user, which is a resource

Understand the difference between a resource and a representation

From the above example calling GET: http:/test.com/user/1 will return a representation of the resource user:1.

A representation is a set of attributes related to the resource, e.g.

• name: mark
• city: brighton

A representation will have a format (XML, JSON , XHTML etc), and a language.

Keep the number of resources low

The resource names should often map conceptual domain entities. They should map to objects, not actions on the objects.

If you want to declare a user as a subscriber, you don’t need to add a resource called subscribe. Just pass the following representation:

• name: mark
• city: brighton
• subscriber: YES

This keeps documentation and coding simpler.

Create addressability by mapping a URI to each resource, possibly each representation

A URI should map to only one resource.

• test.com/user maps only to user

There should be URI mapping to each representation of the resource

• test.com/user.xml maps to the xml representation of the user
• test.com/user.json maps to the json representation of the user

This enables URI’s to be shared in a consistent way, which keeps things simple.

Name resources and representations carefully

Follow simple rules for naming resources. I recommend:

Use forward slashes to show child objects, with a resource for each item.

• /events – exposes all events
• /events/concerts – exposes all concerts
• /events/concerts/1 – exposes concert with id of 1

Use semi-colons where there is no obvious sequence:

• /events/locations/the-concorde-2;the-brighton-dome – is a search for 2 event locations

Use comma’s when the order matters but they are not child items:

• /events/locations/25.9,22.5 – is a lat/long search

This keeps API’s consistent, making it easier to interact with them.

Use POST for creating, not editing

When you POST you POST to an unknown resource.

• POST: /user

How should you handle the following situation:

• POST: /user/1

You could update it with the new data, or you could respond with a already created code, and force the use of PUT.

I recommend keeping things simple, and refusing to update.

Consider the use of overloaded POST only to handle situations where PUT and DELETE are unavailable

If you want to allow your API to support clients without PUT and DELETE (in reality a rare situation these days), use overloaded POST. A true REST API wouldn’t do this, but sometimes you need to be flexible.

One way of doing this is to define in the API the actual call you want to use to replace POST:

• POST: /user/1?method=put
• POST: /user/1?method=delete

The API can then convert the POST call into the appropriate method, and funnel it into the same route.

GET and HEAD should only ever fetch data, never alter or delete it

If you manipulate or delete data using GET, you put your data at risk.

It is possible a web crawler or browser call could delete your data.

GET should only ever fetch data.

Allow for multiple identical PUT or DELETE requests, without side effects

If you are updating the price of a widget in a PUT request, don’t allow anything like:

• price: +1
• price: -2

Instead, only accept a new price:

• price: 3.99

This is because an app could submit a PUT multiple times, without realising the negative effects. In the first example this would result in the price going up by 1 (or down by 2) on each submit.

In the second, the price would always remain at 3.99, there would be no ill effects.

Use HTTP Response Codes

HTTP provides response codes to inform clients of the status of their request. Use them! Don’t just return a 200 response with an error description if something is wrong.

These are the main ones used:

2xx – Success codes

• 200 – OK, all is fine. Entity-body contains the resource requested in its current state
• 201 – Created, a new resource has been created. Location header contains the address of the new resource. Entity-body contains the representation of the new resource as it is on the server
• 202 – Accepted, a clients request is pending and will be completed later. Location header contains the expected address of the new resource so it can be checked later.

3xx – Redirection codes

• 301 – Moved Permanently, the API has moved a resource in response to the request, or an old resource is requested. Location contains the new URI.
• 304 – Not Modified, the client already has this data, used when the client provided a If-Modified-Since header and the data hasn’t been modified. Date header is required, ETag and Content-Location should be same as a 200, Expires, Cache-Control and Vary are required if they’ve changed since last sent.

4xx – Client side error

• 400 – Bad Request, there is a client-side problem, the document in the entity-body should contain more info on the problem
• 401 – Unauthorized, wrong credentials provided, or no credentials provided. WWW-Authenticate header should describe the authentication methods accepted. Entity-body could contain more details about the error.
• 404 – Not Found, no resource matches the requested URI, there is no reference to it on the server
• 409 – Conflict, client attempted to do something which would leave a resource in an inconsistent state, such as create a user with an already taken name. Location could point to the source of the conflict. Entity-body to describe the conflict.
• 412 – Precondition failed, client wanted to modify a resource using a If-Unmodified-Since/If-Match header, the resource had been modified by someone else.

5xx – Server side error

• 500 – Internal Server Error, there is an error on the server

More codes can be found in the HTTP/1.1 Status Code Definitions guide

Handle and use meta-data in HTTP Headers

Implementing these will make your API more flexible and keep information in standard locations rather than URI’s.

These are common request headers (from client to server)

• Accept-Encoding - asks the server to use compression of responses
• Authorization - enables authentication via any method
• Host - required - domain name of the URI, e.g. www.test.com
• If-Match - value of a previous calls ETag response used with a PUT or DELETE. Server should only act if nobody else has modified the resource since you last fetched it. Otherwise provides a 412.
• If-Modified-Since - value of a previous Last-Modified response used with a GET. Server should only provide a response if the resource was modified since the timestamp submitted. Use in conjunction with If-None-Match in case the change occurred within the same second. Otherwise provide a 304.
• If-None-Match - value of a previous calls ETag response used with a GET. Server should only provide a response if the ETag doesn’t match, i.e. the resource has been altered. Otherwise provide a 304.
• If-Unmodified-Since - value of a previous Last-Modified response used with a PUT or DELETE. Server should only act if nobody else has modified the resource since you last fetched it. Otherwise provides a 412.
• User-Agent - information on your client, useful for gathering statistics

These are common response headers (from server to client)

• Content-Encoding - tells the client what compression is being used
• Content-Length - tells the client how many bytes the content body contains
• Content-Type - tells the client the media type the entity-body is, e.g. text/html
• ETag - a string representing a version of a representation of a resource, useful in detecting if a resource has changed with If-Match or If-None-Match
• Last-Modified - the time the representation changed, useful in detecting if a resource has changed with If-Modified-Since and If-Unmodified-Since
• Location - URI relating to the request, varies according to the HTTP status
• WWW-Authenticate - tells the client the expected authentication type when responding with a 401

These are common request and response headers (bi-directional)

• Date - time on the client the request was made, time on the server request was responded too. The server must provide this unless is is responding with a 100, 101, 500, 503

REST is stateless – so don’t handle state in your API

REST API’s must be stateless. Every call requiring authentication should provide the authentication and never a session key.

When you attempt to handle state in your API you create a nightmare of sessions and session handling on the API side, and create lots of repetitive work for each service connecting to your API who has to potentially always handle the case where the session has expired. Handling state will slow down your API and all clients using it.

Stateless API’s are easier to scale, more reliable and simpler to use.

REST is cacheable 1 – allow clients to GET only updated resources via HTTP

If your clients are repeatedly requesting the same data you are unnecessarily slowing all applications down, increasing bandwidth from the server to the clients and wasting computation power. Instead, use HTTP to handle this.

The easy way with Last-Modified

• Server provides a Last-Modified header with each GET call, the date the resource was last modified.
• Clients can now GET with the header If-Unmodified-Since containing the latest Last-Modified value
• The server either updates the resource if the Last-Modified value for the resource matches the one in If-Unmodified-Since, or respond with a 304 Not Modified.

Get more precise with ETags

There is a risk here where more than one person can update data, that the data updated again within the same second. This is why you can also use ETags.

• Server provides an ETag (more on how to create ETags) which represents the resources current state, with each GET call
• Clients can now GET with the header If-None-Match containing the latest ETag value
• The server either responds with the resource if the ETags differ, or respond with a 304 Not Modified.

However, ETags are more costly to generate than Last-Modified, and should be considered carefully.

REST is cacheable 2 – prevent accidental simultaneous updates of the same resource via HTTP

A common issue when more than one client can access the same resource is having one client do an update, and then another client overwrite that update because they didn’t know it had occurred.

The basic way with Last-Modified

• Server provides a Last-Modified header with each GET call, the date the resource was last modified.
• Clients can now PUT with the header If-Modified-Since containing the latest Last-Modified value
• The server either responds with the resource if the dates differ, or respond with a 412 PreCondition Failed.

Get more precise with ETags

• Server provides an ETag (more on how to create ETags) which represents the resources current state, with each GET call
• Clients can now GET with the header If-Match containing the latest ETag value
• The server either responds with the resource if the ETags differ, or respond with a 412 PreCondition Failed.

Read more about preventing race conditions.

Use the HEAD method to allow the client to manage its bandwidth better

The HEAD method for an resource should return a meta-data only representation of the resource.

HEAD: /user should return everything GET: /user would except the entity-body.

This could be useful for a number of reasons, e.g. the Content-Length header might tell the client it doesn’t want to fetch this particular entity-body if its too large.

Version your API, and never change released features

Each URI should begin with a version number.

• /v1/user

Returns:

• name
• phonenumber

If you remove anything from the representation being returned for user, or change the rules about what you accept, you need to increase the version number – don’t just change the current representation.

• /v2/user

Returns

• name

This prevents your clients from breaking!

Understand Hypermedia application state and why you probably shouldn’t use it

Hypermedia Application State (also known as HATEOAS) is a concept wherein the client uses just one URI, and from that URI is able to deduce how to interact with the API by following links, as one would when using a website. What this means in theory is that the client need not know how to use the API in a certain way, which enables the API to evolve without updating all the clients. This talk explains it well.

This is one part of REST I don’t agree with for most situations, although it is technically part of having a true REST API.

The concept is great in theory, but it poses the following issues:

• At least 2 API calls are needed to perform any task, one to identify how to perform the task, and then the one to actually do it – which means more data being transferred, and more time taken to get the data. This is terrible for mobile, especially as the signal could be lost in between asking how to perform the task, and actually doing it.
• You should not use JSON to run this type of API, and JSON is the most efficient way of passing information to clients
• This is not a common way of consuming an API, so it creates complexity for the client developers, which could cause the development to take longer, or put people off using the API
• There is still lots of information the client needs to know about the API in order to respond to it and navigate it, so its not true separation of concerns anyway

Ultimately what this does is put the needs of the developers over that of the users. It places theory over practicality. No other aspect of REST does this, and that is why this is the one thing I don’t recommend, and neither does the creator of Ruby on Rails, nor Michael Bleigh. Others do, and its a big debate area. Understand it and make your own choices.

Next steps

Learn more about API’s

The best book you can read on this subject is the REST bible: RESTful Web Services, by Leonard Richards, a Kindle edition is also available.

Get outside help with your API’s

If you’ve enjoyed this article and have an API project you’d like help with, I may be available as a consultant on your project. I’ve built REST API’s for mobile apps, and worked with Tesco on the early versions of their (non REST) API as a mobile developer. I learned much from this experience, and have both made, and seen, many of the issues that can occur from not following the above guidelines. My business partner and our CTO James McCarthy has over 20 years experience building back-end systems and API’s for organisations such as AMEX and may also be available.

To hire one of us, check out the contact page.

Why test at all?

If you have a site resulting in a call to action there are many things you can alter that might increase take-up.

If you just change things without testing you run the risk of making things worse, or lack a true understanding of what helped to create an uptake.

Create a hypothesis, a series of design suggestions, and test them on real users by using multivariate or split testing.

What is the alternative to multivariate testing? (its split testing)

Split testing allows you to test users on completely different versions of the page, where you could change one or more items, or run an entire redesign. You can test one, two or more variations of the page. A/B testing is term used to describe split testing of 2 alternatives.

Once you have completed the testing, you have a winner and you can make it live.

What is multivariate testing?

Multivariate testing allows you to change a number of elements on the page, and run tests to see which of those elements are more likely to result in improvements to the call to action.

Visitors to the site will see different element combinations each time, and the system you use will attempt to calculate which items are proving more successful over time.

Once you have completed the testing, you need to create a new design based on your learning.

The primary benefit of multivariate testing over split testing

Multivariate testing has a lot of fans, large companies have seen increases in profits thanks to its use. You will find many avid proponents of its use, especially from those who own companies that sell it as a service.

The primary benefit of multivariate testing over split testing is you can try a number of changes all at once, run the tests, and find out approximately which were most successful, growing your knowledge of what triggers your customers to complete a task. If you are going to put this knowledge to good use in the future, then it is good to know. This is one of the principles of the lean startup movement.

To achieve this in a split test, you would need to change one thing at a time, see if it worked, and then if not, roll back and start again, so it would take longer to gain that knowledge.

However, you could also make a lot of changes in a split test, see your profits increase

The downsides of multivariate testing

It is complex to set the tests up, whatever the blurb may say

The tools such as market leaders Visual Website Optimizer and Optimizely both work by allowing you to edit the HTML and CSS inside their apps. Then they roll the changes out onto your site using JavaScript.

Setting up the changes is fiddly and requires some HTML and CSS knowledge anyway. It should be easier for a skilled front-end developer to set up experiments in a split testing environment where you just upload an alternative file. If you aren’t a skilled developer you probably shouldn’t be making the changes anyway.

You need to plan very carefully

You need to think about how all the various combinations of changed elements could look together. You don’t want your site looking like a mess, as that will put people off anyway and skew the data.

It could harm your search engine rankings

Any split or multivariate testing can impact negatively on your search engine rankings as you run the risk of being penalised for duplicate content, lost backlink equity and page slowdown. This SEO company explains it all in more detail.

Whats concerning is that whilst there is plenty you can do if you are running split tests to mitigate the risk, with multivariate you are powerless to do anything. You just have to assume the risk, and take the hit if it occurs. For this reason alone, I wouldn’t use multivariate testing on a site that wasn’t extremely well linked to and established.

You can easily destroy cross browser and multiple platform consistency

When setting up the multivariate tests you have no way of easily testing the changes across multiple browsers and platforms. It certainly needs to be done, but it will take you much longer to do when running multivariate tests than split tests. In a split test you can simply load the 2 pages, and test them manually. With multivariate tests you will need to hope your chosen software makes it easy to force certain scenarios and then work through them all.

Multivariate testing also gives you the potential power to destroy your site, so make sure you trust the HTML and CSS knowledge of whoever has control of the tests.

Its takes a long time to find a potentially inaccurate answer

Multivariate testing doesn’t ever truly prove that a certain element was responsible for the conversion rate increasing. It can only strongly suggest it. Since every user sees a different combination of elements, you can’t be 100% sure it was the element in question which convinced them.

To be even mostly sure as Paras points out you need to see a large increase in conversion rates when a particular element is present, have a large number of visitors and ideally be starting with a page with an already high conversion rate of around 50%-60%. This takes a long time, according to Optimizely “Even a site with fairly high traffic might have trouble completing a test with more than 25 combinations in a feasible amount of time.”

You still need to do a design at the end of the tests

Multivariate testing will produce some pointers, but then you need to create a new design with the results taken into account. There will be more coding to be done, and you might not be happy with the hodgepodge design that will be produced. Plus, that particular combination of elements might not even work together…so…

You still ought to do A/B testing of the new design vs the old

Otherwise, you aren’t testing the final release – the most important of all. Expect to wait around 2 – 4 weeks for that to be completed.

The software isn’t cheap

Expect to pay between $100 and $400 per month to run multivariate tests.

If you trust your redesign ideas, or have an under performing site you could profit quicker using split testing

If your site has obvious issues, that you can see based on intuition and studying more successful competitors, such as:

• an outdated design
• contains quickly drafted copy, that you wrote without outside help
• has not been built on solid design principles and sales ideas

Then it is likely that changing these things will result in higher sales.

You don’t need to know which of your individual improvements lead to the higher sales straight away, you just need a stronger bedrock to build on.

Why spend lots of time and money running multivariate tests when you can clearly see the improvements are there to be made.

Make them, ensure through A/B testing that you won’t actually see a drop in profits, and get there faster.

If you doubt your redesign ideas, or have no clear redesign in mind, you can increase profits slowly over time with multivariate testing

If any of the following apply:

• you can’t see immediately where you would improve the site
• your site is built on solid design principles
• you and others perceive your site is as good or better than your competitors
• you have range of ideas you might implement but are unsure of
• you have strong current conversion rates

Then multivariate testing could be for you, especially if you have a solid knowledge of CSS and HTML.

Try some ideas, and see if any of them make a difference. If they do, update the site, if not, it’s no problem.

You won’t save a failing business this way – it’s too long-winded, but you might improve upon the already successful.

However if you don’t have an abundance of time, visitors or money, beware of multivariate testing

This sums it up for me:

…A/B testing is so speedy and easy to interpret that some large sites use it as their primary testing method, running cycles of tests one after another rather than more complex multivariate tests.

Optimizely – sellers of multivariate testing software

Conclusion

You need to choose the right tool for the job. Each are valuable:

Multivariate testing requires more work, takes longer, carries more risk, but can provide arguably more accurate results.

A/B testing is simpler, quicker, less risky but you won’t always know whats worked unless you test one thing at a time.

FlexSlider2 is a jQuery plugin that allows you to easily insert rotating banners, image galleries and app examples. They also automatically become responsive.

The problem with FlexSlider2

Out of the box however it doesn’t allow you to use custom HTML elements for the direction controls.

The default appears as you mouse over the gallery, looking like this:

I had a need to use permanent navigation, always appearing, and with custom HTML which differed from the default.

Although FlexSlider2 allows you to set custom tabs (those dots at the bottom), there is no easy way of setting custom directional navigation.

So to fix the issue I wrote an extension to FlexSlider2

My extension – Flexslider2+ManualDirectionalControls

Download the extension here, you can start using it straight away, following the instructions on github.

In a nutshell, to add the functionality, all you need to do is include the javascript and do the following:

There are options you can pass, but this keeps it easy by looking for HTML elements named ‘next’ or ‘previous’ inside the ‘.flexslider’ element and takes care of everything.

Why didn’t I just send an updated version of FlexSlider to github?

There was a discussion at Hatch of simply adapting FlexSlider2 to add the functionality and submit a pull request. I gave it some thought, but since the project currently has 55 issues, 4 pull requests and a great deal of discussion around features, I decided to take the law into my own hands.

• The extension works by overriding a single aspect of the existing plugin, and then continuing with the original flow, so it doesn’t break anything.
• Its easy to use, with just one line of code needed to set it up
• It can be used today, without having to worry about being unable to upgrade FlexSlider2 for fear of losing functionality (if you built using my flexslider branch, you could be stuck having to choose between versions)

Preparation

Follow the instructions on setting up virtual hosts on OS X.

Your httpd-vhosts.conf should look something like this:

NameVirtualHost *:80

<VirtualHost *:80>
	DocumentRoot "/Users/markirby/Sites" 
	ServerName localhost
</VirtualHost>

<Directory /Users/*/Sites/>
    Options Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

Make sure you have set ‘/private/etc/hosts’, ‘/private/etc/apache2/httpd.conf’ and restarted apache, as per the instructions.

Create a symlink to link the sites folder to dropbox

Enter the following to create a symlink which will enable you to edit files in either location and have the changes backed up as you work.

ln -s ~/Sites ~/Dropbox/Sites

Download the framework and locate the .a and header files

Download the distribution files for the framework (for OCMock it comes as a dmg) and locate the .a and header files.

Here’s mine on my desktop:

Copy these files into your source folder for your Xcode project

• Make a subfolder in the root of your project folder named ‘Libraries’ (or place it where you wish – I’ll refer to this as {LIBRARIES FOLDER})
• Make a subfolder in this with the name of your Framework, e.g. OCMock – I’ll call this {FRAMEWORK FOLDER}
• Copy the contents of your static framework in here, preserving the original folder structure

When you are done your structure should look something like this:

Create references to the files in Xcode 4

To set up references to these new files:

• Create a new folder in Frameworks called the same as {FRAMEWORK FOLDER}
• Drag all the files inside your actual {FRAMEWORK FOLDER} into this one
• Deselect “Copy items to your destination folder”
• Select the targets you need – in OCMock case it will be the Unit Tests, but generally it will be the main target

You should now see the framework listed.

My project folder now looks like this:

I’ll add any more headers from other Frameworks  in subgroups with the name of the framework.

Add your header search path to the target build settings

• Select the target you added the framework for, in my case, “FrameworkInstallTests”.
• Select the “Build Settings” tab
• Search for “header search paths”
• Locate “Header Search Paths” field
• Double click the field
• Check the “recursive” box
• Add this to the settings:
• $(PROJECT_DIR)/Libraries

Add linker flag

• Select the target you added the framework for, in my case, “FrameworkInstallTests”.
• Select the “Build Settings” tab
• Search for “linker flags”
• Locate “Other Linker Flags” field
• Double click the field
• Add this:
• -force_load $(PROJECT_DIR)/Libraries/{FRAMEWORK FOLDER}/{YOUR FRAMEWORK NAME}.a
• Which should be the full path to the .a file for the framework, e.g. “$(PROJECT_DIR)/Libraries/libOCMock.a”

Restart Xcode and you should be done!

Restart Xcode.

Leave any issues in the comments and I’ll see what I can do.

Are you designing an app which could be composed of native interface elements?

If you are designing an app for a phone, I would strongly consider using native UI components where possible.

• Native UI components provide a unified experience
• The user should already know how to use your app as it features recognisable interface elements
• Time spent redesigning existing components is time that could be spent better on the overall experience and areas that really are specific to your domain

METAR reader for iPhone was built as a packaged web app, and does not use standard UI elements.

It looks very nice, it could be for Android as much as iPhone, but could also easily be created using well styled native UI elements which would make it easier for users to know what to do and give the app a more familiar feel. What are those bottom 3 tabs for?

Some apps don’t really need to use native interface elements…

Apps with neutral designs

If you are designing a tablet app you may find yourself designing something which is neutral, more like a website, which doesn’t use native UI components. On tablet devices apps tend to follow less of a standard UI look, so there is less consistency anyway.

The FT web app looks the same on all devices, and doesn’t lend itself to using native UI elements.

This app can look like this on any device, it uses no common interface elements.

Recreating native interface elements with web technologies is a bad idea

Recreating standard UI components in web can lead to the ‘uncanny valley‘ effect, where the app looks native but doesn’t feel quite right, as this discussion describes.

At the moment you will never get a PhoneGap app with fake UI elements working as well as a native app with real UI components. There is an unobtainable final 5% of performance that can’t be gained.

A native app can work as well any on the device and feels solid and well produced.

Native interface elements differ between platforms

Each platform has a different standard look and feel.

Facebook on iPhone:

Facebook on Android:

Facebook on Windows Phone:

Each version of the app is consistent with the platform running it, and facebook lends itself to this. You certainly couldn’t put the iPhone design onto an Android device without it looking fake.

If you want to develop an app with a consistent UI on the platform running it (and in most cases you should), you need to redesign the app for every platform.

There will therefore be additional CSS work to do on every platform you want the app to run on, but with web you can share the core code. Even if you don’t redesign the app for other devices, browser differences mean you may have inconsistencies which will need to be tested for and worked out.

Neutral designs work well as packaged web apps

If your app doesn’t contain any native UI elements (like the FT app) it can easily be produced with web technologies without feeling fake.

The user has no expectations related to the UI elements you are using, so performance issues are reduced.

It will be easier to create custom UI elements with web technologies than using native tools to do so, so the project can be delivered quicker.

No redesign will be needed when putting the app on other devices, so minimal effort will be needed to target multiple platforms.

To conclude…

Don’t recreate native experiences with packaged web apps.

Use packaged web apps to create platform neutral experiences that can run across many platforms, none of which resemble the native experience on any single platform.