Screen Flow diagram V2 – Final

 

 

 

 

 

Here is the full, final, colour-coded screen flow diagram. Self-loops indicate an action which updates or changes the screen but does not go to a completely new screen.

Analysing this, it is evident that no screen is more than two clicks away from any other screen, which is ideal as it conforms to good HCI / UX principles.

Heuristic Evaluation (i)

The evaluation was done with another Android application developer, so he had somewhat expert knowledge of the platform, as well as of HCI principles. The process took around one hour and was very successful – multiple potential problems were flagged up as not adhering to Nielsen’s 10 principles of heuristic evaluation, and over the course of the following week they were fixed. A subsequent HE with another developer produced far fewer issues (see later post).

The detailed results are as follows:

Feedback

Settings menu problem – changing a setting gave no feedback. Solution – Toast notification on change.

Data update report problem – on pressing refresh, the app would Toast notify “no new data” if this was the server’s response, which the expert felt to be insufficient information. Solution – append “time until next update: x minutes” to the notification.

Visibility

Time display problem – expert believed it to be the current time (i.e. a clock), in fact it was the time that the data was last updated. Solution – prepend “Last Updated” to the time display.

Metaphor

A problem with the humidity icon resulting  in the expert miss-identifying it as corresponding to rain was resolved by overlaying the percent symbol on the droplet:

Navigation

The expert was impressed with the simplicity of navigation and the ability to cancel operations if not desired – especially true on the map screen where the dialogs were “concise and helpful”.

Consistency

The user was pleased to note that the back button had not been remapped and that the settings screen followed the standard Android layout. An issue with colours for the same thing changing on different screens was spotted and quickly fixed.

Error prevention, recognition and recovery

My expert failed to find any issues with this. The app naturally doesn’t allow errors.

Recognition not recall

Fog icon problem – expert did not recognise the icon as corresponding to fog. Solution – rework the design to make it clear:

Flexible use

Gestures (left/right swiping) were in place to change the weather variable quickly and efficiently, but it was not wrapping around (once the last variable was reached, it was necessary to swipe the other way to go back to the start). This resulted in frustration of the expert as he demanded a more efficient means. Solution – implement a wrap around system.

Minimalism/Aesthetic

My expert praised the aesthetic of the app -“good use of images” – i.e. more concise, clear and language-compatible rather than having lots of cluttersome text.

Help and Documentation

Whilst a good amount of documentation existed, I had to explain to the expert that the tiles on the screen were arranged by lat/lng, rather than alphabetically. Solution: prominently display this fact in the help pages.

Overall, the process was very useful and brought real, significant improvements to the useabilty of my app.

Norman’s Design Principles

Here I will explain how I have implemented each of Don Norman’s design principles:

Visibility

Extensive use of icons rather than plain text makes it very easy and quick for users to know what functions are available to them. Additionally, important features like going to the map-interface for changing selected cities is very visible on the main screen and not hidden away behind the menu-button.

Feedback

All button presses should give instant feedback. Extensive testing was done to ensure that this was the case. The refresh button activates a background process so must give instant verbal feedback; in this case a Toast pops up to inform them that the update has been initialised – important because this can take a long time on slow mobile networks. At the other end of the scale, it is important to prevent excessive feedback which then overwhelms the user- to this end I ensured that Toasts never build up by coding a locking mechanism.

Mapping

All icons for buttons were carefully selected and/or designed so that they mapped to the action that pressing them caused. Some were easy as conventions exist – a gear icon for settings, question mark for help, pin-marker for the map screen, thermometer for temperature-view; others were harder and required testing with multiple real world users – a raindrop with a percent symbol overlayed for the relative humidity view, leaves swirled about for the wind view etc. See screen capture:

Affordance

I carefully checked each screen to ensure that nothing which looked click-able had no action. This is the essence of affordance in a software perspective. Although I do provide user documentation, by testing with users I made sure that this was not required in order to use the interface. Basically, buttons, tabs and hyper-links all do what users expect them to do.

Consistency

Part of this means not re-programming the Android hardware buttons – especially the back button which is an important and well-used feature. Apps which do reprogram this, in my opinion and supported by Google’s own documentation, are poorly designed. With my design, I have ensure consistent colour-coding of the weather values across different functions (main screen, detail screen, ranking view). When using external designs I ensured that they were from well known sources so users are familiar with them – e.g. using Google Maps not Bing or Open, sticking with Android’s preferences design rather than making up my own one.

  

Constraints

These reduce errors and focus the user. My mechanism for changing the selected cities was heavily influenced by this:

• The map interface constrains the user to select one of the marked cities
• Currently selected cities are coloured separately so users are clear of their options
• On clicking a marker they are given the city name and confirm they want to use this city
• They are constrained to remove one of the currently selected cities in a simple list view.
• The lack of textual input is a very important constraining principle for ease-of-use.

The settings were also carefully designed to limit options to the most widely-used ones. e.g. the temperature can only be set as degrees F or C; Kelvin was constrained out as it is not a widely used unit in the filed of meteorology.

In all, following these principles has helped me design an app that already meets the design guidelines for publishing to the App store, and has heavily influenced the decisions I made on the way.

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.