Сообщество MLO

Когда-то давно когда земля была еще теплой и по ней бегали динозавры в первых версиях MLO всем хорошо известные контексты назывались местами (Places если быть точным — русскоязычной версии тогда еще не было). Но народ начал использовать их для группировки, помечания задач и проч. непотребств с местами никак не связанными. Поэтому разработчиками было принято волевое решение переименовать Places в толерантное Contexts. И ситуация стала если не выглядеть то хотя бы звучать более-менее логично.
Для обозначения чего используются контексты?
- географических мест (сюрприз!)
- ресурсов: подчиненный Вася, Петя; супермаркет, рынок; интернет (именно для этой категории есть смысл в расписании которое имеют контексты)
- в качестве меток aka Tags
Из сложившейся ситуации возможны два пути:
- оставить винигрет как есть посчитав что внедрение изменений себя не оправдывает;
- разделить контексты так чтобы они более логично отображали суть и свойства задач (возможно не на три а на две части: место-ресурс и тег). в этом случае можно организовать удобный фильтр по тегам. Кстати говоря тема фильтра уже поднималась: Фильтр вместо поиска, но пока не нашла большой поддержки.
А что думаете вы?

Т.к. в данный момент Contexts де-факто используются как Tags, то логичнее было бы сделать из контекстов теги.
Но некоторые теги должны быть предопределенными пользователем для возможности расширеной настройки
(свойства, местоположение и т.д.).

Другими словами объединить функции контекстов и тегов.

Тоже предлагал идею ввести теги, правда параллельно с контекстами (как второй контекст), если память не изменяет где-то в темах по Андроиду Поддерживаю. Гибкость тегов для логики МЛО - почти идеальный вариант. Но удаление контекста как класса мне кажется слишком радикальным. Одно другому не мешает.

Контексты - часть методики GTD. Они бывают:

• времени
• места
• человека

Идея контекста в том, что бы из всего списка задач отфильтровать только те, которые соответствуют вашему текущему контексту (ситуации).

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

meander писал(а):- оставить винигрет как есть посчитав что внедрение изменений себя не оправдывает;

Моё предложение. Выделить в MLO понятие "исполнитель". Остальное оставить как есть.
Или опишите подробнее, в чём вы видите специфику работы с тегами.

P.S. Что бы избежать винегрета названия контекстов начинаю со служебного символа. Так визуально группируются разные типы контекстов/тегов.

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

edw писал(а):Контексты - часть методики GTD. Они бывают:

• времени
• места
• человека

edw писал(а):Моё предложение. Выделить в MLO понятие "исполнитель". Остальное оставить как есть.
Или опишите подробнее, в чём вы видите специфику работы с тегами.
P.S. Что бы избежать винегрета названия контекстов начинаю со служебного символа. Так визуально группируются разные типы контекстов/тегов.

Отвечу с конца: вместо того чтобы делать разделение визуально -- сделать это программно.

По поводу упомянутой методики: мне не понятен смысл контекста-времени. Даже если это просто заданный отрезок времени или фильтр открытых/закрытых часов -- он несет какую-то смысловую нагрузку: это рабочие часы в офисе, часы работы магазина и т.п. То есть мы возвращаемся к понятию ресурса. Единственный спорный пример который я смог придумать -- это контекст "Выходные": это фильтр времени суббота+воскресенье. Но опять же -- он не противоречит концепции ресурса: мне нужны выходные чтобы отремонтировать стол, к примеру.

edw писал(а):Идея контекста в том, что бы из всего списка задач отфильтровать только те, которые соответствуют вашему текущему контексту (ситуации).

На самом деле нужно смотреть шире. Для выполнения задачи (как правило) необходимы определенные ресурсы: для отправки письма с рабочего ящика мне нужен ресурс офис. Если у задачи отправить такое письмо начало пятница 9:00 и окончание воскресенье 21:00 то срок выполения (дедлайн) задачи должен быть пятница вечер если офис закрыт на выходных. И время на выполнение один день а не три. Это пример.

После прочтения Вашей фразы в цитате выше я окончательно понял в чем различие между ресурсами и тегами (за что Вам отдельное спасибо). Ресурсы влияют на видимость задачи в To-Do списке на данном этапе развития MLO; и на планирования задач, как в примере "письмо из офиса" выше, в будущем (я надеюсь).

