No matter how desperate you are to get cracking in Photoshop ALWAYS make a short written response to the brief. This doesn’t have to be well-worded or written like an essay. It can be as simple as a few headings and some bullet points. Obviously the amount of preparation working (including this scoping stage) is directly proportional to the scale of the project. This example is quite small but I will go into an above-average level of detail to break down the task the best I can.
I am now going to share with you the very first steps I took when deciding I was going to embark on this project. Notice the scanned notebook pages below? It’s a great place to start. Notebooks (the paper variety) are quick to use, can mix sketches and text with ease, never run out of power, don’t stop working if the internet connection is down and feature a great skeuomorphic interface!
I’m not going to get all preachy about “how all good design starts in a sketchbook” because I’m not sure that’s always the truth, but working this way can be a huge time saver and you can carry it with you everywhere, ready to add things as they come into your head. If you haven’t got one, I strongly recommend you get one. Make it a nice one so there’s more chance you’ll look after it and use it.
Let’s begin:
The first things I needed to respond with were (explained in detail below):
- Where am I going to get my data from?
- In what format will it be returned?
- What data will be returned (what do I have access to)?
- Are there any limitations?
1. Although I’m unsure if I am actually going to create a working version of the app either for this experiment or for my own development (as I’m already quite good with handling dynamic data) I still wanted to perform a feasibility check to see if what I was imagining was indeed possible. This is especially important if you’re approaching a commercial project or you have intentions on providing a real world solution to a problem.
I knew in advance where I could get my data from. In this instance it was from the Met Office’s DataPoint API. Here you can grab meteorological data captured by the Met Office based on location and frequency. The service is free as with most online data sources. There are plenty of other sources of publicly available data all waiting for a bright spark or designer to help visualise it. Such sources include:
- Google Public Data – http://www.google.co.uk/publicdata/directory (mostly from the EU and US)
- data.gov.uk – http://data.gov.uk/ (data sets from the UK Government)
- Public Data Sets (Amazon) – http://aws.amazon.com/publicdatasets/ (primarily medical / scientific and internet data)
- Example of very specific data set – https://nycopendata.socrata.com/ (public data connected with New York City)
So you see, no shortage of data sources for you to explore!
2. The DataPoint API returns the data in either XML or JSON format, both of which are great to work with in app / web app programming. So that’s a winner.
3. After careful exploration of the documentation accompanying the API I realised I have access to pretty much everything I would need to make a fairly powerful weather app able to display a great deal of information. You can select as many of the 5000 sites covered across the UK as required (they each have an ID number) and the frequency of the forecast is 3-hourly. There is also a 5 day forecast which you can combine calls to when creating a longer-ranged weather app. A detailed weather app goes against my premise of creating a simplified version of the weather forecast so I will discuss the process of selecting data soon.
4. There aren’t really many limitations, at least none that other weather services don’t suffer from. I suppose having to combine different data from 2 separate calls to the API might be a chore, and you should try where possible to minimize calls to the API by only requesting the data you need but aside from these (development issues), there’s nothing to suggest my simplified weather app couldn’t be created!
In the top image I listed all the data that could be grabbed from each call to the API for an individual 3-hour period. It was quite a lot so I needed to prioritise the data I wanted to visualise. There is evidence of this sorting process with a little key identifying primary, secondary and data which may be required dependent on conditions – in this instance: precipitation probability which would only be required if it actually was raining or snowing! I also identified that wind-speed and direction are usually combined into 1 icon which will reduces my primary data count. What a clever device that is, the old number in a circle with an arrow. I had never stopped to consider this before.
I had the idea of choosing only the most important information to display and choosing secondary data should I ever decide to make the app more functional, but this data would be displayed only if the user wanted it, hence why I’ve labeled it ‘secondary’ data.
On the next image you can see how I planned to visualise both the primary data and secondary data – should it ever be needed. I then wrote a small conclusion to this part of the process identifying that the primary data features a very strong conventional visual representation and I could easily implement this into any design, whereas I would struggle to express all but ‘UV Index’ and ‘Feels Like’ visually from the secondary data, and even these are contentious because there is no adopted standard or convention like there is with the primary data.
Based on what I knew at this point (feasibility, data structure and visual concept/style based on research), I then proceeded to write a little brief outlining the scope of the project. This is a good idea because you can always refer back to it to see if all your major design decisions and directions are true to the original concept. It’s also a good idea to pin this up somewhere visible (sticky notes on your computer screen work well for a short-term project) so you’re in constant reminder of what you have to do.
I added an additional brief item to this in that I aimed to complete the whole process (all of what has taken place thus far through to the Photoshop screen mock-ups) in 24 hours. Will I succeed? Read on…
In the next part of this process I’ll be thinking about how the interface might look.