With all previous rwmthings apps, the design process grew from the bottom up. Basically playing with the underlying technologies, then massaging the results into a UI that somehow displayed the content :-).
For MoodUp, a more user centered design approach was used, inspired by both the 2013 Google I/O talk Structure in Android App Design, and the online course Human-Computer Interaction.
The following shows a basic story board for the app flow as it stands today. Note that during development, the app morphed a fair bit from the original ideas…
Key steps include:
- Context is a user, that sometime in their life they are feeling a bit down, a bit lonely, in need of support. They want to be able to reach out anonymously. Either they dont want to turn to their friends, or they dont have many people to turn to.
- Using MoodUp, they can anonymously post a mood (an Image, a Mood, and a Reason) for all other MoodUp users to see. Mood posters are only identified by the Country they are in when posting.
- Other users browsing through moods can find posts they relate to, or feel that they can offer a few words of encouragement for. So they post a comment.
- Commentors are also basically anonymous, being identified only by their selected Image/Avatar, and their current Country location.
- Mood posters are notified when someone comments on their mood, giving some reassurance that there are people out there listening.
- The mood poster responds to the commentor with some thanking words, and a star rating of the comment.
- Net result is a Win-Win for both. The mood poster receives some needed support, and the commentor receives some thanks and appreciation for their support.
The Story Boards give an overview view of the app flow, the usage and outcome. We need to decompose this into a set of use cases for implementation.
For MoodUp, there is only really one type of user, operating in two possible roles. As a mood poster, and as a commentor. Based on the Story Boards, we can come up with the following general set of use cases.
Key points include:
- Key Use Cases include the actual posting of a Mood, Comment and a Thanks/Rating.
- Users need to be able to flick through thumbnails of their own mood posts, and those of other users. Viewing should be done in a simple, grid type fashion to locate a suitable mood post.
- Users need to be able to see a detailed view of a mood post, including the associated comments and ratings.
- Users also need to be able to manage their ‘profile’, which at this stage simply consists of their selected image/avatar that gets displayed along with their comment.
- Other use cases are of lower importance. However one worth mentioning is the ability to mark mood posts, comments or ratings as being Inappropriate. The solution needs to include mechanisms to ensure users are not harassed or bullied.
Next we need to give the user cases some structure or relationships…
Use Case Structure
As outlined in the Google I/O talk, the use cases need some structure. After much tweaking, we settled on the following.
Use case structure determines the path of the user into the app:
- The user is able to directly access the functionality for posting a mood.
- Direct access is provided for browsing through the thumbnails of the users own mood posts, as well as those of other users.
- The user will be receiving notifications for any related comment or rating post, so it is important for efficiency that the user is able to quickly see current and past notifications directly.
- The app also provides direct access to the users profile (image/avatar), as well as their posting statistics.
- A key hub function of the app is the details view. This shows a selected Mood Post data, together with any associated Comments and Thanks/Ratings. These are shows as individual use cases for the My and Others moods – as functionality is slightly different. It is from these hubs that a user performs most actions such as commenting on a mood, or thanking/rating a post.
Use Case Structure to App Structure
As outlined in the Google I/O talk, this use case structure can simply be mapped to an app structure by rotating 90 degrees.
At the highest level of the app, we use the flexible DrawerLayout to provide direct access to the main app screens, including:
- My Moods: Showing thumbnails of all of the users own mood posts.
- Others Moods: Showing thumbnails of other users mood posts.
- Notifications: Lists the recent Comment and Thanks/Rating posts that are related to the user.
- About Me: Access to the profile and statistics of the user.
Direct access to the Post Mood functionality is provided through the ActionBar, visible in most screens.
From these primary screens, the user navigates from a selected mood or notification to show the related Mood Detail, including the mood, and all associated comments and thanks/ratings.
From the Mood Detail view, the user performs the various actions via mainly dialog type boxes.
Mood Data Model
Also key to the solution design is the relationship model. Whilst not directly communicated with the user, they are presented with the mood data that complies with this model.
For every mood there are multiple comments. For every comment there is a single thanks/rating.
This high level interaction design provided a sound basis on which to begin the construction of the app. Highly recommended that independent app designers adopt a similar top down approach to their apps.