Experiment 2 – Process (Development Pt. 2.1)

Ok, so I couldn’t wait to get started on my next planned phase of development: the animated mockup.

If you are unable to build a digital project, or if there’s a project you’re creating that could realistically be produced and you are only the designer pitching the proof of concept to a financial backer or development team/freelancer, it is a good idea to show how your proposed product will work in the real world.

However, you may not have the technical skills required to build a prototype. So why not create an animated short using the interface or designs you have created to tell the story of how your product will work? All you need is your designs in an appropriate format and some basic AfterEffects skills.

I am going to do just this, but before I can even get to the planning stage, I need to realise more of the design, in particular; the wheel of fortune weather display!

This post is dedicated to the development of this asset:

1) Appropriate format

It’s important that this interface remains as crisp and clear as possible. I admit it’s not going to win any legibility awards in its current state but that’s not what this project is all about.

I can however, try my best not to make matters worse by using a visual graphics format that will yield blurry results, hence my decision to use vectors!

The screen mockups produced in Photoshop are fine but they’re bitmap based and although were designed at the correct screen resolution for an iPhone 4 (320 x 480), they were in fact created at 72dpi so they actually look blurry already when displayed as an image on the iPhone.

Therefore, I am going to have to create the whole interface again from scratch using vectors.

Sadly viewers, I have a bit of an admission to make here. I can not use Illustrator properly. I use it all the time, but mostly for printing vector artwork I’ve created elsewhere. And that ‘elsewhere’ is… and there’s no other way of saying this… Flash! I just prefer its organic way of creating shapes and paths. You have to remember, I am not a trained graphic designer, I am a developer that happens to try his hand at design from time-to-time and as such, I was trained to use Flash and have stuck with it ever since.

2) Creating the Template

The next task is to create the template that will hold all the different weather conditions for the 24 hour period. Obviously this is stretching what can be done with Met Office’s DataPoint API because that only yields 3-hourly weather reports, but, because other weather apps tell the story hourly, there’s no reason why my app can’t.

My design requires a disc that can fit 24, individual hourly reports within it:

A quick reminder of how the “disc” should look.

So the first thing I had to do was work out the diameter of the disc. This isn’t as easy as you may think! Firstly, you have to consider the amount of iterations of information (in this case: 24). Then you have to work out how much space you have to allow between their rotational increments (in this case: 15º because 360 / 24 = 15).

Whilst there might be a mathematical formula based on the width of the asset and the amount of increments, I decided it would be quicker (for me) to just take a stab at a diameter based on the visual clues provided by my interface mockups. I chose 1000px and wasn’t far off because when I had created my information holders (3 for each of the 3 circular windows in the design – see image below), grouped them, set their rotation origin to the centre of the 1000px circle (500px, 500px) I saw there was a little bit of overlap on the main (top) circular window.

It wasn’t too much but because of the harsh transition of day to night, it needed expanding so I set the diameter to 1200px and tried again. Second time lucky as you can see below:

Screen Shot 2013-05-25 at 10.53.14
The development of the disc meant that a more accurate, and measured approach was taken to ensure all data could fit into the space that was worked out.

Here it is evident that 24 pieces of data can exist on a disc without hardly any overlap, and 1200px is as large as I wanted any asset really. Hopefully by now you can appreciate how this app might actually work. It should become even more evident when I create the final disc with the correct symbols and values for a typical day. In fact, I plan to create a summer disc and a winter version to demonstrate the differences in colour, symbol, and an opportunity to display the 2 warnings the app could offer of high UV (summer) and harsh “feels like” temperatures (winter).

One thing to note, I did check the space allocated to temperature to support 3 digits for double figure negative values and triple figure positive values. Always consider the space required for information when dealing with dynamically generated content.

Before any of that however, I needed to decide on a colour pallet to represent temperature & wind speed.

3) Creating Colour Scales

It’s not just a case of creating a nice colour pallet. There’s science behind the information on display here. Added to this the conventional way we are used to seeing, temperature at least, displayed on the weather broadcast on television and now delivered on web pages and apps.

Therefore I put my “developer” hat back on and started logically combining colours from convention with a little maths to keep things accurate.


I started with scale. This app is designed to be used in the UK where the weather rarely exceeds 35ºc and hardly ever drops below -20ºc. Therefore I decided my minimum temperature would be -20 and my highest 40 giving a total range of 60. True, these temperatures can be exceeded, and, thinking ahead to make this work for the rest of the world I should consider what to do in these cases. The answer is simple. Just use the highest and lowest colour for numbers that exceed the scale. Their colours will be enough of a visual clue to indicate these extremes and don’t forget, these colours are secondary information as the numerical value is the key feature of this information.

