Description
I think by now most people are aware of the pomodoro technique. It is a strategy to stay on task when doing something less than desirable. It does this by breaking working sessions into chunks with breaks at regular intervals. A normal working session, for example, would consist of 3 work chunks (sometimes called poms or pomodoros). At the start of each pom a timer would be set for 20 to 30 minutes. Once the timer rings it is then reset for a 5 minutes to time a short break. The process repeats like this until the all the sessions are finished or the work is completed.
For this project I wanted to expand on this method to better suit my work flow. The major improvement I wanted to make was the ability to easily track session data. I also wanted to use this data to inform my successive sessions in a meaningful way. Basically I wanted to add feedback into my workflow. This feedback happens on two levels. The first is the pom to pom feedback. After each pom I get the chance to review the session goals. This tight feedback loop does wonders to prevent session drift and rabbit holes. The second level of feedback occurs over a longer time span. Tracking data over weeks of months will allow me to identify trends in my work patterns. I can use these trends to maximize my productive time.
Requirements
I had a few requirements for this project:
- Minimally distracting interface
- Track goals and accomplishments for each task
- Track work time and break time
- Clearly indicated begining and end of poms
- Ability to review session goals
- Ability to display recorded data
Implementation
To meet these requirements I initially made a command line tool pomodoro. It worked well enough for timing each session and providing feedback and productivity. However it was a pain to use. Strings were the only method for input and output. This meant the only form of input protection was an error message. It was also difficult to edit strings of input text. Displaying stats was limited to the terminal window. Certain linux specific commands limited its use to linux machines.
In the current implementation I decided to use a GUI to address these issues. The GUI input forms allowed for a variety of input methods. This meant radio buttons could be used for input protection and large strings could be edited on the same form. A varitey of graphs could allow data to be interpreted more easily. Python includes tkinter as a default module so it is highly portable.
There were also a number of learning benefits to using a GUI over a CLI. Orgainzation is key when using a GUI. As I found out, it is far too easy to write spaghetti code with so many interconnected windows. I got to practise my object oriented design skills. My initial fumbling attempts at using tkinter gave me many opportunities to refactor and pull objects out of the the mess. I also found it a good chance to practice implementing a model view controller pattern. This pattern turned out to be great for this appliction. I can easily add different stats and expand the utility of the program without rewriting everything.
