App Design Outline
In order to build a functioning, well designed mobile app to gather data for theGOODforyou, while working with volunteers and multiple developers worldwide, we need a consistent and detailed outline for what the app should look like, and how it should function in both the backend and UI. As with every aspect of the project, contributions are welcome and will be discussed before being adopted, making the following a fluid, living document that may see many revisions as time goes on.
TheGOODforyou – Journal App Mockup
TheGOODforyou Journal App is a daily logger designed to be as easy to use as possible, while allowing users to enter multiple types of data that can later be analysed, for both the benefit of the user themselves, and for anonymized research conducted through theGOODforyou’s web site.
Log Entries – the app’s backend
Each log entry will have four main criteria: Activity Type, Time, Submission Type, and Entry. For example, the first Activity Type displayed when a user opens the app will be “general”, which uses a text entry hint of “What are you doing?”, and the default Submission Type is “simple”, with a button label of “Submit”. When the user types in the text entry field, this text is registered in the Entry field, and the current system time (with timezone) is registered in the Time field.
Each Activity Type has it’s own table in a user’s database, so that a typical entry might look something like this:
|Activity Type (table name): general|
Waking up for the day
Each Activity Type will feature its own criteria, and there will be 7 by default, though these will be expandable, both as default Activity Types, and eventually as user programmable (and shareable) Activity Types. This system will allow doctors, personal trainers, research scientists, etc., to come up with specific log entry types that can then be easily shared with a group of users for specific and consistent testing. The default Activity Types will be as follows:
|Activity Type||Hint||Submission Types Allowed|
|general||What are you doing?||simple,time,location,reminder,schedule,alarm|
|feeling||How do you feel?||simple|
|note||Note to self||simple,reminder,schedule,alarm|
|todo||Add to To Do list||simple,reminder,schedule,alarm|
|diet||Food and Drink||simple,time,location,reminder,schedule,alarm|
Submission Types will be static (baked into the app/backend, though they will be expanded in the future). For now these will include the following:
|Submission Type||Submission Button Text||Extra Fields|
Each Extra Field will therefore feature its own criteria as well, for instance:
|completed||binary (true or false)|
|repeat||time (hourly, daily, monthly, yearly – with exclusions)|
Using a system like this makes it easy to add other metrics later on. For instance, we will want to integrate with fitness watches and other biometrics, so that we may add an Extra Field called “heartrate” with a type of “number”, and add that, in conjuction with time intervals to a Submission Type called “heartbeat”. We could then add this “hearbeat” Submission Type to the allowed Submission Types for “exercise”. In this instance, a typical log entry would look like this:
|Activity Type (table name): exercise|
Waking up for the day
07:00:00 CST 80BPM, 07:01:00 84BPM, 07:02:00 82BPM
Each Activity Type will be expandable through optional fields as well. By default, users will be able to add Notes to a log entry after it has been entered, which will then be registered in an additional field. This field (and other optional fields) will not be registered other than explicitly, however, as they will likely not be used for the majority of log entries.
These Activity Type tables, and the logs they contain, will be stored in a user’s personal database, and can be queried from the server end for research. A user database will also contain a special table from which only certain entries can be queried – their profile. Initially, a user profile will simply contain their name, date of birth, and sex. Their name should never be queried (we should simply not include the functionality to do so), their date of birth should be limited to age range queries (under 18, 18-25, 25-35, etc.), and their sex should be queriable.
Design – the app’s frontend
The Log Entry Screen
The first screen a user is greeted with on opening theGOODforyou Journal is The Log Entry Screen, and should look similar to the following:
In the topmost section of the app, a title bar with menu button will reside. Immediately under this will be The Main Text Entry Field and The Submission Button. These are followed by The System Clock with date and location, and finally, The Main Log Overview.
The Main Text Entry Field & The Submission Button
The main text entry field is the main focus of theGOODforyou journal. It displays a text hint for the current Activity Type, and accepts user input, which will be registered in a log’s Entry field once The Submission Button is pressed. The default Activity Type when a user begins using theGOODforyou Journal will be “general”, and the default Submission Type will be “simple”. Once a user has begun submitting Log Entries, both The Main Text Entry Field and The Submission Button will retain the Activity Type and Subission Type used last, respectively. To choose a different Activity Type or Submission Type, a user must long-press either The Main Text Entry Field or The Submission Button, as seen here:
Note that if a user has designed, downloaded, or installed additional Activity Types, they would be displayed in this list as well.
As each Activity Type must be designed to support specific Submission Types, some Submission Types may not be available depending on the current Activity Type. For Instance, the “feeling” Activity Type would only allow for a “simple” Submission Type, while the “general” Activity Type would allow a user to select any of the available Submission Types. Because this and other long-press actions may not be obvious to new users (though they are quick and easy to learn), a quick user-walkthrough detailing these actions would be a high priority for mass use.
Once a Log Entry has been registered, The Main Text Entry Field will clear and the onscreen keyboard will slide away, though this field will retain focus.
Special Submission Types
The main view of the app should change when a user selects one of the more complex Submission Types. For instance, on selecting the “time” Submission Type, The System Clock would become a timer, as seen here:
In this instance, pressing the timer would stop it and create a log entry. At this point The System Clock would again display the system time as in the main view, and would only become a timer again on pressing The Submission Button.
Similarly, selecting “location” as a Submission Type would change The System Clock to a timer again, but would also change The Main Log Overview to a map showing a user’s current location and any path they’ve followed while tracking location, similar to the following:
Again, pressing the timer would stop both time and location tracking and create a log entry, after which the view would revert to default (though both The Main Text Entry Field and The Submission Button would retain their last-used values).
For Submission Types such as “reminder”, “schedule”, and “alarm”, users will be presented with a simple time and date selector. This will include the ability to choose whether any of these actions are to repeat and how often they should do so.
The Main Log Overview
This area will display a short list of log entries. It should be easy to read, and as such need not display all the details of a log entry. Time zone, notes, and extra fields such as start/end times and gps coordinates could be omitted from this view to make it more human readable. The most recent entries should appear at the top of the list here, though this area should be scrollable, allowing a user to browse their entire log at a glance. Long pressing any single entry should present the user with the following menu:
Here’s a quick explanation of each menu item displayed here:
Repeat – On choosing “Repeat”, a new log entry is created with the same Activity Type, Submission Type, and Entry text, but with a new Time (the current system time and time zone). This should behave exactly as if a user had typed the same text in The Main Text Entry Field, chosen the same Submission Type, and pressed the Submission Button. If the submission type were “location” for instance, a new log entry would be started, complete with a new timer (for start and stop times) and a new log of a user’s location, but with the same Entry as the original log entry.
Reminder – If “Reminder” is selected, a new reminder is created (regardless of the original log entry’s Submission Type) with the same Entry as the original log entry.
Schedule – Pressing “Schelude” would the same result as “Reminder”, with the exception that the log entry’s Submission Type would be “schedule” rather than “reminder”.
Alarm – “Alarm” will work similarly to “Schedule” and “Reminder”, but with a Submission Type of “alarm”.
To Do – Selecting “To Do” will create a log entry with an Activity Type of “todo”, a Submission Type of “simple”, but with the same Entry as the original log entry.
Details – “Details”, would present the user with the details of the current log entry, including those details not visible in The Main Log Overview. The dialog should look similar to the following:
Note that this details window should show start and end times, gps coordinates, and other extra fields if they are included in a log entry’s Submission Type, and that it will also include an “edit” button to allow users to change any field. Log entries that have been that include the “completed” field, such as “reminder”, “schedule”, and “alarm” Submission Types, as well as Acitivity Types like “todo” should feature a checkbox allowing a user to log whether an item was completed as scheduled.
Analysis – Pressing “Analysis” should take a user to The Log View Screen.
Edit – Pressing “Edit” would take a user to the same dialog as “Details” with the edit button pressed.
Delete – Pressing “Delete” would remove a log entry from a user’s log.
Special Note on Edited and Deleted Items
When a user has edited a log entry, the edited entry should be registered in a user’s database as a new entry, and the original should have two extra fields added – “edited” (set to true) and “linked”, which would simply contain the timestamp of the new edited note for reference. This allows for accurate data analysis in the event that a user edits an important field. After a field has been edited, the original log entry (and any entries that contain the “edited” field, set to true) should no longer be visible in either The Main Log Overview or The Log View Screen. Deleted items will gain a single extra field, “deleted” (and set to true), and will no longer be visible in The Main Log Overview or The Log View Screen. In both cases, however, the original log entries should still be available in a user’s database for querying.
The Main Menu
The Main Menu will contain the following entries:
Log Entry – Selecting “Log Entry” takes the user to The Log Entry Screen.
Log View – Pressing “Log View” takes a user to The Log View Screen.
Settings – Pressing “Settings” will take a user to The Settings Screen.
The Log View Screen
The Log View Screen is similar to The Log Entry Screen, but without The Submission Button or The System Clock. It will give users the ability to view all Activity Types, log entries of a specific Activity Type, or log entries of a specific Submission Type. The different Activity Types and Submission Types would be selectable from drop-down list, and long-pressing a log entry would present a user with the same options as doing so in The Log Entry Screen.
There will be a row of tabs at the bottom of the log entry list allowing the user to see their log as a list view, pie chart or line graph. The mockup above doesn’t contain these tabs, and will be updated soon.
This is a simple list of log entries similar to the one in The Log Entry Screen.
Pie Chart View
The pie chart view would give users a breakdown of their activities. When users are viewing all log entries, the chart would show percentages of each type of entry over a user selectable time frame. If a user is viewing a specific entry type, such as a specific Activity Type, the chart would show percentages of specific entries. For instance, if a user
Line Graph View
The line graph view will contain the same information as the pie chart view, but with lines on a graph showing fluctuations over a time scale.
The Settings Screen
Work in progress.
The To Do List
Work in progress
Reminders, Scheduled Activities, and Alarms
Work in progress