I then roughed out a sample colour scheme of this using colours that would compliment the visual style created so far:


That was simple enough. Now to get a little more accurate.

Using the Gradient Editor (below) I was able to align the colour values I needed at specific locations. For example, for 0ºc I wanted to use the cold looking green colour. Based on a range of -20 to 40 that put’s the location along the gradient at roughly 33% and that’s where it was:

The Gradient editor in Photoshop CS6.

I checked all the other key values too and they aligned quite nicely. I saved the gradient (as it’s bound to be useful again in the future) and applied it to my 240px wide test document, I now had a smooth gradient but there isn’t really any definition to the colours I required at the 60 steps:


In order to obtain 60 values there are two possible approaches to take.

Firstly, I could re-size the document to 60 pixels wide and grab the colour value for each pixel horizontally – which could be tricky. Or secondly, I could save the file as a PNG8 with 60 colour values. I chose the latter and I am finally left with this “banded” gradient of 60 colours ranging from coldest to hottest:


In the end I realised that colour-picking from a file like this was going to be a little inaccurate so what I’m going to do instead is use the Gradient Tool to accurately determine a percentage location based on a value. Eventually, if this project ever goes into production, I will create a colour chart, but until then, I now have my colours for temperature.

There was one slight problem with the gradient however. 0ºc wasn’t blue like we see on the weather. In fact, it’s quite a mid-green and that was no good. So I amended the gradient slightly to ensure that 0 was blue:


I then realised that I couldn’t actually use the percentage sliders of the gradient to accurate colours for certain percentages (after being converted from temperature values from the range). So I created a quick colour pallet for all 60 shades of hue from the range:

Colour pallet for the temperature range.

This allows me to quickly use the colour picker tool to colour correctly the temperatures of the discs.


Because I am intending to create a new, secondary method of displaying wind-speed, I can be a little less accurate as I won’t be breaking convention.

The plan is to create a greyscale gradient that starts with a mid-to-dark grey for the lowest wind-speeds and go all the way up to black for the highest.

After some research I found that in the UK (Shetlands mostly), the wind speed can exceed 170mph so triple digits are required! I decided to cap the colour change at 60 because it is very rare to get sustained wind above this and it is only for secondary display purposes anyway. Also, because I plan to stay with mid grey, getting 160+ steps to black might prove difficult!

I used the same process as for the temperature:

Colour pallet for wind speed range.


4) The Final Discs

And here they are in all their glory complete with typical weather for an extreme summers and winters day:



5) True Flat or embrace a little Skeuomorphism?

You may remember my brief investigation into the shift in design trends concerning digital media application and interface design (and graphic design in general).

My conclusion was that they were both tools to be used when appropriate and that one wasn’t necessarily better than the other. What I haven’t considered is can the two coexist in the same design?

The reason I bring this is up is because I am considering using a drop shadow in my design (see last image). I know of many designers who shudder when the words ‘drop’ and ‘shadow’ are uttered in the same sentence but hear me out, and to be honest, this isn’t a very good example of a skeuomorphic design but because I am comparing it to a (fictional) physical product made of card, there are elements that do conform to a skeuomorphic way of thinking.

Compare the examples below:


We have a true flat design (left), a drop shadow from the whole of the main interface onto the disc (centre) and the same but with a further drop shadow from the main interface onto the white “surround” as in the original design (right).

In my opinion the design on the right has too much shadow action. It starts to get confusing with now 3 “layers” of interface. Also, on the smaller circular “windows”, there is now a ‘button’ type effect appearing which adds to the confusion.

Conversely, I think the design on the left is also confusing. It might be sticking to true flat design principles but it suggests that this is a still image and can not be interacted with directly. That’s not what I want, I want to convey the concept that the information displayed in these windows is on a separate layer behind the main interface and can be interacted with – just as if the design were made of card and you could spin the wheel to achieve this.

The conclusion is to go with what seems to convey my original intention of design – the centre option.

6) A Simple Presentation

Below is a Photoshop mockup of demonstrating how the wheel will work in relation to the rest of the interface and although it’s only a static image, you can already imagine how the interaction model of this app would be implemented and how it would function:



I now have pretty much everything I need to create the animated presentation of my weather app concept. The one thing I am sill missing however is a name and branding. This will be covered in my next post.

Leave a Reply

Your email address will not be published. Required fields are marked *