Future concepts to improve scaling

Over the past few days, we’ve spent a considerable amount of time looking at checklists and have finally accepted that they don’t provide the broad solution that we had hoped it would. It's not that checklists are bad, it's just that they don't always match our needs.

The "common checklist" is just that, a "list" of things that must be "checked". The most common example of a checklist are shopping lists. As a user you write down all the things you wish to buy, then go to the shop and every time you grab something from the shelve you cross the item of the list. This is simple and easy.

However, when we, as developers, are using the checklist, we noticed that this doesn't truly work for us. Our use case is a little bit more complex.

One thing we noticed was that we frequently abused the checklist by writing items in a specific order. This realization led us to understand that checklists can be either unordered or ordered, but they can also include conditional elements (such as the requirement to add screenshots only when the functionality is ready). Consequently, for more complex tasks, which we almost always encountered, we opted to create a separate map instead of using checklists. This approach proved to be a better fit for our needs.

The second thing we noticed was that we often preferred creating a separate map instead of extending the current map. This provides us with a clean context, but had the downside that when we worked from a high level perspective, we had to go search for details. Luckily you can place tasks on multiple maps so quite often we placed the "feature task" both on the high level map as well as the detailed map. This works, but we consider it a good working around.

So we have been working on a few new concepts. Keep in mind that all of this is still in the early design phase.

The first concept we like to call a "procedure". In essence it's a combination of a task and a map. As user you can drill down a procedure to see the other tasks/procedures. However to make this work we need to modify a lot on a technical level.

With procedures, we also are thinking about another concept called "branching". We already have this partially implemented since the concept of forking and joining are natural in a graph, but here we are talking about conditional branching allowing the user to make a choice to abandon a certain branch. This too requires a lot of modification on a technical level, especially if it's known ahead of time that only one branch can be taken.

Then there is the final concept we have been working on which we like to call "blueprints", which allows the user to create a template of a collection of tasks, so that it can easily be reproduced.

However, these are all concepts we have been working on. At the moment we are mostly busy with improving the many small issues. Once those small issues have been addressed we are likely to change the technical layout of the data so that it becomes easier to add additional systems.