Archive | HCI RSS feed for this section

App finish and release onto stores

23 Jan

Now published on Google Play!

I have also submitted the app to Samsung, and they are now reviewing it. It takes about two weeks for a decision, apparently.

Finally available on Samsung store!

User Testing

22 Jan

I conducted a user test with a non-Android App developer who had never seen my app before, but is a user of Android apps. As is traditional, I left the user to explore the system without intervening or allowing questions. This is to determine whether features are obvious and easy to access. The results:

  • User launches app and examines main screen
  • User presses a tile, taking him to the detail view
  • Tries to swipe several times.. system does nothing so he gives up
  • Goes to back to main page and presses the variable bar to change the view
  • User visits the settings, explores, but finds nothing he wishes to change
  • Goes to the table view and plays around… eventually figures out that it can be sorted by clicking the column headers
  • Goes back and visits the map view… clicks a few markers and dismisses them… clicks a marker and sets that location as his new city without problems.
  • Views the main screen and sees his new location
  • Explores the help pages briefly
  • Exits the app.

Key findings

  • User could not get the swipe to work even though that feature is enabled. This doesn’t prevent access to any features but it is handy and neat, and consistent with modern apps. I changed the system to be more sensitive to swipes in an effort to resolve this.
  • The navigation system presented no problems and buttons were readily identified, despite one of the heuristic analysers suggesting that some didn’t look buttony enough.
  • The table view needs a GUI enhancement to make it clear that it is sortable. The user told me at the end that he worked it out because the navigation bar said “Rank View”, but it took him a good 10s to see this so I will enhance the system visibility as this is not acceptable and other users may not be successful in finding this feature.***
  • Dialogs and toasts did not frustrate or confuse user. Excellent.

***Here’s a mockup of the changes I plan to make to this screen:

oldTablenewTable

User testing gives a real insight into how my app might actually be navigated, making it, in my opinion, an invaluable exercise in determining whether all that HCI planning, design and analysis has actually succeeded. Concluding, I have found this process very helpful and would ideally do many more user tests, but with the deadline 24hrs away this is implausible and I must focus on implementing the lessons learned so far.

Heuristic Evaluation (ii)

22 Jan

This second evaluation was shorter and more casual. The expert was an Android App developer looking for violations of Nielsen’s principles.

  • Aesthetic/consistency problem – rows on the table view were too short. This looked poor and was inconsistent with the spacious layout of the rest of the app.
  • Possible metaphor violation – swiping usually causes the screen to wobble or otherwise visibly move. My swipe simply changes the data. The potential complexity of this fix means it may not be implemented.
  • Consistency/metaphor of the buttons – on press, the expert felt they should react by lighting up with a border colour change so that users know it is a button. I agree, and will add this to the implement-queue.

The expert was pleased with the rest of the app, though was not interested to read the help pages. Perhaps that is just the nature of experts, or maybe I should consider condensing them.

 

Casual screen flow diagram using screenshots

22 Jan

City_Weather_Compare_App_Flow_Diagram2

This shows most of the events that occur in the app as a result of button pressing.

Screen Flow diagram V2 – Final

21 Jan

 

 

 

 

 

City_Weather_Compare_App_Flow_Diagram

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)

21 Jan

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:

raindrophumidity

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:

oldFog newFog

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.

device-2013-01-21-191828

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

13 Jan

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.

device-2013-01-21-193118

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:

bars

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.

device-2013-01-21-192237   device-2013-01-21-192003

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.