As I mentioned in my previous post, it is time to start a bit bigger project than creating a blog. Before actually opening a code editor, there are a few things to cover, what this project is.
Pain points
After trying various to-do app out there, unfortunately, I didn’t stick to any of them for very long, even though I wanted to. Giving it a thought, I came to a finding about some personal pain points with these apps:
- A lot of features that may or may not be used
- Must write down every single task to truly see the full potential of the app
- Must be religiously updated with the progress
All of this can be summarized into one single sentence. Popular to-do apps are trying to suit everybody’s needs to capture a wider audience without any particular system. Usually, this is solved by providing various templates based on different types of systems. This kind of to-do apps is great for already disciplined people. They either use a provided template or create their system and stick with it.
I am, on the other hand, not so much of a disciplined person. I spend way more time tinkering and trying to create a perfect system, if there is a feature, I must find a way to use it in a system. Surfing the internet for inspiration. By the end of the day, I almost always feel unsatisfied with how the systems turned out. There is always a thought that there is must be a better way and so the cycle repeats.
This becomes exhausting and I usually just give up. Just take a look at how many features are there:
Requirements for the solution
With the pain points discovered, I concluded what I want from a todo app:
- Must enforce a system that cannot be changed
- Must provide an alignment with long term goals (no shopping lists)
- Can keep track of the progress or history (so I can pat myself on the back later)
- Need updates to the task as little as possible
- A reference dashboard throughout the day
For the past couples of weeks, I did experimentations, keeping in mind the above requirements. I used the pen & paper app for quick iterations.
Very opinionated system for a to-do app
- Write down long term goal (good practice to run a goal through S.M.A.R.T. criteria)
- At the start of the week: write down up to 3 most important tasks for the week, making sure it is aligned with the long term goal
- At the start of the day: write down only 1 most important task of the day + up to 3 additional tasks (if required), making sure they are aligned with the week’s tasks
- During the day reference the tasks & write notes (if necessary)
- At the end of the day: review completed and not completed tasks. For not completed tasks indicate to remove the task or reschedule to another day.
- Repeat Step 3 - 5 till the end of the week
- At the end of the week: review completed and not completed tasks. For not completed tasks indicate to remove the task or reschedule to another week.
- Repeat Step 2 - 7 till the goal is achieved
- ???
- Profit
Keys items to be taken away from this system:
- Hard limit on the number of tasks: forces to think about the actual task that matters and prevents “just to do something to feel productive” tasks
- If the task is not completed by the end of the day/ week: was it really necessary for the goal completion?
- Only 2 times per day (ideally) the entry should be added: nor required to worry about the tasks always being up to date
- Provides a clear history of when and how the tasks are completed/ rescheduled/ deleted
The name
When starting a new project, an unreasonable amount of time is spent on the name, and this was no exception. The whole process of this systems feels like having a diary, just for the goals.
Thus the name of Giary (pronounced as Harry) comes from Goal D*iary*.
I know, very creative. 🧐
Basic features for MVP (Minimum Viable Product)
Because I used pen & paper it might not be quite straightforward to migrate to a digital form. To ease the migration, I have to define the very core features of the system.
- CRUD1 a goal
- CRUD a task
- Assign to a week or day
- Update a status (completed/ not completed/ rescheduled/ deleted)
- Reschedule a task
- Weekly and Daily view for a selected date to view history
- Authentication for cross-device data persistent
Technology stack
If there wasn’t a cross-device data persistent feature, I would most probably be fine with just coding the frontend. I, however, want to have the ability to access the data whether I am at my desk or in bed with my phone. I would need some sort of backend service, where I can store and retrieve the data via an API request.
I had an urge to just create my backend server with help of Laravel, but there more I thought about it, the less it made sense. Here are few things:
- Code a backend + frontend, which means doubling the amount of time spent on this project without meaningful progress
- Take care of correctly implementing security-related items for the backend server when it will be time for production
- Double the amount of bugs I would have to deal with.
- Potentially creating additional cost
With the above being said, I decided to just use Firebase as my backend. Firebase has a generous free tier which should be more than enough for a project like this.
The previous project was coded with Nuxt, which itself is based on Vue2, there are a few of the things like typescript or composition API that is still not fully supported and a bit clunky.
As a result, I will be using Vue3. It has first-class support for the typescript and I really want to try new composition API.
Next step
After all of that, the code editor will still be closed for a little while. For the next step, I will be designing a UI[^2]. This should help to:
- Visualize what data is required
- Quickly iterate the design for various screen sizes
- Save time coding the UI as the desired result is already known
A thought process for UI I will leave for the next post.
Like this? Buy me a coffee
-
Create, Read, Update, Delete ↩
Top comments (0)