I've been using the TaskTimer application since I decided to pursue my game development dream. I used it for time tracking all the tasks in my game project from the beginning. But I'm not pleased with sticking to one thing. Jumping around different kinds of small jobs improves my creativity and releases stress. Besides game development, I like drawing and writing too. Those hobbies don't belong to any big project. But they still take my time and need to be tracked. Traditional project management does not suit these tiny tasks because lacking flexibility.
I realize the tagging or hashtag feature of the social media platform is flexible. It suits for small task management, which doesn't belong to any project.
In my opinion, there are many use cases for tagging. For example, I can select to view those tasks based on some tags ("writing" or "drawing"). It's faster than going through line by line of a very long list. Another case is managing tasks belonging to different projects by tagging them with the project name ("project A" or "project B"). Or we can know who works on specific tasks with the assignee name ("Adam" or "Eve").
Based on those characteristics, I implemented the tagging feature for TaskTimer for around 16 hours. My goal aims at the lean approach of MVP (Minimum Viable Product). I focus all of my effort on creating the core function instead of polishing the appearance of the new feature. But still, keep it easy to use (based on my experience).
I used a fake dataset to test the "Filter By Tags" feature in the development. They help me to check the righteousness of the new feature. Everything seems to be all right, but reality does not stop there. I tested it again with my real dataset. This progress taught me one thing is almost that bugs in offline or online applications usually happen with the official data. A small change could cause many issues when you update your code. It happens all the time. So be careful.
I had a lot of thoughts while working on this TaskTimer project. Such as the philosophy of the product designer. S/He is the one who decides the direction of the product based on their view. Different philosophies create different end products. For example, in traditional project management like Water Fall, the direction of the project managers start from the project to the tasks. The managers have a lot of power and responsibility. But they're usually not the ones has to dirty their hands to get things done. It creates a bureaucracy in the project team. The teammates only want to finish their tasks and not feel their impact on the final product. That is one of the Water Fall weaknesses. And it's hard to change anything in the software because they're all set from the beginning.
For those who are an artist or independent developers, flexibility and freedom are very important. They want to try many different things. Those experiments are small tasks and easy to finish. And things keep changing in their creative mind. If we look at it from this point of view, the best way to manage should start from the task. And all of the tasks pile up to build a complete project. That's the view I used to create TaskTimer.
Besides the philosophy lesson, I also learned some technical aspects of WPF. Such as leveraging UserControl and WrapPanel to create the tagging control as my expectation. I hope the Microsoft engineers will find a way to improve the Designer tool. So I can use it to customize the control style instead of XAML. The markup language (XAML) is complex and hard to understand. I think Unity Engine did a better job in this aspect.
Recently, Microsoft added the MAUI in their latest update. But I went too far with WPF in this TaskTimer project. There is a very tiny chance to try MAUI.
Anyway, I completed the feature I desired for the TaskTimer application. This update is only for my personal use. I will consider publishing it later when I feel it works flawlessly. In the meantime, you can download the previous version here for free.