Статья о том, как внедрить и как продуктивно использовать систему статусов в персональных проектах.
Гайд предназначен для пользователей Obsidian. Однако, если вы к таковым не причисляетесь, то можете ознакомиться только с описанием системы статусов. Возможно, что вам сам подход понравится и у вас впоследствии получится адаптировать его в своих инструментах.
Структура статьи (оглавление)
Введение
Изначально я хотел назвать эту статью "Для любителей Obsidian, проектов и emoji". Однако, не смотря на то, что это название прям максимально точно и ёмко описывает содержание всей статьи, всё же я решил выбрать более спокойное и сбалансированное название.
Вероятно вы уже догадались, что речь будет вестись о проектах и статусах, которые эти проекты будут помогать двигать вперёд. Однако прежде чем мы перейдем к конкретике, я вас сначала помучаю алгоритмом Зонке Аренса, а точнее своей критикой этого алгоритма. Потом я ещё вас помучаю и предложу в качестве альтернативы свой длиннющий алгоритм. И только после этого начнется развитие основной идеи этой статьи.
Стоит подчеркнуть, что статья является комплексным решением. Это значит, что почти все части статьи так или иначе взаимосвязаны друг с другом. В связи с этим я предлагаю вам такой план работы:
Вы поверхностно читаете всю статью целиком, чтобы уловить все основные идеи и приёмы
Далее вы открываете оглавление статьи и на каждом пункте спрашиваете себя "Мне это нужно?"
Если вам это нужно, то открываете нужную главу, вчитываетесь в неё и внедряете в свою систему что-то новое
Если вы на этапе поверхностного чтения не понимаете зачем вам нужны те или иные вещи или идеи, то просто забейте на них. Возможно, мы просто с вами решаем разные проблемы
Важно отметить, что система статусов, которую я предложу, подойдет именно для персональной, творческой работы. Увы, но для коллаборации или для проектов с высокой ответственностью, предложенная система скорее всего не принесёт пользы – есть риск, что она даже навредит.
Также ещё добавлю, что показать свои боевые проекты я, увы, не могу. Поэтому примеры будут такие, которые вы так или иначе уже могли видеть. В общем не обессудьте за это.
Теперь перейдем к основному тексту.
Алгоритм Зонке Аренса
У Зонке Аренса есть алгоритм, который по его мнению может помочь в написании каких-то сложных текстов. Приведу алгоритм в оригинальном виде (Как делать полезные заметки. 2.1 Пишем шаг за шагом. Стр. 35):
Делайте повседневные заметки
Делайте записи о литературе
Создавайте постоянные заметки
Теперь добавьте новые постоянные заметки в свой ящик
Разрабатывайте свои темы и исследовательские проекты снизу вверх внутри системы
Через некоторое время у вас будет достаточно много идей, чтобы решить, на какую тему писать
Превратите свои заметки в черновик
Отредактируйте и вычитайте рукопись
Алгоритм хоть и отражает в какой-то степени действительность, однако в моём случае он всё равно не работает.
Основная проблема, на мой взгляд, заключается в том, что этот алгоритм слабо отражает нелинейность процесса написания, а также недостаточно точно объясняет, что нужно делать на каждом этапе.
Хотя чего это я тут лукавлю. Мне этот алгоритм в принципе не очень нравится. И я даже попытаюсь кратко объяснить почему.
Не открывать впечатлительным личностям
Повседневные заметки – это наивная идея, что в потоке быта можно бессистемно наловить множество хороших идей, из которых потом якобы получится развить что-то стоящее. Если эту мысль развернуть в контексте программирования, то есть у меня стойкое, кхм, ощущение, что работающий код всё же появляется в процессе написания этого кода, а не в процессе запечатления и накопления якобы ценных, случайных всплесков размышлений о том, какой код является работающим. Возможно, я очень превратно воспринял идею "fleeting notes", но в любом случае, как оказалось, я не большой фанат уж совсем бессистемных заметок.
Записи о литературе, конвертация их в постоянные заметки и добавление в "ящик" – это шаги, которые в рамках цифровых систем делаются как одно связанное действие. Причём такое, которое можно сделать в один присест. Если же вы пользователь аналоговых систем с реальным ящиком для заметок или вам в действительности нужно делать эти шаги как раздельные, то вы просто извращенец.
Мысль о разработке проектов снизу-вверх мне тоже не очень нравится. Ибо она подразумевает, что я как будто бы всегда начинаю с нуля. Я как будто бы не знаю как могут развиваться проекты, я как будто бы не могу накидать заранее предварительную архитектуру своего исследования, я как будто бы не могу смоделировать логику развития своего проекта, я как будто бы не могу сделать парочку другую мысленных экспериментов, чтобы определиться с тем, какие примерно шаги в действительности для меня будут полезными и эффективными. В общем по мнению Зонке Аренса я как будто бы изначально "немощный" и мне нужно в процессе "подкачаться". Если что я в курсе, что в книге есть глава про то, что никто никогда не начинает с нуля. Однако, увы, но она не раскрывает мысль, что я могу изначально иметь более-менее ясное видение того, к чему хочу прийти.
Мысль Зонке Аренса о том, что у меня через некоторое время будет достаточно много идей, чтобы решить, на какую тему писать тоже весьма кривая. Эта мысль предполагает, что я будто бы хожу, брожу и делаю заметки по тем или иным источникам, а потом в какой-то неожиданный момент на меня снисходит инсайт и я нахожу себе проблему, которую хочу решить. Также стоит отметить, что эта мысль будто бы исключает ситуации, когда я в рамках базы знаний делаю какое-то последовательное исследование, а потом на основе этого исследования делаю проект или исключает ситуации, когда я делаю проект, а потом под проект делаю исследования. В логике Зонке Аренса я сначала агрегирую заметки, а потом конвертирую их в проект (в конечный текст). Причём сам процесс агрегации ничем не ограничен и толком ничем не обоснован (это даже навевает мысль, что Зонке предлагает нам заняться коллекционированием и надеяться, что в какой-то момент нам повезёт и мы найдем то, что нас сильно зацепит). Я не хочу сказать, что Зонке не прав и в действительности такого не происходит. Просто сама мысль у него получилась кривая – т.е. я её не отрицаю, ибо у меня у самого так или иначе фоном постоянно происходит псевдослучайный процесс агрегации заметок, из которого потом появляется что-то связное и интересное.
С шагами про черновик, вычитку и редактуру всё так. Тут не придерёшься, хех.
Если что это не нападка на Зонке Аренса. Так-то я настоятельно рекомендую прочитать всем заметкоделам его книгу. Ибо сам-то я её внимательно прочёл и сделал по ней довольно большое количество полезных заметок.
В качестве промежуточного решения проблемы алгоритма Зонке Аренса, я решил написать свой, несколько более расширенный алгоритм.
Детализация этапов
Итак, начнём-с.
Написание небольшого количества первых заметок, которые нужны для формирования первоначального видения той или иной проблемы (мой алгоритм начинается с проблемы и формирования начального видения, а не с повседневных заметок)
Это можно производить в рамках предварительного исследования
Можно собрать в одном месте и поверхностно обработать схожие по теме источники из всевозможных "read later"
Можно пройтись по уже имеющимся источникам/заметкам и попытаться дать оценку тому, что есть ли вообще релевантный материал в системе. Если есть, то можно создать мета-заметку и накидать туда соответствующих ссылок
Постепенное формирование списка источников и заметок, которые в потенциале способны стать чем-то связанным и последовательным. И соответственно непосредственная обработка этих источников и заметок
На этом этапе можно сформировать полноценную мета-заметку или сразу создать проект
В рамках мета-заметки или проекта нужно последовательно выкачивать из найденных источников заметки
Логика для внешних источников
Если источник мелкий и при этом оказался не шибко значимым, то можно просто ограничиться комментарием к нему (сделать отступ и написать коммент под внешней ссылкой)
Если источник мелкий, но в нём есть полезные идеи, то создается обычная заметка, записывается в неё всё, что нужно, а сам источник указывается в качестве сноски
Если источник большой и его трудно разом обработать и при этом тут же обобщить в одну заметку, то создается log-заметка, в которой впоследствии выделяются и атомизируются наиболее значимые идеи
Если источник огромный и в нём нужно довольно много всего изучить, то создается заметка-источник, внутри которой происходит разбиение на ряд log-заметок
Логика для внутренних источников
Перейти на следующий этап, хех)
Создание из полученных заметок связанных кластеров (например, с помощью иерархического списка, mindmap или canvas) и последующее написание по ним небольших кусочков текста
В соответствии с поставленным задачами, гипотезами или проблемами ищутся наиболее подходящие заметки, которые сразу объединяются в кластеры
Далее на основе этих кластеров пишутся небольшие, необязательно напрямую связанные между собой, тексты
Формирование первого черновика – первая попытка написать связный текст
Написанные кусочки текста в нужных местах склеиваются или наоборот разбиваются на логические замкнутые блоки (например, с помощью заголовков), благодаря чему формируется 1-ый драфт
Если конечный текст предполагается очень большой, то возможно это будет просто 1-ый драфт какой-то определённой части
Проработка структуры / углубление в определённые части или главы текста (детализирование) / формирование дальнейшего плана действий при необходимости
На этом этапе мы по сути делаем основную работу – пишем плюс-минус конечный текст
Попеременно работаем то над текстом, то над его структурой. Попеременно значит раздельно, хех
Из не самого очевидного. Пытаемся каждый логически связанный блок текста (например, связанный на уровне заголовка) сделать достаточно автономным, чтобы при необходимости этот кусок можно было перенести в другое место. Этот пункт нужен для того, чтобы сохранялась гибкость (об этом будет немного дальше)
В процессе формализуем те или иные проблемы в виде задач и последовательно решаем их
Вычитка своей работы и проведение критического обзора
На этом этапе мы пытаемся оценить связность аргументов, а также логичность структуры отдельных частей или всего проекта
Попеременно включаем, то писателя, чтобы отполировать те или иные формулировки или структуры, то критика, чтобы найти те или иные несостыковки, неточности и прочие проблемы
За счёт неоднократной вычитки текста, пытаемся досвязать, доразвить, докомбинировать различные части нашего проекта
По-серьёзному задумываемся о том, что мы выбрали плодотворное направление, которое нас действительно волнует или, что мы действует уже из-за инерции, довольно жёсткой структуры или внешних нам неугодных требований
Если нам нравится то, что мы делаем и мы видим в этом потенциал, то переходим на следующий этап
Если мы чувствуем, что глобально движемся не туда куда хотим (нас раздирают сомнения или мы вообще не видим смысла в том, что делаем), то можно вернуться к самому первому этапу, чтобы поработать над какими-то другими, новыми проблемами. Или можно просто поработать над другими проектами. В общем делаем передышку, дабы немного охладеть к проекту и дабы подумать о том "нужен ли он нам или есть занятия повеселее и поинтереснее"
Не стоит забывать, что нам никто не запрещает забросить неугодные нам части проекта или создать новый проект и перенести в него только то, что у нас лучше всего получилось, дабы развивать только эти части
Также не стоит забывать, что творчество в большинстве своём итеративный процесс – мы сначала довольно упорно пытаемся что-то сделать, потом анализируем результаты и потом снова пытаемся что-то сделать
Мы старались сделать логически замкнутые блоки информации автономными для того, чтобы сохранить чувство контроля. Само же чувство контроля проистекает из нашей возможности сменить приоритеты и/или выбрать другой путь развития. Если мы не можем распараллелить наш проект или создать новый на основе кусков старого, то значит мы находимся в жёсткой системе, а это сулит тем, что рано или поздно мы можем потерять мотивацию
Модификация структуры и проработка с помощью драфтов
Переставляем части нашего проекта, если это необходимо
Драфтим те куски, которые плохо вписываются в общую канву или стиль
Дописываем все промежуточные, связывающие и вводные части, если это необходимо
Финализация, приведение проекта к конечному виду
Работа с редакторами или рецензентами, если они есть. Допиливание через драфты, если это нужно
Редактирование и исправление мелких ошибок
Формирование служебных структур
Доработка результатов под те или иные формальные требования
Создание конечного проекта (файла)
Публикация или просто донесение результатов своей работы до конечного потребителя
Алгоритм хоть и выглядит как обобщённый, однако он написан по мотивам одного, не самого простого моего проекта.
Наверное, вы сейчас подумали, что как-то уж чересчур детализировано получилось. На столько детализировано, что из-за большого количества деталей всё стало каким-то мутным. Однако не переживайте. Я написал этот алгоритм ни сколько для того, чтобы сделать его практичной альтернативой алгоритму Зонке Аренса, сколько для того, чтобы проиллюстрировать на сколько всё может быть сложнее и неоднороднее в действительности.
Практичности же мы будем достигать с помощью системы статусов. К ней, без лишних слов, и перейдем.
Система статусов
Система статусов выглядит вот так:
структура статусов
На интуитивном уровне вроде ничего сложного и удивительного, правда? Было бы даже странно, если система для проектов состояла из сюрпризов и неожиданностей. С другой стороны, не смотря на интуитивную понятность, именно эту систему я буду обсасывать с разных сторон на протяжении всей статьи.
структура статусов
- ⬛ abandoned
- Preparation 👀
- 🟥 todo or queue
- 💡 idea
- Preprocessing 🛠
- 🧠 brainstorming
- 🔎 research
- Processing ✍🏻
- 🟦 wip
- 📋 revising or structural improvements
- 🖍 editing or critique
- Distributing 📨
- 🟩 completed or pending distribution
- 📦 preparation for distribution or compilation
- 📢 distributedСтатусы у меня используются в виде эмодзи. Я также надеюсь, что удачно подобрал варианты слов, которые вы можете использовать вместо эмодзи. Однако я всё же настаиваю, чтобы вы тоже юзали эмодзи, ибо как бы это не выглядело по-детски, всё же с помощью эмодзи можно довольно ёмко и при этом, что приятно, визуально разметить ту или иную информацию. В статье, я надеюсь, что у меня получится доказать вышенаписанный тезис.
Итак, начнём с того, что статусы условно делятся на четыре группы (дальше мы подробно рассмотрим каждый статус из каждой группы):
Preparation 👀. Статусы, которые относятся к этой группе обозначают, что какие-то части проекта просто существуют, но в них ещё ничего толком нет. Иначе можно сказать, что части проекта, под статусами этой группы, обозначают лишь направления, в которые мы предположительно собираемся двигаться
Preprocessing 🛠. Статусы этой группы говорят нам о том, что мы в той или иной части проекта подготавливаем или уже подготовили первичный материал, от которого будем отталкиваться и который будем развивать
Processing ✍🏻. К этой группе относятся статусы, которые характеризуют основные стадии развития проекта
Distributing 📨. Статусы характеризуют степень завершенности той или иной части проекта
Статусы я разбил на группы для того, чтобы была в принципе какая-то надсистема. Иначе говоря, если вы захотите поменять конкретные статусы или добавить новые, то можно будет сначала подумать о том, к какой группе (или какому, условного говоря, мета-процессу) относится статус.
Конкретизация этапов работы
Теперь давайте конкретно обсудим, что значит каждый статус.
⬛ abandoned – заброшено или заархивировано
Этот статус можно поставить, если какая-то часть проекта нам перестала быть нужна по тем или иным причинам
Также его можно поставить в случаях, когда мы начали что-то развивать, но в процессе поняли, что у этого нет перспектив или нам в принципе неинтересно это двигать дальше
Preparation 👀
🟥 todo or queue – запланировано или находится в очереди
Этот статус ставится на только что созданных частях проекта
По сути этот статус значит, что мы создали какое-то новое направление, которое хотим начать развивать
Можно также сказать, что этот статус значит, что у нас есть направление развития, но кроме него больше ничего и нет
💡 idea – идея
Этот статус обозначает, что мы написали несколько предложений или нарисовали простенькую схему, которые довольно ёмко объясняют, что, как или на основе чего мы собираемся развивать данную часть проекта
Preprocessing 🛠
🧠 brainstorming - брейншторм или первый набросок
Данный статус обозначает, что мы начали развивать первоначальную идею за счёт её расширения, детализации или накидывания новых, связанных идей
Ещё этот статус может значить, что нам нужны какие-то ещё идеи, которые бы помогли решить тот или иной затык
🔎 research - на этапе исследования
Данный статус значит, что мы встретились с какими-то затруднениями и нам нужно провести какое-то дополнительное исследование
Также статус может значить, что у нас есть список источников и заметок, которые нам нужно обработать, чтобы продвинуть ту или иную часть проекта дальше
Processing ✍🏻
🟦 wip – в процессе работы
Статус значит, что мы находимся в процессе развития тех или иных конкретных идей
По сути этот статус значит, что мы нащупали верное направление и теперь просто совершаем последовательное движение
📋 revising or structural improvements – пересмотр, вычитка или улучшение структуры
Статус значит, что мы сделали, что хотели и теперь нам нужно пересмотреть, вычитать материал или нужно по-лучше проработать структуру (отрефакторить)
🖍 editing or critique – редактирование или критический обзор
Статус значит, что часть проекта находится в процессе (полноценного) редактирования
Также статус может значить, что нам нужно исправить какие-то ошибки или неточности
Ещё этим статусом можно обозначить части, которые готовы к тому, что их можно отправить редактору (если он есть) или что эти части можно показать другим людям, чтобы те дали обратную связь (критику)
Distributing 📨
🟩 completed or pending distribution - готово или ожидает публикации
Статус значит, что часть проекта полностью сделана и отредактирована
📦 preparation for distribution or compilation - подготовка к распространению или компиляция
Статус значит, что проект или часть проекта готовы к приведению или уже приводятся к тому виду или к тем правилам, которые есть у (платформы/журнала/сервиса/конференции/репозитория)
Также этот статус может значить, что именно эту часть проекта нам нужно донести до конечного потребителя (своеобразная обратная альтернатива статусу "⬛ abandoned")
📢 distributed – опубликовано, презентовано, распространено, законтребьютено
Статус значит, что мы донесли результаты своей работы в необходимые места
Думаю, что вы уже смогли прочувствовать, что у статусов есть также логика развития: сначала мы вообще в принципе мало-мальски определяемся с тем, что собираемся делать и развивать; потом понемногу собираем свои мысли в кучу и при необходимости находим и изучаем те или иные материалы; далее осуществляем непосредственную основную работу; после анализируем полученные результаты и занимаемся корректировкой; когда всё готово, то мы подготавливаем материал к дистрибуции и непосредственно доносим его в нужные места.
Кстати говоря, если вы прочитаете ещё раз длинный алгоритм, который я в начале статьи написал, то вы поймете, что система статусов так или иначе его формализует.
Статусы в контексте проекта
Теперь давайте применим систему статусов непосредственно для проектов.
Я буду рассматривать два вида проектов
Single-project – мелкий и одиночный проект (одна заметка = один проект)
Longform-project – длинный и многосоставной проект
Для формальности, давайте я покажу как на уровне файлов эти проекты выглядят.
структура single-projects
Single-project в структурном смысле имеет вот такой вид:
.
└── 📂 projects
├── 📝 project 1.md
├── 📝 project 2.md
└── 📝 ...Т.е. есть папка с проектами и в ней куча разных одиночных проектов.
структура longform-projects
Longform-project в структурном смысле имеет вот такой вид:
.
└── 📂 projects
├── 📂 project 1
│ ├── 👉 project 1.md (index)
│ ├── 📜 scene 1.md
│ ├── 📜 scene 2.md
│ └── 📜 ...
├── 📂 project 2
│ ├── 👉 project 2.md (index)
│ ├── 📜 scene 1.md
│ └── 📜 ...
├── 📂 ...
└── ...Т.е. есть папка с проектами и в ней для каждого longform-project выделена своя персональная папка. Также у каждого longform-project есть индексный файл, внутри которого указаны заметки (scenes), относящиеся к текущему проекту. Возможно, вы уже догадались, что такая логика и наименования взяты из плагина Longform и это неспроста (именно его я буду использовать для организации больших проектов).
Можете заранее посмотреть гайд по этому плагину, если с ним не знакомы. Также есть автоматизированный способ создания подобных проектов.
Теперь ещё одно уточнение. Для single-project и для индексного файла longform-project есть смысл использовать сокращённое количество статусов:
⬛ abandoned – проект заброшен или заархивирован
🟥 todo – проект просто запланирован
🟦 wip – над проектом ведётся работа
🟩 completed – проект закончен (проект ожидает дистрибуции)
📢 distributed – проект опубликован/презентован/распространён
Метаданные для single-project или для индексного файла могут иметь вот такой вид:
---
type: project
status: 🟩
---Полноценную же систему статусов мы натянем немного на другое.
Single-project
Сильно не буду вас томить. Идея в том, чтобы в начале каждого заголовка ставить статус. А потом просто открывать список с заголовками и анализировать его.
table of contents
Так отображает заголовки core-плагин Outline. Есть также альтернативный и более функциональный плагин.
Вы можете подумать о том как имплементировать систему статусов по-другому, однако мне кажется, что такой способ маркирования заголовков даёт возможность просто глазами увидеть и оценить сразу весь прогресс проекта. Т.е. не нужно кликать по всем заголовкам, чтобы понять как там обстоят дела. Более того, если запомнить примерную логику статусов, то можно весьма чётко понимать на какой именно стадии находится каждая часть проекта и при этом также примерно понимать, какие действия нужно делать дальше (о том как возвращаться к статусам будет чуть позже по тексту).
К тому же, когда статусы интегрированы в заголовки, то можно оценить прогресс в контексте всей структуры проекта. Я раньше юзал всевозможные варианты канбан-досок, но у них есть проблема, что глядя на них, трудно сразу дать оценку по типу "вот этот кусок проекта сейчас не очень актуален, я лучше вот эти части продвину вперёд".
Кстати говоря, откройте ещё раз скрин, который выше был. Я его сделал в момент, когда писал вот эти самые строчки, которые вы сейчас читаете. Вы можете заметить, что даже такая несложная статья как эта, пишется весьма нелинейным образом. И это даже не моя особенность. Линейно развивать проект или какой-либо текст в принципе крайне трудная и к тому же занудная задача – проще сначала поработать в одном месте, потом в момент затыка или угасания энтузиазма перейти на другую часть, потом снова на другую и т.д.. По сути именно в рамках последовательного переключения с одной части проекта на другую и выполняется весь объём работы. И нет, это не мультизадачность – это именно, что последовательное переключение. Сразу на этот счёт вспоминается Никлас Луман.
Я никогда не заставляю себя делать то, чего мне не хочется. Всякий раз, когда я застреваю, я переключаюсь на что-то другое.
Никлас Луман
Вот и мы как Луман не будем застревать и переключимся на что-то другое)
Небольшая вспомогательная структура
Порой в проекте удобно организовать небольшое закулисье, в котором мы можем сделать какую-то нужную нам работу, но которую не стоит отображать в конечном результате. Для подобных вещей можно использовать, например, вот такой статус "⚙️".
⚙️ в контексте заголовка
Можно, конечно, было без этих пунктов обойтись, но как бы, если я могу себе лишний раз помочь, то почему бы не сделать этого?
⚙️ в контексте callout-блока
Например, можно в callout скрыть ссылки и материалы, которые нам так или иначе помогли.
Также в callout можно свернуть какую-то часть текста, которая нам просто перестала быть нужна.
Быстрый способ вставить статус
Намеренно запоминать статусы весьма скучное занятие, поэтому можно сделать шаблон для templater, который будет выступать в роли подсказки. Шаблон можно повесить на хоткей и при его вызове будет появляться вот такое меню:
подсказка
Далее жмакаете на нужный статус и он вставляется в заметку.
код шаблона для templater
<%*
const statuses = {
'⬛': '⬛ abandoned',
'⚙️': '⚙️ service structure',
'🟥': '👀 | 🟥 todo or queue',
'💡': '👀 | 💡 idea',
'🧠': '🛠 | 🧠 blob or brainstorming',
'🔎': '🛠 | 🔎 aggregation or research',
'🟦': '✍🏻 | 🟦 wip',
'📋': '✍🏻 | 📋 revising or improve structure',
'🖍': '✍🏻 | 🖍 editing or critique',
'🟩': '📨 | 🟩 completed or pending distribution',
'📦': '📨 | 📦 preparation for distribution or compilation',
'📢': '📨 | 📢 distributed',
}
const status = await tp.system.suggester(Object.values(statuses), Object.keys(statuses), true, 'Select status:')
-%><% status %>Для тех кому будет мало и такой автоматизации, есть немного более продвинутый вариант.
Longform-project
С длинными и многосоставными проектами поинтереснее.
Во-первых, полноценную систему статусов я предлагаю использовать только на scenes (посмотрите ещё раз структуру longform-проекта, если забыли что за сцена такая).
Во-вторых, я не вижу ни одной значимой причины для того, чтобы не использовать плагин Longform, хех.
В-третьих, для scene я предлагаю использовать вот такой шаблон:
scene template
<% "---" %>
type: scene
status: 🟥
<% "---" %>
# Preprocessing
## Sources and notes
## Ideas and tasks
# Main textЗадачи выделены в отдельный блок, чтобы их можно было смотреть именно в текущей заметке, а не искать через индексную. Если вы хотите, то можете добавить сюда Dataview-запрос, который собирает задачи из текущей заметки (и который я покажу чуть позже).
Можно также и более короткую версию шаблона использовать:
<% "---" %>
type: scene
status: 🟥
<% "---" %>
# Preprocessing
# Main textПри необходимости мы можем также добавлять драфты в таком стиле:
организация драфтов
# Main text
## Draft 1
text text text
## Draft 2
text text text
## ...Шаблон для scene можно указать в настройках плагина Longform.
выбор шаблона для проекта в плагине Longform
Основная идея в том, что мы теперь формально разграничиваем (на уровне заголовков) процесс исследования и процесс написания конечного текста в рамках одной части проекта. Это по сути значит, что мы можем сначала долго и внимательно поизучать какую-то тему, собрать множество материалов и заметок, провести исследование, наклепать прототипов, сделать нужные нам эксперименты, суммаризировать результаты, а потом на основе всего этого сделать конечную работу (написать конечный текст), причём всё это будет происходить в одной заметке (в одной части проекта).
Потом мы вышенаписанное можем сделать для другой части проекта, потом также для следующей и т.д. В самом конце у нас должен получиться развесистый проект, который будет в себе содержать вообще всё: взаимосвязанные между собой заметки с полезными идеями; источники; правки редактора (если он есть); лог наших действий и размышлений; иллюстрации, схемы, canvases; планы работ по конкретным частям; несколько вариаций (драфтов) текста. Когда нам будет нужно донести свои результаты до других, то мы просто пропылесосим из всех частей проекта полученные результаты и скомпилируем из них конечный продукт.
Вы, наверное, сейчас немного в замешательстве, ибо не понимаете как можно ёмко отразить все сложные процессы исследования, прототипирования, написания и т.п. Вообще говоря... Точно также как и для single-project, только теперь структуру и статусы нам будет отображать плагин Longform:
longform-project
Как настроить такое же отображение будет объяснено далее.
Supercharged links и иконки в плагине Longform
Напомню, что сцену задают вот такие метаданные:
---
type: scene
status: 🟥
---Для того, чтобы у сцены появился статус перед названием заметки, можно использовать Supercharged Links. Чуть позже я покажу, где нам это пригодится. Вы можете вручную сопоставить статус и иконку в настройках плагина. Однако есть немного более автоматизированный способ это сделать. Можно создать сниппет вот с таким содержанием:
supercharged-links-manual.css
.data-link-icon[data-link-type*="scene" i]::before {
content: attr(data-link-status) " ";
}
А вот, чтобы в плагине Longform появилось отображение иконок, придется всё вручную указать (или я просто не понял как это сделать более коротким способом):
longform.css
body {
--longform-status-opacity: 0.3;
--longform-status-padding: 0 2px 0 0;
}
[data-scene-status~="⬛"]::after {
content: "⬛";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="⚙️"]::after {
content: "⚙️";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="🟥"]::after {
content: "🟥";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="💡"]::after {
content: "💡";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="🧠"]::after {
content: "🧠";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="🔎"]::after {
content: "🔎";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="🟦"]::after {
content: "🟦";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="📋"]::after {
content: "📋";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="🖍"]::after {
content: "🖍";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="🟩"]::after {
content: "🟩";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="📦"]::after {
content: "📦";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}
[data-scene-status~="📢"]::after {
content: "📢";
opacity: var(--longform-status-opacity);
padding: var(--longform-status-padding);
}Такую возможность добавили недавно. Кстати, если вы знаете как более ёмко написать сниппет, то напишите об этом в комментариях.
Если вам нужно отобразить иконки с другой стороны, то поменяйте after на before.
Если вы хотите быстро менять статусы у сцен, то есть смысл использовать для этого плагин Metadata Menu. Вроде бы есть даже весьма неплохие гайды на него (гайд 1, гайд 2). Можете также моё демо-хранилище потыкать, ибо там этот плагин используется как основной. Правда не для сцен, но тоже весьма схожих вещей.
Надеюсь, что к данному моменту вы прям прочувствовали всё удобство эмодзи)
Ну, всё. Немного технически подкрутили систему, теперь давайте обсудим ещё один важный процесс.
Как возвращаться к статусам
Идея вот в чём. Если сопоставить статус с какими-то конкретными вопросами, то за счёт этого можно весьма легко и быстро восстанавливать вовлечённость в проект (например, после долгого перерыва).
Логика в общем такая. Вы смотрите на название части проекта и статус, а дальше в соответствии со статусом задаёте себе определённые вопросы.
Preparation 👀
🟥 todo
Есть ли у меня идея (в виде текста, иллюстрации или схемы), которая могла бы ёмко отразить суть того, что я хочу сделать/развить?
💡 idea
(тут всё же придется открыть эту часть проекта и прочитать в чём заключается идея, если мы её изначально забыли)
Появились ли у меня новые мысли или заметки, которые могли бы развить эту идею?
Мне сейчас интересно развивать эту идею дальше?
Preprocessing 🛠
🧠 brainstorming
Могу ли я дополнить или расширить данную часть проекта какими-то новыми идеями или деталями?
Могу ли я уже начать пытаться полноценно раскрывать (превращать во что-то последовательное) найденные идеи?
(Если к этому статусу часть проекта пришла из других более высоких статусов) Могу ли я набросать хотя бы намётки решения, чтобы (продвинуть проект дальше/решить затык)?
🔎 research
Есть ли у меня желание поизучать сторонние или внутренние источники, чтобы найти или добыть нужные мне (знания/решения/случаи/примеры/теории/модели)?
Есть ли у меня желание в том, чтобы (поэкспериментировать/создать прототип(ы)/смоделировать что-либо/верифицировать/суммаризировать результаты своего исследования)?
Processing ✍🏻
🟦 wip
Готов или интересно ли мне развивать дальше эту часть проекта?
Что мне нужно ещё доработать в этой части, чтобы довести до какого-то конечного и логически замкнутого результата? Что мне нужно сделать, чтобы присвоить этой части следующий статус?
📋 revising or improve structure
Есть ли у меня желание заняться вычиткой данной части проекта?
Что я могу отрефакторить, чтобы улучшить конечный результат?
🖍 editing or critique
Что я могу исправить или дошлифовать в этой части проекта?
Эта часть проекта находится в логичном месте или её стоит переместить?
Эта часть проекта (решает поставленные задачи/решает те или иные проблемы/является ли содержательной/имеет логические или фактические ошибки/имеет уникальные или просто полезные результаты/хорошо ли раскрывает те или иные идеи)?
Могу ли эту часть проекта отдать в редактуру или на рецензирование?
Distributing 📨
🟩 completed or pending distribution
Нужно ли эту часть как-то компилировать или подводить под какие-то правила?
📦 preparation for distribution or compilation
Есть ли у меня желание собрать эту часть проекта в конечный вид?
📢 distributed
Я просто красавчик или красавица. Тут без вопросов.
Логику вопросов можно также использовать, когда есть сомнения в том, какой статус стоит присвоить. Типа, например, если часть проекта имеет несколько набросков, то и как бы отрефакторить, дополировать или покритиковать будет нечего. Следовательно можно сразу сказать, что статус будет явно ниже "📋 revising". А там как бы небольшой размах будет из того, что можно выбрать, хех.
Нелинейность как возможность
Помните я в начале сказал, что алгоритм Зонке Аренса не отражает нелинейность написания текста? Вы вероятно могли заметить, что и мой алгоритм лишь отчасти показывает это. Статусы же, естественно, решают эту проблему.
Я для вас ранее уже акцентировал на примере статусов для этой статьи, что даже простой проект может развиваться нелинейно. Однако с помощью статусов можно показать ещё более глубокую нелинейность.
Допустим, что мы дотащили ту или иную часть проекта до "📋 revising". И вдруг так получилось, что на этом этапе мы узнали на сколько много ошибок сделали и вообще какое огромное количество вещей не учли. Также положим, что нам не хватает знаний, чтобы все найденные проблемы решить. Что в таком случае можно сделать? Как вариант сформировать проблемы в виде задач, а сам блок информации пометить, что он теперь на этапе "🔎 research". Тут почему-то мне хочется сказать как в комиксах: "Bam!".
Давайте ещё один пример. Положим, что часть проекта находится на этапе "📦 compilation", т.е. мы прям уже на финишной прямой. Однако, в процессе формирования конечного файла, мы заметили, что у нас какие-то urls битые, а какие-то ссылки (сноски) вообще неправильно оформлены. Что можно сделать? Как вариант оставить задачу в стиле "поправить такие-то и такие-то ссылки" и поставить метку у части проекта, что она теперь на этапе "🖍 editing". Когда будет настроение, мы эти проблемы исправим, а пока что можно отложить процесс компиляции и поработать над другой частью проекта.
Получается идея в том, что статусы можно менять в любом направлении. Нужно накидать каких-то решений? Ставим "🧠 brainstorming". Нужно проверить на ошибки или сделать критический обзор – "🖍 editing". Нужно поработать над самим текстом и его структурой – "📋 revising". Логика, я думаю, ясна.
Дополнительный контекст для задач
Статусы бонусом дают возможность видеть контекст задач. Например
Если задача сейчас находится в месте, где проект "🟦 wip", то это по сути значит, что нам нужно просто продолжать развивать какие-то идеи
Если задача находится в "🧠 brainstorming", то значит нам нужно набросать ещё каких-то идей по какой-то определённой теме или накидать набросок предполагаемого решения
Если на стадии "🔎 research", то вероятно найти или обработать какие-то источники, чтобы решить определённую проблему
Естественно, что тыкать в каждую часть проекта и выискивать в них задачи необязательно. Можно всё собрать в одном месте:
сбор задач из single-project
Т.е. можно в начале проекта агрегировать все задачи из текущего проекта. Мне кажется так делать очень удобно, ибо когда проектов не один, то хочется порой просто пробежаться по определённым проектам, чтобы посмотреть есть ли какие-то проблемы, которые мы можем или хотим решить.
Чтобы получить задачи из текущего файла и чтобы сгруппировать их по заголовкам, можно сделать вот такой Dataview-запрос:
```dataview
TASK
WHERE file.link = this.file.link
GROUP BY meta(section).subpath
```сбор задач из longform-project
Чтобы статус сцены отображался в Dataview-запросе, мы использовали Supercharged Links. Благодаря этому, мы добились, так скажем, единообразия)
Собрать задачи для longform-project можно вот так:
```dataviewjs
const scenes = dv
.pages(`"${dv.current().file.folder}"`)
.where((p) => p.file.link != dv.current().file.link);
dv.taskList(scenes.file.tasks);
```Данный запрос используется в индексной заметке и собирает задачи он из файлов текущей директории (т.е. директории индексного файла).
В качестве бонуса. Если вы хотите сгруппировать сцены по их статусам, то можно это сделать, например, вот так:
группировка сцен по статусам
```dataviewjs
const pages = dv
.pages(`"${dv.current().file.folder}"`)
.where((p) => !dv.func.contains(p.file.link, dv.current().file.link));
const groups = pages.groupBy((p) => p.status);
// определение порядка группировки
const statuses = ["⬛", "⚙️" ,"🟥", "💡", "🧠", "🔎", "🟦", "📋", "🖍", "🟩", "📦", "📢"];
for (
let group of groups.sort(
(a, b) => statuses.indexOf(a.key) - statuses.indexOf(b.key),
)
) {
dv.header(4, "STATUS: " + group.key);
group.rows.forEach((row) => dv.paragraph(row.file.link));
}
```В принципе, при небольшом старании, можно будет вдобавок отобразить задачи из каждой сцены.
Хотел бы подсветить одну важную мысль. Если так получается, что мы какую-то часть проекта понижаем в прогрессе (меняем, например, с "📋 revising" на "🧠 brainstorming"), то нужно прям написать задачу, в которой будет достаточно информации, чтобы понять из-за чего такой downgrade произошёл. Это нужно, чтобы позже не возникло ощущения замешательства, мол почему я сделал так много и вроде даже уже результат есть, а статус находится на уровне "накидывания идей".
Основная цель
Основная цель – завершить проект. Но это как бы и так понятно. Если говорить в рамках статусов, то конечная цель может заключается, например, в том, чтобы сначала довести проект примерно до такого "зелёного" состояния:
🟩 completed
Далее же спокойно компилируются полученные результаты в один общий результат. Ну, а потом каждый двигается кому куда надо.
Мелкие дополнения
Проект может делаться, например, в течение 3-ёх лет, а в конце компилироваться за 2 недели. Вопрос. Есть ли смысл в таком случае оптимизировать процесс компиляции? Это вопрос риторический и адресован он "великим" оптимизаторам (точнее прокрастинаторам).
Напомню, что в Obsidian есть чертовски удобный core-плагин Workspaces. В нём можно сохранять разные конфигурации панелей и открытых заметок. Это прям ужас как сильно оптимизирует многие процессы.
Поощрительная (игровая) составляющая в системе статусов, конечно, присутствует: мол приятно поменять статус с более низкого уровня, на более высокий. Однако всё же основная польза статусов проявляется на больших дистанциях, когда в процессе появляются временные разрывы и из-за которых появляется потребность в восстановлении вовлечённости и прогресса.
Заключение
Что алгоритм Зонке Аренса, что мой алгоритм, что предложенная система статусов не являются достаточно универсальными. Более того, все эти структуры, наверное, с большим трудом или вообще не получится натянуть на ситуации, которые подразумевают сложные коллаборации с другими людьми или предполагают чрезмерно большие и при этом раздробленные (например, на разные отделы) проекты. Такое ограничение проистекает хотя бы из той мысли, что ни алгоритмы, ни статусы не подразумевают какой-то жесткой последовательности или жесткой проверки на соответствие различным стандартам.
Не смотря на то, что статья получилась весьма длинной, я надеюсь, что вы смогли по достоинству оценить лаконичность самого подхода: мы формируем структуру (в виде заголовков в проекте или заметок в плагине Longform) и тут же на эту структуру натягиваем систему статусов. У нас получается сразу и наглядность, которую дают заголовки, и наглядность, которую формируют статусы. Лично у меня такая синергия вызывает только восторг.
Пожалуй, стоит сказать и про сам объём текущей статьи. Во-первых, теперь вы увидели как я пишу подобные статьи и вероятно теперь понимаете откуда берётся объём. Во-вторых, я и хочу, чтобы они были увесистыми, ибо я же пишу как-никак для сурьёзных заметкоделов, хах.
P.S. На статью меня вдохновил непосредственно Зонке Аренс и его алгоритм. Логику статусов же я частично украл из этого хранилища.
На этом у меня всё.
Задать вопрос или как-то расширить эту статью своим комментарием, вы также можете в telegram-канале. Если статья принесла вам пользу и вы в ответ хотите выразить свою благодарность в материальном виде, то можете сделать это вот тут или с помощью кнопки "Задонатить" (смотрите ниже).
