Archive | December, 2012

Screen Flow diagram V1

17 Dec

Screen Flow diagram V1

An early requirements-led flow diagram of how the user would interact with the app

Key functional requiremetns

17 Dec

This post should be considered alongside the previous post  (“Requirements summary”), and aims to fulfill point five of the HCI specification:

Use the light weight shell to describe some of the key functional requirements that you are going to implement in your app

Number #1
Description The app will consist primarily of a screen containing a grid featuring nine tiles – each displaying the current weather in a different city and the name of that city. The tiles will be colour-coded based on the absolute value of the weather variable being displayed.
Rationale This is the essence of the app and its primary reason for existing. Based on the competitor analysis this feature is believed to be unique in its design and execution.
Type Functional
Number #2
Description Users will be able to choose from a range of basic weather variables – Temperature, Rainfall, Pressure, Condition, Humidity, Wind speed.
Rationale This core feature was identified as missing in many current apps by the competitor analysis and gives users a reasonably full picture of the weather rather than the usual limitation of Temperature and Condition. The interviews and personae identify that these extra variables will be important to the core market – enthusiasts.
Type Functional
Number #3
Description The app will have a background task to update the data at set intervals of at least every 30 minutes. A manual update can also be performed by the user.
Rationale Weather data must not go stale as it can change fairly quickly and thus become irrelevant / useless / deceptive. Users will notice this and may grow dissatisfied. Updating is common to all apps from the competitor analysis. The minimum update frequency chosen is based on my knowledge of the weather from over five years’ experience in monitoring it.
Type Functional (background service)
Number #4
Description The cities displayed will be user-modifiable by means of a map interface, which will display all the cities that can be chosen and highlight the currently-selected cities.
Rationale The pre-set cities are unlikely to satisfy user demands for viewing the weather in the places they know. The casualist persona identified this, as did the competitor analysis – all such apps have a means to change locations. The map interface is important as it shows places relative to each other.
Type Functional
Number #5
Description The user interface (UI) will be clean and easy to navigate
Rationale As well as being a good general principle for maintaining and attracting a customer base, one of the interviews revealed that this could be important for attracting the non-enthusiast types such as holiday makers and business users
Type Non-functional
Number #6
Description Only data needed by the user will be downloaded to the device. This will stored in a local database.
Rationale For mobile devices data transfer can be slow and unreliable, and may cost. It is therefore important that only the minimal quantity of data needed is acquired. Database storage is reliable, portable and quick.
Type Data

Requirements – summary

17 Dec

Based on interviews, private thinking, the brainstorm, competitor analysis, personae, and informal discussions, I have gathered the requirements for my app.

Primary requirements will be implemented for this coursework (Version 1.0 of the app). Secondaries will only be implemented if time allows, else they will be postponed. Postponed requirements will be considered for inclusion in future versions of the app, partially based on the results of feedback from version 1.0.

Primary (“Must-haves”)

  • Main screen with colour-coded tiles comparing current weather in different cities
  • Basic set of weather variables to select from
  • City-sorter algorithm to arrange the tiles in a grid: N to S, W to E on the screen
  • Updating mechanism  – automatic and manual
  • Settings to change the units and update frequency
  • Map-based interface for changing the selected cities
  • Europe-wide coverage
  • Completed to a standard that meets the requirements of apps for the Android store
  • Compatibility with the look of existing Android apps
  • Clean user interface, appropriate feed-back, and a help page
  • Local storage of data in an SQLite database, updated from a web server which will hold all possible data in a MySQL database, updated from an API.

Secondary (“Should/Could-haves”)

  • Extensive, customisable set of weather variables
  • Global coverage
  • Multiple user-defined city collections for the main screen
  • Ability to change time-frame of data (max/min/yesterday…)
  • Gestures to change weather variable or time-frame
  • Searchable cities on a map and non-map interface
  • City summary to show all data for a single city – accessed from clicking tile
  • Ported to be Windows 8 –compatible
  • Reliable data – bad sites to be blacklisted.

Postponed (“Wants”)

  • Animation (tile rotation, colour transitions)
  • Graph-based view
  • Ported to be iOS -compatible
  • Draggable tiles to enable custom arrangement
  • A mechanism for users to report bad data.

Data Model

17 Dec

Data Model


The web server (owned by me) will access the API through a PHP script which is set up (through Cron) to retrieve and store the data every 30 minutes. The data are stored in a MySQL database running on the server. The app will have an Android Service to asynchronously grab and save the data from the server (through a PHP-managed web page to process the request). This data will be stored locally on an SQLite database so that only data needed by the user will be stored, making this is an efficient model. The user database will also have a table of every city available, along with lat/long data so the user can select cities from a maps interface.


