TaskAlot 3.1 - Technical specification: verschil tussen versies
Naar navigatie springen
Naar zoeken springen
| (12 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
| − | == | + | == Start Page == |
| − | + | The ''start page'' contains as ''in-line databases'' the entities that are discussed below as ''stand-alone databases''. | |
| − | + | == Task == | |
| − | * | + | * 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 |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Properties: | |
| − | == | + | {| class="wikitable" border="1" |
| + | |- | ||
| + | ! Property | ||
| + | ! Type | ||
| + | ! Remarks | ||
| + | |- | ||
| + | | 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? | ||
| + | |} | ||
| − | == | + | == Project == |
| − | + | The ''Projects page'' is a stand-alone database page with 3 views: | |
| − | + | * Open projects | |
| + | * Closed projects | ||
| + | * View: By category | ||
| − | == | + | == People page == |
| − | === | + | The ''People page'' is a stand-alone database page with 1 ''gallery view''. |
| + | |||
| + | == Notes page == | ||
| + | |||
| + | 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)]]. | ||
| + | |||
| + | == Recurrent tasks == | ||
| + | |||
| + | 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. | ||
== Collaborations == | == Collaborations == | ||
| Regel 50: | Regel 81: | ||
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. | 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. | ||
| + | |||
| + | Those complications: | ||
| + | |||
| + | * 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? | ||
== See also == | == See also == | ||
| + | * [[Peek view (Notion) | Peek view]] | ||
* [[TaskAlot 3.0 - Context | TaskAlot 3.0 - Context]] | * [[TaskAlot 3.0 - Context | TaskAlot 3.0 - Context]] | ||
* [[TaskAlot 3.1 - Functional specification | TaskAlot 3.1 - Functional specification]] | * [[TaskAlot 3.1 - Functional specification | TaskAlot 3.1 - Functional specification]] | ||
Huidige versie van 13 dec 2022 om 09:13
Start Page
The start page contains as in-line databases the entities that are discussed below as stand-alone databases.
Task
- 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
Properties:
| Property | Type | Remarks |
|---|---|---|
| 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? |
Project
The Projects page is a stand-alone database page with 3 views:
- Open projects
- Closed projects
- View: By category
People page
The People page is a stand-alone database page with 1 gallery view.
Notes page
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).
Recurrent tasks
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.
Collaborations
Database "Person"
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.
Those complications:
- 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?