Red Ant

Red Ant web design award at UTS

Sat, 20 Jun 2009 08:25:06 GMT

We’ve been sponsoring a design prize at our local university – UTS. We’ve been involved with UTS for a few years now, including doing studio visits and professional practice talks.

The prize is for excellence in web design, and is open to any design student at UTS, but appears to be popular for the Visual Communication department. The Design school already has quite a strong web design component, and we thought that sponsoring an award would be an effective way of encouraging this.

The award is made available to the student(s) who are judged through their portfolio and interview to have the most creative and practical approach to design for web media.

This years winner is David Chin- congratulations from everyone at Red Ant

New work: Beautyheaven update

Sat, 20 Jun 2009 07:31:31 GMT

We’ve just deployed a big upgrade to a site that we work on – Beautyheaven.com.au. The site is built in Ruby on Rails, and features articles, product reviews and video tutorials on beauty products and techniques.

Beauty Heaven is the leading independent Beauty site in Australia, and we’re thrilled to be working with them. The site has a thriving membership, who continually add content and reviews to the site. They have a really neat-o loyalty system, where members get points the more they participate on the site- writing reviews of products, comments, and forum postings. Members review beauty products, and there is a crack team of users to that road test various lotions and potions.

This is the latest release is part of a number of changes that we’ve been making to the site to improve functionality and performance- faster, higher and that sort of stuff.

Some of these are new features you can see, such as a new home page, directory of beauty salons and new signup processes. Others changes are not so visible- like the totally rocking page cache that means pages load quicker and more efficiently. I could go on for hours with graphs and stuff, but won’t bore you here…

This latest release involves upgrading from an early version of Rails (1.3) to the current version (2.3). Rails 2 has seen a massive number of improvements, so it’s quite a big leap. We used our trusty tool of choice Capistrano to manage the deployment – so we were able to test on our various stages of test servers before releasing into the wild.

Here are some screens:

The new feature that pulls in the latest articles on the home page (javascript)

Latest video widget thing that pulls in video and story excerpts (flash)

Salon directory application

fat footers

Tue, 31 Mar 2009 16:37:18 GMT

There’s a bit of a design trend at the moment towards making more of the footer area at the bottom of your site. Rather than just having a few links and a copyright statement, some sites are starting to add more elements to their footer area as a way of helping users navigate.

In several recent projects, we’ve experimented with extending the footer area. We’ve had some mixed results. It certainly seems like a good idea- the theory being that the user scrolls to the bottom of the page and gets a prompt or “call to action” to go to another page. There is a good summary of why on Web Designers Wall that I’ve summarised here:

Engage user click and visit duration – theory being that the footer would be the last thing they see on the page
Lazy users who can’t find the sitemap can just go to the bottom of the page
Promote specific links
Save user’s time- allow them to quickly jump from page to page.
Save them a click – no need to click to sitemap
Enhance layout design (aka – I have no content but want to fill up my web page)

I’ve been curious about the impacts of this element, as I’ve had a few discussions with people about whether they work, and if a typical user would ever really scroll to the bottom of the page to see it. Because I’m really in to that kind of thing and get my rocks off with a good graph, we’ve been tracking some metrics around how people use these footers. This isn’t an exhaustive study of the interweb, just our experience on a handful of relatively popular sites that we’ve worked on.

the Good

By tracking where and what people click, we’ve seen that a link in a “fat” footer will generally get more clicks than the same link in the top navigation. Update: the actual uplift or increase in clicks changes depending on the site, the content and footer layout, and of course the time period that you’re comparing. The best result we’ve seen is 620%, which is pretty nice.

This is seems to be particularly so for links in the bottom right corner. If you’re still thinking that no one scrolls below the magical “fold”, then you might find this article interesting: Blasting the Myth of the Fold by Milissa Tarquini . Oh- don’t freak out, but you’re way down below the fold right now anyway…

the Bad

