Часть 2. Управление знаниями в Obsidian. Базовый рабочий процесс. Журнал. Источники и их библиотеки. Пример

98097215b3acb48305177e396cc2bc2b.png

В этой статье будет показано как можно начать организовывать свою базу знаний в Obsidian, отталкиваясь от источников. В статье будет разобрано то, какие стоит использовать папки и теги; как создать свою первую точку входа в систему. Также будет уделено внимание способу ведению журнала (дневника). Статья будет предполагать, что вы не против автоматизации процессов в своей базе знаний, поэтому все источники будут шаблонизированы и впоследствии собраны в свои отдельные библиотеки с помощью dataview. Завершится статья подробным примером (алгоритмом) рабочего процесса.

предыдущая статья

Структура статьи (оглавление)

Можете открыть структуру в отдельной вкладке, чтобы понимать, где вы находитесь в тексте.

  • Введение

  • О паранойе

  • Предварительные советы

    • Слепая печать

    • Смена языка одной клавишей

    • Автодополнения

    • Не для управления делами

    • Язык программы

    • Облачное хранилище и резервные копии

    • Wiki-ссылки

    • Названия заметок

      • Термины короткие, идеи длинные

      • Заметки строчными буквами

    • Не дублируйте информацию

    • Единственно возможным образом

    • Источники

  • Базовый рабочий процесс

    • Папки

    • Теги

    • Первая точка входа

    • Ваша справка

    • Панели

    • Создание заметки

    • Журнал

    • Списки источников

  • Dataview

  • Projects

  • Дополнительные оптимизации

  • Пример рабочего процесса

  • Итог

Введение

Когда вы прочитаете статью, то вероятно у вас может появиться ряд вопросов в стиле «и это всё? так просто? и это будет работать? серьёзно?».

Да. Система будет работать и более того она будет как можно меньше стараться вам мешать делать основную свою деятельность, т.е. читать, думать, создавать идеи, понимать и осознавать, учиться и т.д. Отсюда стоит также понимать, что, если вы не будете читать, думать и прочее, то система вам никак не поможет.

Эта часть статьи будет состоять по сути из множества конкретных советов о том как стоит делать. Вы вправе повторить один в один в своей системе или можете просто понять суть того почему я предлагаю то или иное решение и сделать что-то своё. Однако в любом случае вам нужно держать в голове, что мы с вами находимся на разном уровне развития, на разных жизненных циклах, у нас с вами разные интересы, разные взгляды, разные в конце концов личности и характеры. Всё это отразится на вашей базе знаний.

Со временем у вас появится опыт того как стоит строить свою систему, свою базу знаний. Вы по ходу дела поймете что стоит дооптимизировать в системе, что стоит совсем убрать, вы поймете как, условно говоря, поворачивать систему определенной стороной, чтобы она помогала вам решать ваши актуальные нужды. Моя роль тут в том, чтобы просто дать пару подсказок как можно побыстрее получить что-то вменяемое, что будет давать заметную отдачу.

Отмечу ещё то, что вероятно есть риск, что вы не совсем сразу поймете (или точнее прочувствуете) почему какое-то решение в действительности является долгоиграющим (например, почему нужно отказаться в каком-то смысле от папок и тегов). Это нормально, ибо вы читаете статью последовательно, переходя от одной частности, к другой и отчего у вас не появляется общей картины сразу (к тому же у вас ещё нет опыта ведения базы). В самом конце я соберу все советы в кучу и покажу пример рабочего процесса (на мой взгляд, это самая полезная часть статьи).

Если вы уже знаете, что вам нужно от системы, если у вас уже есть что-то работающее или даже хорошо отлаженное, то не теряйте время и НЕ читайте эту статью.

О паранойе

Мой опыт показывает, что в процессе работы в Obsidian, вы так или иначе всунете в него какой-то плагин, какое-то такое решение, которое в итоге таки приведёт к тому, что у вас не выстроится тот же самый эффективный рабочий процесс в какой-нибудь другой программе. Даже вопреки тому, что все говорят, мол Obsidian использует MD-файлы и это якобы даёт некоторую универсальность, всё это отчасти лукавство.

