This is the first entry in a semi-regular series sharing things that we’ve been looking at and reading recently …

Sarah (one of our project managers)

• Broadband becomes a legal right in Finland

• Guggenheim collaborates with YouTube and invites video submissions

Sue (one of our designers, recently returned from a break in the sunny northern hemisphere)

• Eye-candy and inspiration on www.citid.net

• Great experimental fonts (also: free!)

• Lighten up your winter blues: heaps of colour and shapes on Coolhunter

Alastair (one of our developers)

• Firefox 4 introduces more HTML 5 and CSS functionality. One step further towards the death of Flash? Still in beta so one for the developers.

• Excellent! Wayne and Garth spotted in the UK. Party on!

Rachel (our office manager)

• Artist creates masterpiece on an iPad

• World Cup 2010 statistics: all the key data for each team, from the Guardian

(Rachel notes that she’s not as much of a sports fiend as the above link might suggest, and also recommends data/infographic blog Cool Infographics)

Jake (who looks after our usability testing tool IntuitionHQ)

• David Gillis on Fusing Content Strategy with Design, in UX Magazine

• The Real Life Social Network, slides from a presentation by Paul Adams, Senior User Experience Researcher at Google

• Gnarcade – Video Game Invasion: for video game fans, and geeks in general

Courtney (that’s me – project manager)

• Aaron Straup Cope’s magical slippy map showing the world as revealed by geo-tagged photos on Flickr

• Significant Objects, an investigation of art and the market through short stories and eBay

• Swallows and Amazons, the current exhibition at Robert Heald Gallery, which is close to our office – on show until 31 July.

Last week I was lucky enough to go along to Foo Camp in Sebastopol, California. ‘Foo’ stands for ‘Friends of O’Reilly’, and Foo Camp is a yearly gathering of about 250 people (largely from the web and technology fields) at the O’Reilly Media headquarters. Run unconference-style, the weekend is a chance for people and ideas to mix and mingle, in hopes of producing those magical moments of realisation and inspiration.

Foo Camp is also a terrific chance to see a whole bunch of alpha geeks in their natural environment. And one of the most interesting trends evident at the event – as Linda Stone noted – was that laptops seemed to have disappeared in favour of iPads and smartphones.

What was interesting about this, for me, was the different tone an iPad brings to a group interaction. In meetings or gatherings, laptops form walls between people. Keys clack away noisily. Whatever the person behind the laptop is doing – work or play – is hidden and solitary. In this sense, the laptop is something of a dis-connecting tool.

In contrast, the way I saw people using the iPad was more like a menu or a map or a comic – something to be freely passed around, used by a couple of people at once. iPhones are similar, but they’re still more like sharing around a work tool – a practical act. The iPad doesn’t strike me as a work tool at all. When people use it, they seem either relaxed or immersed; if the laptop is a wall, then the iPad is a pool – something to dive down into. Or as Matt Jones observes, a magic table. Writing about the experience of playing Marble Mixer on the iPad, he notes that it’s a ‘simple game, well-executed’, which ‘sings’ when your friends join in:

Beautiful. Simple. But also – amazing and transformative!

We’re all playing with a magic surface!

When we’re not concentrating on our marbles, we’re looking each other in the eye – chuckling, tutting and cursing our aim – and each other.

There’s no screen between us, there’s a magic table making us laugh. …

It shows that the iPad can be a media surface to share, rather than a proscenium to consume through alone.

When I talked about the laptop phenomenon with Rowan Simpson, he mentioned a blog post he’d written a few years back about the Amish approach to technology, based on this 1999 Wired article by Howard Rheingold. As Rheingold writes:

Amish settlements have become a cliché for refusing technology. Tens of thousands of people wear identical, plain, homemade clothing, cultivate their rich fields with horse-drawn machinery, and live in houses lacking that basic modern spirit called electricity. But the Amish do use such 20th-century consumer technologies as disposable diapers, in-line skates, and gas barbecue grills. Some might call this combination paradoxical, even contradictory. But it could also be called sophisticated, because the Amish have an elaborate system by which they evaluate the tools they use; their tentative, at times reluctant use of technology is more complex than a simple rejection or a whole-hearted embrace. What if modern Americans could possibly agree upon criteria for acceptance, as the Amish have? Might we find better ways to wield technological power, other than simply unleashing it and seeing what happens? What can we learn from a culture that habitually negotiates the rules for new tools?