One of the reasons that we thought using a large footer was a Good Thing was SEO. It turns out this isn’t necessarily the case. Big fat disclaimer here – we’re not an SEO agency, and personally I think the world would be a better place if Google was switched off every few days to give us all a break.

Based on advice from a variety of SEO agencies that we’ve worked with on projects (rather than SEO heresay written in forums and on toilet walls):

While it’s generally a good idea to link from one page to the next to promote internal linking…
its not so great to have every page linking to every other page (or at the least, lots of pages). It dilutes the meaning of those links.
While a search spider can use the footer links to index your site…
you can achieve this by including a link to your sitemap, plus using a valid sitemap.xml file.
Having lots of links makes you look more “spammy” to a spider – above a certain amount you start looking more like a link farm and less like a useful content site. And spammy = Bad.

Another reason we liked a big footer was that it made it easier for users. It turns out this isn’t always the case either.

We do a fair bit of multivariate design work, which involves testing different page elements on real users visiting a site. This is testing what real living users do on a real web site, so the results are always interesting. Some users get a fat footer, while others get a thin footer.

Surprisingly, the larger format footer doesn’t always perform better. Sometimes a smaller “thin” footer absolutely wallops it. Obviously this result will be different from site to site, and depends on how you determine your goal (MVT results rely on having a goal or action that you can measure at the end of a user session). One theory as to why a smaller version outperforms is that a smaller footer means less clutter on the page. So a user is more likely to click on the goal link than wander off somewhere else on your site.

Based on these results, I certainly would avoid sticking on a big footer just because you’ve seen it somewhere else. (Damn – I’ve just realised we have one at the bottom of our site). Used in certain ways, the links in the footer can be very effective and help users. Putting a lot of links at the bottom of your page might give you some advantages, but based on our experiences and results there are drawbacks as well. I’d certainly avoid the new whitehouse.gov approach of sticking the whole sitemap down there.

Tails for Whales

Thu, 12 Mar 2009 20:40:32 GMT

We’ve finally launched an update to the 551 project- you can check out the sparkly new goodness here.

Basically, each year Japan sends all these boats down to the Southern Ocean to hunt for whales. Last year they got 551, hence the name of the project. Fingers crossed that this year the number will be much lower, but the only way that is going to happen is if we all hassle, hassle, and hassle some more.

The Tails project involves taking photos of people making a whale tail with their hands (take a look at the site to get a better idea). These photos go into TV commercials, web sites, magazines, and a big book that went to our Prime Minister.

Hold off adding your tail pic for a few more sleeps- we’re beavering away on a new upload tool that will allow you to add your image straight in to the flash feed. To get the project up quickly, we’ve done the design and flash work first. We grabbed all of the images and associated information from the Flickr group and made a JSON feed for the Flash. This will then get replaced with a new admin tool that will help manage all the gazillions of photos and allow all the whale lovers to send in their stuff.

We worked on this project with the Dudes at Republic of Everyone, and IFAW. We hope you enjoy it and feel inspired to take a few Whale Tail photos of your own.

Why we use Ruby on Rails

Tue, 03 Mar 2009 14:14:07 GMT

We do a lot of work with a programming language called Ruby on Rails. When I explain this, some people look at me blankly (disclosure: I get that a lot anyway…). Techie people usually start gushing about how great it is, or want a fight about how X is better. Many people have heard of it somewhere, but are unsure what it is all about.

Here’s my summary of why we use Rails.

The “Ruby” bit is a programming language called Ruby that was developed in the early 1990’s, while Rails is the “framework” bit. It can run on all different types of servers, and has been used to build a few high profile sites such as Twitter.

The framework is a term to describe a way of working. It’s a set of tools and methods that speed up the routine stuff and increase productivity. They allow developers to spend more time on the problem at hand. To use a cheesey metaphor- say you need to drive from Sydney to Melbourne. A framework means you can start your trip straight away without needing to build the car and find some wheels. You still have to drive the car, but you don’t need to do all the painful stuff around making the car. Someone before you has already made a perfectly good car as part of the framework – in fact they’ve probably made a few. You can get straight into the driving. If for some reason you need a different car, you can always get under the hood and bling that car, or you might want to make a new one.

