You are here: Home » Archives for Andy Weir

Author Archives: Andy Weir

The ever-growing desire for HTML5

Written by Andy Weir. Posted on September 26, 2011. Filed under Blog, creative technology, Innovation, mobile, production, project management. Tagged , , , , , , . 17 Comments.

html5logo

Since March of this year, on every brief that we’ve pitched for, on every project that we’ve been involved in or produced, every client has requested up front that the final solution is delivered in HTML5. This requirement stretches across a multitude of concepts including broad-reaching banner campaigns, 3d interactive websites, and global competitions. We are usually delivered a brief that includes an outline of the idea, alongside this front-loaded request for the method of delivery.

Naturally we have been intrigued as to some of the reasons for this and after speaking further with our clients they range from:

  1. We want our product to be multi-platform immediately, web and mobile are created in the same instance.
  2. We want to show off the latest technological capabilities.
  3. We don’t want to be left behind.

These are essentially very bad reasons. Reason 1 is frankly incorrect and reason’s 2 and 3 are usually agency specific reasons rather than audience driven.

We feel like there is a lot of mis-information going around about HTML5 that is leaving a lot of people preaching the medium as being more important than the idea. For example – why would a campaign to get the general public to sign up for charity donations be delivered using WebGL when only a smallish proportion of people on the internet can view it?

As mentioned, using HTML5 does not immediately mean that your website will work accross all browsers, web and mobile. It’s a falacy based upon the end goal of the developer community. Eventually we may be able to do this, but for current marketing campaigns – it’s just not going to happen. When using HTML5 or even discussing it, we mustn’t see it as an all encompassing ‘player’ such as Flash, we must look at it as a palette of functionality that works in an uneven pattern accross the landscape of modern browsers. Even for people working within the industry it’s very difficult to get an accurate picture of how web browsers support HTML5. For example the much talked about ‘Canvas’ tag which allows complex interactions within a space on the page is not supported by Internet Explorer versions 8 downwards – which serve over 31%* of the web community. Also, WebGL which has attracted a lot of attention through projects such as The Wilderness Downtown and Ro:me is only partially supported by 40%* of the web community. To put that into context, it was only a few years ago that even with Flash coverage at 85-90% we still faced a job to persuade clients that Flash was the correct technology to use. Now we seem to be disregarding the stats and just hoping for the best.

I recently found this website – HTML5test.com , which allows you to measure how much your browser supports HTML5. I did a simple test of the browsers that I had available. Most of them were pretty much the latest versions so I was quite surprised at the results. Each browser is scored on its ability to support the features and related specifications of HTML5. The maximum score available is 450:

  • Google Chrome 13 – 341
  • Mozilla Firefox 6 – 313
  • Apple Safari 5.1 – 293
  • Opera 11 – 286
  • Microsoft Internet Explorer 9 – 141
  • Apple Safari (mobile) – 210

I would suggest that outside of the development community the results are perhaps rather surprising. There is simply not one browser that can do it all. We are kidding ourselves that HTML5 is the current solution to every brief.

So what does this mean? The current HTML5 terrain is obviously full of quite a few potholes. Maybe Creative Teams should still just point us to where we are going on our journey and Creative Techs and Producers will navigate. It’s difficult not to be excited about HTML5 and all it’s capabilities, but at the early stages of a project perhaps it is better to be open minded about the method of delivery. What are we saying, how we are saying it and who are we saying it to should be the core requirements of a brief. After we’ve established that – perhaps we can work out TOGETHER the best way to deliver the message.

Having said all that – by no means are we saying that we’re not excited by HTML5 or that we don’t want to use it. We’ll be blogging shortly about all the positive things that HTML5 is adding to the web and where it has been used in the best ways.

*All stats have been taken from caniuse.com

Who are these ‘Users’ anyway?

Written by Andy Weir. Posted on September 8, 2011. Filed under Blog, production, project management. Tagged , , . 49 Comments.

There is a niggle in the back of my head. A meddling thought that comes out of no-where every so often and then disappears as quickly as it came. I’ve only just been able to crystalise and thus articlate this thought so here is my attempt at putting it to bed.

In a world of relatively new concepts like user centered design, information architecture, why is the language we use so far removed from reality?

