Tracking teams' productivity was always a challenge. Trello tool helps to organize work and complete task. But how to interpret delivered cards so you will know more about your efficiency? Check this article, where I will go through the idea behind Trello Stats, what kind of challenges had to overcome as a front-end developer and what did I learn.
At my few months in as a front-end web developer trainee at DO OK, one of the colleagues from our workroom, shared an exciting idea for a web application - Trello Stats. After talking with our team leader, we decided that we will create it together.
Trello Stats is basically a standalone extension of Trello website which lets you track your teams’ productivity by displaying simple data about each user’s ongoing, finished and outdated tasks. If you haven’t had a chance to discover Trello before, it’s a web application that lets you organize your and your team’s work through boards. Boards are made of lists of small notes/descriptions/tasks - called cards. That’s pretty much the gist of it - you can then add due dates, assign users to certain tasks, mark tasks as complete and so on. The tasks as mentioned above made my colleague see a space that could be filled - there wasn’t a way to track how many tasks each user has done, how many are in progress, which user often doesn’t meet the deadlines etc. That’s where Trello Stats would come in, it would let you sign in using Trello, pick the board and see the info about each user’s tasks split into three categories - done, in progress, and outdated.
A quick Google search showed there aren’t any apps that would do what we aimed for; they were either too complex or didn’t really offer what we had in mind with Trello Stats. First and foremost, we wanted something simple, minimalistic; something with a good base foundation that we could build on, and as easy as possible for the user to get into. We’ve decided that without further ado, it’s time to get into it. First of all, we’ve made some base designs using Adobe XD, and after having that done, we’ve picked a tech stack. We decided to go with MERN (MongoDB, Express.js, React.js and Node.js) stack, which turned out to be a good fit for our needs.
Since we wanted to have some configuration and filtering through date spans, the first question was, how will the tasks be read and tracked by the system?
The fact that Trello has a built-in feature for checking tasks off as finished, and also picking the deadlines, initially made it pretty straightforward. Back-end could check which ones were done, outdated, or in progress by checking those values. However, this was only the beginning, as there were a few more cases to consider. First things first - what if the user preferred dragging finished tasks onto a board that he’d for example call “finished” instead of checking it off as finished via Trello feature? Some users prefer it that way or combining both.
Therefore, it ought to be an option.
After that, there was also one more thing to take into account - what if some cards were assigned to the user and they weren’t meant to be tasks but instead notes directed towards the said user? It should be possible to exclude lists like those.
Now to the less obvious parts - filtering by date. Should the system consider tasks in date spans only by their creation date or things such as tasks that are due, in progress, or were completed in the selected time interval? After some brainstorming, we’ve decided it would be the most straightforward to consider tasks by the creation date because otherwise, there would be too many little cases to worry about, and it could be confusing. For example - assignments that were in progress but didn’t have due dates (those are optional in Trello), would appear in virtually any date span, and we’ve assumed that the user would care mainly about the creation date, which would lead to the most relevant tasks for a particular time.
Ultimately, we’ve decided that the tasks initially will be read by the system. Outdated tasks are returned from back-end as outdated when they go past their due date without being marked as complete. Finished ones are marked as ended when the user has checked them off. Then the rest is returned as “in progress”.
After that, users should also have the ability to pick custom lists based on their purpose, hence the settings view.
In this situation, settings come down to three categories, where you can pick lists that contain tasks which are either done, outdated or lists that should be excluded from tracking altogether.
At that point, we have reached the core functionality of Trello Stats.
Contact our front-end team now!
What I love at DO OK is how everyone is so friendly and willing to help and explain things. As a beginner, it’s been helping me tremendously. During this project, I’ve learned quite a bit.
Whenever I’ve stumbled upon an issue that could be easily solved by using external plugins, I went on a search. A good example would be react-flatpickr, thanks to that plugin I’ve got a good, clean date picker ready to do some work in a matter of seconds. I could then modify it for my own needs, change the styling by overwriting its premade classes, and we’re set. Of course, it’s necessary to know the foundations and the concepts behind some things, but it’s not always necessary to reinvent the wheel again and again if time could be saved.
I also realized the importance of clean code. There’s always a place for innovation and refactoring, but it is good to know some rules and conventions that are currently the most relevant. Naming things so that they can be understood rather instantly by anyone, proper indentations, the order of imports and so on. Those things matter, and I haven’t really had a chance to pay attention to it before, due to my lack of knowledge and experience. I am happy how this project has put my mind onto it, thanks to my colleagues’ feedback.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand“ - Martin Fowler
Last but not least, I’ve got to work with back-end crafted by my colleague from our software development company. It was insanely satisfying to see how I get things from back-end by making requests and how it all works together. What I realized, and that’s probably more than obvious to a lot of you, is that the fact that we’re front-end developers doesn’t mean we should isolate ourselves in that particular part of web development, and we should understand at least the foundations of back-end and how computers in general communicate, and vice versa.
Don't forget to keep your code clean; it's essential for your career as a software developer.
One thing is certain - I had a lot of fun participating in this project. I think the idea behind it is interesting, and it is far from realizing its potential. We’re still at an early phase, and it has its’ core functionalities set. If you’d like to expand onto the ideas, share some suggestions, ideas - feel free to do so, we would absolutely love it!
It is open-source, and you can contribute to our company's repo on a Github here:
-cropped.png)
.jpg)