Если ко всему этому добавить то, что Obsidian проприетарный софт с основателями китайцами, то можно как-то совсем приуныть.

Однако в попытке хоть как-то развеять паранойю, стоит также сказать следующее. У Obsidian довольно мощное сообщество по всему миру. В каком-то смысле именно оно выдало большой кредит доверия данному софту. Пока что прецедентов в том, чтобы разочароваться в Obsidian не было. Будем считать, что это хороший признак, которого достаточно для того, чтобы начать (или продолжать) пользоваться Obsidian.

Предварительные советы

Слепая печать

Я даже не говорю про 10-пальцевый ввод. Стоит научиться печатать хотя бы не глядя на клавиатуру. Если вы смотрите постоянно на клавиши и на свои пальцы, то на самом деле вы просто ужасно много тратите своего внимания фактически в пустую. К тому же вы постоянно тратите по лишнему волю (или если кому-то удобнее, то мыслетопливо), а это значит, что вы постоянно будете существенно понижать свои шансы на то, чтобы войти в состояние потока.

Смена языка одной клавишей

Возможно вы заметили, что у вас на клавиатуре есть клавиша, которую вы редко используете. Нет, я сейчас не про scroll lock. Всё куда ближе. Я говорю про caps lock. Поменяйте смену раскладки клавиатуры на эту клавишу, чтобы просто немного ускорить процесс ввода.

Автодополнения

Вы наверняка часто пишете свой email и ФИО. Не кажется ли вам, что этот процесс можно оптимизировать?

В заметках также часто будут появляться моменты, когда вам нужно писать однотипные вещи. Например, это могут быть

Сюда же можно отнести какие-то частые опечатки.

Если вы пользователь Windows или MacOS, то поставьте Punto Switcher. В нем вы сможете в том числе настроить клавишу смены раскладки, добавить свои автодополнения и вдобавок получите плюшку в виде автоматической смены раскладки в процессе печатания. Я же являюсь пользователем Linux, потому использую программу autokey.

Не для управления делами

В Obsidian можно обустроить себе систему по управлению делами, но не рекомендую вам этого делать. По крайней мере поначалу.

Вместо этого лучше отдельно изучите, например, метод GTD и попробуйте его реализовать в каком-нибудь todoist. Пользы вы от этого получите немерено. При этом у вас появится хорошее разграничение в голове: всё таки для дел и планирования нужна (и уместна) одна система (пространство), а для знаний другая.

Язык программы

Чтобы по первой не тупить, можете попробовать на русском. Позже рекомендую перейти на английский. Причины следующие:

  • Плагины обычно не переводят, поэтому вам придется думать об одной логике два раза

    • Я имею в виду то, что есть много типовых выражений в описании функций тех или иных плагинов, которые позволяют вам быстрее вникнуть в суть

  • Если у вас появится какие-то затруднения или вы захотите что-то изменить в Obsidian, то запрос в гугле c английскими терминами программы даст вам больше полезных результатов

  • Иметь языковое единообразие в той же палитре команд приятнее, чем его не иметь

В этом гайде интерфейс будет на английском.

Облачное хранилище и резервные копии

Хранить труды десятков, сотен, тысяч часов своей работы в одном месте, да ещё и просто на своем компьютере — максимально идиотская идея. Так что подумайте о том, чтобы продублировать свою базу в каком-нибудь облачном хранилище или на github (процесс синхронизации реализуется в этом плагине, проще всего организовать так).

Можно также использовать Syncthing, чтобы, например, продублировать базу на телефон или свой сервер.

Вдобавок стоит делать регулярные резервные копии. Плотно поработали на неделе? Заархивируйте базу на всякий случай и архив также продублируйте в разных местах. Скорее всего это излишняя мера предосторожности, но лучше с ней, чем иметь риск нарваться на какую-то неосторожную случайность, которая лишит вас всей базы.

Wiki-ссылки

Есть большой спор о том, что лучше использовать: классические MD-ссылки или wiki-ссылки. Мой ответ — wiki-ссылки потому что их проще и быстрее делать и изменять, а также они опрятнее выглядят. В будущем, если вас разъест паранойя, то вы можете написать скрипт (например, на Python), который переделает всё в классические ссылки. Ну или вы можете просто заюзать плагин.