Frameworks are relatively new on the scene. Rails is one that gets lots of buzz (but it isn’t the only one). Its been used to build lots of different things, including very popular, high traffic sites. What’s attractive (for us) about Rails is that some pretty clever people have spent time working out the best way to make things for the web.

Why Rails and not something else? There are thousands of different languages and ways you could build a web site. Some are more popular than others, and some require specific tools or technologies. Some cost a lot to license, while others are free. While I can’t say we’ve tried them all, over the past 12 years we’ve been in business we’ve certainly tested and kicked the tyres on a few.

What I’ve learnt is that it is quite difficult to manage a team that covers several languages. Each language and tool has some unique way of doing things. So running different projects made in different ways can be (was) a bit of a handful. Supporting and maintaining them is even harder. Maybe my mind doesn’t work that way (another disclaimer: I can’t juggle balls or spin plates either). Some development teams go with three or four, while we’ve found it better to focus on one.

We’ve specialized in Rails as we’ve found it makes us more efficient. It helps us develop things faster, and our team collaborates more. It’s also introduced a bundle of ideas and ways of working – from how we make things to testing and publishing.

1. Rails really suits making websites

Its popularity has a lot to do with Rails being particularly well suited to building web sites. You can make a working prototype of an idea pretty quickly, and then build out from that. It has addressed a lot of the problems you can run into on a large web project. Sudden changes in scope, new/better ideas, changes to functionality and design. It comes with lots of goodies that help you make interfaces that are pleasant to use. There’s a lot of satisfaction with making something that is, well, nice.

2. Rails is a bit of a gateway drug

Think of Rails as a gateway drug – you play around, build a few things, and get into Ruby- which is a very “that makes sense” language. Suddenly you’re onto the hard stuff and you realise that it’s going to be tricky to go back to the old way you were doing things.

It encourages you to make stuff in an Agile way, which is a Good Thing.

3. Stop developers peeing on trees

One of the little problems that we run into is getting another developer to take over a project already started by someone else. Invariably, they seem to spend their first hours/days/weeks adjusting things so that they make sense to them. Much like a cat or dog in new surrounds, a bit of pee on a few trees says you mean business.

This is usually petty stuff, like using underscores rather than dashes or renaming a few database tables. Sounds small, but this can then snowball when it then needs to be applied everywhere else. Frustrating when it wasn’t really required, but the developer felt compelled to pee.

Rails has this thing called “convention over configuration”, which avoids all the peeing. Rather than starting from scratch, there are all these conventions that make a lot of sense. Say I was making a list of these blog posts that you’re reading now. The list would be called “posts”. Each item on my list would be a “post”.

Make sense? Not “BlogPost”, “blog_item” or “myblog89-entry”. This saves time in simple ways- like once you see “post”, you can assume it belongs to “posts”.

4. Model View Controller

The Model View Controller (MVC) principle is a big part of Rails. In a nutshell it means that you break up your data and logic (the Model), what it looks like (the View), and how it interacts with the user (the Controller) into separate areas.

If you’re familiar with HTML, it’s kind of like using CSS to separate your layout and your content. At first, it might not have seemed that useful to separate layout and content, but it gives the developer an extraordinary amount of flexibility. Everything is in nice neat compartments, so you can fiddle around with your layout (the View) without breaking other stuff. Same language across all of them.

5. Active Record- database Esperanto

One of the pains with web development is Choosing Your Database. You might start off development with a simple database system. Later on you might want to upgrade for whatever reason (say more data, higher traffic). Who knew that changing between two flavours would mean subtle but critical changes to most of your code?

