TaskAlot 3.1 - Technical specification
The start page contains as in-line databases the entities that are discussed below as stand-alone databases.
- The Task page is a stand-alone database page with 8 views
- It contains a rollup-property Project category (next to a local category fiel that copies the category name from the project to which the task is associated. I don't remember why. Maybe
|Name||Name||Just the name of the task|
|Project||Relation||A task could be associated with multiple projects. That works fine through this kind of relation|
|Project status||Rollup||Tasks usually are associated with projects. This property contains the status of the project: This is needed in order to be able to have changes of project status propagate to the associated tasks. One potential problem: When a task is associated with multiple projects, and one projects gets closed but the other stays active. What will happen to this task (it should stay open)?|
|Category||Multi-select||A locally populated multi-select dropdown box - Seems overkill to define a database table just for categories|
|Project category||Rollup||Copy the project's category. I don't remember what this property is for. And how about when a task is part of multiple projects?|
The Projects page is a stand-alone database page with 3 views:
- Open projects
- Closed projects
- View: By category
The People page is a stand-alone database page with 1 gallery view.
The Notes page is a stand-alone database page with a list view.
Pages vs. Peek view templates
Peek view templates have been defined for the following objects/situations:
- Tasks » Daily overheads
- Projects » NewProjectTemplate-2022.11
- People » People template.
Although I initiually found peek view pages terribly confusing, I start to like them → Peek view (Notion).
Recently (last months 2022), recurrent tasks has been introduced to Notion. The TaskAlot 3.0 prototype contained some examples. Might be interesting, when I would use Notion also as an agenda - I can't wait to ditch Google Calendar.
Since folks with whom I collaborate, don't automatically have access to the system, have a database "Person", rather than using the build-in field Person to refer to folks with whom I collaborate.
In Notion, you can set for each object whether it is shared with someone:
- This is part of the free version of Notion
- It solves the private vs. shared problem: Folks can only see what is explicitly shared with them. E.g., they can't even see the other folks in the database Person
It has one major drawback: You need to share every object separately. It seems that you can't easily see what has been shared and what not.
Focus on dates, skip weeknumbers for now
I often think in weeks and weeknumbers, rather than dates. Can be become complicated within Notion. So let's first use just dates.
- Weeknumbers somehow should include the year as well: Eventually, there will come a time that it isn't obvious anymore to which year week 48 refered to
- There is an automatic field for when the card was created. I can translate that with a simple formula to a field Wk created. But what about a deadline on Monday in week 12? Really enter week 12, or rather the real date?