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