В заметке-источнике есть ссылка на PDF-файл (или на djvu, или epub или любой другой подобный). Именно на него мы нажимаем и именно его мы аннотируем.
Пример
Жмёте на ссылку PDF-файла правой кнопкой мыши, потом "Open in default app". PDF-файл откроется в вашей стандартной читалке.
Этот способ подразумевает, что вы источниками управляете в самом Obsidian. В целом этот способ вполне себе самодостаточный.
Но с другой стороны, есть большой смысл в том, чтобы разделить управление источниками и управление знаниями. В таком случае стоит использовать что-то типа Zotero. Однако пихать ещё и его в гайд было бы чересчур жестоко. Да и не всем это нужно.
Обработка статей
Я тоже не нашёл хороший способ конвертировать статьи в PDF. Поэтому пользуюсь расширением, которое включает режим чтения и из него уже конвертирую в PDF. Проблему это не шибко решает, но по крайней мере статьи получаются более-менее читаемыми.
Про buttons
Можно сделать их в одну линию, но они будут не всегда корректно работать (если вообще заработают).
Пример
Вот тут, например, проекты будут открываться (плагин Projects), а из Templater шаблон не создастся. А вот, если создавать шаблон из QuickAdd, то всё будет окей.
Немного ещё про обработку (текстовых) источников
Я, пожалуй, сокращу алгоритм, который привёл в статье до более читаемого, хах. Ну, и немного его расширю. Возможно, что так я смогу показать какая схема, на мой взгляд, является "правильной" и возможно это вам поможет как-то получше и поточнее настроить и структурировать ваш рабочий процесс.
Общий алгоритм такой:
Быстрое чтение источника(выявление основной сути и обозначения для себя, что нужно ли в принципе дальше изучать текст)
Чтение с аннотированием(выделение опорных моментов, возможно написание по ходу дела комментариев, визуальные какие-то дорисовывания; этот этап нужен для того, чтобы чётко разметить текст, который мы собираемся обрабатывать)
На основе аннотацийформирование конспекта(отражение своего понимания текста; только тут начинается использоваться Obsidian)
Разбиение конспекта на атомные заметки(создание заметок, которые будут независимы и которые будут нести какую-то полезную, значимую информацию)
Вынесение атомных заметок в заметку-источник и приведение их в некую первичную плюс-минус читаемую структуру (частенько именно из заметок-источников будут набираться заметки для дальнейшего использования; выносить атомные заметки можно сразу после того как был атомизирован конспект по, например, какой-то главе книги)
Дальше уже на выбор
Создание мета-заметки, которая будет объединять какие-то определённые идеи из разных источников в одну "кучу"
Создание иерархии, которая будет предельно чётко показывать как идеи (заметки) друг к другу относятся (т.е. создание эдаких справочных страниц)
Создание проекта, который будет уже напрямую использовать заметки, которые были намайнены из различных источников
Создание прочих структур, которые могут, например, реализовывать какие-то иные алгоритмы обработки информации
Связывание заметок между собой – развитие сети взаимосвязанных мыслей (вообще говоря, этот процесс можно делать когда угодно – можно во время конспектирования, можно во время проектов, а можно напрямую заниматься перебором заметок)
Важно заметить, что не обязательно именно в таком жёстком виде использовать алгоритм. Да, и вообще мета-заметки и иерархии – это структуры, которые удобны, логичны и понятны именно мне (это стоит учитывать... хотя, вообще говоря, если почитать того же Зонке Аренса, то у него подобное также можно вполне себе найти).
Можно, например, начать с создания проекта, а потом под этот проект набирать источники, их обрабатывать и тем самым прогрессировать (решать поставленные задачи).
Можно сначала создать мета-заметку и вести в каком-то смысле исследование: ставить гипотезу, искать и обрабатывать источники, находить всё более сложные и точные вопросы, играть с мыслями. Потом, когда исследование куда-то наконец-то приведёт, то можно подрихтовать мета-заметку и сделать из неё нечто похожее на манускрипт (прообраз статьи, книги или чего-то похожего).
Иерархии же обычно выступают как служебная структура. Так, например, её довольно легко сделать когда мы изучаем что-то последовательно и в таком случае она выступает скорее просто как помогающая обучению. Но куда более интересны иерархии, когда мы их делаем по сложным и запутанным источникам или когда их в целом собираем из разрозненных источников (по сути через своего рода инсайты). В этом случае иерархии будут выступать скорее как хорошая интеллектуальная опора.
Наверное, даже будет разумнее начать именно с волнующих проблем, а не пытаться заниматься упорядочиванием всей поступающей информацией. Иначе говоря, стоит сначала создать потребность (смысл), а потом уже её пытаться удовлетворять за счёт изучения источников и обработки их в Obsidian.
***
Я уже начал писать статейку про все эти мета-заметки, иерархии и прочее, но с ней меня пока что разбирает прокрастинация. Так что надеюсь, что такие мои не шибко обогащенные примерами, и не очень структурированные комментарии как-то вам помогают.
Как-то уже и заскучал от того, что в русскоязычном пространстве давно ничего не появлялось интересного про Obsidian. И тут ваша статья.
Сразу замечу пару вещей из приятного. Статья у вас визуально хорошо размечена, да и в целом написана крайне понятно. Ну, и не могу не отметить, что иллюстрации у вас весьма симпатичные, хех.
Теперь о самой системе. Тут уже чисто моё мнение. Не претендую на объективность. Просто решил подкинуть немного критики и парочку идей.
Шаблоны для всех типов задач стоит сделать абсолютно одинаковыми по структуре. Для inbox в том числе.
Обоснование в том, что у вас основное слабое место находится в обработке inbox и как следствие проблемен процесс изменения типа задачи. Из-за разных шаблонов нужно слишком много делать ручных манипуляций. Ну, или изначально заниматься угадыванием типа задачи, что уже звучит не шибко надёжно.
Само же изменение типа задачи стоит делать с помощью изменения метаданных, например, плагином Metadata menu. Так процесс работы с задачами станет ближе к таск-менеджерам, что, в данном случае, будет, как мне кажется, хорошей оптимизацией.
Также дефолтной заметкой стоит сделать inbox-задачу. Причём назначить её создание на какой-нибудь хоткей (вполне себе можно даже назначить на ctrl+n). Ну, и сделать, чтобы по этому хоткею выдавалось окно в которое нужно вписать текст задачи. Так получится организовать быстрый рабочий процесс наполнения inbox:
нажал хоткей -> написал текст задачи -> жмакнул enter
Далее стоит вместо какой-то панели сделать отображение задач из inbox. Отсюда рождается следующий рабочий процесс – разбор inbox:
... -> нажал на задачу из inbox на панели -> поменял параметры задачи с помощью metadata menu (можно вызывать меню хоткеем или кнопкой, которая рядом с заметкой будет) -> нажал на следующую задачу из inbox на панели -> ...
Два этих процесса получится сделать только, если шаблоны для всего будут структурно одинаковыми, а отличие же будет обеспечиваться только метаданными. В целом такое единообразие довольно нетрудно достичь. Например, можно сделать вот так:
Шаблон
---
class: тут тип задачи
due: дата
attendees: тут будут ссылки на людей
---
```dataview
...
```
# Description
# Task(s)
- [ ] <% tp.file.title %>
# Notes/Agenda...
Все значения метаданных можно заранее определить и впоследствии расширять с помощью metadata menu(т.е. плагин будет чётко всё определять, а значит ничего в голове не нужно держать и при этом через этот же плагин можно будет модифицировать систему). А attendees можно вообще заавтоматизировать в виде выпадающего списка с мульти-выбором, т.е. сделать так, чтобы автоматически отображались все люди, которые есть в системе и при необходимости которых можно было быстро добавлять или убирать. Короче плагин metadata menu прям мощный в этом смысле.
С такой логикой, правда, придется подумать, что делать с плагином checklist. Вероятно даже, что он будет лишним.
Ещё несколько идей.
Для визуального различения задач можно использовать Supercharged Links. Хотя, наверное, было бы прикольнее, если вы придумали как можно использовать (автоматизировать) Banners – типа нажал на задачу, а там какая-нибудь красивая картинка вверху, которая мгновенно позволит определить тип задачи.
Возможно, чтобы метаданные не зашумляли визуал, можно вообще полностью скрыть блок yaml с помощью сниппета. В сниппете что-то типа такого должно быть:
Теоретически от пункта Links можно избавиться. Потому что у вас есть и так отображение входящих и исходящих ссылок. Сами же ссылки на другие задачи можно делать сразу в самих задачах. Например, положим, что у нас открыт проект и в нем будет такая задача:
- [ ] [[Сделать маленький шаг к великой цели]]
Т.е. задача уже и так как ссылка. Когда мы перейдем в эту задачу, то в перечне сразу же увидим, что она пришла из проекта. В общем Links – это лишняя сущность. Кстати, если проекты обозначить с помощью Supercharged Links, то можно будет в перечне ссылок сразу понять, что задача пришла именно из проекта, а не, например, из другой задачи.
В остальном же я думаю, что вы сделали отличную базовую систему, от которой можно легко оттолкнуться всякому, кто захочет начать управлять делами в Obsidian.
Я не уверен, но возможно для вдохновения вам покажется интересным вот этот парень. Я так и не разобрался как подробно у него всё работает, но на визуальном уровне всё выглядит интуитивным.
Классно) Уже прям намного лучше понял как устроена ваша система.
Вообще я, наверное, лучше подытожу, чем буду дальше разбирать ваши идеи и видения (а то так можно до бесконечности, хех).
Думаю основной профит нашего диалога в том, что
вы формализовали, уточнили аспекты вашей системы, что несомненно сделало ваше видение чуть более целостным и ясным, а саму систему немного более полезной и персонализированной
я узнал для себя новые механики управления задачами и проектами в ограниченных условиях конкретной софтины или, иначе говоря, в более общем смысле почерпнул из вас полезные идеи
за что спасибо) на мой взгляд, вы сделали однозначно крутую работу)
Немного ещё про контроль скажу. То, что вы приняли за "контроль над всем" скорее на деле же является проявлением принципов и определенных идей. Не будь их, то система по управлению делами превратилась бы в агрегатор несбывшихся желаний, а база знаний в огромную мусорную свалку.
Хотя всё равно отмечу, что мысль, которую вы скинули неплохая – так скажем подпинывающая, хах.
Про Note composer не знал, что всё так просто, хах)
То, что вы помните названия проектов - это хорошо, но ещё лучше, когда в менюшках показывается только релевантная информация - на случай, если память вас всё же в какой-то момент подведет. Кстати, это легко пофиксить, если добавить в excluded files все папки кроме projects. Но это, подойдет, если вы другие заметки не ищете через поиск по названию.
Про то как автоматизировать логику с due я не знаю. Теоретически я бы смотрел в сторону QuickAdd и в частности на функцию capture.
Предположение
Я, к сожалению, не знаю как заставить этот плагин отправлять задачи в нужные проектные заметки. Но зато довольно понятно как можно отправлять задачи в daily notes. Нужно указать в пути отправки такое:
Date_Notes/Daily/{{DATE}}
В самом же шаблоне вставки нужно сделать что-то по аналогии того, что добавляет tasks, т.е
- [ ] {{VALUE}} ➕ {{DATE}} ? {{DATE}}
Но в таком случае будет дублирование функционала: есть daily notes и есть tasks, который и так обозначает, что задача на сегодня. Можно попробовать с помощью templater завтоматизировать логику в виде вопросов (задача на сегодня? регулярная задача?), но я не знаю будет ли это работать вместе с QuickAdd. Однако опять же смысл это делать, если нет автоматизированной механики отправления задачи в нужный проект.
С другой стороны, если проекты обозначать тегами, то можно куда угодно из инбокса выкидывать задачи. Главное навесить тег.
Про наследование задач и проектов. Начнем с проектов на примере года. У вас есть проект "Изучение Obsidian" и в нём стоят метаданные
Date:: #2023-05
Когда наступит 2024 год, то этот проект автоматически не изменится на просроченный или на задачу 2024-го года, ну, и в целом не появляется никаких отметок, что во временном смысле задача потеряла актуальность и нуждается в пересмотре. Т.е. такое нужно вручную отслеживать.
С месячными задачами тоже самое - если в задаче стоит 6-ой месяц, а сейчас уже 7-ой, то вы не увидите эту задачу в своей текущей месячной заметке. В общем нужно всё вручную контролировать - наследовать. Или я просто не всёк как у вас рабочий процесс это учитывает.
Кстати, с обычными задачами тоже самое, но с ними вы сделали хотя бы логику с "Накопилось".
Вообще, вы сильно не смотрите на то, что я так много придирок написал. Так-то я понимаю как сложно сделать персональную систему, что для управления знаниями, что для задач, что для проектов: нужно много чего попробовать, многими знаниями накачать себя, а потом в довольно смелой манере приложить опыт и какие-то теоретические наработки при решении большой управленческой проблемы, к тому же в преломлении конкретной среды/инструмента/ограничений. У вас же вроде как получилось сделать что-то собранное и что вам помогает, а это однозначно круто!)
Прикольная система. Правда, чтобы понять как она работает мне пришлось хорошо так вчитаться в ваши пояснения и по ходу дела проверять на тестовой базе (то, что вы её сделали, это прям огонь). По ходу дела записывал свои наблюдения, поэтому то и дальнейший текст получился таким длинным.
Из достатков системы. Тут кратко. На мой взгляд система вполне себе рабочая и она будет приносить какую-то пользу, если, конечно, в ней разобраться.
Из недостатков. Тут уже намного больше. Прям намного... Но они все, в большей степени, точечные и исправимые (по крайней мере мне так кажется на первый взгляд).
В системе мало автоматизации
Много вещей производится вручную
Например, создание задачи из inbox и последующее её добавление в проект
Note composer добавляет в конец проекта и при этом как есть, т.е. не обрамляет текст в задачу (понимаю, что все завязано на Telegram, но все же должна быть какая-то универсальность)
При этом он показывает все заметки, хотя нужны только проекты
Саму же задачу нужно создавать через tasks
При этом нужно ещё и указать due, чтобы заработала логика в периодических заметках
Может быть всё проще и я банально не понял как это сделать
Механика для формирования задач на месяц есть, а механики наследования задач нет
По сути, если уж использовать Obsidian по серьезному, то все блоки callouts должны заполняться автоматически из текста самого проекта (проект это не только задачи, но и какой-то объясняющий, комментирующий, логирующий текст) и выступать просто как нечто суммирующее
задачи должны парситься из текста проекта
"Links" на внешние ресурсы также должны парситься автоматически из текста
"Мысли и разное" также должны за счёт каких-то специфических знаков изыматься автоматически из текста проекта
Метаданные должны легко меняться кнопочками, а не за счёт их переписывания
Это нужно хотя бы для того, чтобы не приходилось вспоминать все элементы системы (статусы и роли)
поддержка многих логик тоже поддерживается вручную
не хватает формального алгоритма работы со всеми задачами (отсюда сразу же проблема, что непонятно с какого боку в систему нужно заходить - есть много всего, много разных отображений, но какое самое важное, первичное?)
расширяемость системы обеспечивается путем переделывания шаблонов и их применения ко всем соответствующим заметкам (что в потенциале является очень занудным занятием)
ну, или надо заранее много думать об обратной совместимости с текущей системой (что ужас как затратно по времени и силам)
проблема использования Obsidian как раз в том, что если хорошо не продумать какую-то железобетонную логику, то обилие из возможностей просто может в какой-то момент убить все потуги
Не понял смысла всех периодических заметок
В них просто на автомате собирается какая-то информация по задачам, при этом сами по себе они нефункциональные
Нельзя ничего добавить и как следствие нигде не парсятся задачи из этих периодических заметок
Получается, что в системе рождается море типовых заметок, которые теряют актуальность сразу же после наступления следующего дня/месяца/года
Логически их все можно заменить одним дашбордом (канвасом)
В системе плоховато проработаны обзорные практики
Например, нельзя просто взять и посмотреть в одно какое-то место и увидеть всю систему сразу
Т.е. нельзя увидеть все проекты (пусть даже по одной роли) и все относящиеся к ним задачи
Кроме разве что годовой заметки, но её минус в том, что она показывает только проекты без задач
Кстати, ещё и по годам механики наследования нет
Имеющиеся же обзорные методы не дают возможности как-то изменять проекты не заходя в них (т.е. в данном случае это изменение ролей и статусов)
Чтобы понять к какому проекту относится задача, нужно на неё навестись мышкой (в идеале, конечно, должно быть понятно сразу к какой роли относятся все видимые задачи и к какому проекту)
Я так и не понял где надо посмотреть, чтобы понять какие задачи нужно делать сейчас или в ближайшем будущем и при этом я понимал контекст
Логика с одной задачей это не обзорная практика
Логика с созданными в данный день тоже не очень, т.к. время создания не придает какого-то однозначного приоритета
Заходить в конкретный день (planned), чтобы узнать какие задачи мне нужно сделать тоже не вариант, т.к. могут быть задачи, которые нужно сделать, но не в этот день, а в принципе в ближайшем будущем
Заходя в роль, я вижу проекты, но не вижу задач
Заходя в проект я вижу задачи по проекту, но не вижу актуальных задач из других, связанных и также актуальных проектов
Короче нет какого-то достаточного отображения, которое бы довольно быстро мне объясняло, что нужно делать и в контексте чего эта деятельность вообще лежит
Логики внепроектных задач таки нет, что как бы странно - не все же в наших жизнях должно быть проектом
Есть Read и Watch later, но это же не проекты - это просто списки с какими-то источниками
Кстати, если в них оставить такую же логику как и в обычных проектах, то будет длинное перемежение из просмотренного (что по сути нужно где-то в ином месте агрегировать) и запланированного. Т.е. будет длинная мешанина
Вообще ручное перетаскивание выполненных задач мне в целом кажется какой-то рутиной и занудной практикой (после эдак 500 задач, это просто должно крепко-накрепко надоесть)
В системе есть необоснованное дублирование
Есть заметки с ролями, а есть ещё теги с ролями (заметки дублируют теги)
Есть шаблоны для всех ролей, которые отличаются внутри только тегом (дублирование одной сущности)
planned/success это просто часть daily, которая чуть-чуть имеет другую логику, но не другой общий смысл (дублирование функционала)
и они тоже все затегированы, хотя лежат в отдельных папках (папки дублируют теги)
Календарь не имеет смысла
Он не показывает, когда есть запланированные дела
Нет смысла создавать дневные заметки через календарь, потому что в дневных заметках нет механики создания задач
Нет механики архивирования проектов
В целом отработана механика работы с проектами как с набором задач, а не как с комплексными проектам
В метафоричном смысле походит на ситуацию, где у тебя есть машина и где колёса ты почему-то решил крутить сам, а остальные части машины (возможности) ты тащишь как бы в довесок по приколу
Ну, и последний минус, который трудно исправимый и который по сути к системе не относится, а скорее к самому Obsidian.
Система будет работать только пока открыт Obsidian. В остальное же время, ты не получаешь уведомлений о задачах, нельзя добавить задачу на ходу с мобильного устройства (например, через функцию виджета), нельзя получить доступ к своей системе через веб с полной поддержкой интерфейса, нельзя шерить ссылки на сайты, на видосики, на заметки и прочее напрямую в инбокс Obsidian (да, энтузиасты сделали интеграцию с Telegram, что круто. Но есть же ещё и другие места, где мы получаем информацию).
Короче я понимаю, что как-то уж сильно разошёлся. Но в этом наверное и есть смысл - мы что-то выкладываем в открытый доступ, чтобы это как-то оценили.
Можно сказать, что в грубом приближении это одно и тоже. В более же тонком всё сильно разнится. Логирование процесса своего вникания – это прямолинейный способ в чём-то разобраться за счёт, условно говоря, "подражания" какому-то источнику на бумаге. Конспектирование – это процесс формирование сжатого пересказа самых главных идей, которые впоследствии будут где-то использоваться и переиспользоваться. Лог остается как есть. Конспект доделывается и шлифуется до адекватного уровня читаемости.
Однако я решил, что плагин projects довольно прост в освоении и весьма функционален. Но, чтобы в нём разделить чётенько на направления, нужно использовать именно подпапки.
Я лично юзаю плагин db-folder (его можно юзать из самого projects) и он мне немного больше нравится в плане конфигурирования. Сами файлы проектов у меня лежат в плоской структуре. Проекты же организуются сущностно также как и источники, т.е. через метаданные и ссылки.
Про шаблон для дефолтной заметки
Довольно трудный вопрос.
С одной стороны, хорошей мыслью будет добавить какой-то шаблон для дефолтной заметки. Возможно, даже из метаданных можно будет в будущем какую-то пользу получить.
Но с другой стороны, скорее всего дефолтные данные будут в большинство своём не более, чем информационным шумом. Хуже того, если вдруг появятся какие-то новые идеи о том как организовать шаблон обычной заметки, то, вероятно, придется переделывать все старые заметки. А это очень занудно и по сути опять же может ничего не дать.
Лично для себя я нашёл компромиссное решение. Я сделал такой дефолтный шаблон:
<%* -%> - эта штука нужна, чтобы "сломать" метаданные и шаблон перестал выдаваться при запросах
Он построен на использовании плагина для интервальных повторений. Как мне кажется, это более разумное решение, которое заменяет простой перебор своей базы в случайном порядке (так или иначе перебирать свою базу знаний всё равно дело полезное).
В остальном же обычные заметки у меня используются в виде ссылок в мета-заметках, в иерархиях, в проектах, в других заметках и этого более или чем достаточно. Периодически я использую логику вечнозелёных заметок, но делаю это вручную и когда я действительно понимаю, что это принесёт пользу. Можно сказать, что я наращиваю сложность точечно в конкретных случаях и только там, где она реально нужна. Иначе говоря, сложность достигается не за счёт сложной структуры самих заметок, а скорее за счёт сконцентрированного использования множества разных заметок в конкретном месте.
(Ну, и кстати, да... Стоит уточнить, что в системе у меня больше всего атомных заметок, поэтому дефолтные заметки у меня именно они.)
Источники унифицируются потому что они унифицируемы. Как бы это не тавтологично звучало. Также проекты, мета-заметки, периодические заметки, цитаты, заметки по авторам, иерархии и схожее тоже унифицируются, так как понятно, что в них должно быть. Но вот в обычной заметке трудно предсказать, что будет написано и как это можно заранее упорядочить. Поэтому лучше не тратить силы на гадания и тем более не подписываться на потенциальные последующие исправления.
Про картинки
Не знаю в чём причина. Должно всё чётко отрабатываться.
Про структуры в папке files
В ней лежит всё, что не является заметкой. Все структуры и перечисления нужных файлов мы делаем в заметках.
Хотя, наверное, всё же стоит отметить, что в моей логике, работа с файлами – это единоразовое мероприятие. Так в заметку добавляется какой-то документ, pdf, картинка и прочее, а в остальных же случаях делается ссылка именно на заметку, а не на файл.
Про обработку информации
Тоже сложный вопрос, хех.
Управление знаниями не шибко лёгкий процесс. То, о чём вы говорите не совсем относится к базам знаний.
Если уж совсем кратко, то у вас крайне короткий цикл работы со знаниями: черновик -> обработка -> чистовик.
Вам стоит прежде вот этот небольшой блок прочитать.
Как вы из него поняли, между сбором информации и её применением лежит довольно много других этапов. База знаний существует для того, чтобы голова не лопнула от натуга держать внутри все эти процессы, переходы и отношения.
Короче говоря, вам нужно порядок проблемы повысить, чтобы понять как поступить правильно. Этого можно, в первую очередь, добиться за счёт довольно прямолинейного способа – просто копить данные в базе знаний и ждать, пока не начнут проявляться систематические ошибки, мешающие дальнейшему эффективному накоплению и изъятию информации. Далее же анализировать эти ошибки, искать решения и их внедрять.
Менее прямолинейный способ, но более разумный заключается в следующем. Вам, например, нужно нарисовать подробную схему всех рабочих процессов в базе знаний (как знаете, как понимаете). Далее эту схему вам нужно улучшать по мере изучения каких-то источников про базы знаний (данных), про разные способы обработки информации, источники про работу мозга и обучение, про создание всяких разных сложных систем, про работу с проектами и т.д. Улучшаете схему -> улучшаете базу знаний.
Я понимаю, что таким ответом не решаю вашу проблему напрямую. Но, с другой стороны, я могу, конечно, теоретически (т.е. так я делать всё равно не буду) просто вам вывалить все решения и их обоснования, которые я принял в своей базе знаний. Но толку, как по мне, от этого не будет, так как вы просто будете примерять разные решения, вместо того, что напрямую реализовывать возможности уже имеющихся у вас инструментов в соответствии с вашими нуждами.
В общем моё предложение в том, что, либо подождите, пока решение родится из возникающих проблем, либо нарисуйте схему вашей базы и пытайтесь её улучшать за счёт её регулярного обдумывания (модификации) и новых знаний.
Запрос на две категории
dataview
```dataview
LIST
WHERE
contains(category, [[obsidian]])
OR
contains(category, [[Бег]])
``
В статье я оставил недоделанной тему автоматизации плагина Longform. В целом я так и не придумал каких-то простых способов, поэтому решу эту проблему как знаю. Однако сделаю я это, к сожалению, немного выбиваясь из логики прошлой статьи.
Решение с помощью templater
Плагин Templater может сам создавать директории, а Longform же парсит свои проекты с помощью метаданных. Этими фактами можно воспользоваться, чтобы создать функцию создания проекта Longform. Итак, создадим шаблон.
templater
<%*
let title = tp.file.title
if (title.startsWith("Untitled")) {
title = await tp.system.prompt("Title");
}
await tp.file.rename(title)
-%>---
type: project
longform:
format: scenes
title: <% title %>
workflow: Default Workflow
sceneFolder: /
scenes: []
ignoredFiles: []
---
<% tp.file.move("projects/" + title + "/" + title) %>
Суть его в следующем: блок, который идет до метаданных – я его юзал в прошлой статье (кратко логика его в том, что при создании заметки будет выдано окно в которое нужно вписать название заметки) type: project – у меня все проектные заметки лежат просто в папке projects (по сути это плоская структура за исключением папок для индивидуальных longform-projects, а все же направления задаются ссылками на заметки-категории, т.е. не папками как я сделал это в статье); отображение, сортировка и фильтрация делается у меня с помощью плагина db-folder (а не с помощью projects, как я сделал это в статье); короче говоря, у меня выделен отдельный тип заметок-проектов и это вам придется учитывать далее (именно это всё и выбивается из логики прошлой статьи) <% tp.file.move("projects/" + title + "/" + title) %> – эту штуку лучше объяснить на примере. Если мы создадим из шаблона заметку и назовём её, например, "Маркеры хорошей базы знаний", то будет создана заметка по пути "projects/Маркеры хорошей базы знаний/Маркеры хорошей базы знаний.md". Заметка созданная по этому пути будет работать и как индексная заметка для Longform, и как заметка, которую мы будем парсить (с помощью dataview или ещё как-то).
Создание проекта с помощью templater
Положим, что шаблон будет называться "longform template". Если его положить в папку к остальным шаблонам, то создать longform-проект можно будет с помощью самого templater.
Templater: Create new note from template
Если стоит плагин buttons, то кнопка будет такая:
button
```button
name ? longform project
type note(Untitled) template
action longform template
templater true
```
Создание с помощью QuickAdd
Если шаблон лежит где-то в ином месте (т.е. не в том, где templater берет шаблоны по дефолту), то вполне себе разумно добавить команду по созданию проекта с помощью QuickAdd.
Нужно создать новую команду из шаблона в настройках QuickAdd.
QuickAdd
1 - пишем название команды
2 - выбираем template
3 - жмем "Add Choice"
Заходим в настройки и в них нужно указать точное место шаблона в базе. Например, шаблон у нас может лежать по этому пути "projects/templates/longform template.md"
QuickAdd
Заходим в настройки
Вставляем (или пишем вручную) наш кастомный путь к шаблону "projects/templates/longform template.md" и жмем галочку, чтобы автоматически открывалась созданная заметка.
Закрываем это окно и жмём молнию, чтобы добавить команду в палитру команд.
Как вы могли заметить на предыдущем скрине, можно попытаться мимикрировать функцию под сам плагин Longform. Выглядеть это будет в палитре так:
Палитра команд
Ни шибко чисто выглядит, но в целом почему бы и нет?
Кстати, button будет выглядеть вот так:
button
```button
name ? longform project
type command
action QuickAdd: add PROJECT (longform)
templater true
```
Отображение проектов с помощью dataview
Тут может быть что-то типа такого.
dataview
```dataview
LIST
FROM "projects"
WHERE contains(type, "project")
```
Без указания типа заметки, как-то уж совсем трудновато придумать как можно отобразить single-project и longform-project в виде одного списка проектов.
Настройка в db-folder
Если вы юзаете этот плагин, то для корректного отображение придется немного изменить настройки:
db-folder (projects)
FROM "projects" WHERE type
Суть в том, что теперь он будет показывать заметки из папки projects у которых есть поле type. Это нужно для того, чтобы индексные файлы Longform также отображались как проекты (ну, и стоит отметить, что у обычных проектов тоже должен стоять в метаданных "type: project", чтобы они отображались).
Дополнения
Возможно вы уже поняли, что индексные файлы Longform можно называть как угодно – т.е. не обязательно, чтобы было название "index", которое предлагает сам плагин.
Не вижу большого смысла использовать Longform для single-project. Поэтому вам стоит, наверное, создать два шаблона: первый для longform, а второй для обычных проектных заметок. Однако, если вам всё же хочется единообразия, то можете этого попробовать добиться за счёт функции tp.system.suggester, которая будет вас спрашивать какой вам проект нужен (single или multi) и в зависимости от выбора менять шаблон.
Если вы создавали базу по моему гайду, то у вас все заметки создаются в корне, а файлы скидываются в папку files. Однако в случае Longform-проектов есть смысл складывать файлы по проекту в подпапку проекта (например, это нужно для того, чтобы потом можно были эти файлы проще как-то искать и использовать вне Obsidian, а также это полезно для архивирования). Чтобы так сделать нужно в настройках Obsidian поменять следующее:
files and links
Так мы сохраним логику с тем, что по дефолту заметки будут складываться в корень (это не относится к заметкам Longform), файлы по этим заметкам также будут лежать в папке files. Но файлы для Longform заметок будут складываться в папку проекта.
Архивирование проектов происходит путём скрытия папки в файлом менеджере. Плюс в том, что вы больше не видите проект в Obsidian. Минус в том, что если вы создали какие-то новые знания (новые заметки) из проектов, то при скрытии проектов пропадут связи и возможно какие-то заметки станут orphans.
Я сторонник атомизации мыслей. Мне кажется, что это добавляет больше возможностей
в улучшении понимания идей
благодаря самому процессу разбиения
за счёт нахождения их места в других местах/контекстах или иерархиях
в последующем использовании
в прикладном смысле (создание прототипов, продуктов, сложных систем, концепций, алгоритмов и прочего)
в создании более точных, ясных и понятных ссылок внутри системы
Атомизация довольно интеллектуально затратный процесс. Поэтому, я думаю, что не стоит растрачивать силы тогда, когда атомные заметки потом не получится толком нигде использовать.
В преломлении этой статьи. Она уже сама по себе является приложением. Вы её читаете и что-то внедряете. Несомненно есть большой смысл в том, чтобы как-то залогировать свой процесс вникания. Я, например, системы других обсидианщиков порой вообще не могу распарсить без ведения записей по ходу дела. Однако эти записи позже я не атомизирую, ибо достаточно и лога, который я сделал (по сути эти записи остаются просто как справочная страница).
Наверное, стоит привести пример, когда атомизация имеет смысл.
Представьте, что вы занимаетесь спортивной медициной. Допустим вам попалась статья, которая говорит о влиянии гипертермического закаливания (по простому сауны) на выделение гормона роста. Для вас это важная информация, потому что гормон роста влияет на регенерацию тканей. Вы добавляете эту статью в вашу базу знаний и начинаете её обрабатывать – выделяете важные моменты, записываете свои мысли, ведете в целом конспект, дописываете уточнения и расширения при необходимости, может быть иллюстрации какие-то рисуете, выделяете основные факторы и условия, проверяете на статистическую достоверность и всё в таком духе. Далее из статьи нужно вынести какую-то пользу. Это можно сделать в том числе за счёт атомной заметки.
Так вы можете выделить из своих записей основную суть (например, что гипертермическое закаливание повышает выносливость и гормон роста), добавить к этой сути конкретное перечисление условий (повышает на столько-то процентов гормон роста, в такой-то возрастной группе, при таких-то параметрах влажности и температуры, при таком-то времени и прочее) и всё это превратить в атомную заметку. Саму же атомную заметку далее стоит связать с заметками "гормон роста", "гипертемическое закаливание" и поместить её, например, в мета-заметку"факторы влияющие на гормон роста".
Что это всё даёт на практике? В следующий раз, когда вам, например, будет нужно повлиять на гормон роста спортсмена (в силу, например, его недостатка), вы, например, откроете поиск в базе знаний и напишете "гормон роста". По связям вы найдете и мета-заметку (где будут явно перечислены все факторы и все известные в целом вам способы), и соответственно при необходимости можете найти все подтверждающие исследования(которые тоже не подвешены в воздухе, ибо снабжены вашими размышлениями, акцентами, уточнениями и всем, что вы там написали, пока изучали статьи).
Надеюсь такой занудный и объемный пример более-менее прояснил картину. Как технически это все сделать есть в самой статье: можете открыть алгоритм, который в конце на блоке "атомизация (рефакторинг)" и последующий за ним "Связывание".
Второй вопрос. Про метаданные
Если в них нечего поместить в соответствии с их логикой, то ничего. Просто остаются пустыми.
На всякий случай уточню и расширю немного понимание:
tag – если исходить из логики статьи, то сюда можно поместить тег атомизации ⚛ и возможно тег для пересмотра заметки⏳, если есть плагин spaced repetition
children – здесь можно сделать ссылки на конспекты и в целом что-то порожденное источником (например, если это книга, то могут быть "проекты по книге...", "практическая работа по книге...", "прототипы по книге...", "мои статьи по книге...", "методические пособия по книге...", "результаты испытания по книге..." и прочее подобное), а также можно добавить сюда же ссылку на pdf-файл (что, наверное, даже будет немного практичнее, чем тот способ, который я указал в статье)
Третий вопрос. Про статусы
Работа с базой знаний – это марафон. Если в базе что-то очень долго обрабатывается, то ничего страшного. Никто никуда не должен торопить.
Возможно, чтобы у вас появилось более чёткое разграничение, стоит немного расширить количество статусов. Например, вот так:
todo - ожидающие обработки
Нигде ещё не упоминал, стоит, пожалуй, хоть тут сказать. Не стоит использовать базу знаний как агрегатор для read later. Ибо это может создать огромное количество бесполезных ссылок и создать длиннющие и совершенно неинформативные списки с источниками (типа какой смысл источника, если в нём нет вообще ничего?)
Статус todo стоит расценивать как прямое намерение в ближайшем будущемразобрать источник, потому что он, например, нужен для какого-то проекта
wip - в процессе работы
atom - ждёт разбиения (вариант, чтобы не использовать тег ⚛️ на источнике, а только на конспектах или где-то ещё)
abandoned - заброшенный источник (не приходит, к сожалению, в голову какое-то короткое слово)
done - обработанный источник
Четвертый вопрос. Про разные хранилища
Идея хорошая. Обоснование вполне себе нормальное. Но я, наверное, лучше бы так не рекомендовал делать.
Если достаточно точно проработать рабочий процесс, то путаницы не появится, а возможность использовать заметки и как справочные страницы, и как атомные останется.
Честно говоря, я так сейчас подумал... И понял, что у меня начинает голова пухнуть из-за того, что я не шибко могу представить как вообще должна работать разделённая на разные хранилища организация вики-стиля и zettelkasten-стиля.
Наверное, стоит ещё немного пояснений добавить. Если есть необходимость создать какой-то опорный текст или узконаправленную структуру, то можно пользоваться механизмом мета-заметок. (Для организации больших структур всё так же остаются категории.) Если нужно сделать что-то в обучающих целях или в качестве прикладной работы, то тут через механизм проектов. Если есть нужда создать какие-то иерархические структуры, то через механизм соответственно иерархических заметок. Вдобавок можно смазывать рабочие процессы с помощью вечнозеленых заметок и с помощью различных алгоритмов по типу ENCODE.
Надеюсь, что я ответил на ваши вопросы, ну и надеюсь, что покрыл большинство других потенциальных, хех.
```dataview
LIST
WHERE contains(type.class, "instruction")
```
Ещё, наверное, стоит отметить возможность использовать в качестве метаданных заметки. Это по сути значит, что можно будет получить пользу как от использования метаданных, так и от самой заметки, а именно от её связей.
yaml
---
category: [[instruction]]
---
но лучше всё же такое делать в самой заметке, чтобы ссылки были клибельными и Obsidian их исправлял автоматически при переименовании
category:: [[instruction]]
Отсюда рождается возможность использовать иные механики взаимодействия с заметками. Так в следующей статье будет, например, про одну из таких механик – про иерархические заметки.
Теги, к сожалению, не подразумевают, что между ними можно делать какие-то связи.
Возможно есть ещё какие-то различия, которые я не вспомнил. Можете вот эту статью глянуть для большего углубления.
Немного про категоризацию я вот тут написал. К этому могу разве что ещё немного объяснений добавить.
Вы добавляете в систему, допустим, 10-15 каких-то источников. Работаете с ними. В какой-то момент, вам может показаться, что эти источники сильно тематически друг с другом связаны. Вы думаете как их можно связать друг с другом.
Связь можно сделать через категорию. Пусть это, например, будет категория "furniture assembly instructions" (инструкции по сборке мебели). Создаёте заметку с одноименным названием (помечаете её тегом ?️ или каким-то иным вам привлекательным образом). Далее пробегаетесь по своим источникам, находите все те самые 10-15 связанных по тематике источников и категоризируете их. В статье я это сделал через поле "category". Можете ещё раз глянуть на пример книжной заметки в статье.
Если вы заранее знаете какая у вас может появиться категория, то можно в заметках-источниках проставить призрак заметки. Когда необходимость в категории появится, то вы просто создадите заметку и оформите её как надо.
Можно ещё через inbox аккумулировать источники. Это скорее можно использовать для того, чтобы не приходилось вручную проходиться по всем источникам в поисках нужного. Т.е. вы создаете заметку и в ней перечисляете все нужные вам ссылки и материалы по ходу работы или исследования, а потом со временем преобразуете её во что-то более постоянное (например, мета-заметку).
Далее, можно в заметке-категории сделать dataview-запрос на то, чтобы был сделан показ заметок относящихся к именно текущей категории. Это можно сделать, например, так:
dataview
```dataview
LIST
WHERE contains(category, [[]])
```
Если ссылку оставить пустой, то она автоматически будет расцениваться как ссылка на текущую заметку.
Можно ещё более точечно сгруппировать источники или просто заметки. В таком случае вы создаете мета-заметку и в ней перечисляете всё, что вам нужно. Мета-заметку также стоит отнести к какой-то категории. Возможно будет что-то такое (первая строчка – это название заметки):
пример мета-заметки
инструкции для сборки шкафов диванов кресел
category:: [[furniture assembly instructions]]
# Инструкции для шкафов
- угловые шкафы
- [[инструкция по сборке какого-то углового шкафа]]
- ...
- встроенные шкафы
- [[инструкция по сборке какого-то встроенного шкафа]]...
# Инструкции для кресел и диванов
## Инструкции для кресел
...
## Инструкции для диванов
...
Небольшое дополнение. Чтобы категориальные заметки не были подвешены в воздухе стоит их все создавать в какой-то индексной заметке (в статье я эту заметку так и называл "index"). Саму же индексную заметку стоит вынести, например, на dashboard. Это нужно для того, чтобы можно было легко искать все нужные темы и в целом понимать какие категории есть в системе. А вот сразу пример dataview-запроса, который отобразит вложенные категории, если у вас таковые появятся:
dataview
```dataview
LIST
FROM #?️
WHERE
!contains(file.inlinks, this.file.link)
AND
file.link != [[]]
SORT file.name ASC
```
Второй вопрос. Про сортировки
Можно плагин sortable добавить. Он позволит нажимать на колонки таблиц dataview и менять порядок сортировки.
В остальном же сортировку и фильтры в dataview можно сделать только вручную, т.е. делать отдельные запросы. Например, категориальная заметка является примером отдельного фильтра.
Если вам нужны прям какие-то продвинутые (более автоматизированные) возможности в сортировке и фильтрации, то стоит поставить плагин db-folder.
Ещё вариант это предварительно добавлять в шаблоны дату с помощью конструкции:
templater
<% tp.date.now() %>
Можно немного усложнить логику. Так можно добавить меню, которое при создании заметки будет спрашивать "Вы сегодня начали?". Если ответ "да", то он проставит сам дату в указанном месте:
Четвёртый вопрос. Про верность схемы работы с источниками
Да, схема, которую вы привели верная.
В целом могу разве, что ещё подкинуть идею. Помимо того, что есть категории, можно расширить также количество типов источников. Так, если у вас в базе знаний много именно инструкций, то почему бы не выделить их отдельно:
yaml
type: instruction
Но так лучше не делать, если нет уверенности в том, что это действительно нужно и это действительно принесёт пользу.
Пятый пункт, но не вопрос.
Довольно трудно выдать целиком всё видение про упорядочивание базы знаний, да ещё и в рамках комментариев. Более того, способов сгруппировать как-то знания довольно много и все они нуждаются в персональном рассмотрении. Чтобы у вас появилось более объемное видение того как всё это можно устроить, стоит глянуть или даже помучить своими вопросами других обсидианщиков.
Круто, что вы привели пример своего рабочего процесса. Это явно мне помогло в понимании сути вашего вопроса.
Пока я думал об ответе, у меня в голове произошёл некий конфликт. Его, пожалуй, и попробую раскрыть. Делать это буду на основе трех сторон.
Беспристрастная сторона.
Если у вас произошло именно такое распределение заметок, то пусть так оно и будет. Значит ваша база знаний построена на основе логики "формализую проблему - пытаюсь её решить - ход решения логирую" и вероятно этому не нужно противиться. Более того, скорее можно даже улучшить этот процесс за счёт придания более проектных свойств. Иначе говоря, стоит формировать базу знаний через призму проектов.
Очень пристрастная сторона.
Лично мне такой перевес не очень нравится. Ибо его я интерпретирую как то, что у вас в базе крайне мало переиспользуемых знаний. Что довольно плохо, так как сильно снижаются возможности в решении трудных, комплексных задач. Черновик (проект) – это всё же попытка решить какую-то узкую и конкретную проблему.
Попробую на примере объяснить, что я имею в виду. Представьте, что вам захотелось бы не купить и как-то заюзать Wi-Fi камеру, а её разработать. Порядок сложности, как вы понимаете, разный. Так, например, вам уже понадобились бы знания схемотехники, оптики, материаловедения, знания в области программирования (возможно проектирования) контроллеров, может ещё какие-то знания в области обработки цифровых и аналоговых сигналов. (Честно говоря, я не знаю как конкретно разрабатываются видеокамеры. Возможно областей больше и они ещё специфичнее.) Все эти области крайне наукоёмкие и, мягко говоря, их будет очень трудно использовать и переиспользовать в рамках лишь проектной базы знаний.
Компромиссная сторона.
Попробуйте как-то изменить ваше распределение в сторону, где у вас есть и довольно внушительный набор заметок с фундаментальными знаниями, и при этом, где вы этот же набор довольно интенсивно используете в своих проектах.
Не шибко врубаюсь о чём вы конкретно спрашиваете, поэтому отвечу в меру своего понимания.
Для того, чтобы удобно навигироваться по своим заметкам создается стартовая (начальная) страница. Способов её организовать множество. Однако в статье я предлагаю сделать отображение начальной страницы с помощью Dashboard.
Суть Dashboard в том, что эта штука позволяет в режиме preview отображать списки в несколько столбцов (в зависимости от свободного места по горизонтали).
То, что выделяется с помощью "---" является областью метаданных, которыми можно эффективно размечать (категоризировать) заметки.
В метаданных можно использовать:
свои какие-то ключи
например, можно использовать ключ type, чтобы выделить разные типы заметок
ключи предопределенные Obsidian
к таким относятся
aliases – задает альтернативные наименования для заметки
tag – задает тег для заметки
cssclass – применяет заданные (сгруппированные) изменения к заметке
также бывают ключи, которые задаются определенными плагинами и механику которых будет отрабатывать именно плагин
например, это может быть obsidianUIMode (суть которого изложена чуть выше в комментариях)
Если говорить в преломлении Dashboard, то он, условно говоря,создает новое значение для ключа cssclass (если же точнее, то Dashboard просто создает набор сгруппированных css изменений, который впоследствии может быть также сгруппировано применен). Когда вы указываете это значение в заметке, то Obsidian распознает и применяет отображение в соответствии с кодом (в нашем случае из сниппета).
Сниппет для отображения в виде Dashboard создается по той причине, что Obsidian решил именно так отрабатывать механику внесения постоянных и небольших пользовательских изменений в css код.
Если же вы хотите писать код как в конструкциях по типу Dashboard, то это не ко мне.
С другой стороны, возможно, вам просто не хватает организованности в процессе написания. Тут я разве что могу посоветовать поискать источники информации в таком стиле.
Это и неудивительно, что вам не встречаются материалы по тому как извлекать знания для написания статей. Этот процесс слишком тривиален – вы как-то смотрите на свои записи и на их основе пишете текст. К этому можно ещё добавить процесс группирования заметок конкретно для статей, но тут тоже нет большой разницы в том как вы это будете делать:
создадите проектную заметку и в её начале (или в каждой главе) укажете все нужные заметки;
будете на ходу интегрировать свои заметки в текст;
создадите отдельную мета-заметку и по ней будете ориентироваться;
протегируете все нужные заметки и будете надергивать их из поиска;
разложите заметки на canvas;
создадите определенную группу метаданных и будете по ней делать запросы в dataview.
От выбора способа группирования суть не изменится, так как механизм написания останется прежним – вы будете как-то смотреть на свои заметки, а потом на их основе писать.
Самое трудное – это искать нужные заметки (если они, конечно, есть... если их нет, то самое трудное их качественно вычленить из исследуемых материалов). И, увы, но этот поиск сильно зависит именно от того как у вас устроена база знаний. Отсюда и обилие статей, видео и курсов о том как эту базу знаний получше можно устроить и какие механизмы стоит внедрить.
Ну и да, эта статья больше говорит о том чем может отличаться процесс извлечения знаний в случае разных источников и в меньшей степени о том как построить базу знаний (именно об этом будет в следующей части).
Обработка книг
Не совсем так как вы описываете.
В заметке-источнике есть ссылка на PDF-файл (или на djvu, или epub или любой другой подобный). Именно на него мы нажимаем и именно его мы аннотируем.
Пример
Жмёте на ссылку PDF-файла правой кнопкой мыши, потом "Open in default app". PDF-файл откроется в вашей стандартной читалке.
Этот способ подразумевает, что вы источниками управляете в самом Obsidian. В целом этот способ вполне себе самодостаточный.
Но с другой стороны, есть большой смысл в том, чтобы разделить управление источниками и управление знаниями. В таком случае стоит использовать что-то типа Zotero. Однако пихать ещё и его в гайд было бы чересчур жестоко. Да и не всем это нужно.
Обработка статей
Я тоже не нашёл хороший способ конвертировать статьи в PDF. Поэтому пользуюсь расширением, которое включает режим чтения и из него уже конвертирую в PDF. Проблему это не шибко решает, но по крайней мере статьи получаются более-менее читаемыми.
Про buttons
Можно сделать их в одну линию, но они будут не всегда корректно работать (если вообще заработают).
Пример
Вот тут, например, проекты будут открываться (плагин Projects), а из Templater шаблон не создастся. А вот, если создавать шаблон из QuickAdd, то всё будет окей.
Немного ещё про обработку (текстовых) источников
Я, пожалуй, сокращу алгоритм, который привёл в статье до более читаемого, хах. Ну, и немного его расширю. Возможно, что так я смогу показать какая схема, на мой взгляд, является "правильной" и возможно это вам поможет как-то получше и поточнее настроить и структурировать ваш рабочий процесс.
Общий алгоритм такой:
Быстрое чтение источника (выявление основной сути и обозначения для себя, что нужно ли в принципе дальше изучать текст)
Чтение с аннотированием (выделение опорных моментов, возможно написание по ходу дела комментариев, визуальные какие-то дорисовывания; этот этап нужен для того, чтобы чётко разметить текст, который мы собираемся обрабатывать)
На основе аннотаций формирование конспекта (отражение своего понимания текста; только тут начинается использоваться Obsidian)
Разбиение конспекта на атомные заметки (создание заметок, которые будут независимы и которые будут нести какую-то полезную, значимую информацию)
Вынесение атомных заметок в заметку-источник и приведение их в некую первичную плюс-минус читаемую структуру (частенько именно из заметок-источников будут набираться заметки для дальнейшего использования; выносить атомные заметки можно сразу после того как был атомизирован конспект по, например, какой-то главе книги)
Дальше уже на выбор
Создание мета-заметки, которая будет объединять какие-то определённые идеи из разных источников в одну "кучу"
Создание иерархии, которая будет предельно чётко показывать как идеи (заметки) друг к другу относятся (т.е. создание эдаких справочных страниц)
Создание проекта, который будет уже напрямую использовать заметки, которые были намайнены из различных источников
Создание прочих структур, которые могут, например, реализовывать какие-то иные алгоритмы обработки информации
Связывание заметок между собой – развитие сети взаимосвязанных мыслей (вообще говоря, этот процесс можно делать когда угодно – можно во время конспектирования, можно во время проектов, а можно напрямую заниматься перебором заметок)
Важно заметить, что не обязательно именно в таком жёстком виде использовать алгоритм. Да, и вообще мета-заметки и иерархии – это структуры, которые удобны, логичны и понятны именно мне (это стоит учитывать... хотя, вообще говоря, если почитать того же Зонке Аренса, то у него подобное также можно вполне себе найти).
Можно, например, начать с создания проекта, а потом под этот проект набирать источники, их обрабатывать и тем самым прогрессировать (решать поставленные задачи).
Можно сначала создать мета-заметку и вести в каком-то смысле исследование: ставить гипотезу, искать и обрабатывать источники, находить всё более сложные и точные вопросы, играть с мыслями. Потом, когда исследование куда-то наконец-то приведёт, то можно подрихтовать мета-заметку и сделать из неё нечто похожее на манускрипт (прообраз статьи, книги или чего-то похожего).
Иерархии же обычно выступают как служебная структура. Так, например, её довольно легко сделать когда мы изучаем что-то последовательно и в таком случае она выступает скорее просто как помогающая обучению. Но куда более интересны иерархии, когда мы их делаем по сложным и запутанным источникам или когда их в целом собираем из разрозненных источников (по сути через своего рода инсайты). В этом случае иерархии будут выступать скорее как хорошая интеллектуальная опора.
Наверное, даже будет разумнее начать именно с волнующих проблем, а не пытаться заниматься упорядочиванием всей поступающей информацией. Иначе говоря, стоит сначала создать потребность (смысл), а потом уже её пытаться удовлетворять за счёт изучения источников и обработки их в Obsidian.
***
Я уже начал писать статейку про все эти мета-заметки, иерархии и прочее, но с ней меня пока что разбирает прокрастинация. Так что надеюсь, что такие мои не шибко обогащенные примерами, и не очень структурированные комментарии как-то вам помогают.
Как-то уже и заскучал от того, что в русскоязычном пространстве давно ничего не появлялось интересного про Obsidian. И тут ваша статья.
Сразу замечу пару вещей из приятного. Статья у вас визуально хорошо размечена, да и в целом написана крайне понятно. Ну, и не могу не отметить, что иллюстрации у вас весьма симпатичные, хех.
Теперь о самой системе. Тут уже чисто моё мнение. Не претендую на объективность. Просто решил подкинуть немного критики и парочку идей.
Шаблоны для всех типов задач стоит сделать абсолютно одинаковыми по структуре. Для inbox в том числе.
Обоснование в том, что у вас основное слабое место находится в обработке inbox и как следствие проблемен процесс изменения типа задачи. Из-за разных шаблонов нужно слишком много делать ручных манипуляций. Ну, или изначально заниматься угадыванием типа задачи, что уже звучит не шибко надёжно.
Само же изменение типа задачи стоит делать с помощью изменения метаданных, например, плагином Metadata menu. Так процесс работы с задачами станет ближе к таск-менеджерам, что, в данном случае, будет, как мне кажется, хорошей оптимизацией.
Также дефолтной заметкой стоит сделать inbox-задачу. Причём назначить её создание на какой-нибудь хоткей (вполне себе можно даже назначить на ctrl+n). Ну, и сделать, чтобы по этому хоткею выдавалось окно в которое нужно вписать текст задачи. Так получится организовать быстрый рабочий процесс наполнения inbox:
нажал хоткей -> написал текст задачи -> жмакнул enter
Далее стоит вместо какой-то панели сделать отображение задач из inbox. Отсюда рождается следующий рабочий процесс – разбор inbox:
... -> нажал на задачу из inbox на панели -> поменял параметры задачи с помощью metadata menu (можно вызывать меню хоткеем или кнопкой, которая рядом с заметкой будет) -> нажал на следующую задачу из inbox на панели -> ...
Два этих процесса получится сделать только, если шаблоны для всего будут структурно одинаковыми, а отличие же будет обеспечиваться только метаданными. В целом такое единообразие довольно нетрудно достичь. Например, можно сделать вот так:
Шаблон
Все значения метаданных можно заранее определить и впоследствии расширять с помощью metadata menu (т.е. плагин будет чётко всё определять, а значит ничего в голове не нужно держать и при этом через этот же плагин можно будет модифицировать систему). А attendees можно вообще заавтоматизировать в виде выпадающего списка с мульти-выбором, т.е. сделать так, чтобы автоматически отображались все люди, которые есть в системе и при необходимости которых можно было быстро добавлять или убирать. Короче плагин metadata menu прям мощный в этом смысле.
С такой логикой, правда, придется подумать, что делать с плагином checklist. Вероятно даже, что он будет лишним.
Ещё несколько идей.
Для визуального различения задач можно использовать Supercharged Links. Хотя, наверное, было бы прикольнее, если вы придумали как можно использовать (автоматизировать) Banners – типа нажал на задачу, а там какая-нибудь красивая картинка вверху, которая мгновенно позволит определить тип задачи.
Возможно, чтобы метаданные не зашумляли визуал, можно вообще полностью скрыть блок yaml с помощью сниппета. В сниппете что-то типа такого должно быть:
css-snippet
Теоретически от пункта Links можно избавиться. Потому что у вас есть и так отображение входящих и исходящих ссылок. Сами же ссылки на другие задачи можно делать сразу в самих задачах. Например, положим, что у нас открыт проект и в нем будет такая задача:
Т.е. задача уже и так как ссылка. Когда мы перейдем в эту задачу, то в перечне сразу же увидим, что она пришла из проекта. В общем Links – это лишняя сущность. Кстати, если проекты обозначить с помощью Supercharged Links, то можно будет в перечне ссылок сразу понять, что задача пришла именно из проекта, а не, например, из другой задачи.
В остальном же я думаю, что вы сделали отличную базовую систему, от которой можно легко оттолкнуться всякому, кто захочет начать управлять делами в Obsidian.
Я не уверен, но возможно для вдохновения вам покажется интересным вот этот парень. Я так и не разобрался как подробно у него всё работает, но на визуальном уровне всё выглядит интуитивным.
Это можно решить ссылкой на роль.
Meta и dataview
В самой [[Role01]] же поменять чуть-чуть запрос. Например, в "Проектах" поменять на такое:
Ну и в других местах, где вы по тегу делаете запрос вместо такого, тоже надо исправить. Где именно так происходит это уже вам виднее.
Классно) Уже прям намного лучше понял как устроена ваша система.
Вообще я, наверное, лучше подытожу, чем буду дальше разбирать ваши идеи и видения (а то так можно до бесконечности, хех).
Думаю основной профит нашего диалога в том, что
вы формализовали, уточнили аспекты вашей системы, что несомненно сделало ваше видение чуть более целостным и ясным, а саму систему немного более полезной и персонализированной
я узнал для себя новые механики управления задачами и проектами в ограниченных условиях конкретной софтины или, иначе говоря, в более общем смысле почерпнул из вас полезные идеи
за что спасибо) на мой взгляд, вы сделали однозначно крутую работу)
Немного ещё про контроль скажу. То, что вы приняли за "контроль над всем" скорее на деле же является проявлением принципов и определенных идей. Не будь их, то система по управлению делами превратилась бы в агрегатор несбывшихся желаний, а база знаний в огромную мусорную свалку.
Хотя всё равно отмечу, что мысль, которую вы скинули неплохая – так скажем подпинывающая, хах.
Видос хорошая идея, хех.
Про Note composer не знал, что всё так просто, хах)
То, что вы помните названия проектов - это хорошо, но ещё лучше, когда в менюшках показывается только релевантная информация - на случай, если память вас всё же в какой-то момент подведет. Кстати, это легко пофиксить, если добавить в excluded files все папки кроме projects. Но это, подойдет, если вы другие заметки не ищете через поиск по названию.
Про то как автоматизировать логику с due я не знаю. Теоретически я бы смотрел в сторону QuickAdd и в частности на функцию capture.
Предположение
Я, к сожалению, не знаю как заставить этот плагин отправлять задачи в нужные проектные заметки. Но зато довольно понятно как можно отправлять задачи в daily notes. Нужно указать в пути отправки такое:
В самом же шаблоне вставки нужно сделать что-то по аналогии того, что добавляет tasks, т.е
Но в таком случае будет дублирование функционала: есть daily notes и есть tasks, который и так обозначает, что задача на сегодня. Можно попробовать с помощью templater завтоматизировать логику в виде вопросов (задача на сегодня? регулярная задача?), но я не знаю будет ли это работать вместе с QuickAdd. Однако опять же смысл это делать, если нет автоматизированной механики отправления задачи в нужный проект.
С другой стороны, если проекты обозначать тегами, то можно куда угодно из инбокса выкидывать задачи. Главное навесить тег.
Про наследование задач и проектов. Начнем с проектов на примере года. У вас есть проект "Изучение Obsidian" и в нём стоят метаданные
Когда наступит 2024 год, то этот проект автоматически не изменится на просроченный или на задачу 2024-го года, ну, и в целом не появляется никаких отметок, что во временном смысле задача потеряла актуальность и нуждается в пересмотре. Т.е. такое нужно вручную отслеживать.
С месячными задачами тоже самое - если в задаче стоит 6-ой месяц, а сейчас уже 7-ой, то вы не увидите эту задачу в своей текущей месячной заметке. В общем нужно всё вручную контролировать - наследовать. Или я просто не всёк как у вас рабочий процесс это учитывает.
Кстати, с обычными задачами тоже самое, но с ними вы сделали хотя бы логику с "Накопилось".
Вообще, вы сильно не смотрите на то, что я так много придирок написал. Так-то я понимаю как сложно сделать персональную систему, что для управления знаниями, что для задач, что для проектов: нужно много чего попробовать, многими знаниями накачать себя, а потом в довольно смелой манере приложить опыт и какие-то теоретические наработки при решении большой управленческой проблемы, к тому же в преломлении конкретной среды/инструмента/ограничений. У вас же вроде как получилось сделать что-то собранное и что вам помогает, а это однозначно круто!)
Прикольная система. Правда, чтобы понять как она работает мне пришлось хорошо так вчитаться в ваши пояснения и по ходу дела проверять на тестовой базе (то, что вы её сделали, это прям огонь). По ходу дела записывал свои наблюдения, поэтому то и дальнейший текст получился таким длинным.
Из достатков системы. Тут кратко. На мой взгляд система вполне себе рабочая и она будет приносить какую-то пользу, если, конечно, в ней разобраться.
Из недостатков. Тут уже намного больше. Прям намного... Но они все, в большей степени, точечные и исправимые (по крайней мере мне так кажется на первый взгляд).
В системе мало автоматизации
Много вещей производится вручную
Например, создание задачи из inbox и последующее её добавление в проект
Note composer добавляет в конец проекта и при этом как есть, т.е. не обрамляет текст в задачу (понимаю, что все завязано на Telegram, но все же должна быть какая-то универсальность)
При этом он показывает все заметки, хотя нужны только проекты
Саму же задачу нужно создавать через tasks
При этом нужно ещё и указать due, чтобы заработала логика в периодических заметках
Может быть всё проще и я банально не понял как это сделать
Механика для формирования задач на месяц есть, а механики наследования задач нет
По сути, если уж использовать Obsidian по серьезному, то все блоки callouts должны заполняться автоматически из текста самого проекта (проект это не только задачи, но и какой-то объясняющий, комментирующий, логирующий текст) и выступать просто как нечто суммирующее
задачи должны парситься из текста проекта
"Links" на внешние ресурсы также должны парситься автоматически из текста
"Мысли и разное" также должны за счёт каких-то специфических знаков изыматься автоматически из текста проекта
Метаданные должны легко меняться кнопочками, а не за счёт их переписывания
Это нужно хотя бы для того, чтобы не приходилось вспоминать все элементы системы (статусы и роли)
поддержка многих логик тоже поддерживается вручную
не хватает формального алгоритма работы со всеми задачами (отсюда сразу же проблема, что непонятно с какого боку в систему нужно заходить - есть много всего, много разных отображений, но какое самое важное, первичное?)
расширяемость системы обеспечивается путем переделывания шаблонов и их применения ко всем соответствующим заметкам (что в потенциале является очень занудным занятием)
ну, или надо заранее много думать об обратной совместимости с текущей системой (что ужас как затратно по времени и силам)
проблема использования Obsidian как раз в том, что если хорошо не продумать какую-то железобетонную логику, то обилие из возможностей просто может в какой-то момент убить все потуги
Не понял смысла всех периодических заметок
В них просто на автомате собирается какая-то информация по задачам, при этом сами по себе они нефункциональные
Нельзя ничего добавить и как следствие нигде не парсятся задачи из этих периодических заметок
Получается, что в системе рождается море типовых заметок, которые теряют актуальность сразу же после наступления следующего дня/месяца/года
Логически их все можно заменить одним дашбордом (канвасом)
В системе плоховато проработаны обзорные практики
Например, нельзя просто взять и посмотреть в одно какое-то место и увидеть всю систему сразу
Т.е. нельзя увидеть все проекты (пусть даже по одной роли) и все относящиеся к ним задачи
Кроме разве что годовой заметки, но её минус в том, что она показывает только проекты без задач
Кстати, ещё и по годам механики наследования нет
Имеющиеся же обзорные методы не дают возможности как-то изменять проекты не заходя в них (т.е. в данном случае это изменение ролей и статусов)
Чтобы понять к какому проекту относится задача, нужно на неё навестись мышкой (в идеале, конечно, должно быть понятно сразу к какой роли относятся все видимые задачи и к какому проекту)
Я так и не понял где надо посмотреть, чтобы понять какие задачи нужно делать сейчас или в ближайшем будущем и при этом я понимал контекст
Логика с одной задачей это не обзорная практика
Логика с созданными в данный день тоже не очень, т.к. время создания не придает какого-то однозначного приоритета
Заходить в конкретный день (planned), чтобы узнать какие задачи мне нужно сделать тоже не вариант, т.к. могут быть задачи, которые нужно сделать, но не в этот день, а в принципе в ближайшем будущем
Заходя в роль, я вижу проекты, но не вижу задач
Заходя в проект я вижу задачи по проекту, но не вижу актуальных задач из других, связанных и также актуальных проектов
Короче нет какого-то достаточного отображения, которое бы довольно быстро мне объясняло, что нужно делать и в контексте чего эта деятельность вообще лежит
Логики внепроектных задач таки нет, что как бы странно - не все же в наших жизнях должно быть проектом
Есть Read и Watch later, но это же не проекты - это просто списки с какими-то источниками
Кстати, если в них оставить такую же логику как и в обычных проектах, то будет длинное перемежение из просмотренного (что по сути нужно где-то в ином месте агрегировать) и запланированного. Т.е. будет длинная мешанина
Вообще ручное перетаскивание выполненных задач мне в целом кажется какой-то рутиной и занудной практикой (после эдак 500 задач, это просто должно крепко-накрепко надоесть)
В системе есть необоснованное дублирование
Есть заметки с ролями, а есть ещё теги с ролями (заметки дублируют теги)
Есть шаблоны для всех ролей, которые отличаются внутри только тегом (дублирование одной сущности)
planned/success это просто часть daily, которая чуть-чуть имеет другую логику, но не другой общий смысл (дублирование функционала)
и они тоже все затегированы, хотя лежат в отдельных папках (папки дублируют теги)
Календарь не имеет смысла
Он не показывает, когда есть запланированные дела
Нет смысла создавать дневные заметки через календарь, потому что в дневных заметках нет механики создания задач
Нет механики архивирования проектов
В целом отработана механика работы с проектами как с набором задач, а не как с комплексными проектам
В метафоричном смысле походит на ситуацию, где у тебя есть машина и где колёса ты почему-то решил крутить сам, а остальные части машины (возможности) ты тащишь как бы в довесок по приколу
Ну, и последний минус, который трудно исправимый и который по сути к системе не относится, а скорее к самому Obsidian.
Система будет работать только пока открыт Obsidian. В остальное же время, ты не получаешь уведомлений о задачах, нельзя добавить задачу на ходу с мобильного устройства (например, через функцию виджета), нельзя получить доступ к своей системе через веб с полной поддержкой интерфейса, нельзя шерить ссылки на сайты, на видосики, на заметки и прочее напрямую в инбокс Obsidian (да, энтузиасты сделали интеграцию с Telegram, что круто. Но есть же ещё и другие места, где мы получаем информацию).
Короче я понимаю, что как-то уж сильно разошёлся. Но в этом наверное и есть смысл - мы что-то выкладываем в открытый доступ, чтобы это как-то оценили.
Про конспекты
Можно сказать, что в грубом приближении это одно и тоже. В более же тонком всё сильно разнится. Логирование процесса своего вникания – это прямолинейный способ в чём-то разобраться за счёт, условно говоря, "подражания" какому-то источнику на бумаге. Конспектирование – это процесс формирование сжатого пересказа самых главных идей, которые впоследствии будут где-то использоваться и переиспользоваться. Лог остается как есть. Конспект доделывается и шлифуется до адекватного уровня читаемости.
Про иконки
С помощью плагина Icon folder.
Про подпапки в projects
Можете сделать плоскую структуру.
Однако я решил, что плагин projects довольно прост в освоении и весьма функционален. Но, чтобы в нём разделить чётенько на направления, нужно использовать именно подпапки.
Я лично юзаю плагин db-folder (его можно юзать из самого projects) и он мне немного больше нравится в плане конфигурирования. Сами файлы проектов у меня лежат в плоской структуре. Проекты же организуются сущностно также как и источники, т.е. через метаданные и ссылки.
Про шаблон для дефолтной заметки
Довольно трудный вопрос.
С одной стороны, хорошей мыслью будет добавить какой-то шаблон для дефолтной заметки. Возможно, даже из метаданных можно будет в будущем какую-то пользу получить.
Но с другой стороны, скорее всего дефолтные данные будут в большинство своём не более, чем информационным шумом. Хуже того, если вдруг появятся какие-то новые идеи о том как организовать шаблон обычной заметки, то, вероятно, придется переделывать все старые заметки. А это очень занудно и по сути опять же может ничего не дать.
Лично для себя я нашёл компромиссное решение. Я сделал такой дефолтный шаблон:
yaml
<%* -%> - эта штука нужна, чтобы "сломать" метаданные и шаблон перестал выдаваться при запросах
Он построен на использовании плагина для интервальных повторений. Как мне кажется, это более разумное решение, которое заменяет простой перебор своей базы в случайном порядке (так или иначе перебирать свою базу знаний всё равно дело полезное).
В остальном же обычные заметки у меня используются в виде ссылок в мета-заметках, в иерархиях, в проектах, в других заметках и этого более или чем достаточно. Периодически я использую логику вечнозелёных заметок, но делаю это вручную и когда я действительно понимаю, что это принесёт пользу. Можно сказать, что я наращиваю сложность точечно в конкретных случаях и только там, где она реально нужна. Иначе говоря, сложность достигается не за счёт сложной структуры самих заметок, а скорее за счёт сконцентрированного использования множества разных заметок в конкретном месте.
(Ну, и кстати, да... Стоит уточнить, что в системе у меня больше всего атомных заметок, поэтому дефолтные заметки у меня именно они.)
Источники унифицируются потому что они унифицируемы. Как бы это не тавтологично звучало. Также проекты, мета-заметки, периодические заметки, цитаты, заметки по авторам, иерархии и схожее тоже унифицируются, так как понятно, что в них должно быть. Но вот в обычной заметке трудно предсказать, что будет написано и как это можно заранее упорядочить. Поэтому лучше не тратить силы на гадания и тем более не подписываться на потенциальные последующие исправления.
Про картинки
Не знаю в чём причина. Должно всё чётко отрабатываться.
Про структуры в папке files
В ней лежит всё, что не является заметкой. Все структуры и перечисления нужных файлов мы делаем в заметках.
Хотя, наверное, всё же стоит отметить, что в моей логике, работа с файлами – это единоразовое мероприятие. Так в заметку добавляется какой-то документ, pdf, картинка и прочее, а в остальных же случаях делается ссылка именно на заметку, а не на файл.
Про обработку информации
Тоже сложный вопрос, хех.
Управление знаниями не шибко лёгкий процесс. То, о чём вы говорите не совсем относится к базам знаний.
Если уж совсем кратко, то у вас крайне короткий цикл работы со знаниями: черновик -> обработка -> чистовик.
Вам стоит прежде вот этот небольшой блок прочитать.
Как вы из него поняли, между сбором информации и её применением лежит довольно много других этапов. База знаний существует для того, чтобы голова не лопнула от натуга держать внутри все эти процессы, переходы и отношения.
Короче говоря, вам нужно порядок проблемы повысить, чтобы понять как поступить правильно. Этого можно, в первую очередь, добиться за счёт довольно прямолинейного способа – просто копить данные в базе знаний и ждать, пока не начнут проявляться систематические ошибки, мешающие дальнейшему эффективному накоплению и изъятию информации. Далее же анализировать эти ошибки, искать решения и их внедрять.
Менее прямолинейный способ, но более разумный заключается в следующем. Вам, например, нужно нарисовать подробную схему всех рабочих процессов в базе знаний (как знаете, как понимаете). Далее эту схему вам нужно улучшать по мере изучения каких-то источников про базы знаний (данных), про разные способы обработки информации, источники про работу мозга и обучение, про создание всяких разных сложных систем, про работу с проектами и т.д. Улучшаете схему -> улучшаете базу знаний.
Я понимаю, что таким ответом не решаю вашу проблему напрямую. Но, с другой стороны, я могу, конечно, теоретически (т.е. так я делать всё равно не буду) просто вам вывалить все решения и их обоснования, которые я принял в своей базе знаний. Но толку, как по мне, от этого не будет, так как вы просто будете примерять разные решения, вместо того, что напрямую реализовывать возможности уже имеющихся у вас инструментов в соответствии с вашими нуждами.
В общем моё предложение в том, что, либо подождите, пока решение родится из возникающих проблем, либо нарисуйте схему вашей базы и пытайтесь её улучшать за счёт её регулярного обдумывания (модификации) и новых знаний.
Запрос на две категории
dataview
Логика contains как раз решает вашу проблему.
В статье я оставил недоделанной тему автоматизации плагина Longform. В целом я так и не придумал каких-то простых способов, поэтому решу эту проблему как знаю. Однако сделаю я это, к сожалению, немного выбиваясь из логики прошлой статьи.
Решение с помощью templater
Плагин Templater может сам создавать директории, а Longform же парсит свои проекты с помощью метаданных. Этими фактами можно воспользоваться, чтобы создать функцию создания проекта Longform. Итак, создадим шаблон.
templater
Суть его в следующем:
блок, который идет до метаданных – я его юзал в прошлой статье (кратко логика его в том, что при создании заметки будет выдано окно в которое нужно вписать название заметки)
type: project – у меня все проектные заметки лежат просто в папке projects (по сути это плоская структура за исключением папок для индивидуальных longform-projects, а все же направления задаются ссылками на заметки-категории, т.е. не папками как я сделал это в статье); отображение, сортировка и фильтрация делается у меня с помощью плагина db-folder (а не с помощью projects, как я сделал это в статье); короче говоря, у меня выделен отдельный тип заметок-проектов и это вам придется учитывать далее (именно это всё и выбивается из логики прошлой статьи)
<% tp.file.move("projects/" + title + "/" + title) %> – эту штуку лучше объяснить на примере. Если мы создадим из шаблона заметку и назовём её, например, "Маркеры хорошей базы знаний", то будет создана заметка по пути "projects/Маркеры хорошей базы знаний/Маркеры хорошей базы знаний.md". Заметка созданная по этому пути будет работать и как индексная заметка для Longform, и как заметка, которую мы будем парсить (с помощью dataview или ещё как-то).
Создание проекта с помощью templater
Положим, что шаблон будет называться "longform template". Если его положить в папку к остальным шаблонам, то создать longform-проект можно будет с помощью самого templater.
Templater: Create new note from template
Если стоит плагин buttons, то кнопка будет такая:
button
Создание с помощью QuickAdd
Если шаблон лежит где-то в ином месте (т.е. не в том, где templater берет шаблоны по дефолту), то вполне себе разумно добавить команду по созданию проекта с помощью QuickAdd.
Нужно создать новую команду из шаблона в настройках QuickAdd.
QuickAdd
1 - пишем название команды
2 - выбираем template
3 - жмем "Add Choice"
Заходим в настройки и в них нужно указать точное место шаблона в базе. Например, шаблон у нас может лежать по этому пути "projects/templates/longform template.md"
QuickAdd
Заходим в настройки
Вставляем (или пишем вручную) наш кастомный путь к шаблону "projects/templates/longform template.md" и жмем галочку, чтобы автоматически открывалась созданная заметка.
Закрываем это окно и жмём молнию, чтобы добавить команду в палитру команд.
Как вы могли заметить на предыдущем скрине, можно попытаться мимикрировать функцию под сам плагин Longform. Выглядеть это будет в палитре так:
Палитра команд
Ни шибко чисто выглядит, но в целом почему бы и нет?
Кстати, button будет выглядеть вот так:
button
Отображение проектов с помощью dataview
Тут может быть что-то типа такого.
dataview
Без указания типа заметки, как-то уж совсем трудновато придумать как можно отобразить single-project и longform-project в виде одного списка проектов.
Настройка в db-folder
Если вы юзаете этот плагин, то для корректного отображение придется немного изменить настройки:
db-folder (projects)
Суть в том, что теперь он будет показывать заметки из папки projects у которых есть поле type. Это нужно для того, чтобы индексные файлы Longform также отображались как проекты (ну, и стоит отметить, что у обычных проектов тоже должен стоять в метаданных "type: project", чтобы они отображались).
Дополнения
Возможно вы уже поняли, что индексные файлы Longform можно называть как угодно – т.е. не обязательно, чтобы было название "index", которое предлагает сам плагин.
Не вижу большого смысла использовать Longform для single-project. Поэтому вам стоит, наверное, создать два шаблона: первый для longform, а второй для обычных проектных заметок. Однако, если вам всё же хочется единообразия, то можете этого попробовать добиться за счёт функции tp.system.suggester, которая будет вас спрашивать какой вам проект нужен (single или multi) и в зависимости от выбора менять шаблон.
Если вы создавали базу по моему гайду, то у вас все заметки создаются в корне, а файлы скидываются в папку files. Однако в случае Longform-проектов есть смысл складывать файлы по проекту в подпапку проекта (например, это нужно для того, чтобы потом можно были эти файлы проще как-то искать и использовать вне Obsidian, а также это полезно для архивирования). Чтобы так сделать нужно в настройках Obsidian поменять следующее:
files and links
Так мы сохраним логику с тем, что по дефолту заметки будут складываться в корень (это не относится к заметкам Longform), файлы по этим заметкам также будут лежать в папке files. Но файлы для Longform заметок будут складываться в папку проекта.
Архивирование проектов происходит путём скрытия папки в файлом менеджере. Плюс в том, что вы больше не видите проект в Obsidian. Минус в том, что если вы создали какие-то новые знания (новые заметки) из проектов, то при скрытии проектов пропадут связи и возможно какие-то заметки станут orphans.
Ядрёные (в смысле непростые) вопросы, хах.
Немного не понял, что вы имеете в виду:
Первый вопрос. Про атомизацию
Почти философский вопрос.
Я сторонник атомизации мыслей. Мне кажется, что это добавляет больше возможностей
в улучшении понимания идей
благодаря самому процессу разбиения
за счёт нахождения их места в других местах/контекстах или иерархиях
в последующем использовании
в прикладном смысле (создание прототипов, продуктов, сложных систем, концепций, алгоритмов и прочего)
в создании более точных, ясных и понятных ссылок внутри системы
Атомизация довольно интеллектуально затратный процесс. Поэтому, я думаю, что не стоит растрачивать силы тогда, когда атомные заметки потом не получится толком нигде использовать.
В преломлении этой статьи. Она уже сама по себе является приложением. Вы её читаете и что-то внедряете. Несомненно есть большой смысл в том, чтобы как-то залогировать свой процесс вникания. Я, например, системы других обсидианщиков порой вообще не могу распарсить без ведения записей по ходу дела. Однако эти записи позже я не атомизирую, ибо достаточно и лога, который я сделал (по сути эти записи остаются просто как справочная страница).
Наверное, стоит привести пример, когда атомизация имеет смысл.
Представьте, что вы занимаетесь спортивной медициной. Допустим вам попалась статья, которая говорит о влиянии гипертермического закаливания (по простому сауны) на выделение гормона роста. Для вас это важная информация, потому что гормон роста влияет на регенерацию тканей. Вы добавляете эту статью в вашу базу знаний и начинаете её обрабатывать – выделяете важные моменты, записываете свои мысли, ведете в целом конспект, дописываете уточнения и расширения при необходимости, может быть иллюстрации какие-то рисуете, выделяете основные факторы и условия, проверяете на статистическую достоверность и всё в таком духе. Далее из статьи нужно вынести какую-то пользу. Это можно сделать в том числе за счёт атомной заметки.
Так вы можете выделить из своих записей основную суть (например, что гипертермическое закаливание повышает выносливость и гормон роста), добавить к этой сути конкретное перечисление условий (повышает на столько-то процентов гормон роста, в такой-то возрастной группе, при таких-то параметрах влажности и температуры, при таком-то времени и прочее) и всё это превратить в атомную заметку. Саму же атомную заметку далее стоит связать с заметками "гормон роста", "гипертемическое закаливание" и поместить её, например, в мета-заметку "факторы влияющие на гормон роста".
Что это всё даёт на практике? В следующий раз, когда вам, например, будет нужно повлиять на гормон роста спортсмена (в силу, например, его недостатка), вы, например, откроете поиск в базе знаний и напишете "гормон роста". По связям вы найдете и мета-заметку (где будут явно перечислены все факторы и все известные в целом вам способы), и соответственно при необходимости можете найти все подтверждающие исследования (которые тоже не подвешены в воздухе, ибо снабжены вашими размышлениями, акцентами, уточнениями и всем, что вы там написали, пока изучали статьи).
Надеюсь такой занудный и объемный пример более-менее прояснил картину. Как технически это все сделать есть в самой статье: можете открыть алгоритм, который в конце на блоке "атомизация (рефакторинг)" и последующий за ним "Связывание".
Второй вопрос. Про метаданные
Если в них нечего поместить в соответствии с их логикой, то ничего. Просто остаются пустыми.
На всякий случай уточню и расширю немного понимание:
tag – если исходить из логики статьи, то сюда можно поместить тег атомизации ⚛ и возможно тег для пересмотра заметки⏳, если есть плагин spaced repetition
children – здесь можно сделать ссылки на конспекты и в целом что-то порожденное источником (например, если это книга, то могут быть "проекты по книге...", "практическая работа по книге...", "прототипы по книге...", "мои статьи по книге...", "методические пособия по книге...", "результаты испытания по книге..." и прочее подобное), а также можно добавить сюда же ссылку на pdf-файл (что, наверное, даже будет немного практичнее, чем тот способ, который я указал в статье)
Третий вопрос. Про статусы
Работа с базой знаний – это марафон. Если в базе что-то очень долго обрабатывается, то ничего страшного. Никто никуда не должен торопить.
Возможно, чтобы у вас появилось более чёткое разграничение, стоит немного расширить количество статусов. Например, вот так:
todo - ожидающие обработки
Нигде ещё не упоминал, стоит, пожалуй, хоть тут сказать. Не стоит использовать базу знаний как агрегатор для read later. Ибо это может создать огромное количество бесполезных ссылок и создать длиннющие и совершенно неинформативные списки с источниками (типа какой смысл источника, если в нём нет вообще ничего?)
Статус todo стоит расценивать как прямое намерение в ближайшем будущем разобрать источник, потому что он, например, нужен для какого-то проекта
wip - в процессе работы
atom - ждёт разбиения (вариант, чтобы не использовать тег ⚛️ на источнике, а только на конспектах или где-то ещё)
abandoned - заброшенный источник (не приходит, к сожалению, в голову какое-то короткое слово)
done - обработанный источник
Четвертый вопрос. Про разные хранилища
Идея хорошая. Обоснование вполне себе нормальное. Но я, наверное, лучше бы так не рекомендовал делать.
Если достаточно точно проработать рабочий процесс, то путаницы не появится, а возможность использовать заметки и как справочные страницы, и как атомные останется.
Честно говоря, я так сейчас подумал... И понял, что у меня начинает голова пухнуть из-за того, что я не шибко могу представить как вообще должна работать разделённая на разные хранилища организация вики-стиля и zettelkasten-стиля.
Наверное, стоит ещё немного пояснений добавить. Если есть необходимость создать какой-то опорный текст или узконаправленную структуру, то можно пользоваться механизмом мета-заметок. (Для организации больших структур всё так же остаются категории.) Если нужно сделать что-то в обучающих целях или в качестве прикладной работы, то тут через механизм проектов. Если есть нужда создать какие-то иерархические структуры, то через механизм соответственно иерархических заметок. Вдобавок можно смазывать рабочие процессы с помощью вечнозеленых заметок и с помощью различных алгоритмов по типу ENCODE.
Надеюсь, что я ответил на ваши вопросы, ну и надеюсь, что покрыл большинство других потенциальных, хех.
Я не знаю почему у вас так. Проверьте документацию.
Ммм, наверное, можно сказать, что разница в разделенности.
tag – это внутренний функционал Obsidian. Логика тегов расширяется только за счёт вложенности. Например
tag
type и category – это заданные пользователем метаданные. Тут, наверное, стоит особенно подчеркнуть, что именно пользователем.
Логику метаданных можно расширять также за счёт вложенности, но только уже более прозрачно:
yaml
Пример того как можно достать данные:
dataview
Ещё, наверное, стоит отметить возможность использовать в качестве метаданных заметки. Это по сути значит, что можно будет получить пользу как от использования метаданных, так и от самой заметки, а именно от её связей.
yaml
но лучше всё же такое делать в самой заметке, чтобы ссылки были клибельными и Obsidian их исправлял автоматически при переименовании
Отсюда рождается возможность использовать иные механики взаимодействия с заметками. Так в следующей статье будет, например, про одну из таких механик – про иерархические заметки.
Теги, к сожалению, не подразумевают, что между ними можно делать какие-то связи.
Возможно есть ещё какие-то различия, которые я не вспомнил. Можете вот эту статью глянуть для большего углубления.
Первый вопрос. Про темы
Немного про категоризацию я вот тут написал. К этому могу разве что ещё немного объяснений добавить.
Вы добавляете в систему, допустим, 10-15 каких-то источников. Работаете с ними. В какой-то момент, вам может показаться, что эти источники сильно тематически друг с другом связаны. Вы думаете как их можно связать друг с другом.
Связь можно сделать через категорию. Пусть это, например, будет категория "furniture assembly instructions" (инструкции по сборке мебели). Создаёте заметку с одноименным названием (помечаете её тегом ?️ или каким-то иным вам привлекательным образом). Далее пробегаетесь по своим источникам, находите все те самые 10-15 связанных по тематике источников и категоризируете их. В статье я это сделал через поле "category". Можете ещё раз глянуть на пример книжной заметки в статье.
Если вы заранее знаете какая у вас может появиться категория, то можно в заметках-источниках проставить призрак заметки. Когда необходимость в категории появится, то вы просто создадите заметку и оформите её как надо.
Можно ещё через inbox аккумулировать источники. Это скорее можно использовать для того, чтобы не приходилось вручную проходиться по всем источникам в поисках нужного. Т.е. вы создаете заметку и в ней перечисляете все нужные вам ссылки и материалы по ходу работы или исследования, а потом со временем преобразуете её во что-то более постоянное (например, мета-заметку).
Далее, можно в заметке-категории сделать dataview-запрос на то, чтобы был сделан показ заметок относящихся к именно текущей категории. Это можно сделать, например, так:
dataview
Если ссылку оставить пустой, то она автоматически будет расцениваться как ссылка на текущую заметку.
Можно ещё более точечно сгруппировать источники или просто заметки. В таком случае вы создаете мета-заметку и в ней перечисляете всё, что вам нужно. Мета-заметку также стоит отнести к какой-то категории. Возможно будет что-то такое (первая строчка – это название заметки):
пример мета-заметки
Небольшое дополнение. Чтобы категориальные заметки не были подвешены в воздухе стоит их все создавать в какой-то индексной заметке (в статье я эту заметку так и называл "index"). Саму же индексную заметку стоит вынести, например, на dashboard. Это нужно для того, чтобы можно было легко искать все нужные темы и в целом понимать какие категории есть в системе. А вот сразу пример dataview-запроса, который отобразит вложенные категории, если у вас таковые появятся:
dataview
Второй вопрос. Про сортировки
Можно плагин sortable добавить. Он позволит нажимать на колонки таблиц dataview и менять порядок сортировки.
В остальном же сортировку и фильтры в dataview можно сделать только вручную, т.е. делать отдельные запросы. Например, категориальная заметка является примером отдельного фильтра.
Если вам нужны прям какие-то продвинутые (более автоматизированные) возможности в сортировке и фильтрации, то стоит поставить плагин db-folder.
Третий вопрос. Про даты
Наверное, самый простой способ, это использовать плагин natural language dates.
Ещё вариант это предварительно добавлять в шаблоны дату с помощью конструкции:
templater
Можно немного усложнить логику. Так можно добавить меню, которое при создании заметки будет спрашивать "Вы сегодня начали?". Если ответ "да", то он проставит сам дату в указанном месте:
templater
Четвёртый вопрос. Про верность схемы работы с источниками
Да, схема, которую вы привели верная.
В целом могу разве, что ещё подкинуть идею. Помимо того, что есть категории, можно расширить также количество типов источников. Так, если у вас в базе знаний много именно инструкций, то почему бы не выделить их отдельно:
yaml
Но так лучше не делать, если нет уверенности в том, что это действительно нужно и это действительно принесёт пользу.
Пятый пункт, но не вопрос.
Довольно трудно выдать целиком всё видение про упорядочивание базы знаний, да ещё и в рамках комментариев. Более того, способов сгруппировать как-то знания довольно много и все они нуждаются в персональном рассмотрении. Чтобы у вас появилось более объемное видение того как всё это можно устроить, стоит глянуть или даже помучить своими вопросами других обсидианщиков.
Круто, что вы привели пример своего рабочего процесса. Это явно мне помогло в понимании сути вашего вопроса.
Пока я думал об ответе, у меня в голове произошёл некий конфликт. Его, пожалуй, и попробую раскрыть. Делать это буду на основе трех сторон.
Беспристрастная сторона.
Если у вас произошло именно такое распределение заметок, то пусть так оно и будет. Значит ваша база знаний построена на основе логики "формализую проблему - пытаюсь её решить - ход решения логирую" и вероятно этому не нужно противиться. Более того, скорее можно даже улучшить этот процесс за счёт придания более проектных свойств. Иначе говоря, стоит формировать базу знаний через призму проектов.
Очень пристрастная сторона.
Лично мне такой перевес не очень нравится. Ибо его я интерпретирую как то, что у вас в базе крайне мало переиспользуемых знаний. Что довольно плохо, так как сильно снижаются возможности в решении трудных, комплексных задач. Черновик (проект) – это всё же попытка решить какую-то узкую и конкретную проблему.
Попробую на примере объяснить, что я имею в виду. Представьте, что вам захотелось бы не купить и как-то заюзать Wi-Fi камеру, а её разработать. Порядок сложности, как вы понимаете, разный. Так, например, вам уже понадобились бы знания схемотехники, оптики, материаловедения, знания в области программирования (возможно проектирования) контроллеров, может ещё какие-то знания в области обработки цифровых и аналоговых сигналов. (Честно говоря, я не знаю как конкретно разрабатываются видеокамеры. Возможно областей больше и они ещё специфичнее.) Все эти области крайне наукоёмкие и, мягко говоря, их будет очень трудно использовать и переиспользовать в рамках лишь проектной базы знаний.
Компромиссная сторона.
Попробуйте как-то изменить ваше распределение в сторону, где у вас есть и довольно внушительный набор заметок с фундаментальными знаниями, и при этом, где вы этот же набор довольно интенсивно используете в своих проектах.
Не, ну, это уж слишком простой путь, хах. Лишаете человека экспериментов.
Не шибко врубаюсь о чём вы конкретно спрашиваете, поэтому отвечу в меру своего понимания.
Для того, чтобы удобно навигироваться по своим заметкам создается стартовая (начальная) страница. Способов её организовать множество. Однако в статье я предлагаю сделать отображение начальной страницы с помощью Dashboard.
Суть Dashboard в том, что эта штука позволяет в режиме preview отображать списки в несколько столбцов (в зависимости от свободного места по горизонтали).
То, что выделяется с помощью "---" является областью метаданных, которыми можно эффективно размечать (категоризировать) заметки.
В метаданных можно использовать:
свои какие-то ключи
например, можно использовать ключ type, чтобы выделить разные типы заметок
ключи предопределенные Obsidian
к таким относятся
aliases – задает альтернативные наименования для заметки
tag – задает тег для заметки
cssclass – применяет заданные (сгруппированные) изменения к заметке
также бывают ключи, которые задаются определенными плагинами и механику которых будет отрабатывать именно плагин
например, это может быть obsidianUIMode (суть которого изложена чуть выше в комментариях)
Если говорить в преломлении Dashboard, то он, условно говоря,создает новое значение для ключа cssclass (если же точнее, то Dashboard просто создает набор сгруппированных css изменений, который впоследствии может быть также сгруппировано применен). Когда вы указываете это значение в заметке, то Obsidian распознает и применяет отображение в соответствии с кодом (в нашем случае из сниппета).
Сниппет для отображения в виде Dashboard создается по той причине, что Obsidian решил именно так отрабатывать механику внесения постоянных и небольших пользовательских изменений в css код.
Если же вы хотите писать код как в конструкциях по типу Dashboard, то это не ко мне.
С другой стороны, возможно, вам просто не хватает организованности в процессе написания. Тут я разве что могу посоветовать поискать источники информации в таком стиле.
Это и неудивительно, что вам не встречаются материалы по тому как извлекать знания для написания статей. Этот процесс слишком тривиален – вы как-то смотрите на свои записи и на их основе пишете текст. К этому можно ещё добавить процесс группирования заметок конкретно для статей, но тут тоже нет большой разницы в том как вы это будете делать:
создадите проектную заметку и в её начале (или в каждой главе) укажете все нужные заметки;
будете на ходу интегрировать свои заметки в текст;
создадите отдельную мета-заметку и по ней будете ориентироваться;
протегируете все нужные заметки и будете надергивать их из поиска;
разложите заметки на canvas;
создадите определенную группу метаданных и будете по ней делать запросы в dataview.
От выбора способа группирования суть не изменится, так как механизм написания останется прежним – вы будете как-то смотреть на свои заметки, а потом на их основе писать.
Самое трудное – это искать нужные заметки (если они, конечно, есть... если их нет, то самое трудное их качественно вычленить из исследуемых материалов). И, увы, но этот поиск сильно зависит именно от того как у вас устроена база знаний. Отсюда и обилие статей, видео и курсов о том как эту базу знаний получше можно устроить и какие механизмы стоит внедрить.
Ну и да, эта статья больше говорит о том чем может отличаться процесс извлечения знаний в случае разных источников и в меньшей степени о том как построить базу знаний (именно об этом будет в следующей части).
Этот вопрос вы можете задать Google или ChatGPT.
Например, что-то такое. Немного отличается от скрина, но суть та же.
homepage