When choosing whether to adopt new technology, the Amish ask: will it bring us together, or draw us apart? When someone sits down in a group and flips open a laptop, it immediately disconnects them.  At Foo Camp, the absence of laptops seemed to bring people together. At the same time, people using iPads seemed no less connected to what was going on – logically – than people using pen and paper.

Am I – once something of a doubting Thomas – now a convert? No. I still don’t think I need an iPad, unless my future holds a lot of travelling that I don’t currently know about. But I am really excited to see how iPads get used in places like classrooms and museums, and how we all exploit their ability to draw people together.

Cross-browser compatibility issues are the bane of web developers world-wide and in this ever shifting landscape it is important to have processes that integrate cross-browser testing in a robust and systematic way. Over the last 9 years we have evolved a robust workflow for web development and cross-browser testing is an integral part of this.

An overview of the process

We start by constructing the HTML/CSS in a text editor (Textmate, RubyMine IDE or Aptana IDE) and viewing it in Firefox. We develop standards compliant HTML/CSS, so Firefox is a great starting point as it supports the CSS standards well and enables us to use a number of key tools including Pixel Perfect, YSlow and the Web Developer toolbar.

Once we are happy that the design is accurately implemented in Firefox we use Litmus to create screenshots across a selection of Browser/Operating System combinations. Litmus has a number of great features that really make this process easy. Firstly, you can retest the page with a simple button click and Litmus keeps track of the revisions, secondly Litmus uses the W3C validators to check that the HTML and CSS validate and links trough to the error pages and thirdly Litmus lets us indicate visually whether a particular combination is rendering correctly so we can keep track of what is complete and what remains.

Running the initial test in Litmus will usually through up a number of issues, especially in IE6 (suprise!). At this stage we move on to the target Browser/Operating system to correct the issues. More often than not this is a process of finding work-arounds for the poor standards support in IE6 and IE7 while still ensuring the the HTML/CSS validates and is semantically correct.

We iterate through the testing in Litmus and fixing problems on the target platform until we are happy that the design is working correctly across all platforms. We then use the publish option in Litmus to create  publicly accessible version of the test to send through to our client. This enables our clients to be certain the design is rendering correctly across platforms. You can see an example test here: http://boost.litmusapp.com/pub/5125956

From here the HTML/CSS gets passed to a developer who integrates the HTML with the web application or content management system. This is where the utility of Litmus really shines. During this phase we use Litmus in the same way as we use Unit tests in our programming, to confirm that nothing is broken as we add features and develop the site. This is the key to consistent and successful projects, constant and consistent testing during the life-cycle of development.

Using Litmus

The first step is entering the URL to test and choosing the Browser/Operating Systems. Once you have made your choice you can set this to be the default for further tests.

Litmus: starting the test

The second step is viewing the results. The overview screen gives an estimate of how long all tests will take to complete and the page updates as the tests complete. On the left side it shows the results of the HTML and CSS validation.

Litmus: Test overview screen

The third step is to check each of the individual results. At this stage we usually mark the ones that are passing and the ones that are failing to keep track of progress.

Below is a page that is not rendering correctly, and we mark this as incompatible.

Litmus: Example of a failing page

Below is a page that is rendering correctly, and we mark this as compatible.

Litmus: Example of a passing page

The final step is to publish the test and send the URL to the client, you can view the test here: http://boost.litmusapp.com/pub/5125956

Here at Boost we lovingly handcraft our HTML and CSS when implementing our designs. We use text editors rather than programs like Dreamweaver or Frontpage. We find it’s faster, and it enables us to produce clean, correct code that’s easy to integrate.

Our process starts with the production of the designs in either Photoshop or Fireworks. Once these are approved by our client, we convert them to HTML/CSS templates before integrating them with the web application or content management system.

At the HTML/CSS stage we use two tools to ensure the design is being accurately implemented: Pixel Perfect and Litmus. Today I’ll focus on Pixel Perfect - I’ll talk about Litmus another time.

What is Pixel Perfect?