Названия заметок

Термины короткие, идеи длинные

Заметки с терминами мы называем так как они звучат, т.е. как есть, например, «нормальное распределение». Это позволит нам быстрее такие заметки связывать с другими, где эти термины используются. У Obsidian есть встроенная функция по поиску таких заметок. Если мы добавим также aliases, то увеличим количество совпадений.

С идеями наоборот. Идеально, когда суть идеи мы можем передать в названии заметки. Т.е. для идеи мы пишем длинное название, чтобы её было легче потом искать. Да и вдобавок неплохим таким упражнением является упаковывание каких-то сложных концепций в 10 слов.

Заметки строчными буквами

Все заметки мы пишем с маленькой буквы, чтобы позже их можно было легко вставлять в текст с минимум корректировок (точнее совсем без них).

Думаю, из моей логики понятно, что имена собственные, мы наоборот пишем с большой.

Не дублируйте информацию

Это относится вообще ко всем уровням ведения базы:

  • если у вас есть название вверху заметки, то зачем вам оно ещё нужно в заголовке? правильно, незачем.

    • более того, когда вы будете вставлять заметку в другую заметку вот так ![[]], то у вас будет висеть этот злосчастный заголовок

  • не надо оформлять список исходящих и входящих ссылок

  • не надо создавать множество одинаковых заметок, просто потому что вам встретилась одна и та же мысль в разных местах

    • дополните, модифицируйте или измените то, что у вас уже есть

    • создайте ссылку на имеющуюся заметку

  • желательно (особенно по первОй) делать односторонние ссылки

    • т.е. чтобы у вас в перечне исходящих и входящих ссылок не было повторов

    • а также для того, чтобы понимать направление связи (это тоже полезная информация)

Единственно возможным образом

Старайтесь организовывать базу так, чтобы все операции в ней выполнялись каким-то единственно возможным образом. Это немного странное требование, но оно нужно для того, чтобы у вас выработались нужные привычки, которые освободят ваш разум от лишних мыслей по типу: «как бы мне добавить новую заметку?», «мне использовать эту функцию с помощью кнопки на панели или как команду, или хоткеем?».

Отсюда же стоит сразу сделать вывод, что уберите всё, чем не пользуетесь, чтобы оно вас не путало и не сбивало ритм.

Источники

Теперь самый главный и самый важный совет. Если вы начинаете делать свою базу с нуля, то настоятельно рекомендую её формировать, отталкиваясь от источников (в этой статье я буду строить всю логику именно на основе этого совета). Что я имею в виду, я покажу на следующем алгоритме (дальше будет наглядная иллюстрация).

  • Создаем заметку по названию источника. Пусть это будет, например, книга «От атомов к древу».

  • Далее внутри неё мы делаем ссылку, например, на заметку с названием «конспекты по книге От атомов к древу».

  • В заметку «От атомов к древу» мы выносим из конспектов какие-то самые важные атомизированные мысли.

    • Формируем из заметок какие-то структуры (например, методом outliner)

    • Пишем какие-то свои суммирующие заметки

    • Выносим заметки в отдельную категорию, которые нам особенно интересны и которые мы хотим развить

Так стоит делать по той причине, что скорее всего вы ещё не знаете какие сферы интересов вас действительно волнуют и которые бы вам хотелось как-то изучить и как-то в них покопаться. Отсюда же мысль о том, что вы вероятно не сможете как-то достаточно отчетливо и безошибочно обозначить наиболее общие категории, к которым потом отнесете все свои источники и которые потом для вас станут наиболее короткими точками входа.

Работу же, которую вы сделаете внутри заметки-источника, вы легко потом переместите в нужные места.

Выглядеть это будет примерно так:

d053d45df29bc640a5ac23f6ce0e94fc.png

Базовый рабочий процесс

Папки

Структура папок вот такая:

b89189a9149a1515a209b221c299a728.png

Меньше можно. Больше нельзя.

