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.