Users, Use-Cases, Scenarios, Actions, Interactions.

If user-centered design is intended as a way of humanising and making products and services more relevant and usable for the target audience, then all of these phrases are a direct contradiction of that ethos. Who really uses these words in real life?

Over the past year we’ve been involved in quite a few big website build projects that have required a significant period of user centred design. I am not just talking about doing wireframes. Our way of working puts our ‘users’ at the heart of everything we do. We always set out our requirements gathering stage of the project by positioning them from the target audience point of view. The language of all our documentation is all based in ‘UX speak’. For example:

  1. As a user I want to log in to the website and see all my uploaded photos.
  2. As a user I would like to share my photos with my friends.
  3. As a user I would like to be able to delete old photos that I no longer wish to display.

You get the general idea. This helps us formulate a wish list of functionality, which leads through to the creation of wireframes and then these prioritized features are designed and built. Our testing period uses the above terminology to check whether we have succeeded or not in what we originally set out to do. We can place great big ticks next to each ‘User Story’. So far so good right? Well, not really.

As we go through the above process our team often have to justify the design and functionality decisions we are making.That means that these documents, conversations etc are all shared with account directors, client marketing directors, client CEOs etc. Whenever I suggest that we are basing this or that route on something that the ‘user’ might do I am met with a familiar 3 second look. Its a look that firstly questions whether they have heard me correctly, secondly tries to work out why that word is relevant within the sentence and thirdly relaxes into an uncomfortable “ok buddy, I think you mean ‘our customers’ so lets just pretend that you didn’t see me wince when you said ‘user’ to me”.

A user? A what? Are they on drugs? A user story – why is it a story? Who is telling the story? Is this jackanory?.

‘User’ is the word user that I am most ill-at-ease with. It is jargon of its worst kind and I grimace everytime I say it. I will maybe say it 20 times a day and just assume that it means the same to me as it does to others. But it doesn’t. To others it reinforces the idea that people are almost programmed to do what we think they will do. The phrase de-humanizes our audience so much that we creep into habits of making huge presumptions on what they do and how they will do it. The phrase tempts us to be lazy, it tricks us into grouping a multitude of different personalities into one homogenous meld of a human/user. A (huser maybe?).

So what’s the solution? I don’t have one that I am completely convinced by.

One method of humaizing our user’s in this world is to give them typical personalities. These can exist as pen portraits.

‘Suzy is 23 years old and has left university where she studied bio-chemistry. She is a fitness fanatic and is a member of a local running club. She is on Facebook and has 262 friends although she would say that only 20 of them are real friends.’

The idea being that in your test scripts you can relate your ‘characters’ to the journey’s that you set up.

  1. Suzy recieves an email and is asked to ‘Sign up to join the party’.
  2. Suzy clicks on the link and is taken to www.jointheparty.com.
  3. Suzy now needs to register her details.

I think it’s probably a good thing for the development team to think about the various personalities the product may encounter – but for the wider team? I think the response might be ‘Who the **** is Suzy?’

So has anyone got any bright ideas? Should we just translate this ad-land speak into simple laymens terms?

Users, Use-Cases, Scenarios, Actions, Interactions.

could translate to…

People, Things that might happen to these people, What someone has done, Stuff you need to do, Stuff you do and you get something back.

It doesn’t quite work does it? It just all sounds a bit rubbish – without any sort of knowledge behind the words.
So anyway – I’m looking for answers so if you have any please follow these user stories:

Scenario:

  • User is on blog url http://weirandwong.com/blog/whoareusers/.
  • User has read blog post.
  • User has urge to comment on blog post.

User Actions:

  • User  types enlightening and helpful comment in box entitled ‘Post a comment’
  • User fills in Captcha form
  • User presses ‘Post Comment’

Admin Actions:

  • Admin reads user comment
  • Admin finds comment useful
  • ‘Admin’ becomes ‘Andy’ from henceforth
  • ‘Users’ becomes ‘Dudes’ from henceforth

Test complete. Maybe.

 

Poverty Over – A Case Study, Part 4 – Delivering

