How do you decide between blocks and pages? For example, I’d like to keep a log of all my job applications, with page/block properties such as company, status, feedback, website, resume, cover letter, date posted etc. On one hand, I don’t wanna clutter my link suggestions by creating a page for each job application, on the other hand, pages feel “cleaner” than blocks.
- For the various criteria, check this post and its links.
- For your specific example, if it is just a log, keep it in journal (i.e. in blocks).
1 Like
This is not a direct answer to your question but have you considered creating a separate graph for your job search?
For topics with a fair amount of notes that are very specific and may not be something I need long-term, I would separate them from my knowledge graph into their own graph. In your example, once you land your new job, you may want to archive your Job Search 2024 graph for future reference but not have it bloat your knowledge graph and return unintended query results.
1 Like
A rule of thumb is “a page is a block with a name”: if you need to reference it by its name then it’s a page, otherwise it’s a block.
3 Likes
The problem is that everything can be potentially referenced by name (in my case, “Applying for job in Company X”)
Sure, but is there a sentence in which you would actually use that reference?
I had the same challenge.
After playing around a lot, my rule of thumb is that I avoid creating a page or tag as much as possible and only create a page or tag when it is a high-level topic (or high-level folder like in file management) that holds related information like multiple job applications.
So I just “dump” my application information in the journal starting with the job title as a block. Then I tag the blog e.g. job application. Then I create a sub-block with the properties and so on.
On the page “job application” (created by the tag), I use queries to list all applications. By clicking on them, they appear in this “clean” way like a page. You also achieve this clean view by clicking on the bullet next to the high-level block.
1 Like
thank you! why do you think I should use blocks in this case?
Because what you plan to put inside is not proper knowledge, but mere information. Each application is neither a proper name, nor a concept (you cannot write an article about it), but a specific instance (one among many) of job application (this is the real concept). So the proper knowledge page is job application, and its instances are blocks.
I think I’d argue for a hierarchical page here or a name space. Something like [[Job Applications/Company XYZ]]. And then within the Job Applications page I would simply have it query the children and only list the ones that are relevant. I might even put a date code at the front of the page name like [[Job Applications/YYYYMMDD Company XYZ Job Title]]. That way if I am searching for pages directly and not with a query I can find them more easily and quickly.
I typically use Journal entries more for actions and chronological logging while pages are more for information.
Job Applications themselves aren’t super informative once they transition into interviews you’ll want to type them all together somehow and I’d tend to do that starting with the ancestor, in this case, the job application. But I also don’t want them turning into a soup in one page or really populating the general global name space as they aren’t things that I would commonly look for directly.
1 Like