Теги предназначены исключительно для фильтрации задач (и в Outline и в To-Do, почему нет: отфильтрованное дерево или отфильтрованый список): в несколько кликов получить задачи которые имеют определенный тег или теги. (Или не имеют определенных тегов: использоание условий AND, OR, NOT позволит быстро и гибко отфильтровать задачи)

Подведем итоги. Бывают сны без сновидений но не бывает сновидений без снов

Контексты суть

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

meander писал(а):Контексты суть

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

Если отвлечься от MLO и любого другого софта, то я бы предложил говорить о:

• ресурсах - людях и вещах, необходимых для выполнения той или иной работы,
• контекстах - устоявшемся термине методологии GTD, с которым связан определённый алгоритм автоматического уменьшения списка задач, - "могу делать в данном контексте (ситуации)"
• тегах (метках) - механизм классификации элементов, активно используемый в Веб 2.0 (идея фолксономии)

Обратите внимание на разницу между "необходимо" и "могу" в первых двух вариантах. Иногда говорят о "жёстком" и "мягком" планировании.

Пример различия между ресурсом и контекстом человека:

• Иванов готовит документ - задача которую делает Иванов, выступая в качестве ресурса и которая не должна отображаться в моём списке To-Do (хотя необходима в Схеме)
• передать Иванову документ - это задача которую я могу сделать при условии, что выполняется контекст "Иванов" (он находится рядом)

meander писал(а):По поводу упомянутой методики: мне не понятен смысл контекста-времени. Даже если это просто заданный отрезок времени или фильтр открытых/закрытых часов -- он несет какую-то смысловую нагрузку: это рабочие часы в офисе, часы работы магазина и т.п. То есть мы возвращаемся к понятию ресурса. Единственный спорный пример который я смог придумать -- это контекст "Выходные": это фильтр времени суббота+воскресенье. Но опять же -- он не противоречит концепции ресурса: мне нужны выходные чтобы отремонтировать стол, к примеру.

Я так же активно использую контексты Рутины (Утра, Полудня, Послеобеденная, Вечера, Понедельник - Воскресенье). Например социальные сети - это Рутина Вечера. Желательно просмотреть, но если не сложилось - не беда. Опять же, обратите внимание на различие в постановке акцентов: главное не в том, что бы задача была выполнена, а в том, что бы она не появлялась в списке To-Do в какое-то другое время.

MLO - система управления задачами. Вопросы управления задачами решаются в рамках дисциплин Time Management и Project Management. Преимущество MLO в том, что он лучше других реализовывает "мягкие" методики Time Management ("жёсткие" значительно хуже - интеграции с календарём нет).
С позиции Time Management есть только один ресурс - Вы (ваше время). Методики оптимизируют относительно этого параметра. И, как выяснятся, подход ко времени как к ресурсу (назначение сроков) на уровне отдельного человека работает хуже, чем подход с позиции контекстов (отфильтровывание лишнего). Объясняется это с позиции психологии просто - назначение сроков увеличивает стресс, фильтрация по контекстам его снижает. В греческом языке есть даже два понятие "времени" - кайрос и хронос.

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

Мучаю-мучаю я новый MLO для зеленого робота (впрочем касается и win-версии) и все больше склоняюсь к мысли, что нужно все-таки два контекста. Вернее, имеющиеся сейчас контексты переименовать в ТЭГИ, потому как уже готов весь механизм для работы с ними как с тэгами (множественное назначение, условия поиска, фильтрация, наследование и прочее). А добавить надо именно контексты, причем исключительные, способные принимать только одно ключевое значение. Тогда будет проще реализовать планирование сегодня-неделя-месяц, и меньше будет пунктов перемешиваться в списке контекстов. Достаточно заносить туда исключительное фундаментальное условие - то есть мягкий срок или исполнителя, а все остальное - в тэги. Только предложение тогда придется переделать с "Долой контексты" на "Дайте еще контекстов!" ).

От контекстов не нужно избавляться. Но теги нужны однозначно.
К примеру, я лично использую контекст как указание места. Теги- инструменты. А так сборная солянка получается.
Например, контекст @ДомИнтернет в моём понимании должен быть представлен контекстом @Дом, и тегом "Интернет".

У меня привычка использовать GTD так:
Контекст- место.
Тег- инструмент.
Ресурс- исполнитель.
К примеру, не использовать непонятную конструкцию в качестве контекста @ДомИнтернет, а отдельно контекст @Дом, и тег "Интернет".

Было бы идеальным вариантом. А уж если бы программа умела исполнителя выдёргивать из контактов- вообще мечта.