Written by Andy Weir. Posted on March 28, 2011. Filed under production, project management, work. Tagged , , , , , , . 46 Comments.
In the final phase of this Poverty Over Infographic Case Study, not only were we delivering the actual flash interactive infographic, but we were finishing off the rest of the website build as well. I’ve not mentioned it up until now but all this work was going on simultaneously to the infographic.
The website involved creating templated pages for 8 factors that often surround countries in poverty. Each page has a case study and eventually will have content created by The Guardian newspaper. We created a simple templated system that allows Christian Aid to update this content in their own time – without an expensive CMS behind it.

As well as the website build we created the 8 specific animations for each factor that usually surrounds poverty.
An example of which is here:
In reality the website and animation delivery went very smoothly – credit to our designer, developer and animator!
So, we had delivered the site in its final connected up state. The infographic was in place and most content was now sitting on the website. Naturally this was the first time that the client had seen everything in context of each other. We entered a period of tweaks, minor functionality and design improvements.
In the background we were rigorously functionality testing, system and browser testing. It is important though that at this stage of the project we look all the way back to the original goals of the communication and ask ourselves whether we’ve achieved what we set out to do?

It was our job to display and highlight the following key parts of the story:

1. The world has, on the most part, moved out of poverty especially over the last 60 years.
2. There are however vast parts of Africa and Asia that still have a a way to go.
3. Countries that have been extremely poor before have come out of poverty.
4. With further investment, development and aid – it is possible to move the countries remaining in poverty into prosperity.

So have we achieved what we set out to do? Well, early indications are that sharing of the site through Twitter and Facebook is going through the roof – which is nice to hear. However, in the spirit of continuous improvement – let us know what you think. Does it work? What could we have done better? We’ll take your comments on board and hopefully bear them in mind on our next interactive infographic!

Poverty Over – A Case Study, Part 3 – Building

Written by Andy Weir. Posted on March 22, 2011. Filed under Blog, production, project management, Review, work. Tagged , , , , , , , . 37 Comments.

In my previous post I talked about entering the build stage of our project without a complete plan over what the final infographic was going to look like or how it was going to behave. That might sound foolhardy and naive to some, but for W+W we start each project knowing that a voyage of creative and technical discovery awaits. With a project as intricate and as complex as this – uncertainty in initial planning actually serves the creative process better. It allows us to make discoveries and react to them based on creating working prototypes and versions, rather than second guessing the outcome of a myriad of variables.

At the start of this stage – the client was happy with where we were – but were naturally concerned that nothing looked very ‘Christian Aid’ yet. And for good reason too. We had purposefully left the style guides on a shelf gathering dust. It was time though to start tying together our initial ‘look and feel’ designs with the actual graphic style of the Poverty Over campaign.

For the build of this Infographic – we worked in weekly sprints. Each week I presented the development work to both the Agency and the Client at the same time. Credit to Tyrone at BMB who allowed this to happen and massive credit as well to Tom, the Christian Aid Marketing Director who entered into this agile spirit of things with much enthusiasm.

What did this weekly review mean? So what if there was one? You might be asking these questions….

Well -it meant that each week we would review our progress and look at our accomplishments. Where the infographic was working, where it wasn’t, why it wasn’t. Each week I would take the team feedback and then reprioritise the tasks and features that we would work on in the next sprint. I didn’t use the words Agile much and I didn’t force the idea that this was a revolutionary way of working. It was simply a weekly review of where we were at, albeit presented to the entire team as one and with a clear agenda.

In the background myself and the team were constantly working out which were the most important areas to focus on and in what order to do it in. The entire creative process felt fairly organic – but was underpinned with structure and good organisation.

As the sprints rolled past we rolled through the following features in this prioritised order:

1. Creating a palette and look and feel that a) allowed the user to read the data in the clearest way and b) was on brand for christian Aid.
2. Working out what to do with data anomalies – what happens when a country is missing data for a few years?
3. Working out what to do with countries that had changed borders, names, had been split up or merged? I can tell you a lot about history now that I didn’t know before this project!
4. How much tilt and ’3Dness’ is needed? Does the user need to spin the map a full 360 degrees?
5. How do we display contextual information? This ended up being the timeline pop ups that display key dates.
6. Do we show the future? Can we predict it? What is Christian Aid asking the user to do?
7. How else can I filter the map? We built around double the amount of filters that currently exist on the site. In the end we decided that some were simply too complex for the user to get their heads around. Sometimes less is more!
8. Allow the user to zoom in and study the detail closer.
9. Allow the user to move the map around the page.
10 How to represent scale? (One of the lessons we learned from our research is that a map must always have a scale)
11. Create an intro movie that introduces the concept
12. Create an intro movie that mimics the data and displays the correct poverty levels