Active Record is like database Esperanto. You can write everything in Active Record, and it no longer matters what database you use. As always, if you want to get under the hood and write specific code for your database, you’re free to do so.

6. Ruby Gems

What you get as part of the Rails is pretty good, but it also has this tool called Ruby Gems. This allows you to download things that add to what Rails can do. You can grab a database, a tool for testing your code, or something that will add cool little graphs to your page.

7. Capistrano

Capistrano is a tool that helps you publish sites. For a simple site with just a few pages, this isn’t much of an issue- just copy the files onto the server. But as soon as your site becomes a bit more advanced, you’ll need to update several things at once. When you update, you might have changed how a few things work- which might mean an extra column to your database, deleting some images, and replacing some files. This can be a real pain to do by hand. Prone to error in fact.

Capistrano automates this process- we tell it we’d like a current version of projectX on our testing server, and it works out the rest for us. When this has tested OK, Capistrano then plonks the tested version onto the live server. It can even do stuff like roll the current live site back to yesterday’s version.

Twitter Update

Twitter have had some well publicised scaling issues, and this has been taken as evidence of scaling problems with Ruby. This isn’t as straight foward as it might sound – he’s why.

First off, Twitter deals with a fairly unusual traffic profile. Their scaling issues are sudden, massive surges in messages that need to get queued and delivered. The engineering issues they face are relatively unusual- where they’ve faced scaling problems with pretty standard/mature technologies such as MySQL and Memcache. So they’ve discovered they need to solve these issues in quite specific ways.

Second, these specific scaling issues are to do with parts of their system, such as the messaging service. There is a good discussion and great comments from the Twitter guys here

My example of Twitter might not be the best – as far as I understand they use Rails on the front, and they’ve recently switched to Scala for their back end. Perhaps better examples of popular sites using Rails are Hulu.com (a video portal by Fox & NBC Universal) and NYTimes.com. Any others you think are good examples please drop me a line :)

Multi-variate testing

Sat, 11 Oct 2008 11:18:50 GMT

Lately, we’ve been doing quite a bit of work on sites which involve multi-variate (MV) testing. It’s quite interesting, but hard to explain. In a nutshell, MV testing means testing lots of little changes or variations to a web site to see what works. Does bold orange type work better than small grey type? Should we show the price on this page or not at all?

Traditionally, to find out how you should best design and structure your site you might do some testing on a sample of users. There’s lots of ways of doing this, from giving them a set of thing to find on your site and timing this through to tracking user’s eye movements as they look at different pages. If you feel a strong, overwhelming desire to irritate, you could always set up an entry and exit survey on your site.

The weird thing about humans is that <shock horror> what they say they would do and what they actually think and do might be quite different. Coca Cola found this out with New Coke.

In his book Blink, Malcolm Gladwell writes about the mistake that Coca Cola made of basing decisions on “sip tests”, where a drinker is given only a small sample.

... although many consumers react positively to the sweeter taste of Pepsi when drinking it in small volumes, it may become unattractively sickly when drunk in quantity. Coke, on the other hand, may be more attractive for drinking in volume, precisely because it is less sweet.

So, while focus groups and testing are certainly useful and valid approaches, there are a number of reasons why something might test one way but return a very different result in real, day to day existence. In the case of a web site, you might have a myriad ideas on how to improve something. Different ideas might apply to different pages. Unfortunately there is a practical limit to the number of different experiences you might be able to ask your test subject about. Oh- unless you are Google and you have lots of pigeons.

MV testing involves running a live test on your web site. Each time a new user comes on to the site, they get assigned a set of variations. We can then measure how well a particular element or group of elements perform. This might be on one page, or it might be across every page in the site.

We might change visual things such as the colour or size of images/text. We could change the way things are described or titled. We might change navigation or page layout. Each user visiting the site gets assigned a particular set of variations, and these can get tracked against a control to see how well that performs.

The first step is to work out what we’re trying to get your user to do. For the kind of work Red Ant does, this usually involves completing a signup form or buying something. So getting users through to that is the goal.