Speed –In-app URL-fetching followed by XML parsing is resource intensive and potentially error-prone, especially as 9+ locations are needed. By giving this job to a web service scheduled script, errors can be caught and execution time is fairly irrelevant.

Efficiency – Let’s say a hundred people are using my app simultaneously, and all use London as one of their cities. This means the very same London XML page from the API is parsed 100 times.

Scalability – The API only allows 500 requests per hour, so if my app had very many users (wishful thinking, maybe, but the concept is important), in-app parsing of the API XML could lead to my being disconnected from their service, leading to the failure of  my app. By storing the data on my own server, I am free to scale up the resources as necessary.

Portability: If I had chosen to process the data on the app itself, I would have to code this up for each platform I develop on. In contrast, this model allows the whole chunk of data processing, filtering and storage to occur within a reusable framework (a web server), so it is only written, modified, (debugged, enhanced etc.) once.


Persona 2 – Casualist

17 Dec


This persona is largely based on the interview with Jules. Both personae will help me identify with the user so I can more effectively ascertain the app requirements.


Persona 1 – Enthusiast

17 Dec

Persona 1 - Enthusiast

This persona is partially based on the interview with Ahmed, but mostly derived from my own experience in the weather community


Initial mockup

12 Dec


Will be updated after proper requirements gathering


12 Dec

This aims to fulfill point three of the HCI coursework specification:

Records of interviews with your client and/or users. Describe how you prepared for the interview and include the questions that you asked

