Updated Requirements

On the basis of the heuristic evaluation, the change in deadline, and weeks of development and testing, I have updated the requirements:

Primary (“Must-haves”)

• Colour-coded tile screen comparing current weather in different cities
• Basic set of weather variables to select from
• City-sorter algorithm to arrange the tiles 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
• Android compatibility (e.g. for resolutions) and design consistency (icons, menus, settings etc.)
• Easy to use – clean interface, help documentation
• Gestures to change weather variable on home screen, to complement the buttons that do this too
• 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”)

• City summary to show all data for a single city – accessed from clicking tile
• Quick view of all cities available and their current data, sort-able by name or value
• Multiple user-defined city collections for the main screen so > 9 cities can be saved
• Searchable cities on a map and non-map interface
• Option to display rank data (amongst all 100+ cities) as well as the absolute values.

Postponed (“Wants”)

• Drag-able tiles to enable custom arrangement
• Pre-set city collections for major countries, and “random set” option to generate a collection
• Animation (tile rotation, colour transitions)
• Ability to change time-frame of data (max/min/yesterday…)
• Extensive, customisable set of weather variables
• Ported to Windows 8  platform
• Ported to iOS platform.

Removed from previous requirements

• Reliable data – bad sites to be blacklisted
• A mechanism for users to report bad data
• Global coverage
• Graph-based view.

 

Notes:

• The handling of bad data requirements have been removed after extensive testing, including with users, showed them to be redundant.
• Global coverage and a graph-based view were deemed to be outside the scope of the app so could conflict with its purpose.
• Several secondary requirements have been demoted owing to time constraints.
• The gestures requirement has been promoted following the consideration of Norman’s principles (see that post for detail).
• Heuristic evaluation and my own testing revealed the benefits of the “quick view of all cities data…” requirement. It will be added if time allows.
• A few other minor features have been thought up and added to either the Secondary or Postponed list.

Android AlertDialog Bug

I found a bug in the android API: when showing an AlertDialog, you cannot set both a message (setMessage) and a list (setItems or setMultiChoiceItems etc.). They somehow cancel each other and nothing gets displayed. So when using lists, you are stuck with just having a title.

Annoying, but solved thanks to stackoverflow (of course).

Use Case

This use case will be partially based on scenario 1. As recommended by the HCI lecture notes, I will follow the Fowler method for documenting a use case.

Goal: general usage to gain information about live weather in different cities.

Steps:

1. The system displays the dashboard with the default locations.
2. The system checks for new data and updates the screen
3. The user clicks the ‘change location’ button
4. The system loads the map interface showing all available locations, highlighting the currently in-use ones
5. The user finds a not-in-use city and clicks the marker
6. The system prompts the user to deselect one of the nine in-use cities and displays an option to return to the map or go home
7. The user chooses one from the nine given and clicks ‘ home’
8. The system updates the data and displays the new dashboard
9. The user views the temperature data and swipes left
10. The system changes the displayed weather variable to rainfall
11. Repeat steps 9 and 10 until the user is satisfied with the comparison or all variables have been displayed
12. The user closes the app but returns after 10 mins and presses the refresh button
13. The system checks for new data but none is found
14. The system subtly informs the user that this is the case
15. The user closes the app.

2. If no new data is found:
2.1. Don’t update the screen.

12. If new data was found:
12.1. The system updates the screen and subtly informs the user

12a. If no network connection is found:
12a.1. The system abandons attempt to update data
12a.2. The system subtly informs the user of a network failure

Scenario 2 – Casualist (Jill)

Jill is on holiday with the kids for October half-term, lying on a beach in southern Spain. She is having a wonderful time in the Mediterranean sun and heat. After weeks of damp, overcast dross back home in London, she really needed this holiday.

Whilst lying there, Jill wonders what it is like back home. She knows it’s probably rubbish, but it will make her feel much better to have it confirmed. She doesn’t want to ring anyone right now, and there aren’t any newspapers nearby so she gets out her phone. There’s this wonderful lightweight app she discovered recently that lets her compare the weather in different cities around Europe. It loads up in no time and she can immediately see the contrast in weather thanks to the highly-informative colour-coded tiles. The blue of London (9 C) compared to the deep orange of Seville (38 C) fills her with joy.

Having already set up her cities (she swapped Oslo for Seville from the defaults) before coming away, and thanks to the highly efficient data model of GC02 WxApp, Jill’s perusal of the weather uses less than 1KB of data, costing Jill almost nothing in roaming charges (much less than a text or call). With automatic updates turned off, she locks her phone without shutting down the app, safe in the knowledge that no further costs (albeit fractional) will be incurred.

Jill lies back and smiles at the thought of Londoners get rained on in the cold, miserable streets whilst she soaks up these joyous rays.

Scenario 1 – Enthusiast (Jack)

Jack is travelling on the Overground to work. Thankfully he has found a seat, but as it is a long journey he is, as ever, looking to kill some time. He’s finished reading the Metro and is now on his htc. Jack is not much of a gamer; he prefers to browse news sites, blogs, weather sites and such. He gets his buzz from reading interesting things.

After checking the BBC News app, Jack loads the GC02 WxApp. He kills a bit of time flicking through the screens, observing the weather in cities around Europe – once again marvelling at how cold it gets in Budapest in the winter, and how wet it has been in Athens lately. He views the detail for London – cloudy, mild, dry – and wishes he could be in Trondheim where he can see there have been gales (his favourite weather event).

After changing a few of the cities on his dashboard and flicking through some of the weather variables again, he looks up and realises he’s missed his stop. He makes a note to be careful when using GC02 WxApp – it’s too absorbing for him.

Screen Flow diagram V1

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

Key functional requiremetns

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

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

Design

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.

Benefits

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

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.