It’s been a week now since publicly announcing my todo app, One Thing Done Today. Since the announcement, a handful of my friends have been using One Thing Done Today in the private beta and providing great feedback. I’ve been using OTDT daily to help me build OTDT as well as getting other things done. Both my friends and I using OTDT has allowed me to get great feedback in whats working and what could be improved in OTDT.
This week I rolled out the ability to archive and delete tasks in One Thing Done Today. But before rolling out these features I had to ask myself if these controls are even needed. With OTDT, I purposely made the UI simple and sparse, so that the user can focus on getting the task at hand done. Each element’s placement and inclusion has been intentional.
So when I set out to introduce archive and delete this week, I had to ask myself first, are they necessary for a person’s workflow and if so, why?
While using OTDT in my day-to-day, I noticed the list modal was getting quite cluttered since it shows every task ever create. The UI showed both completed tasks as well as tasks that were still waiting to be completed.
As the list continued to grow, if I didn’t complete a task that was created a while ago, I would have to scroll a ton to find it. On top of that all those finished tasks were becoming daunting to look at 
.
For this reason, I introduced the ability to archive a task. This gives the user the ability to do some house-cleaning to keep their list of tasks neat.
A usability lesson that I had learned while implementing the archive button was the positioning of the buttons in relation to the tasks. Originally I had put the archive button inline with the task. So that it showed up at the very end of the task title. After using it I realized that because every title differs in character length, the positioning of the button was always different.
This meant that the user spends a lot of time searching for the archive button. So I instead fixed the position of the archive button in the same spot for every task. Doing this mitigated the issue of searching for the archive button and sped up the ability to clean up your tasks list 
.
A couple of days after I had introduced archive, I noticed a pattern in my workflow with OTDT. There are times when tasks that exists in my list no longer needs to be done. I didn’t want to archive the item, since I don’t care about keeping it for historical reasons and although I could edit the task and repurpose it for getting something else done, it didn’t feel like an ideal workflow. For this reason, I decided to include the ability to delete a task.
When implementing the delete function, I initially thought about the data side. Each task has a status attribute which is used to indicate if it is incomplete, complete, archived and handle different states of the task. The UI is reflected upon these different states. At first, I thought about introducing a deleted state when implementing the delete function. This was because I thought like the archive function, a person might want to have a historical record of even deleted tasks — like how Gmail does it. When you delete an email in Gmail, it flags it and you have X amount of days to retrieve it before it is purged from your inbox.
Unlike emails, I don’t think tasks are that important in keeping around once a user deems it worthy of being deleted, so I decided to not introduce a status flag for it, but instead have it completely deleted from the database when the user deleted them.
As far as placement, I decided to group it next to the archive button so that a user can always know where it is in relation to a task.
There is still room to make the UI cleaner when the list of tasks continue to grow, but I think introducing these two controls this week was a step in the right direction in giving the user the ability to maintain their list. I hoping to spend time this week to implement Stripe so that I can keep the user sign-up flow within the app instead of leaving with the current Paypal setup.
