Experiment 2 - Process (Development Pt. 1)

So, after a very short time in the planning stage, I fired up Photoshop and started to realise my concept.

Because the proposed weather app featured a novel way of communicating the time of the weather in question, and because it had to display secondary data dynamically (when required), it was essential to produce a number of mock-ups to demonstrate how the design would display this dynamic information:

[caption id="attachment_135" align="aligncenter" width="320"] A chilly day in Lincoln (where the person using this app would currently be located), with a strong southerly wind. It's partly cloudy and it's 12.00pm.[/caption]

[caption id="attachment_136" align="aligncenter" width="320"] mockup3 20.22.57
Meanwhile in Hull (some is browsing the weather in Hull but not located there - check the icon difference), there's going to a 60% chance of snow at 11pm and be very cold thanks to that northerly wind. Better wrap up.[/caption]

[caption id="attachment_137" align="aligncenter" width="320"] I thought it would be nice to show a warm summer / autumn day to demonstrate that the temperature display would use a similar hue scale to that of the BBC weather to indicate how warm / cold it was. Ranging from deep blue for the coldest temperatures (-20°) to deep red for the hottest (40°).[/caption]

[caption id="attachment_138" align="aligncenter" width="320"] An alert for high UV Index would be displayed next to the temperature (because the issue is linked to the high temperature in this instance). There would also be a red highlight on the temporal display informing the user they better check this time slot out! This represents dynamic data and would only be displayed if the value required care to be taken in the sun - which in the UK, doesn't happen all that often![/caption]

[caption id="attachment_139" align="aligncenter" width="320"] It's a similar story for the Feels Like temperature. If it's a set distance below the ambient temperature (for arguments sake; let's say 5°), then it would be displayed as an alert positioned between the temperature and the wind speed/direction. Also, the moon icon is highlighted red indicating this is for the weather conditions at 11pm.[/caption]

So, job done. I set out to visualise a concept for a weather app that would be a joy to use (probably), display useful data in a slightly abstract way and feature the new art direction of choice: flat. On that subject however, I did mock up my earlier interface design with a mix of the interaction model from the concept above and from its own original concept, but this time, I added subtle drop shadows to the circular "windows" because I am not sure, without animating the mockup (see foot of post), if a rotating disc with flat shading would have the same impact as if it were made out of card for example. I have a feeling I might have to bring the two styles together in order to make the effect I am after, work:

[caption id="attachment_134" align="aligncenter" width="320"] Does the drop shadow reinforce the notion that the weather information is contained on a layer "below" the main interface? Or is it too distracting and is it an issue that breaks the Flat design principle?[/caption]

You may have notice I have labelled this as part 1. This is because I fully intend to use this example to demonstrate how to present a concept for an interface or functional piece of digital design without actually creating it with code. Something that I think a great deal of you (students) will find useful! Check back for that soon!