image/svg+xml

Planner Iteration

Jun 17, 2020

After planning my days using a paper planner for several years, I realized that a lot of my work could be automated. I have a lot of hobbies that I need to keep track of, but planning on paper was repetitive.

My paper planner system worked; I had made several iterations to discover the design that works best for me. The first version of my electronic app was basically a web version of the paper planner system. I planned out the functionality beforehand and then built the app. This worked, but led to problems (as I'll discuss later on).

The purpose of this post is to explain why the second version of the planner app, although much simpler, worked much better. Starting from scratch after nearly a year made development more effective, easier, and faster.

Rubidium

The first planner web app I built was called Rubidium. I planned out all of the features that I used in a paper planner and then started building. Although I planned out all functionality, I did not plan out how the software would work or how I would develop. This led to a large number of features and an inefficient development cycle.

The database has several problems: This was my first time using Mongo DB, the database was nearly the last thing I added, and I rushed to implement it. Currently the database just serializes all user info and puts it in the database as a string. This works, but requires getting rid of old data so that the serialization and deserialization does not slow over time.

The other thing I added rushed at the end was CSS. Although the CSS looks fine on certain screen sizes, it does strange things on very large or small screens that I never fully resolved.

Because I did not iterate on the app using feedback from anyone but myself, Rubidium is very hard to use and understand for new users. I originally planned tutorial functionality, but decided since not many people would use the app, it was not needed.

Since I based the app on my paper planner app, there were many features that were rarely if ever used (for example, long-term goals that did not do much). Although the purpose of Rubidium was to avoid doing repetitive tasks, the similarity to paper meant that using the app was still repetitive in some ways. For example, I did the same weekly planning every week and the same daily planning every day.

Sending Rubidium to Production

Rubidium was not built with a production pipeline in mind. It did not use any automatic deployment pathways. Deploying on my server was manual and required changing code (because the app did not use environment variables). This led to many problems when I needed to fix bugs (such as the app behaving oddly because the server was in UTC and my device was using local time).

Rubidium 2

Goal

After using Rubidium for about a month, I realized that the main shortcoming for me personally was that there was no accountability system. After a little personal debate, I decided to build a new planner app from scratch. By this time, I had taken a few user experience design classes and learned a lot about software development from my employment. The original idea involved a simple goal tracker that existed in harmony with Rubidium, but the quick development cycle allowed this idea to evolve into Rubidium 2, which is the planner I use now.

Initial Prototype

The first prototype did nothing but call the Trello API to find tasks and present those tasks in an order determined by a simple algorithm. Rather than planning out my days, I wrote an algorithm to do that for me. This prototype took about a week.

Rubidium 2 was simple. I followed the philosophy that what I didn't program was more important than what I did. In other words, my focus was on cutting features, not adding them. I didn't add a database since it was not necessary. I didn't write an interface for goal creation or calendar management since I could just use the Trello API and Google Calendar API respectively.

Another feature that was cut was user accounts. Since this was a personal planner app, I didn't bother with account management. Instead, Rubidium 2 has a simple password verification that does not need a database. The app only uses my goals and can adapt to my needs.

In addition to simplifying features, I also automated the production pipeline. I used .env files and a simple cron job to automatically deploy Rubidium 2 at midnight each night there was an update. Although this took some time to set up, it was worth it because it allowed me to test prototypes and iterate very quickly. Instead of Rubidium where each change could take an hour to deploy, I could make changes on the fly and see the results immediately.

After a week, I was expecting Rubidium 2 to be more of a prototype than a usable app, but I liked it so much that I actually started using it as my main planner app. The random order of tasks and simplicity made it faster and more engaging to use.

Various iterations

Because I could add features, I continuously adapted the app to meet my needs. For example, I added:

Conclusion

When I started Rubidium, I wanted it to be a showcase of my user interface design skills. In the time it took me to write it, I took two user experience design classes and learned that user experience design is not about applying rules to an interface, but about meeting the needs of the user. Although I am the only user of Rubidium, it would have been very beneficial to start out with a prototype so that it would meet my needs more effectively. Instead, I focused on functionality, which led to a user interface that is less fluid that I would like.

By contrast, Rubidium 2 was built iteratively, worked quickly, had only features I need, met all of my needs, and was agile enough to be changed quickly (which I do often). In the future, I plan to iterate on all of my apps in the same way I did with Rubidium 2.