I decided to conduct some informal interviews with people I know in order to help me deduce the app requirements.  People were pre-selected so that they had some interest in the weather (however minor), and as wide a range of user backgrounds as possible was chosen to best reflect the smartphone demographic. This has to be within reason for this project – though this is the biggest downside since I don’t have ready access to a range of class or location backgrounds – most people I know are middle class and English.  Fortunately, though, most app users are young (, so I have chosen to interview two students on this course and one, older, family member. My own experience being a weather fanatic and communicating with other such beings will further guide me in requirements-gathering.

I generated a basic script using the principles covered in lectures (e.g. avoid leading and long questions), but this was only for a guide – i.e. I planned for a semi-structured interview. Responses were recorded on paper in note form so I will present only my conclusions from each participant. As suiting the interview style, a relaxed location was chosen for conducting the interviews (at home or in the computer labs when not busy).


  • What weather apps (or websites) do you use / like?
  • How interested are you in the weather? What aspects?
  • Have you had experience with a feature to compare the weather in different locations?
  • What are your thoughts on this feature as you have experienced it in apps you have used?
  • Would you like to see this feature developed?
  • What are your feelings on the graphics of weather apps in general?
  • What are your feelings on user customisation in apps in general?
  • And how about the use of animation? Is performance an issue?
  • — Now I explain my app idea —
  • Are there features of my app that interest you?
  • Anything missing you would like to see?
  • — Ask about specific features if they raise them —


Pending completion of interview process…

Names have been changed to preserve anonymity

James (15-35)

Uses basic weather apps like the default Apple one (which displays current temperature and condition icon, and a basic forecast for a number of user-defined locations). This is more than enough for him so he has no interest in the features of my app, but he kindly looked at my idea and gave some feedback:

  • Weather apps should pay significant attention to graphics and animation – it is on par with performance
  • Travellers (business, gap year, holiday-makers) may be a good target demographic
  • Most weather apps with the location compare feature allow the user to change the number of locations displayed – may be something to look at for my app
  • Thinks that users will mostly be power users so consider features to cater for weather experts.

Conclusion: some good ideas, but not target user so will have to weight this interview in light of this.

Jules (40+)

Uses Met Office app to check latest weather and view forecasts for her home town (London). Only looks at weather in other cities if she is visiting them. She claims to be ‘fascinated by the weather’, but this seems limited to observing temperature swings day by day – especially in winter. She checks the temperature using the MetO app, but hasn’t tried an app which simultaneously compares different locations. However, she thankfully was interested in the idea – “I sometimes like to see how much colder/warmer it is in Italy where I go on holiday every year” – she does this through occasional reading of the weather page in newspapers (all seem to do a global roundup these days). Graphics/ animation are not a big deal to her – she just wants the information to be easily and quickly accessible. Here is a roundup of her thoughts on the feature of my app:

  • Temperature / weather is main concern – maybe rainfall but nothing more
  • Keep the main page simple – doesn’t want to be searching for the right icon
  • Not interested in obscure places, just the main global cities.

Conclusion: These sort of lightweight users could be a big customer base if I focus on a clean, uncluttered interface, though it does seem the weather interest is needed.

Ahmed (15-35)

Uses the default Android weather app. Tried a more detailed one once (thinks it was GoWeather), but found that he didn’t use it. However, he says he is interested in the weather and does check out websites like the Met Office and Netweather (a popular site catering mostly for enthusiasts) when there is something going on (snow, storms, heat, cold). Therefore in times when there is “extreme weather like the recent floods” he would like to see how different places in the UK compare. I suggest another example – the European heat wave of 2003 – and he confirms that such an event would lead him to want to compare European cities. This leads to an interesting idea for my app whereby the  user could switch between different panels – one for local (e.g. the UK), one for regional (e.g. Europe), and one for global cities. As for graphics / animation – the conclusion is that for this sort of thing he would not be as interested as in other apps because “it is more about the data visualisation – focus on that”. Some other points

  • Probably going to be used almost exclusively by enthusiasts – focus on their needs
  • Data quality is important for this group as they know their stuff – people get annoyed by incorrect data if that is the main feature

Conclusion: Just the sort of user I’m looking for, and the most enthusiastic, so will weight his views accordingly.


Unfortunately it seems the level of interest in the weather needed to use my app is higher than the typical app user (James), so I will have to focus on catering for the smaller market of weather enthusiasts (Jules and Ahmed being at he lowest end of this scale). So this is my target user. I have gathered lots of ideas from these interviews and will now draw up my requirements based on these and on my own knowledge of the high end weather enthusiast (e.g. me).

WxApp Competitor Analysis

12 Dec

This aims to cover point two of the HCI specification:

A competitor analysis – describe the strengths, weaknesses of existing competitor apps and identify any opportunities for your app, for example, is there any functionality that you could implement that no other app provides?

To my knowledge, after searching Google Play and online, there are no applications that have a tile-based city weather comparison feature. I found a few that do have features for comparing weather in different locations, though always as part of a much larger application and not using a visual grid interface. I will perform a competitor analysis on the main android apps I found that have a feature for comparing LIVE or HISTORICAL weather in different cities. FORECAST comparing apps were ignored as this is not one of the ideas I came up with in my brainstorm so I have no intention of including this feature.

The apps I will compare and the type of location comparing they do

Weather Underground – Map

Go Weather EX – List

Android Weather – Map

Weather Tunnel – List

Weather Underground

CompetitorAnalysis - Weather Underground

A flashy app with animation, map overlay, nice icons and a wealth of information. However, it is slow, feature-heavy, and often unresponsive (feedback!) . The comparison feature has colour-coding but as it is a map, you are limited to viewing locations around a given location (comparing London and LA is impossible).

Pros: Good graphics, detailed information, live updates, very many cities/locations, colour-coding.

Cons: Slow, has adverts, restricted to one weather variable (temperature), limited settings options.

Go Weather EX


One of the most installed weather apps on the market with several million downloads, and 4 star rating. A focus on flashiness may explain this (video backgrounds, claimed HD). Comparing is either via small icons in-app, or big icons as a widget. Not colour-coded.

Pros: excellent graphics, really clean UI

Cons: pesters user to upgrade to paid-version, again limited to temperature and  a condition icon.

Android Weather


This is a simple app that lets you save cities and flick through them to view the weather, but not compare the cities directly in this way. The comparison is done on a map with pre-defined cities, each with a large bubble giving a weather conditions icon and the temperature (not colour-coded).

Pros: Broad and detailed settings for units and data updates, nice fonts and icons, uses gestures

Cons: Adverts, poor UI design (dead-ends, missing buttons etc.) , very limited number of cities on the map (only two in the whole of the southern hemisphere!),  limited to comparing temperature and weather condition.

Weather Tunnel


Basic app with limited graphics and no colour-coding. The location comparator is in a list view so distant locations can easily be compared.

Pros: Quick, can compare lots of cities quite easily

Cons: Adverts, dated graphics and icons, text-heavy, help-link goes to browser, limited to comparing weather condition and temperature.


  • My idea of a grid dashboard comparing multiple cities does not seem to have been done to the extent I plan. The colour-coded tiles concept is unique (to my knowledge), as is the use of a wider range of weather variables (rainfall, humidity, pressure etc. – most stick with temperature and  a weather condition icon).
  • All the apps only compare live data, so there is also scope for uniqueness in showing max/min/mean data for the day, and even historical data (perhaps this could be a pay-for feature to be developed later).
  • Give detailed unit options if the app is to be deployed globally.
  • Provide update settings like: “Update only on Wi-fi”, “Set update frequency”, “Update manually only”.
  • The most-downloaded apps have good graphics, so I need to consider making some effort in this area.
  • To get good reach, it will need to be able to get data from cities around the world – no apps I looked at limit the user to one continent  (my initial idea specifies European cities only).

Specification Brainstorm

12 Dec

Specification Brainstorm

Made with

This is a brainstorm I did when I first came up with the idea for my app. From this I will design my interview questions.