Next is to come up with some ideas around how we might convince them to get to the goal.

Say your site sells vegetables. One way to sell your vegetables might be to list all of them on the home page. Or we might want only the best sellers. Or maybe only the cheapest. Or the ones that get most organic search traffic.

The vegetables might be listed alphabetically, or organised into groups like root vegetables. By colour might look nice. I like using lots of garlic when I cook spinach, so perhaps some kind of grouping by recipe might work well.

Depending on the number of things we’re trying to test and volume of traffic through the site, we can start to see what is working and what isn’t. We’ve been working with Accenture and their tool xOs, and that does some cool things like start to tune the site over time. So as some variations start to out perform others, more traffic starts getting directed to these variations. This usually means an even bigger lift in performance against the control site.

The MV approach isn’t suitable for all sites. It can be complicated and takes a while to set up. Tests take a while to run, and you might not get a clear winner. It’s easy to get wowed with the technology, but not actually achieve anything. Garbage in usually means garbage out.

But when everything does click into place, we’ve seen some terrific improvements in site performance. And it is certainly very interesting work to do- in terms of both design and the actual build.

Some links you might find useful:

Wikipedia – oh font of all knowledge
Marketing Experiments – a really interesting site to sign up to if you’re into this kind of thing
Avinash Kaushik’s blog – great discussions on experimentation, online marketing and such
Split tester calculator online calculator for working out test results for simple a/b
The squirrel guys – points for personality and pushiness!

Snapshot of our latest work

Fri, 12 Sep 2008 09:45:13 GMT

Here are a few of the projects that have been keeping us busy lately. I really should get around to putting them in to our portfolio, but the army of little fairies that live in our server that do all our work (well, the hard stuff anyway) have been a bit slack lately.

Beauty Heaven

Beauty Heaven is the leading independent Beauty site in Australia, and we’re thrilled to be working with them. The site has a thriving membership, who continually add content and reviews to the site. They have a really neat loyalty system, where members get points the more they participate on the site- writing reviews of products, comments, and forum postings. They review various beauty products, and have a crack team of users to that road test various things.

We’ve recently rebuilt a Salon review tool, as well as optimised the signup process and home page.

Visit Beauty Heaven

Kleenex Puppy

This is site that we’ve been working on for a while now. The product packaging has been updated, so this design reflects the “premium” positioning.

Visit the Puppy

Project 551

Each year, Japanese whaling ships travel down from Japan to the Southern Ocean whale sanctuary. This year they managed to kill 551 whales.

We made this site for the International Fund for Wildlife as part of a campaign to highlight this. You can submit a photo of yourself making a whale tail with your hands, and get it included in a big glossy book.

Visit the 551 site

American Express cards

Multivariate testing site for American Express, which is performing quite well. This is a live test, so some people get the control (old site) and some get the MVT site.

Republic of Everyone

Republic of Everyone is a small brand agency that focus on sustainability.

Visit the site

u By Kotex (also known as That Beaver)

This is a consumer site that we made for the uBy Kotex brand.

Visit the site or the alternative version for New Zealand

Yates “Get a Seed” viral campaign

Viral component to an existing site, which encourages members to invite friends in.

Check out the campaign

OAK 67

Competition site where you can win money and prizes each day as part of an on pack promotion.

Visit the site

Bushells Tea

Product site and game for Bushells Tea brand

Visit the site

we've been found out

Thu, 11 Sep 2008 12:59:44 GMT

Those cunning William Gibson fans have found us out.

Refactoring a design

Sat, 26 Apr 2008 21:07:29 GMT

We’ve recently spent some time adding some new features to a site that we built a while back. Part of this was moving it to a new CMS, and since we had the chance, we took a look at each of the templates to see where they could be improved.

I won’t bore you with all the various tweaks and changes, but one page in particular was interesting in terms of refactoring a design. The page was a product menu. It lists several product groups and the products within each. Each product menu has between two and seven groups of products.