Pixel Perfect is a Firefox/Firebug extension that allows web developers and designers to easily overlay a web composition on top of the developed HTML. Pixel Perfect is built on top of Firebug (another Firefox extension), so you will need to have Firebug installed and active to use Pixel Perfect.

The video below is a quick look at how Pixel Perfect is used.

Why Pixel Perfect?

We strive to ensure that the integrity of the design is kept as it is implemented.

Because of the way different that browser and operating systems render HTML text, it is practically impossible to get sites rendering identically across all browsers and operating systems that we support. Using tools like Pixel Perfect helps us to make the differences all but imperceptible.

With considerable effort going into our design at Boost, it is important that this is reflected in the final product. While a small gap here and a slightly different text size there seem like small issues in the rough and tumble of building a site, they all add up. What was once a tight, balanced and considered solution to a design problem can turn out as ramshackle, unpolished and unprofessional.

Before we found Pixel Perfect we tried a number of different tools including Afloat, which makes the OS X Preview application partially transparent, but this approach was less flexible and didn’t work as well.

What are the benefits of using Pixel Perfect?

Using Pixel Perfect in our HTML/CSS production workflow provides a number of tangible benefits, including:

• reduced time and cost during the quality assurance process
• increased speed of development of the HTML/CSS
• creating closer working relationships between designers and developers
• a better looking website of which we can all be proud.

Run, don’t walk, to get Pixel Perfect today

Grab your copy, for free, from: http://www.pixelperfectplugin.com/

And don’t forget to give a donation if you want to see this great plugin grow and flourish.

It seems that week on week Google introduces new tools without fanfare and it’s easy for these to slip by unnoticed. A year or so ago Google Web Optimizer appeared in the Adwords toolbar. There hadn’t been much of a buzz about it appearing but who could ignore a link that promised to ‘optimize’ your website, and from Google no less.

Taking a closer look at Google Web Optimizer it was clear this is a very useful tool in the web designers toolkit. In a nutshell it allows developers and designers to test variations of design, copy or even whole pages.

Google Web Optimizer enables you to set up tests to determine which copy, design or combination of both is best going to meet your conversion goals.

Setting up and running a test is easy, with Google Web Optimizer taking you through it step by step. You will need a Google Adwords account to access Google Web Optimizer, this is free and there is no need to be running an Adwords campaign. When you login to Google Adwords you will see the Web Optimizer link under Campaign Management in the toolbar.

Website Optimizer is under Campaign Management in your Google Adwords account.

There are two choices when setting up tests, AB testing which enables you to test two seperate versions of a page, and multivariate testing which enables testing of changes to multiple areas of a page with multiple variations. Both of these are extremely useful, though the amount of traffic a site receives determines how useful the multivariate testing can be.

The two options are nicely explained when you are starting your experiment.

Once your test has started you can login to Google Web Optimizer at any time and review progress. It is important to note that with the multivariate testing the number of areas and number of variations for each increases the number of variations and consequently the number of visits needed to get a conclusive result. Google suggest only using multivariate tests if your page gets more than 1000 visits per week. Our experience suggests that it is useful to have a great deal more than that!

Results can be viewed while the experiment is running.

Google Web Optimizer is designed for testing copy and design in order to improve conversion rates. We have used it to fine tune the copy on our homepage to increase the number of visitors visiting our portfolio pages.

When redesigning an interactive tool for a client it was not clear the exact text we should use for the call to action. We suggested that once we had the site live we could run a Google Web Optimizer test to see if small changes to the text could improve the conversion rate. We tested two new variations of the call to action in two seperate places. This provides nine combinations (including the originals).

We ran the test for two weeks and then analysed the results. It was clear that a number of combinations were doing worse than the original while a couple of combinations were doing better. At this stage we did not have enough data to conclusively decide which was working the best. We turned off the under performing combinations so that we could more quickly see which combination was working the best.

Variations that aren't performing can be stopped sending more traffic to the remaining variations.

With the best of the new combinations currently showing a 10% increase in conversion performance it won’t be long before we have a clear winner. The total time to setup the test was around 4 hours.

Google Web Optimizer is quick and easy to setup, delivers useful data with a minimum of fuss. Optimizer is an essential tool in improving conversion for any website and who doesn’t need that?