There were of course many other themes and features that we worked through each week. The reality was that we were always focusing on the most important or most risky issues. As weeks went by – so many answers kept falling into place, not by design, but by discovery and by a repetitive and sensible approach to experimentation.

In the next and final instalment of this case study I will talk about our final delivery of the Infographic and all of the other elements of the website that supported it.

Poverty Over – A Case Study, Part 2 – Designing

Written by Andy Weir. Posted on March 22, 2011. Filed under Blog, production, project management, Review, work. Tagged , , , , , , , . 35 Comments.

Our Design stage for Poverty Over was a lot of fun. And fast!

We set out to explore the Look and feel of the infographic and how, in principle, it was going to work. However, it was not our intention to have all of the UI, buttons and micro detail of the infographic nailed down at the end of this stage. We intended to find a visual style, find the limits of the tech, marry the 2 together, and finish by writing a list of functionality that we could start building in the next phase.

Our Design stage was to be filled with rapid prototyping, with all members of the team around the same table. No distractions, focused on the questions we had posed from the ‘Think’ stage (How was it going to look? How would we represent the data? How far could we push the tech?).

We worked fast and without any design limitations. Corporate styleguides and other confining restrictions were ignored. Our designer, creative technologist and 3D animator worked closely together in these early stages and we experimented with colour palettes, finding the right sort of map and then the way we displayed the data.

We realised that the data worked best as a graphic device when it was displayed with differing heights of the country land levels. Poor nations were below sea level, developing countries above sea level. It felt like a nice metaphor for comparing growth and decline. We also realised that in order to show comparative data levels for all countries then all countries needed to be on display all of the time. Unfortunately this meant that an interactive spherical globe was not as effective as the flat map. We subsequently decided to use the globe concept in the intro sequence, which sets up the communcation and introduces the themes of poverty and change.

Here are some screen grabs of our various prototypes:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

We spent 6 days prototyping and at the end we had come to the conclusion that technically we couldn’t use 3d models that were output from a 3d programme. In the end we decided to use the flash 3d API and some custom code to extrude the world map and draw it in 3d.

We had also been trying to add a light source, shadows and textures to the map surface. However this was causing the infographic to seriously slow down in how it rendered and moved on screen. We weighed this up and decided that the user’s ability to interact with the data was more important than adding texture effects. We knew we could make the map look great with flat colour as well. We’d just have to work within these boundaries!

So after a prototyping stage of around 7 working days we knew the method of displaying the data, the view of the map we wanted, how we were going to do it and how far we could push the tech. We also had a completely off brand colour palette and were still unsure of what else we could do with the data! At the moment we had a very straight-forward play through of the history of the world. The next challenge was to contextualise it. Why did Australia jump into huge wealth in the 1850s, what was causing Venezuela to buck the Great Depression and leap forward in the 1930s? For the data to start telling a story, we had more work to do.

We knew we couldn’t actually plan all of this stuff up front – we just didn’t know how the data was going to look at that point. We also didn’t know how many filters we should have – how many could we add before it would start to be confusing and detract from the central message? And what was the point of them?

So, we launched into our build stage, with a plan… but only a plan for the most high value and high risk elements that we planned to tackle in the next week or so. Fortunately our way of working allowed us to do this and we knew that making too many guesses at this stage would be a waste of time.

Read more about how we faced these challenges in part 3 of this case study – coming soon!

 

Poverty Over – A Case Study, Part 1 – Thinking

Written by Andy Weir. Posted on March 17, 2011. Filed under Blog, production, project management, work. Tagged , , , , , , , , , , , . 200 Comments.