Need to cut to the chase? Here is our original version, which we redesigned it to be faster and more useful. You can play with the new version here.

The original version

Our original version was this:

This was (in my opinion) a good example of something that “photoshops well”, but is not particularly usable in when filled with real data. This wasn’t evident until the site was live and filled with real content, and you needed to find something specific (rather than “a product”) or browse around a product area.

Each product area has a drop down list, which shows a set of product names that you select from:

This design worked well if:

you knew the exact name of what you were looking for (so you could find it in the list)
you could find the item easiest via an alphabetical ordering
once you’d selected a product, you didn’t want to jump to another
the product area blurbs were helpful for you in your search

Refactoring

It’s not that there was anything that wrong with the original layout. The design neatly fits all the required information in, plus a blurb about each of the product areas. We designed this area so someone could get to any product with a minimum number of mouse clicks- and measuring against this metric the design is successful.

However, we all thought there were a few ways that we could improve the page, and make it more useful:

we dropped the text summary to get back some space
arranged each area in a vertical list rather than a grid. Each item expands to show all the products within. Clicking on another product area collapses the first.
used thumbnails of each product as a visual aid.
increased the size of the mouse click hit area to make it easier to click on a specific product (the previous select list made it easy to choose one product too high/low if you weren’t careful with your mouse)

Here is the revised design, and you can play with it here

We thought that using thumbnails of each product might be a nice idea, but it was only when we prototyped real data such as the tools menu that we could see how useful a thumbnail would be in this instance. The tools menu lists all different types of secateurs, saws, and tree cutting devices. There is no way you could know whether the ARS Fruit Pruner 300L is the same or different to the ARS Fruit Pruner SE30 (they are different) by looking at the product names. But it is quite clear from the thumbnail that the SE45 is closer to the 300L.

Another thing that we didn’t realise during the intial design phase was how products are named. Yates often include the brand or product area as part of a name, which makes for a lot of repetitive data in each. This repetition makes it hard to scan a list and pick the difference when displayed in the way that we had it. Having thumbnails greatly help with this problem.

Avoiding the waterfall

The design process for a web site works well when iterations or design cycles are allowed/encouraged to occur. For us, this means avoiding waterfalls- where one person or team does a bit, then passes it on to the next. Tasks progress from one stage to the next in one direction- rarely going back upstream. For web sites, they often look like this:

one person makes a wireframe UI
who passes it on to another to get it signed off by the client
and then on a designer to photoshop
then on to an HTML person to cut
and then somehow squeeze it into a CMS or web app

Since someone has diligently been getting signoffs at critical points, there is little opportunity or motivation for someone towards the end to redress issues- in fact it often becomes progressively harder (“that’s already been signed off…”). You’ll end up with exactly what you asked for, but it might not be the most satisfying process or final result.

The way we try to tackle this issue is to involve everyone as early as possible, and get them operating as an autonomous team. If someone sees something that is not ideal or presenting problems with their own stage, we try and fix it (aka “repairing broken windows”) by taking it back upstream.

In this instance, the design had gone pretty much all the way through our process. But by looping back and spending some additional UI and design time, we were able to resolve other issues eg: the grid layout was difficult and taking time to maintain across different browsers, and adding in additional areas was a manual HTML/CSS task. We were also able to make significant improvements to the usefulness of the screen.

Earth Hour goes 3D!

Wed, 19 Mar 2008 15:42:46 GMT

As part of our ongoing work on Earth Hour, and to help contextualise the global nature of the 2008 event (144,000 signups and counting...), we made this 3D globe using Papervision3D. We've plotted all the sign-ups based on IP (using the Red Ant spy satellite) and a total count of sign-ups by country.

You will need Flash player 9 installed to view this demo.

We output zipped data files on a regular basis, and after the event we plan on showing how the message spread over time, so check back soon!