Основная проблема - не всегда понятно, где роль, а где персона. Тем более, для задачи, в которой важна компактность записи.
На самом деле тут отношения есть, я просто не стал их акцентировать. Понятно, что у одной персоны может быть несколько ролей, равно как и, наоборот, одну роль могут играть несколько персон.
В данном случае, на мой взгляд, стоит придерживаться простого правила - если определен человек (например "показать результаты Алисе"), то это персона, если человек не определен и могут быть варианты - это роль ("показать результаты коллеге"). Понятное дело, что тогда задача может уточнятся (т.е. требовать исправления, что плохо, ибо время и переключение контекста), но, мне кажется, это делать необязательно. Все-таки между напоминалкой и педантичным списком задач для беспрекословного исполнения должна быть разница.
Опять же, тонкое деление не однозначно даже для стратегии против тактики.
Ну, на этот счет можно условится жестко. Например, атомарная/рутинная/типовая задача/проект с протяженностью не более двух месяцев - это тактика, комплекс проектов или направлений исследований - стратегия. Для упрощения можно совсем отказаться от использования терминов "тактика" и "стратегия" - толку в них мало.
Это нельзя делать, классификация должна покрывать всё. Иначе вот это будет присвоено 90 процентам записей
Это, увы, нужно, потому что почти всегда есть неопределенность. Разумеется, она имеет свойство уменьшаться (а данные по объекту уточнятся), но надо понимать, что ХЗ - это лишь связка, маячок, а контекст будет раскрываться в других словах.
Но что применение этой сущности должно быть ограничено - согласен. Например, по времени или по допустимым действиям.
Я не вижу различия между последними тремя.
Сделать - это да, повтор "создать", хотя предполагалось, что под сделать имеется ввиду некое относительно атомарное действие вне основных контекстов, например "сделать ТО". Передать - это трансфер между сущностями. "Передать сущность:документ сущность:персона" Повторить - операция над операциями (мы так до функций высших порядков договоримся :)), т.е. повторение уже существующей операции.
И я не уверен в формуле "уничтожить = завершить".
Там не равенства, а инварианты. Я просто поставил их рядом, потому как эти операции обычно завершают некий цикл.
Для правильного интерфейса нужна правильная информационная модель. Нельзя методом дизайна создать что-то удобное, если надо выбирать (не задумываясь) больше чем из семи и выбор не однозначен.
А вот тут позвольте не согласится.
1. дизайн играет не последнюю роль (успех Эппл, например), в деле с TODO, когда альтернатив, мягко говоря, до пояса, наиболее критичным будут аспекты именно быстрого вовлечения, непринужденной работы и последующего привыкания. Скажем так, если пользователю не понравится лук или он будет тратить на внесение заметки более 30-60 секунд - на успех можно рассчитывать, только если доплачивать за использование.
2. как мы знаем, построить идеальную модель все равно не получится (с тем же успехом можно заняться моделированием всего, но это уже экстремизм). Да, мы можем покрыть большинство наших каждодневных задач, но это все равно будет достаточно неполная картина мира. Поэтому я и уточнил, что система должна быть расширяемой и каждый мог ее адаптировать под свой типовой набор действий/сущностей.
3. в моем списке не более 6 пунктов, хоть в сущностях, хоть в операциях. Да, сущности потом требуют уточнения (например, для персоны необходимо будет выбрать из потенциально объемной адресной книги), но это можно сделать в несколько шагов.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2012-02-03 06:09 am (UTC)На самом деле тут отношения есть, я просто не стал их акцентировать. Понятно, что у одной персоны может быть несколько ролей, равно как и, наоборот, одну роль могут играть несколько персон.
В данном случае, на мой взгляд, стоит придерживаться простого правила - если определен человек (например "показать результаты Алисе"), то это персона, если человек не определен и могут быть варианты - это роль ("показать результаты коллеге"). Понятное дело, что тогда задача может уточнятся (т.е. требовать исправления, что плохо, ибо время и переключение контекста), но, мне кажется, это делать необязательно. Все-таки между напоминалкой и педантичным списком задач для беспрекословного исполнения должна быть разница.
Ну, на этот счет можно условится жестко. Например, атомарная/рутинная/типовая задача/проект с протяженностью не более двух месяцев - это тактика, комплекс проектов или направлений исследований - стратегия. Для упрощения можно совсем отказаться от использования терминов "тактика" и "стратегия" - толку в них мало.
Это, увы, нужно, потому что почти всегда есть неопределенность. Разумеется, она имеет свойство уменьшаться (а данные по объекту уточнятся), но надо понимать, что ХЗ - это лишь связка, маячок, а контекст будет раскрываться в других словах.
Но что применение этой сущности должно быть ограничено - согласен. Например, по времени или по допустимым действиям.
Сделать - это да, повтор "создать", хотя предполагалось, что под сделать имеется ввиду некое относительно атомарное действие вне основных контекстов, например "сделать ТО".
Передать - это трансфер между сущностями. "Передать сущность:документ сущность:персона"
Повторить - операция над операциями (мы так до функций высших порядков договоримся :)), т.е. повторение уже существующей операции.
Там не равенства, а инварианты. Я просто поставил их рядом, потому как эти операции обычно завершают некий цикл.
А вот тут позвольте не согласится.
1. дизайн играет не последнюю роль (успех Эппл, например), в деле с TODO, когда альтернатив, мягко говоря, до пояса, наиболее критичным будут аспекты именно быстрого вовлечения, непринужденной работы и последующего привыкания. Скажем так, если пользователю не понравится лук или он будет тратить на внесение заметки более 30-60 секунд - на успех можно рассчитывать, только если доплачивать за использование.
2. как мы знаем, построить идеальную модель все равно не получится (с тем же успехом можно заняться моделированием всего, но это уже экстремизм). Да, мы можем покрыть большинство наших каждодневных задач, но это все равно будет достаточно неполная картина мира. Поэтому я и уточнил, что система должна быть расширяемой и каждый мог ее адаптировать под свой типовой набор действий/сущностей.
3. в моем списке не более 6 пунктов, хоть в сущностях, хоть в операциях. Да, сущности потом требуют уточнения (например, для персоны необходимо будет выбрать из потенциально объемной адресной книги), но это можно сделать в несколько шагов.