Yesterday we launched povertyover.christianaid.org.uk. It was a fantastic, yet challenging project to work on and over the next few days I’ll be describing the craft of producing this interactive infographic. I say craft because I truly believe that is what we do. We take an idea, whittle it, shape it and fashion it into something that makes sense in the digital arena. Something that the target audience will take meaning from and hopefully – share it with their friends – which was the goal of this website.

When BMB approached us with this brief we were extremely excited to be involved. Robin and I follow a lot of infographic blogs and from the outset we were enthusiastically researching these and looking for great examples of map based infographics. The thought of being paid to create infographics that moved and reacted to data, time and various other filters was very appetising.

From the outset, the data we were to display was clearly defined. For each of the existing 285 countries of the world, a statistician had put together a 500 year history (where possible) of their relative poverty or wealth. Read more here for how these figures were calculated. We were supplied a figure from between 0.1 and 1.0 for each country for every year. It was our job to make this look beautiful, allow people to explore the data in an interesting way and highlight the following key parts of the story:

1. The world has, on the most part, moved out of poverty especially over the last 60 years.
2. There are however vast parts of Africa and Asia that still have a a way to go.
3. Countries that have been extremely poor before they’ve come out of poverty.
4. With further investment, development and aid – it is possible to move the countries remaining in poverty into prosperity.

Initially we looked at many influences and considered lots of different directions for how we were going to start representing the data. We loved Aaron Koblin’s work (Robin blogged about his show at the V&A last year here) and whilst we respect what he does, we quickly realised that we needed to be extremely graphic in our communication style – which was probably quite far removed from Koblin’s work . There were quite a few variables in our brief; wealth, poverty, maps and time. We needed to be single minded in our approach to how this was represented. Here are some of the approaches and influences we looked at:

 

 

 

 

 

 

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Carl and Simon – the most excellent creative team at BMB had also researched many different types of maps (this is a whole cartographic language on it’s own). They provided us with some great books like this one.  We were able to find inspiration from many examples here – but also it started reinforcing lots of map do’s and don’ts!

Initially Carl and Simon were extremely keen to represent the data as a globe that the user could spin around themselves. We knew that until we actually started experimenting with the data and the visuals that we just couldn’t be so conceptually ‘nailed down’ just yet. To their (and the BMB producer Tyrone’s) credit they allowed us to be pretty non-specific with how we were going to display the map at this stage. We entered our prototyping phase with gusto, knowing that the team were in for some serious experimentation!

Any period of prototyping needs to have some clear questions to answer. We had three:

a) What was the infographic world going to look like? Was it to be a globe, a flat map, a 3/4 view?
b) How would we represent the changing HDI value? By colour? By the size of countries? By height or behaviour?
c) How far could we push the tech spec? A world map, with all of the country borders etc has hundreds of edges. If we are doing something in 3D how was Flash going to handle all of the interpretation of the data on the fly and then rendering it as 3d values. Should we use Papervision? Away 3D? Should we use 3D models from 3DStudio Max? What could we get away with before it fell over?

We finished our ‘Think’ stage of the project knowing that we had only planned the project in terms of the objectives and the potential of the raw data. Now… looking at the project from outside eyes, this might sound a bit irresponsible and lacking in “traditional” planning techniques, after all it might appear that we had simply created a list of questions based around look and feel, style and technical possibilities. We felt though that we had now fleshed out exactly what the website needed to communicate and we were now in an extremely good place – our Design stage was ready to go.

In my next blog post I will describe how we prototyped and started working out a visual style for the infographic.

 

Poverty Over – An Interactive Infographic

Written by Andy Weir. Posted on March 15, 2011. Filed under Blog, production, work. Tagged , , , , , , , , , , , , . 39 Comments.

Poverty Over

I’m really pleased to announce our latest work, in collaboration with BMB in London and for Christian Aid – check out povertyover.christianaid.org.uk.

In the coming days we’ll be blogging more about how we took this idea from scamp stage – right through to the finished product, to give you more of an insight into how we work. But now… back to the work.

The aim of the website is to show a history of poverty, illustrating that over the last two hundred years many countries have come out of poverty and have entered prosperous periods of development. Hopefully by showing that many countries can leave poverty behind, it will inspire you to invest in and develop the world’s remaining poor countries.