Почему так?
Дело в том, что папки являются довольно негибкой иерархической структурой. Вы можете наплодить много папок, но потом при первом же каком-то неоднозначном случае вам придется в муках страдать от вопроса «куда бы мне положить эту заметку?». Да, никуда! Не надо думать куда складываются заметки! Пусть они складываются куда-нибудь, а куда именно неважно.

Более того, когда вы создаете множество папок, то вы будете регулярно их перебирать. Вы будете тратить время, чтобы разобраться в том, что у вас построено не ассоциативно, а в собственных нагромождениях перекрученной логики.

Гибкость нашей системы достигается за счёт управления связями. Ибо связи меняются быстро и легко. Это значит, что в такой системе, к нужной мысли или категории мы быстро подведем нужную мысль или другую категорию. При этом мы не будем тратить время на то, чтобы что-то искать в жесткой иерархии. Мы скорее будем регулярно спрашивать свою систему «в тебе есть какие-то похожие мысли, обороты, слова, идеи?» и в таком случае система нам будет сама подкидывать что-то годное.

Хочу также отметить, что чем раньше вы отлипните от папок, тем лучше. Возможно на каком-то моменте, вам стоит вообще отключить их отображение.

Теперь по самим папкам.

  • files

    • сюда складываются файлы (png, jpg, pdf…), чтобы они не мешались с основными заметками

    • стоит также установить в настройках, чтобы файлы складывались автоматически именно в эту папку

    • стоит убрать эту папку из поисковой выдачи (надеюсь вы разобрались с интерфейсом программы)

  • home

    • в ней лежит файл homepage — ваша первая точка входа (о ней будет чуть дальше по тексту)

    • так как этот файл очень важен, то пусть он лежит в отдельной папке

    • сюда же вы можете положить всякие свои трекеры и т.п. (если в этом есть нужда)

    • тут же вы можете разместить, например, MOC заметки

  • periodic

    • в ней лежат две основные папки

      • daily

      • weekly

    • обе папки нужно убрать из поисковой выдачи

    • также в ней лежит папка templates, которая отделяет основные шаблоны от шаблонов недельной и дневной заметок

    • вы можете добавить папки для месячных и годовых заметок, если у вас есть в этом нужда

    • периодические заметки имеют обычно типовые имена, которые не несут полезной информации, поэтому их лучше отделить от основной базы

  • projects

    • в ней мы плодим столько папок, сколько у нас есть направлений

      • статьи

      • ютюб

      • работа

      • прототипы

      • и т.д.

    • хранить проекты с основными заметками не стоит по нескольким причинам

      • проект живет конечное время, а значит и заметки по нему также имеют срок годности

      • нужно уметь отделять знания от результатов применения этих знаний

      • порой полезно архивировать (скрывать) определенные проекты

  • templates

    • тут мы храним все используемые шаблоны

    • рекомендую не сходить с ума и не делать по 10000 шаблонов на все случаи жизни

  • корень

    • здесь мы храним нашу базу знаний

    • есть большой плюс в том, чтобы хранить именно в корне — при поиске заметок вы не будете видеть путь к заметке, а значит вас не будет сбивать с толку лишняя информация

Как я сказал, меньше папок вы можете сделать, но больше нельзя. Начнёте делать больше, снова погрязнете в бессмысленных муках раздумий о том как бы получше структурировать свою базу знаний.

Общий вид получится примерно таким:

717e5246ac3aac6690faad1288258839.png

Стоит заметить, что эти папки созданы также, чтобы немного улучшить или упростить логику работы некоторых функций Obsidian и некоторых плагинов. Вообще говоря, если вы отбитый (но в хорошем смысле, т.е. любите сразу окунаться во что-то непривычное), то можете забить на папки совсем и все возникающие проблемы фиксить по мере их поступления.

Теги

Теги — это (неоправданное) усложнение. Поэтому не надо тегами пытаться размечать какие-либо иерархии, разные уровни взаимоотношений и прочее.

Тегами можно только пометить какие-то заметки.

Например, можно использовать в качестве тегов эмодзи (если вы варитесь в среде обсидианщиков, то наверняка поняли у кого я украл эту идею) и использовать их следующим образом: