Category: App Studio

Iteration 3: Adapt Phase

Target user feedback

I didn’t get much user feedback on this iteration as not much had changed since the previous iteration. The user feedback I did get reinforced how important good design is, as they were unimpressed by the technical elements of the app and entirely focused on the placeholder colors and images and heavily critiqued those

Lessons Learned

I learned that mobile apps have a lot of boilerplate code. Additionally, Java has even more boilerplate code. These together made the app easily several thousand lines most of it declaring classes that were used once, or functions that were only there to sate non-null callbacks.

What worked, What didn’t work

The whole app came together nicely after a few classes were fully understood.

The calendar came together nicely after I understood AsyncTask and the CalendarContracts better. I floundered around a bit in the beginning as I was not sure where, to begin with pulling calendar information. Next, I struggled under the impression that CalendarContract.Events was the table that would give me instances of events not knowing there was a whole other table called Instances.

The Goal tab was also a challenge was the Room Persistence library requires several different files to work in tandem. The tab also required the use of RecyclerViews which were not entirely intuitive in their operation.

Lastly, the initial idea of tracking time was thrown out. This was done in the previous iteration but it is important to mention as it was originally the core concept of the app. In my own time tracking adventures and from user feedback, tracking time usage, even across all devices, doesn’t tell a complete picture of how productive the time was nor does it intrinsically inform how to proceed. I think there could still be a synthesis done between goal setting, time tracking, and time management. Unfortunately, while my app does a good job of goal tracking, it is not the answer to that dialectic.

Iteration 3: Speculate Phase

For this final Iteration, I will need to have a fully functional app. For the MVP, the app should do the following:

• Display user’s events for three days
• Add events to the user’s calendar
• Track goals in SQLite calendar
• Track goal progress locally
• Display goals by area
• Display some data about goal progress
• Add Goal related events
• Notify users about upcoming goals
• Onboard users

The greatest challenge at this point, having dropped data tracking, will be effectively using a table to store the goal progress as discrete bits of information. The goals for weeks, years, and beyond will easily be stored in a table but the daily goals which have an associated event will be more challenging.

Iteration 2: Adapt Phase

In this iteration, I had focused more on creating a goal-setting system. A such much of my user testing revolved around how often people set goals and whether they track the goals in terms of sub-events completed or an emotional feeling about them. More user responded that the tracking was a quantitative process if they used one, but the completion was more of a qualitative one. This means that a simple check-in after events should be enough to determine if users achieved a goal.

Compared to my last iteration, which was more focused on laying the ground work for data tracking and reporting on that, this iteration is more about creating and following through with goals. If I do not have time tracking in this iteration but have check ins after events about completeness, I will consider that an MVP.

This will then require a database to store goals and events related to them. This shouldn’t be too hard as the database will only have 3 tables: one for events and one for goals and one for completed goals. I could create a table for each goal area, but I found most users in my target demographic – 18 -25 years old – don’t plan out farther than 6 months – 1 year. This will result in under 100 goals at a maximum.

Lastly, there were a number of UI changes I have to make. Most of them are similar to the previous iteration but with the exception of making the Goals easier to read, as it was not included in the last iteration. The UI changes will be very important as most users I interviewed were ambivalent about using a goal setting app, even though they set goals and tracked the progress of them

For this stage of iteration 2, I pivoted away from solely tracking users and focused more on creating a goal oriented app with the added feature of tracking time and relating that to goals.

I spent most of my time creating a new prototype as both a visual for user’s and a road map for myself. I was then able to use the road map from the prototype to prioritize working what features to work on. Android, as I have previously found is fickle and, with each new update, changes the fundamental way in which things are coded.

Despite this I was able to learn some more about fragments and data storage and how best to implement them into my app. Time tracking, though previously fundamental to my app, will have to wait until I have a firmer grasp of Android Studios. Understanding how the app can work outside its sandbox, how apps can best store data, and how to programatically make beautiful UIs will have to come first.

Iteration 2: Speulate

Having recieved user testing and seeing how people responded to my first iteration, I need to reprioritize my feature list to be more goal oriented and less about the minute minutes of people’s daily phone usage.

Ideally, the app would have year’s goals, which were broken down by months, then by weeks, and, lastly, by day to day. For an MVP, all this data could be stored to a user’s calendar and not stored on a server. In a further iteration the data should be stored server side so that user’s could easily resume long term goals when they get a new phone. Also for the MVP, I think having goal break downs and some measure of time tracking at a minimum. Lastly, after each event in a user’s calendar, the app will have a notification asking them if they accomplished whatever the goal was and mark that down. I think having a subjective measure is better than having an objective measure of time as most of my user testing indicated that goal achievement was measure more as an emotional response than whether or not they spent x hours doing an event.

In a further iteration, I may use these coupled with the time tracking to create a metric of how well they have progressed towards their goal. This sort of breakdown is a very common theme in goal setting books. The app should start up and load goals as well as checked off goals. It will then check if there are any markers for this week related to each goal and warn users if they are not progressing toward a goal.

Adapt Phase

For the adapt phase, I needed to figure out what worked with my prototype and what didn’t work.

Tools

For the prototyping, I used AdobeXD, which I found very intuitive and useful for making prototypes. I was also able to use Google’s material design icons for my app which made the look of the prototype feel very consistent.

Originally, I had planned on using React Native so that my app would work on both platforms but after some investigation, I found that there was no way to inform users how they spent time on their phone and that even the workarounds to inform users when they used their phone were frowned upon. So I switched to Android Studio.

Android Studio is fairly robust but it is also very extensive and time consuming to research as each API changes things and so testing each step of creation is tedious. However, calendars are a a ubiquitous feature and I was able to find numerous tutorials about everything I needed to know.