For WEIR+WONG – the challenge has been to visually interpret what was in effect a spreadsheet with 500 years worth of data for 285 countries. Our team of designers, developers and animators have come up with something which is genuinely compelling to look at, showing us a history of the world’s poverty and allowing us to delve deeper into the information.

In recent years there has been an explosion of Infographics on the web. Some of it looks amazing and communicates its data really well. However, there is so much of  it that looks great but is difficult to understand. The message muddled by the medium perhaps. I guess the most striking fact is that most of it is just really static. There are so many Jpegs or PDFs that warrant a first look but nothing more. We were really keen to be involved in an Infographic that was pretty, easy to understand as well as interactive.

We really enjoyed working on this project and hope that you enjoy looking at it too! The development process was extremely challenging and involved lots of collaboration from technologists, animators and developers in order to achieve this result. If you’d like to find out more, we’ll be releasing a series of case studies looking at each part of the project over the coming days, we hope you enjoy this, and we hope it encourages you to get involved to help bring poverty to an end.

Dedication. The only way to work.

Written by Andy Weir. Posted on February 15, 2011. Filed under about us, Blog, Future gazing, production, project management, work. Tagged , , , , , , , , . 19 Comments.

We’ve got lots of pretty big projects on at the moment, all quite varied and all for very different types of clients. We’re hoping to be able to share some of the stuff we’re doing very soon on this website, so stay tuned kids. Exciting times for WEIR+WONG! In the meantime, I have a fantastic and revealing insight into the way we are are working. I guess that nobody has ever thought about this before, let alone implemented it, so please hold on to your hats. Ladies and Gentlemen I give you……… dedicated resource. Tada. Booooooooooooooooom. I thank you.

At WEIR+WONG we have been working with some fantastic designers and developers. These guys are simply the best in the business. They uber-rock. We have allowed them to rock harder by simply giving them one job to do on a day by day basis. No daily interruptions so they can just have a quick think about ‘this other project’ or upload some changes for something they didn’t do in the first place. Robin and I are producers that like to protect our team from interruption, and dis-information.

Why is this a revelation? Because we know that from speaking to and working with other agencies resourcing is a nightmare usually based around booking up 1 hour slots. An unmanageable task for the poor resource manager and a false economy anyway. The way forward is one job, one day per any one person.

How do we do it? It’s quite simple really:

  1. We book resource per job and not based on a bunch of time that can be used up on a multitude of different projects.
  2. A morning scrum. What did we do yesterday, What are we doing today, What’s stopping me do it?
  3. An open channel of communication throughout the day with the rest of the team. Don’t go to the producer if you need a design asset. Speak to the designer. Remember that building complex stuff should always be a conversation between creatives and techies. If it isn’t then something is wrong.
  4. Limited interruptions from producers. Save them up for the next Scrum.
  5. A prioritised list of functionality and features. If you finish something early, get working on the next bit and don’t ask anyone for permission.

So what benefits have we seen. Lots. We can’t think of any negatives either.

  1. Creative people have the head space to think laterally and focus on the proposition and user experience. We don’t really care when, where or how they arrive at the solution. In fact we trust them to arrive at the solution, and we seem to be finding better solutions faster these days.
  2. Technicians and developers can get themselves in the ‘coding zone’ without interruption. We’re being delivered better, more robust code that is tested and clearly has had more love given to it.
  3. Client and agency feedback is turned around much quicker. We can react quicker to change and produce more robust and thought out solutions.
  4. People like working with us. Their day is less stressful.
  5. We like working like this. Our day is less stressful.

But I guess that everyone knows this already. It’s pretty obvious that dedicated workers can only be a positive thing. So what gives with my sarcastic take that this is a new insight. Well, if you aren’t doing it yet it is a new insight. And most agencies and production companies aren’t.

This can change. Believe.

Lovely people, saying nice things.

Written by Andy Weir. Posted on November 30, 2010. Filed under Blog, Enjoying life. 14 Comments.

Client love
We asked our clients to write about their experience of working with us, and we’ve been really pleased to receive some very flattering feedback!

We’d like to take the opportunity now to say that it’s been an absolute pleasure working with you all in our first year, and we look forward to more opportunities to collaborate in the future.

But enough waffle from us, please have a look at what our clients are saying about us…