Thanks to Federico Viticci at MacStories, last year I started using Toggl to track the time spent on many of my tasks. I started initially for two reasons. First, the work I was doing at the time was hourly, and I punched in and out for the day and for lunch. Keeping an account of how long I had been working and how long I had been away at lunch ensured I didn’t end my day or my lunch too early or too late.
Second, there are sometimes long stretches of time when I’m doing something—from working on Partly Sunny to playing a game to just reading Twitter—where I have no idea how long I’ve been doing that something. Tracking my time has allowed me to, well, keep track of my time—it has allowed me to better understand what I’m spending my time on. And in the case of working on a project, it allows me to better understand how long something actually takes to complete.
When I started using Toggl, I made sure to not be militant with my time tracking. I’m not tracking everything I do to the point where I get so annoyed with it and want to print out the Toggl website and set fire to it. But things that are work related and tech related—the things I need to track or the things I’m most curious about tracking—I’ve been tracking.
To aid in this tracking, I’m using the indispensable (and hopefully long-lasting) Workflow. While the new Toggl app has improved over the previous version, it still is clunky to use and doesn’t offer ways to quickly start and stop time entries—like, for example, a widget or Apple Watch app or even 3D Touch shortcuts—and doesn’t have a native iPad app. This is where Workflow comes to the rescue. Federico discussed how he used workflows to start and stop Toggl timers when Workflow gained the ability to more powerfully work with web APIs. Later, in an edition of Club MacStories, he wrote about a new approach that used dedicated workflows for quickly starting and stopping timers.
Using his modified workflow idea, I created several workflows fashioned to how I use Toggl. For example, I have a Partly Sunny timer that when run asks what I’m working on (development, testing, replying to emails, etc.) and starts a time entry with that chosen thing as its description. I also have a Games timer that asks what game I’m playing. For this timer, I have several defaults (including Alto’s Odyssey, Really Bad Chess, Mini Metro, and Rodeo Stampede), but I also have an “Other” option. I built my workflows so that if I select “Other”, Workflow will prompt me to type in the other thing I’m doing that isn’t a preset in the list.
As I was creating my timer workflows, I kept pulling out portions of them that were the same in each and creating reusable workflows to embed with the Run Workflow action (I’m still happy this was added to Workflow. The Run Workflow action has allowed me to create many reusable workflows to run inside other workflows.). For example, the actions that create the encoded Toggl authentication became a separate workflow. The actions that processed the selected description choice and asked for input when “Other” was selected became a workflow. My goal was to pull out all the duplicate actions so that if I ever wanted to update these core actions I wouldn’t have to update them in ten or more places.
Eventually I reached the point where I thought creating a sort-of “super workflow” for starting time entries was the way to go. Rather than having several reusable workflows, could I have just one? Challenge accepted! For me, part of the joy of using Workflow is actually building the workflows and experimenting to see what I can do. It’s like visual programming—visual problem solving.
What I ended up creating is a workflow that takes as input a dictionary of project IDs and a list of descriptions. It does some parsing and starts a time entry accordingly. Here’s what the workflow looks like (select the image for a larger version):
If I send the workflow more than one project ID or description, it asks which one I want to use for the time entry; if there is only one of either, it just uses that one project ID or description. And for the descriptions, if I select “Other”, the workflow prompts me to type in an other item. The workflow is also built to handle “None” for a description; choosing “None” starts a time entry with a blank description. Once this parsing and processing takes place, the workflow starts the time entry.
Because the super workflow does all the processing of IDs and descriptions and handles the Toggl API call that starts the time entry, I can more easily create other workflows that set up the timers or groups of timers. These timer-setup workflows then, with the Run Workflow action, run the super workflow. None of the timer-setup workflows contain any of the processing and handling actions, so if I need to adjust them in the future, I’m adjusting them in one place: the super workflow. Reusable code (sort of) for the win!
So what do the timer-setup workflows look like? They’re much simpler than the super workflow. Each timer-setup workflow contains a dictionary of project IDs and a list of possible time-entry descriptions associated with the project IDs. For example, my Partly Sunny timer workflow has one project ID—that for my Partly Sunny Toggl project—and a list of several possible descriptions: “Development”, “Testing”, “Replying to emails”, etc. The aforementioned games timer looks similar.
One of my other timers is a reading timer that has four project IDs in the projects dictionary (those for Twitter, Reddit, RSS, and Pocket) and one description in the list: “Reading”.
You’ll notice there are a few more actions under the Nothing action. Each of these timer workflows do include a few more actions that package the projects dictionary and the descriptions list into a dictionary that gets sent to the super workflow, and then the super workflow is run. None of these actions are modified when duplicating a timer workflow or creating a new one.
So with this setup, how easy is it to create a new timer workflow for something new I want to track? Let’s do it. I’m working on a new app project (more on this later), so I’m going to create a timer workflow for it. First, since I don’t have a workflow for this, I create the project on the Toggl website (I suppose I could—should?—make a workflow to do this). Next, I get the Toggl project ID for it with another workflow (that I believe came from Federico at some point) that returns a list of all my projects and prompts me to choose the one I want the ID of. The workflow copies the project ID to the clipboard for easy pasting in the next step.
Next, I duplicate an existing timer workflow and delete any project IDs and descriptions I don’t need for this new timer. In the projects dictionary, I type in the name of my project and paste in the ID. Then, in the descriptions list, I add any descriptions I want shortcuts for.
And that’s it. My new timer workflow is done. And it works in both the Workflow widget and the Apple Watch app.
Thanks to the indispensable Workflow, tracking my time with Toggl is easy and convenient. And thanks to the Run Workflow action, I can create reusable workflows to embed in other workflows instead of having duplicate actions in multiple places.
And a big thank you goes to Federico for inspiring me to not only better track my time but better track my time efficiently and conveniently with Workflow and Toggl.
Here are links to the various workflows:
- Super workflow
- Toggl auth (run from inside the super workflow)
- Timer example
- Get Toggl project ID
If you have ideas or suggestions to improve these workflows, please let me know!
Happy time tracking!