For my user testing, I used the AdobeXD app which worked very well to demonstrate to users. I also took a small survey which I explain below.

User Feedback

After doing some user testing, user’s said that seeing how they had done was not as important to them as goal setting. My first older user’s – read: parents – said that they did goal setting and then incrementally worked backwards. So 20-year goals, 10, 5, 1, 6 months, 1 month, this week, and then today. Each goal was then adjusted every increment for smaller goals and more often for larger goals. For example, daily goals were set daily, as were weekly set weekly, monthly set monthly, and yearly set yearly.

This approach looked like a development of the younger user’s goal setting which was done mostly weekly or as needed. Younger users indicated that they only planned a few weeks in advance and were more focused on fitting everything into their calendar rather than having for reaching 5 or 10-year goals.

Additionally, all users said that they rarely used time tracking apps and that they were focused more on planning for the future rather than seeing how they used their time. I think that this is because they had no reason to see how they had used their time. I think if the app gave more reasons to track time usage people would use it more. For example, if the app suggested events such as eating lunch/breakfast/dinner etc. at common times that the user was free or suggested increasing/decreasing time spent on certain apps people would use it more.

Goal setting is not currently what the app is intended to do but it could be a future improvement. I may also pivot to incorporate grand goal planning into setting events, admonishing users, and controlling the grand view for how the app works. This would make it so that each action was attributed toward or against long term goals in areas such as financial, career, familial, and others. Each action could then be marked as a positive or negative on a given goal.

Lastly, users gave some feedback on making the prototype’s UI better but these were minor fixes such as increasing the number of days visible on the calendar view and have the graphs be more legible.

Going Forward

Going forward, I will continue to build out the app as a goal setting and tracking app as this angle was more requested by users. Simply having the data was not enough for users. Instead, applying that information to push toward larger goals will help my app help users.

Explore phase

Unfortunately, I was more ambitious than I should have been. While React Native is a great library and fairly easy to use even with all the modules, there were almost no libraries for accessing data usage as it is an exclusively Android functionality. Even then, data collection on such a scale is frowned upon even if it is just displayed to the user.

Since that is the case, I have switched to using the native Android Studio. In React Native, I would have to write all the code in Java and then wrap it in React in order to access all the phone data I would need. I did complete the prototype and had some user testing though few people seemed to be as anal about tracking their habits as I was.

The final product is mostly a proof of concept that I can integrate all the pieces together. The polishing will come later.

The calendar was requested from the phone calendar. This should be changed in a production version of the app to a login with server storage of all user data to allow for cross platform tracking.

Lastly, the main point of the app to track user’s data had to be shelved for now while the groundwork of a calendar and event interfacing was laid.

Link to Prototype: https://xd.adobe.com/view/66c86bdc-7dcf-45b8-4537-d6541264266a-10f9/

Link to Github: https://github.com/akierson/manageTimeBetter

Speculate phase

Prioritized feature list

• Time tracking via data access
  • A functional view of the user’s data usage
• Allow user to create events
  • Check-ins after events to see if user accomplished the event
• Track Data
  • Store data

Tools needed

• Illustrator
• AdobeXD
• React Native

Things needed to implement features

• Request app permissions
• Set default apps
• Store data
• Load data

I have decided to use AdobeXD for the prototyping and Adobe Illustrator for any necessary graphics. I think this should only take a few hours at most.

For the actual programming, I am planning on using React Native. This may present some problems with accessing and writing data, as well as data tracking but this should possible given Facebook’s usage of React Native and it’s wide sweeping tracking. I have some previous experience with JavaScript so hopefully, React is not too hard to learn. Additionally, this will require learning Expo, which should not take as long.

The individual features for the minimally viable product should not take as long as there will be minimal data processing.

• Data Tracking

Data tracking and getting running apps looks fairly easy from this StackOverflow post. However, I would have to either run the app at all times in the background or extract all the data from one of Google’s apps that track it which may be easier.

• Event creating and puching to Google calendars

As I have an Android, I will be using Google calendar for this first iteration and may add more calendars as necessary. The Google Calendar API is fairly easy to use but most phone’s also have an internal calendar, though it appears to be written similarly to Google Calendar API.

• Data Storage

This may not be as necessary on the first iteration as there will not be as much data processing when displaying the user’s data usage and how accurately they stuck to their calendar. It will be more important when the data is then used to improve the user’s habits as processing the data on each start up may be more than the phone can handle.

I want to create an app that helps with planning and time management. I have barely passable time management and it would be a great way to help myself and people that need to improve their time management. Similar to this could be an app that improves habits or breaks them. While this may be easier in the form of a simple reminder, it is not as useful to me. In this app, I hope to combine the functionality of time trackers and to-do list into a single functional app

Time Management App

The objective would be to create an app that works in tandem with a person’s calendars to block out times when tasks can be accomplished and give reminders when a task can be completed. It could also work off of knowledge of a person’s habits, say limit work time based on previous habits or give suggestions to start projects earlier.

My target users would be college kids who are just starting to learn time management skills and want to passively learn how to do it without as much forethought.

Competition

There is serious competition for this, both on the side of task lists/planners and time trackers.

• Any.do – To do list with built-in calendar support
• Smarter Time – phone usage tracker, can be connected to computers.
• RescueTime – phone usage tracker, has computer tie in. Doesn’t work as well
• Google Tasks – Simple to do list attached to every Google account.

Fortunately, there seems to be very little competition for an app that does both.

Challenges

I can foresee a few challenges with a project of this scope. Foremost would be a user’s reluctance to give over the necessary information. It will be necessary to build the features in such a way that each part can work without the input of all the others if a user’s doesn’t want to, say, give access to calendars or doesn’t want to input the time they will spend napping.